GitHub Copilotの提案を採用する前に見る点:補完・チャット・エージェント別の確認項目

三つの使い方の違いを一枚で見る

下の表は、公式資料の記述をもとにした編集上の整理です。

• 補完、提案が届く単位：行・コードブロック・既存コードへの編集、人が確認する範囲：提案された全変更と、その前後のコード、最初に見る点：意図との一致、型・境界条件
• チャット、提案が届く単位：回答内のコードと説明文、人が確認する範囲：回答全体と、貼り付け先との整合、最初に見る点：説明の裏取り、存在しないAPIの有無
• エージェント、提案が届く単位：ブランチ+PR(複数ファイル)、人が確認する範囲：差分全体、テスト結果、ワークフロー、最初に見る点：依頼範囲を超えた変更、権限・秘密情報

三つに共通するのは、公式のベストプラクティスが挙げる観点です。機能面だけでなく、セキュリティ、可読性、保守性を見ること。そして自動テスト、リンター、コードスキャンを併用することです。以降のチェックリストはこの観点を、使い方ごとの範囲に当てはめたものです。

補完:一つずつ受け入れる前に見る点

補完は小さな提案なら、Tabキーで簡単に採用できます。そのぶん「見たつもり」で通しやすいのが弱点です。インライン提案の資料には、有効に見えても構文や意味が正しくないコードを出すことがあること、扱いが難しい構造やマイナーな言語では質が下がりうることが書かれています。

補完の確認チェックリスト

• [ ] 提案を一度読み、何をしているか自分の言葉で言えるか
• [ ] 変数名・関数名・引数の順序が、このファイルの既存コードと一致しているか
• [ ] 境界条件(空配列、null、0件、タイムゾーンなど)の扱いが意図どおりか
• [ ] 設定値、URL、鍵のような文字列が埋め込まれていないか(説明用のダミーに見えても本物の可能性があります)
• [ ] 公開コードとの一致を検出する設定(ブロックまたは出典表示)を、組織の方針に合わせて把握しているか
• [ ] 採用後、そのファイルのテストかリンターを一度走らせたか

補完では、確認範囲を広げすぎないことが現実的です。数行ごとに全体を読み直す必要はありませんが、関数一つ分を補完でまとめて受け入れた場合は、チャットやテストで挙動を確かめる側に切り替えてください。

チャット:回答を貼り付ける前に見る点

チャットは回答に説明が付くため、正しそうに見えやすい使い方です。Copilot Chatのアプリケーションカードでも、もっともらしいが意味的・構文的に正しくないコードが出る可能性や、機密情報や脆弱性を含みうることが挙げられています。ここでは、コードだけでなく説明文も確認対象に含めます。

チャットの確認チェックリスト

• [ ] 回答が前提にしているバージョン・ライブラリが、自分のプロジェクトと合っているか
• [ ] 回答中の関数名やオプションが実在するか(公式ドキュメントか型定義で確認)
• [ ] 説明文の主張と、コードの実際の動作が食い違っていないか
• [ ] 回答が触れていない副作用(DB更新、ファイル削除、外部通信)がないか
• [ ] 貼り付け先の既存の命名や例外処理の流儀に合わせたか
• [ ] 渡した情報に、実在の鍵・個人情報・顧客データを含めていないか

公式のベストプラクティスは、コンテキストとして関連ファイルを開き、不要なファイルは閉じること、大きなタスクを小さな依頼に分けることも勧めています。確認しやすい回答を得るための入力でもあります。

依頼文の例(説明用の例です。実際に実行した結果ではありません)

次の関数に、空配列と重複IDの場合の処理を追加してください。
- 既存の関数シグネチャは変えない
- 変更した行と、変えなかった行を分けて説明する
- 追加した分岐ごとに、確認用のテストケースを1つずつ示す
- 自信がない前提(ライブラリのバージョンなど)があれば最初に列挙する

「変更した行と変えなかった行を分ける」「前提を列挙させる」の二点で、人が見る範囲が狭まり、裏取りの対象も明確になります。

