GitHub Copilotでコードレビューをするときの使い方

GitHub Copilotでコードレビューをするときは、AIを一次チェックに使い、指摘を差分・仕様・テストで人が確かめます。PRのreviewとIDE内のローカル変更reviewでは、利用できる画面や対象が異なります。Copilotのコメントや承認表示だけで、リリース可否を決めないでください。

GitHub公式Docsでは、Copilot code reviewはGitHub.com、CLI、Mobile、VS Code、Visual Studio、Xcode、JetBrains IDEなどで提供されると説明されています。一部機能はplan、組織policy、IDE対応に依存します。手元でどの入口が使えるか、PRとローカル差分で同一機能があるかは、現在のGitHub画面と公式条件を確認します。

レビュー前に差分の目的を書く

AIへPR全体を渡す前に、変更目的、影響する利用者、重要な契約、特に見てほしいriskを書きます。例：「パスワード再設定の有効期限を短縮。期限切れ処理とメール送信を確認。token形式、画面文言、DB schemaは変えていない」。この説明がないと、review指摘を仕様と照らしにくくなります。

diffに無関係な整形や生成物があれば先に分けます。何に対するreviewかが明確になり、関係ない変更を本質的な指摘として扱う危険が減ります。IDEでローカル変更を見る場合は、保存済みdiffか未保存bufferか、機能がどちらを対象にするか確認します。

PR reviewとIDE reviewを分ける

GitHub上のpull requestではCopilotをreviewerに指定し、diffにコメントを受ける方法があります。対応IDEでは、現在の変更を選んでレビューを依頼する経路もあります。出力がPR commentかIDE上の指摘か、対象が選択範囲・作業ツリー・PR全体のどれかは機能ごとに異なるため、画面で確かめてください。

Copilot code reviewは有料Copilotプランで利用できます。さらにCopilot Business / Enterpriseでは、管理者がAIクレジットの従量課金とライセンスなし利用のpolicyを有効にすると、個人ライセンスのないメンバーもGitHub.comで利用できます（IDEは対象外です）。IDEに専用reviewがなければ通常chatで変更点と要件を読ませることはできますが、それを専用機能と同じ動作や保証として扱いません。plan条件は更新されるため、古い価格・利用条件を固定的に書かず公式案内を参照します。

変更riskに合わせて見る範囲を決める

すべての変更を同じ深さで見なくて構いません。表示文言と、権限・決済・個人情報・データ移行では見落としたときの影響が違います。変更fileを機能ごとに分類し、利用者が観測する結果、外部API契約、保存data、認証・認可、失敗時の挙動を確認します。

表は横にスクロールできます

リスク領域	Copilotへ頼む確認	人が確かめること
入力・表示	空値、境界、error表示	実画面と操作
data更新	欠損、重複、競合	schema、migration、復旧
認証・権限	他人の参照・操作	deny条件とtest
外部連携	timeout、retry、二重送信	相手先契約と副作用
料金・決済	金額、通貨、状態遷移	独立した期待値・記録

依頼は「一般的な問題を探す」だけでなく、優先領域を示します。存在しない脆弱性を前提に指摘を作らせず、実害のある候補はfile、line、発生条件、影響とともに示させます。

指摘をコードとEvidenceへ戻す

commentは該当箇所が今回のdiffか、前提とcodeが一致するかを確認します。次に挙動を変える受け入れ条件、呼び出し元、testを読みます。単なる可能性の指摘なら再現条件や実害を調べます。妥当な指摘でも提案patchが安全とは限らないため、適用前にdiffとして確認します。

指摘を「採用」「要調査」「誤検知」に分類すると進めやすくなります。採用したものは最小修正とtestで再確認し、誤検知は理由を残します。同じ指摘が続くなら、repository instructionsやPR説明に不足している設計情報がないか確認します。AIを黙らせるためにコードを複雑にしないでください。

Repository instructionsの使いどころ

Repository custom instructionsは、project固有のarchitecture、test方法、重要な禁止事項を共有する手段です。GitHubが案内する.github/copilot-instructions.md等を利用し、実際のrepositoryに合う短い規則を保ちます。適用対象や読み込み条件は機能ごとに異なるため、全IDE・review経路に同じように適用されるとは決めつけません。

