GitHub Copilotコードレビューを調整しやすく。指示・準備・通信設定をリポジトリごとに確認

何が発表されたか

GitHubは2026年7月17日、Copilot code review をリポジトリの事情に合わせて調整しやすくする更新を案内しました。Copilot code review は、プルリクエスト（変更提案）をAIに読んでもらい、気になる点や直し方の候補を出してもらう機能です。今回の更新では、AIへ渡す指示、レビュー前の準備、ネットワークへのアクセス、実行環境を、より分けて設定できるようになりました。

わかりやすい変更の1つは、AIが読む指示ファイルです。これまでも copilot-instructions.md などを使えましたが、今回からはプルリクエストの変更先ブランチにある指示を読めるようになりました。たとえば「この画面では専門用語を避ける」「変更後は必ずテストを確認する」といったチームの約束を、まだ公開前のブランチで試せます。REVIEW.md、GEMINI.md、CLAUDE.md も読み取り対象に加わりました。

さらに、.github/workflows/copilot-code-review.yml でレビュー専用の準備手順を決められます。必要な依存関係を入れたり、確認用の道具を動かしたりするための入口です。ネットワーク通信を制限するファイアウォールは既定で有効になり、コードレビューとクラウドエージェントの実行環境も別々に選べるようになりました。

初心者に何がうれしいか

初心者にとってAIレビューが難しく感じる理由は、「何を見てほしいか」をAIにうまく伝えにくいことです。一般的な指摘だけでは、プロジェクト独自のルールや、初心者向けの書き方まで見てもらえません。指示ファイルを置けると、毎回チャットで説明しなくても、チームで決めた見方をAIへ渡しやすくなります。

また、いきなり会社全体のルールを変えず、1つの変更ブランチで試せるのも安心です。AIの指摘が厳しすぎる、逆に見てほしい点を見落とす、といった場合は、指示を短く直して再度レビューできます。人のレビューを置き換える機能ではなく、「確認する観点をそろえる下書き役」と考えると使いやすいでしょう。

ネットワークを制限した状態でレビューを動かせる方向になったのも、仕事で使うときの小さな安心材料です。ただし、どこまで通信が必要か、セルフホスト型ランナーでは同じ設定が使えるかなどは環境で変わります。便利さと権限は、別々に確認するのが大切です。

まず試すなら何をするか

最初は、影響の小さいリポジトリで、短い指示を1つだけ試しましょう。たとえば「日本語の画面文言は、専門用語を言い換える候補も出してください」「変更した箇所に対応するテストがあるか確認してください」のように、答え合わせしやすい内容がおすすめです。指示が長すぎると、何が効いたのか分かりにくくなります。

次に、レビュー結果を人が3回ほど読み、「役に立った指摘」「不要だった指摘」をメモします。そのメモをもとに、指示を1行ずつ足したり外したりすると、自分たちに合うレビューの形を見つけやすくなります。準備用の設定ファイルやランナー設定は、慣れてから管理者と一緒に触れば十分です。

注意点

AIのレビュー結果は、正しそうに見えてもそのまま採用しないでください。プロジェクトの背景、利用者への影響、セキュリティ、動作確認は人が最後に判断します。特にレビュー用の準備手順へ秘密情報を渡す場合、誰が見られるか、実行ログに残らないかを先に確認しましょう。

2026年7月17日時点で、ファイアウォールは既定で有効と案内されていますが、セルフホスト型ランナーは対象外です。使えるプラン、権限、設定画面、対応する実行環境は今後変わる可能性があります。導入前にはGitHub公式の最新ドキュメントと、組織のセキュリティルールを確認してください。