GitHub CopilotのAIレビューが「測れる・調整できる」仕組みへ｜2026年7月19日版
GitHubは7月17日、Copilotによるコードレビューとコーディングエージェントの運用機能を拡充しました。重要なのは、AIを導入するだけでなく、リポジトリ単位で効果を測り、実行環境やレビュー方針を調整できるようになったことです。
今回の更新により、管理者は「どのリポジトリでAIがプルリクエストを作成・レビューしているか」をREST APIから確認できます。開発チームは依存関係や専用ツールをレビュー環境へ追加し、ネットワークアクセスも個別に制御できます。
- Copilotの活動をリポジトリ別に取得できるREST APIが一般提供
- AIが作成・マージ・レビューしたプルリクエストを日単位で集計
- コードレビュー専用のセットアップファイルを利用可能
- GitHubホステッドランナーではファイアウォールが標準で有効
AIコードレビューをリポジトリ単位で測定
新しいAPIは、企業または組織の配下にある各リポジトリについて、1日分のCopilot活動を返します。
追加されたエンドポイントは次の2つです。
- 企業向け：
GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD - 組織向け：
GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
レポートには、Copilot coding agentが作成・マージしたプルリクエスト数、Copilot code reviewがレビューしたプルリクエスト数、コメント種別ごとの提案数が含まれます。
従来の組織・ユーザー単位の集計では、利用が活発なチームまでは把握できても、具体的にどのコードベースで成果や負荷が生じているかを追いにくい面がありました。リポジトリ単位になれば、たとえば次の比較が可能になります。
- AIレビューを有効にしたリポジトリと未導入リポジトリの違い
- Copilotが作成したプルリクエストのマージ状況
- レビュー提案が多いリポジトリの言語、構成、開発工程
- 導入支援やルール整備を優先すべきチーム
ただし、件数だけでレビュー品質は判断できません。提案数が多くても、誤検知や軽微な指摘ばかりなら効果は限定的です。マージまでの時間、修正後の不具合、開発者が採用した提案の内容など、チーム側の指標と組み合わせる必要があります。
レビュー前の環境構築を専用ファイルで定義
Copilot code reviewでは、.github/workflows/copilot-code-review.ymlを使ってレビュー実行時の環境を設定できるようになりました。
このファイルには、依存関係のインストール、必要なツールの準備、リポジトリ固有のセットアップ手順などを定義できます。AIがソースコードだけを読んで判断するのではなく、そのプロジェクトを検証できる環境へ近づけられる点が実務上の変化です。
たとえば、生成コードの確認に専用リンターが必要なプロジェクトや、複数パッケージを事前に用意するモノレポでは、レビュー前の準備を明示できます。専用ファイルがない場合は、既存のcopilot-setup-steps.ymlがあればフォールバックとして使われます。
ここがポイント: AIレビューの精度はモデルだけで決まりません。参照できる指示、実行できるツール、依存関係、ネットワーク範囲を整えることが、実用的な指摘につながります。
リポジトリ内の指示をレビューへ反映
カスタム指示の読み取り方も変わりました。Copilot code reviewは、プルリクエストのベースブランチではなく、変更元であるヘッドブランチから指示を読み取ります。
対象には次のファイルが含まれます。
copilot-instructions.md*.instructions.mdAGENTS.md- エージェント用スキル
REVIEW.mdGEMINI.mdCLAUDE.md
これにより、新しいレビュー規約を本番ブランチへ先にマージせず、機能ブランチ上でコード変更と一緒に検証できます。一方、プルリクエストで指示ファイル自体が改変される可能性もあるため、重要なリポジトリではレビュー対象として明示する運用が必要です。
ファイアウォールとランナー設定を分離
GitHubホステッドランナーで動くCopilot code reviewには、ファイアウォールが標準で有効になります。管理者はリポジトリまたは組織の設定から、レビュー中に許可するインターネットアクセスを調整できます。
コードレビューとCopilot cloud agentのランナー設定も分離されました。コードレビューには標準ランナー、より重い自動修正には別のランナーを割り当てる、といった構成が可能です。
注意点は、セルフホステッドランナーでは現時点でこのファイアウォールを利用できないことです。社内ネットワークへ接続したランナーを使う組織は、GitHub側の標準設定に頼らず、通信先、認証情報、実行権限を自社環境で制限しなければなりません。
日本の開発チームが確認すべきこと
今回の更新は、Copilotを試験導入から組織運用へ移すチームに影響します。
開発責任者・管理者
まずCopilot usage metricsポリシーを有効にし、レポートを閲覧する権限を整理します。APIへアクセスできるのは、企業所有者、請求管理者、組織所有者、またはView Copilot Metrics権限を付与されたカスタムロールです。
取得データは評価や監視の件数競争に使うのではなく、導入支援が必要なリポジトリやレビュー工程の変化を見つける材料として扱うのが現実的です。
リポジトリ管理者
導入前に、次の項目を点検してください。
- AIレビューに読ませる指示ファイルと責任者
copilot-code-review.ymlで実行するコマンド- 外部ネットワークへの接続先
- シークレットを渡さずに実行できる構成
- セルフホステッドランナー利用時の通信制御
開発者
レビュー指示を機能ブランチで試せるため、一般論の指摘を減らし、プロジェクト固有の命名、テスト、互換性、セキュリティ要件を反映しやすくなります。ただし、AIのコメントは人間の承認やテストを置き換えるものではありません。
継続ウォッチ
次に見るべきなのは、測定できる範囲と品質評価のつながりです。
- リポジトリ別レポートが管理画面でも可視化されるか
- 提案の採用率や修正結果を追える指標が追加されるか
- セルフホステッドランナーにもファイアウォールが提供されるか
- 指示ファイルの変更を安全に承認する運用が定着するか
今回の更新で、AIコードレビューは単体の支援機能から、設定・実行・測定を伴う開発基盤へ一歩進みました。導入チームが最初に行うべきことは利用件数を増やすことではなく、1つのリポジトリで指示、実行環境、通信制御、評価指標をセットにして検証することです。