1票を持つAIは、審査対象ブランチから指示を読む。GitHub Copilot承認機能の設計と落とし穴

AIレビューは、ついに「参考意見」ではなく、マージを成立させる1票になった。
ところがそのAIは、審査対象であるhead branchからレビュー指示とスキルを読む。
2026年9月1日のGitHub Copilot Code Review更新は、レビュー自動化よりも重要な「誰を信頼主体にするか」という設計変更である。

GitHubは同日、CopilotによるPull Request承認をパブリックプレビューで公開した。管理者が明示的に許可すると、CopilotのApproveレビューを、rulesetやbranch protectionが要求する承認数に数えられる。

これは単にコメント欄へ緑のチェックが増える話ではない。LLMの確率的な判定が、GitHubの決定論的なマージ制御へ接続されたということだ。本記事では、公式Changelogと現行GitHub Docsを基に、その接続点、信頼境界、導入時の安全な切り方を分解する。

結論を先に言うと、Copilot承認は「全リポジトリで人間レビューを置き換える機能」ではない。低リスクな変更パスに限定し、CIや静的解析を別の必須条件として残し、AI向け指示ファイルの変更には人間のCODEOWNERS承認を要求する場合に、初めて扱いやすい。

9月1日に何が変わったのか

従来のCopilot Code Reviewは、既定ではCommentレビューを投稿した。問題点や修正案は示すが、required approvalsの数には入らない。2026年9月1日の更新では、次の2段階が導入された。

1. すべてのCopilotレビューに「承認可能と判断したか」というapproval assessmentを表示する
2. 管理者が有効化した場合だけ、Copilotが正式なApproveレビューを投稿し、その票をマージ要件に数える

この2つは似ているが、セキュリティ上は別物だ。assessmentは観測情報であり、単独ではマージ要件に影響しない。Approveはリポジトリの状態遷移を可能にする入力である。

項目	Approval assessment	CopilotのApproveレビュー
既定状態	全Copilotレビューに表示	無効
required approvalsへの加算	されない	設定次第で1票として加算
主な用途	人間の判断材料	マージゲートの充足
有効化の権限	不要	enterprise、organization、repositoryの管理設定
新しいcommit後	新レビューで再評価	既存承認はdismissされ、再レビューが必要
公開状態	提供中	パブリックプレビュー

対象プランはCopilot Pro、Pro+、Max、Business、Enterprise。GitHubは「既定で無効」と明記し、enterprise、organization、repositoryの3階層で制御できるようにしている。

承認がマージゲートへ届くまで

仕組みを、モデルとGitHubの制御面に分けて考えると理解しやすい。

Pull Request / push
        |
        v
自動または手動のレビュー要求
        |
        v
GitHub Actions runnerで文脈収集・ツール利用
        |
        +--> diff / repository context
        +--> custom instructions / AGENTS.md / skills
        +--> MCP context
        |
        v
