AIにコードを書かせるだけでは、開発は完了しない
GitHub CopilotをはじめとするAIコーディングエージェントは、機能追加やバグ修正の実装を大きく効率化します。一方で、AIが生成したコードをそのまま受け入れてよいわけではありません。
重要なのは、AIにコードを書かせることではなく、何が変わり、実行でき、実際に期待どおり動くのかを人間が検証したうえで採用することです。
GitHubが紹介したCopilotアプリでは、この検証に必要な3つの機能がパネルとして統合されています。
diffパネル：コードの変更内容を確認する- ターミナルパネル：コマンドを実行して動作を確かめる
- ブラウザパネル：WebアプリなどのUIを実際に操作する
これまでエディタ、ターミナル、ブラウザを切り替えて行っていた作業を、Copilotアプリ内で連続して進められる点が特徴です。
変更内容をdiffで確認する
AIエージェントに機能追加を依頼した後、最初に確認したいのは「どのファイルに、何が追加・削除されたのか」です。Copilotアプリのdiffパネルでは、変更前と変更後の差分を確認できます。
一般的なdiffと同様に、追加された行は緑、削除された行は赤で表示されます。ファイル全体を読み直さなくても、変更箇所に集中してレビューできるのが利点です。
レビューでは、単にコードが動きそうかを見るだけでなく、次の観点を確認すると効果的です。
- 依頼していないファイルまで変更されていないか
- 既存の仕様や命名規則に沿っているか
- エラーハンドリングや入力値の検証が抜けていないか
- 不要な依存関係や設定変更が追加されていないか
- テストやドキュメントへの影響がないか
内容に問題があれば、変更を受け入れる前にコメントを残したり、Copilotに修正を依頼したりできます。つまり、AIの出力を一度受け取って終わるのではなく、差分を起点に対話しながら品質を高める流れを作れます。
ターミナルで「実行できるか」を確かめる
コードを読むだけでは、ビルドエラーや依存関係の問題、実行時の不具合までは分かりません。そこで次に使うのがターミナルパネルです。
Copilotアプリでは、セッション内からプロジェクトのコマンドを実行できます。たとえばWebサイトであれば、クライアント側のディレクトリへ移動して開発サーバーを起動するスクリプトを用意し、Runボタンから実行できます。
例として、プロジェクトのスクリプトが次のような処理を行うケースを考えます。
cd client
npm run dev
実際のコマンドやディレクトリ構成はプロジェクトによって異なりますが、ポイントは、AIが変更したコードをプロジェクト本来の手順で起動して結果を確認することです。
ターミナルでは、次のような確認ができます。
- ビルドやテストが成功するか
- 開発サーバーが正常に起動するか
- コマンド実行時に警告やエラーが出ていないか
- 変更によって既存機能が壊れていないか
- 複数のプロセスを動かす必要があるか
複数のターミナルを開いて切り替えられるため、開発サーバーを起動したまま、別のコマンドを実行するといった使い方もできます。
ブラウザで「実際に動くか」を確かめる
ビルドが成功しても、ユーザーが期待する操作を実行できるとは限りません。UIを持つアプリケーションでは、ブラウザ上で実際に画面を確認することが重要です。
Copilotアプリのブラウザパネルを使えば、起動したWebアプリを同じアプリ内で開き、追加した機能を操作できます。画面のレイアウト、ボタンの挙動、入力フォーム、エラーメッセージなどを目視で確認できます。
さらに、Pick & Polishツールを使うと、画面上の要素を選択して、その部分の調整をエージェントに依頼できます。たとえば、次のような改善を行う場面が考えられます。
- ボタンの余白や配置を調整する
- 見出しや説明文の表示を変更する
- 選択したコンポーネントのスタイルを修正する
- UI上の不自然な表示を改善する
修正後は開発サーバーを再実行し、ブラウザで変更結果を確認します。この反復によって、コード上の修正と画面上の結果を結び付けながら作業できます。
3つのパネルが作る「AIコーディングの検証ループ」
Copilotアプリの構成を、開発フローとして整理すると次のようになります。
- AIエージェントに機能追加や修正を依頼する
- diffパネルで変更されたファイルとコードを確認する
- ターミナルパネルでビルド、テスト、開発サーバー起動などを実行する
- ブラウザパネルでユーザー操作を再現する
- 問題があればAIに修正を依頼する
- 再度diff、実行、ブラウザ確認を行う
- 問題がなければ変更を受け入れ、プルリクエストを作成する
この流れで特に重要なのは、検証を一度で終わらせないことです。AIによる修正を重ねるたびに、差分と実行結果を見直す必要があります。
エディタ、ターミナル、ブラウザを行き来する従来の開発でも同じ確認は可能ですが、作業場所が分散すると、確認漏れやコンテキストの喪失が起きやすくなります。関連する情報を横並びで扱えることは、初心者だけでなく、複数の作業を並行して進めるエンジニアにとっても意味があります。
AI生成コードを受け入れる前のチェックリスト
AIエージェントが作成した変更をマージする前に、最低限次の質問に答えられる状態にしておくとよいでしょう。
1. 何が変わったのか
- 変更されたファイルを把握しているか
- 追加・削除された処理の目的を説明できるか
- 依頼内容と関係のない変更が混ざっていないか
2. 実行できるのか
- ビルドや必要なコマンドが成功したか
- テストを実行したか
- 実行時のエラーや警告を確認したか
3. 本当に動くのか
- 主要なユーザー操作を実際に試したか
- 正常系だけでなく、入力ミスや空データも確認したか
- 既存機能に影響が出ていないか
この3段階は、AIツールの種類にかかわらず利用できる基本的な考え方です。Copilotアプリのdiff、ターミナル、ブラウザパネルは、それを一つの作業環境で実践しやすくするものと位置付けられます。
チーム開発で考えるべきこと
AIによる実装速度が上がるほど、レビューの役割は重要になります。コード生成が速くなっても、仕様判断やリスク判断まで自動的に正しく行われるとは限りません。
テックリードや開発マネージャーが導入を検討する場合は、ツールの利用方法だけでなく、受け入れ基準も合わせて決める必要があります。
- AIが変更したコードも通常のコードレビュー対象にする
- プルリクエストには変更目的と検証手順を記載する
- 自動テストと手動確認の役割を整理する
- 本番環境に影響する変更は追加レビューを求める
- 秘密情報や機密コードを扱うルールを定める
Copilotアプリはレビューからプルリクエスト作成までの作業を効率化しますが、最終的な採否の判断を自動化するものではありません。人間が変更内容と検証結果に責任を持つという原則は変わりません。
「生成」から「検証込みの開発」へ
AIコーディングエージェントの活用で成果を出すには、プロンプトの工夫だけでなく、生成後の確認プロセスを設計することが欠かせません。
GitHub Copilotアプリの新しい体験が示しているのは、AI開発の中心が「コードを生成すること」から、変更をレビューし、実行し、実際の動作を確認してから安全に採用することへ移っているという点です。
まずは小さな機能追加を題材に、次のループを実践してみるとよいでしょう。
diffで変更範囲を読む- ターミナルでビルドやテストを実行する
- ブラウザでユーザー操作を確認する
- 問題があれば修正し、再び検証する
AIに任せる範囲を広げるほど、人間が確認すべきポイントを明確にすることが重要になります。何が変わったか、実行できるか、実際に動くかを確認する習慣が、AIを活用した開発を速さだけでなく安全性の面でも実用的にします。
出典： GitHub Blog