特にpath-specific instructionsが常に効くと期待せず、今回固有の範囲は依頼文にも書きます。秘密情報や顧客dataを指示fileへ貼ってはいけません。指示を追加したら、応答が実際にその規則に沿うか確認します。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  GitHub Copilot

  公式サイトを見るTool詳細を見る

Review effortと大きなPR

GitHubのCode ReviewにはLiteとBalancedのreview effortが案内されています。速度重視の日常変更と、複雑または高riskの変更で使い分けられます。選択値、既定値、適用scopeは製品更新や設定で変わり得るため、画面と公式Docsを確認します。深い設定でも正しさは保証されません。

変更が大きすぎて指摘とcodeの関係が追えないなら、努力levelを上げるよりPRを小さく分ける方が判断しやすくなります。自動reviewの設定や再reviewのタイミングも、repoの運用に合わせて確認します。

人による最終reviewとCI

Copilotの指摘がゼロでも問題なしとは証明されません。要件、data移行順、認可境界、外部service契約など、codeだけでは決まらない事実を人が確認します。CIやtestは同じ条件を再現し、別の方法で回帰を検出します。AIのcommentを受け入れた場合も、修正後のtestとdiffを確認します。

Copilotが「承認可能」と評価した場合も、repositoryの必要承認数やbranch protectionを自動で置き換えるわけではありません。Copilot approvalsは設定・利用状況に依存し、標準ではAI reviewが必須承認に数えられないことがあります。実際のrepository設定を確認してください。

実務用のreview依頼例

「このPRは検索結果の順序を変更します。まずdiffから仕様変更を要約してください。次に空結果、同順位、page境界、未知の値、既存URLへの影響を見て、実害がある候補だけfileとline、発生条件、影響を示してください。提案codeは適用せず、既存testが検証する契約と追加が必要なtestを分けてください。」

この例は出発点です。認証・決済・個人情報では、対象data、権限境界、失敗時の処理を具体的に指定します。差分外の大規模改善や一般論へ広げないよう範囲を決めます。

AIものさしの判断

GitHub Copilot code reviewは、変更の一次screeningと論点の洗い出しに使います。GitHub.comかIDEかで対象と操作が異なるため、手元で使える範囲を確かめます。plan、組織設定、利用経路の条件も確認します。

最終判断は指摘数や承認表示ではなく、要件への適合、riskに対応する根拠、test結果、diffから行います。AIに見つけてほしい問題を具体化し、各指摘をcodeと再現条件へ戻せるときに価値があります。高riskの変更では、人のreviewとCIを省かず、必要ならsecurity担当や仕様決定者へ確認します。

指摘を処理するdecision log

レビュー結果を受け取ったら、各指摘について対象行、前提、実害、対処を短く記録します。採用する場合は、修正と検証testを紐づけます。保留なら何を追加で確認すれば判断できるか、誤検知ならどの仕様やcodeが根拠になるかを残します。この記録があると同じ議論を繰り返さず、reviewを学習可能な工程にできます。

| 判定 | 記録する根拠 | 次のAction |

| --- | --- | --- |

| 採用 | 再現条件と影響 | 最小修正と回帰test |

| 要確認 | 不足している仕様・環境 | ownerや利用条件を確認 |

| 誤検知 | 契約・既存処理・test | 理由を残して閉じる |

一つのPRに多数の指摘がある場合、優先度は発生確率だけでなく、影響範囲と検出しやすさで判断します。低確率でもdata損失や権限漏れにつながる指摘は先に確認します。些細な表記とsecurity riskを同列に並べないことが重要です。

Copilotのレビューで見えにくいもの

差分だけでは判断できない要件、運用手順、顧客との合意、法務上の条件は、AI reviewに期待できません。生成dataの移行手順やrollback可能性も、単体のコードコメントからは分からないことがあります。そうした項目はPR descriptionや別の承認手続きに明示し、必要な担当者が確認します。