LiteまたはBalancedでレビュー・承認判定
        |
        +--> assessmentだけを表示
        |
        `--> 管理ポリシーとpath条件を満たす場合はApprove
                         |
                         v
              required approvalsの1票として評価
                         |
                         v
              CIなど他の必須条件も通ればmerge可能

Copilotのエージェント機能は、GitHub Actions runner上でリポジトリ全体の文脈収集やツール利用を行う。標準のGitHub-hosted runnerが既定で、private repositoryではActions minutesも消費する。GitHub-hosted runnerを組織で無効にしている場合、エージェント機能は限定版レビューへフォールバックする。

モデル処理の費用目安は、公式DocsでLiteが1レビューあたり0.05〜1米ドル相当、Balancedが0.25〜5米ドル相当のAI creditsとされる。Balancedは複雑なロジック、セキュリティ上重要なコード、複数サービスをまたぐ変更を深く見る一方、AI creditsと場合によってはActions minutesを多く使う。金額は固定価格ではなく、PRサイズ、指示、モデル更新で変動する推定レンジである。

最大の逆説: 被審査側がレビュー規則を持つ

GitHub Docsには、見落としやすい重要な仕様がある。Copilot Code Reviewは、custom instructions、agent instructions、agent skillsをbase branchではなくhead branchから読む。

たとえばfeature/paymentをmainへマージするPRなら、レビューに使われるAGENTS.mdや.github/skills/はfeature/payment側の内容だ。GitHubは、指示やスキル自体の変更を同じPRで試せる利点として説明している。

一方、承認をマージ要件へ接続すると、これは信頼境界になる。PR作成者が変更できるブランチに、AIレビュアーの評価規則も置かれるからだ。

ここから「指示を書けば必ず承認を奪える」と断定することはできない。モデル側の固定指示、GitHubのポリシー、レビュー実装の詳細はすべて公開されておらず、公開資料だけでは攻撃成功率を評価できない。ただし、被審査対象と審査ポリシーが同じ変更集合に入る構造は、明示的に管理すべきである。

さらに2026年8月27日の更新で、Copilot Code Reviewはbotが作成したPRを自動レビューできるようになり、非常に大きなPRにも対象を広げた。AIが作った変更をAIが読む経路は現実のものになった。ただし、Copilot cloud agent自身が作成したPRに対するCopilot承認が、あらゆるruleset構成で有効票になるかは今回の公開資料からは確認できない。ここは実環境で検証すべき未確定点として残る。

path globは「AIの職務範囲」を表す

repository管理者は、Copilotの承認をrequired approvalsへ数える対象をfile pathで限定できる。指定できるglobは最大15個で、変更された全ファイルが許可globのいずれかに一致するPRだけが対象になる。1ファイルでも範囲外なら、そのCopilot承認をマージ要件の票として数えない。

論理式にすれば次のようになる。

count_ai_approval =
  enterprise_policy_allows
  AND organization_policy_allows
  AND repository_auto_approval_enabled
  AND every(changed_file matches one_of(up_to_15_globs))

このall-files条件は重要だ。許可対象のドキュメント変更に、認証コード1行を混ぜて承認範囲を拡張する、といった単純な迂回を防げる。path globは単なるフィルターではなく、AIレビュアーの職務記述書として設計すべきだ。

変更領域	Copilot承認を数える判断	理由
docs/**、examples/**	導入候補	影響範囲が比較的限定され、差し戻しやすい
生成済みスナップショット	条件付き候補	再生成チェックをCIで決定論的に検証できる場合
src/**全体	初期導入では避ける	変更の意味と影響範囲が広すぎる
.github/**、AGENTS.md	除外を推奨	レビュー動作、workflow、指示そのものを変えうる
認証、決済、権限、migration	除外を推奨	誤承認時のblast radiusが大きい
secretsやデプロイ設定	除外を推奨	実行環境や資格情報への影響がある

上表の判断はGitHubの公式推奨をそのまま転記したものではなく、公開仕様から導いた実務上の提案である。

安全に導入する5つの制御

1. 最初はassessmentだけを使う

Copilotは承認機能を有効にしなくても、すべてのレビューにapproval assessmentを表示する。まず数週間、AIの判定と人間の最終判断の一致率、見逃し、再レビュー回数を測る。票を与える前に、自分たちの変更分布で性能を評価できる。

2. AIの1票だけでmerge可能にしない

Copilot承認は、テスト、lint、型検査、SAST、依存関係ポリシーの代替ではない。required status checksを残し、機械的に判定できる条件は決定論的な検査へ寄せる。AIには仕様との整合や文脈依存の不具合探索を担当させる。

3. head branch由来の指示を保護する

AGENTS.md、CLAUDE.md、REVIEW.md、.github/copilot-instructions.md、.github/instructions/**、.github/skills/**、MCP設定、Actions workflowをCODEOWNERSの対象にし、人間の承認を要求する。Copilot承認用globからも除外する。

4. pushごとに再レビューする

GitHubは、Copilot承認後に新しいcommitがpushされると、その承認をdismissすると説明している。自動レビューのReview new pushesも有効にし、最後に見たdiffと最後にマージされるdiffを一致させる。branch protection側のstale approval dismissalも併用する。

5. MCPを「追加の証拠」として扱う

Copilot Code Reviewは、issue tracker、ドキュメント、service catalogなどのMCPコンテキストやrepository内のagent skillsを使える。2026年7月29日のGA時点で、レビューからのMCP tool callはread-onlyと説明されている。ただし外部情報が正しいとは限らない。MCPの応答だけを根拠に承認させず、PR内のテストや検証可能なstatus checkへ接続する。

人間レビューとの比較

観点	人間レビュアー	Copilot Code Review
required approvals	通常は1票になる	明示設定時だけ1票になる
判断の再現性	個人差と疲労がある	モデル更新や文脈で変動する
repository文脈	経験と組織知に依存	runnerで収集し、指示・skills・MCPで補う
指示の配置	組織規範やレビュー文化	head branch上のファイルも読む
大量PRへの対応	待ち時間が増えやすい	8月27日から非常に大きなPRも対象
コスト	人件費と待ち時間	AI credits + private repositoryのActions minutes
説明責任	本人とチームに帰属	最終的には有効化した管理者と運用組織に残る

重要なのは「AIか人間か」の二択にしないことだ。レビューは、仕様確認、静的検査、動的テスト、セキュリティ分析、所有者承認という異なる検査の合成である。Copilotに1票を与えても、他の独立した検査まで同じ主体へ集約しない方がよい。

限界と未公開部分

• パブリックプレビューであり、設定項目や挙動は変更されうる
• GitHub自身が、Copilotはすべての問題を発見する保証がなく、出力を人間のレビューで補うよう明記している
• approval assessmentのしきい値、利用モデル、プロンプト、校正データ、誤承認率は公開されていない
• LiteとBalancedの費用は0.05〜1米ドル、0.25〜5米ドルという広い推定幅で、Actions minutesは含まれない
• path globはblast radiusを絞るが、許可範囲内の重大な誤りまでは防がない
• head branchの指示が承認判定へ与える影響の強さは、公開資料だけでは定量化できない
• bot作成PRの自動レビュー対応と承認機能を組み合わせた場合の、全ruleset条件での自己承認防止挙動は明文化が不足している

したがって現時点で測るべきKPIは「コメント数」ではない。人間との判定不一致率、承認後の差し戻し率、見逃した本番障害、path別の誤承認率、1レビューあたり総費用である。

実務への含意

今回の更新で変わったのは、AIの賢さより権限モデルだ。レビューコメントは助言だった。required approvalsに数えられる票は、マージ可能性を変えるcapabilityである。

エージェント設計では、能力と権限を別々に扱う必要がある。Copilotに全コードを読ませること、承認判定を表示させること、正式なApproveを投稿させること、その票をマージ要件に数えることは、4つの異なる権限段階だ。GitHubの3階層ポリシーとpath globは、この段階を分離するための制御面と読める。

最も安全な初期構成は、全PRでassessmentを観測し、AIの有効票は低リスクpathだけに限定し、指示・workflow・認証・決済にはCODEOWNERSによる人間承認を残す形だ。AIをレビュアーに任命するなら、プロンプトより先に職務範囲をコード化する必要がある。

まとめ

• 2026年9月1日、Copilot Code Reviewは設定次第でrequired approvalsを満たすApproveレビューを投稿できるようになった
• assessmentは全レビューに表示されるが、それだけではマージ要件に数えられない
• レビューはActions runnerで文脈を集め、head branch上の指示やskillsも読む
• 管理はenterprise、organization、repositoryの3階層で、repositoryでは最大15個のpath globにより有効票の範囲を限定できる
• 新しいcommit後はCopilot承認がdismissされるため、pushごとの再レビューが必要になる
• 実務では、低リスクpathへの限定、独立したCI、人間のCODEOWNERS承認、指示ファイルの保護を組み合わせるべきである

「AIがコードを読めるか」という問いは、もう半分しかない。残り半分は「AIの判断に、組織が何票を与えるか」だ。

参考リンク

Copilot code review can now approve pull requests（GitHub Changelog、2026年9月1日）

Copilot code review: Resolution reasons and expanded capabilities（GitHub Changelog、2026年8月27日）

Configuring code review by GitHub Copilot（GitHub Docs）

About GitHub Copilot code review（GitHub Docs）

Using GitHub Copilot code review on GitHub（GitHub Docs）

Configuring runners for GitHub Copilot code review（GitHub Docs）

Managing a branch protection rule（GitHub Docs）

Copilot code review: Agent skills and MCP now generally available（GitHub Changelog、2026年7月29日）