エージェント:PRをマージする前に見る点

エージェントは、調査、計画、複数ファイルの編集、テストやリンターの実行まで進め、結果をブランチとPRにまとめます。GitHub上のCopilotに関する概要によると、GitHub Actionsで動くセッションでは、変更できるのはタスク開始時に指定した1つのリポジトリに限られ、実行時間の上限は59分です。クラウドサンドボックスでは複数リポジトリを扱えます。どちらの環境でも、同時に扱えるブランチは1つで、1タスクにつき作成できるPRは1つです(2026年10月30日に確認した記述で、将来変わりえます)。利用できるプランや組織ポリシーは契約によって異なるため、自分の環境で確認してください。

Copilot Agentsのアプリケーションカードによれば、クラウドエージェントはデフォルトブランチに直接プッシュできず、copilot/ブランチなどに限られます。エージェントが起こしたPRで動くActionsワークフローは、書き込み権限のあるユーザーの承認が必要です。コミットには署名があり、セッションログへのリンクが付きます。こうした仕組みはありますが、同じ資料で、クラウドエージェントが生成するコードにも誤りや脆弱性がありうるため、マージ前にレビュー・テストすべきだと述べられています。マージ判断は人が行う前提で、次を見ます。

エージェントの確認チェックリスト

• [ ] 依頼に書いた範囲を超えたファイルが変更されていないか(差分のファイル一覧から確認)
• [ ] 削除された行、テストの削除・スキップ化、閾値の緩和がないか
• [ ] 依存パッケージの追加・更新と、設定ファイル、CI定義の変更がないか
• [ ] セッションログで、何を実行して何が失敗したかを確認したか
• [ ] 自分の手元(またはCI)でテストを実行し、エージェント報告と一致したか
• [ ] ワークフローを承認する前に、変更されたワークフロー定義と参照先を読んだか
• [ ] 秘密情報、個人情報、社内URLがコードやログに残っていないか
• [ ] PR説明の主張を、差分と照合したか(説明が実態と違うことがありえます)

依頼文の例(説明用の例です。実在するリポジトリではありません)

Issue「請求書一覧の日付が日本時間で表示されない」を修正してください。
範囲:src/invoices/ 配下のみ。他のディレクトリは変更しない。
禁止:依存パッケージの追加、CI設定の変更、既存テストの削除・無効化。
完了条件:新しいテストを1つ追加し、既存テストがすべて通ること。
PRには、変更ファイルごとの理由と、確認できなかった点を書いてください。

範囲と禁止事項を先に書いておくと、レビュー時に「依頼どおりか」を差分と突き合わせやすくなります。依頼文に書いた制約は、守られたかをチェックリストで確かめる対象でもあります。

範囲が広いほど、人が先に決めておくこと

三つの使い方の違いは、確認の手間が増える順番でもあります。編集上の提案として、使い分けの目安を挙げます。

• 書く内容が頭にあり、入力を省きたい、向きやすい使い方：補完、理由：差分が小さく、その場で確認できる
• 知らないAPIや書き方を調べたい、向きやすい使い方：チャット、理由：説明と根拠を要求でき、裏取りもしやすい
• 範囲が明確でテストがある定型作業、向きやすい使い方：エージェント、理由：完了条件を機械的に確認できる
• テストがなく、影響範囲が不明な変更、向きやすい使い方：補完・チャットで小さく、理由：エージェントの結果を自動で検証しにくい

エージェントに任せる前に、次の三点を決めておくと確認が楽になります。

1. 完了条件を機械で判定できるか(テストやリンター)。なければ先に用意するか、小さな依頼にします。
2. 変更してよい範囲を依頼文に書いたか。
3. 誰がマージを承認するか。依頼者本人が見る場合も、チェックリストを使って「読んだ」を記録します。

補完とチャットでは、見る単位を「提案」に置きます。エージェントでは見る単位が「PR」に変わります。この切り替えを意識すれば、同じ「提案を確認する」でも、見落としやすい箇所を絞れます。