GitHub CopilotのPR承認を安全に試す　「AIがApprove」と「人の確認」を分ける導入手順

この記事で分かること

GitHub Copilot code reviewは、Pull Request（PR）に問題点をコメントするだけでなく、設定によっては正式な「Approve」を付け、その承認をマージ要件の一つとして数えられるようになりました。

結論から言えば、最初から全リポジトリで有効にする機能ではありません。安全な始め方は、Copilotの承認を人間のレビューの代替にせず、低リスクなファイルに限った追加ゲートとして試すことです。具体的には、次の順序が適しています。

承認評価だけを表示し、マージ要件には数えない
AIの判断と人間の判断が一致するか記録する
文言修正など低リスクなパスだけで正式なApproveを許可する
必須テストと人間の承認を残したまま、適用範囲を見直す

重要なのは、「Copilotが承認可能と評価した」「CopilotがApproveを送信した」「PRがマージ可能になった」という三つの状態を混同しないことです。AIによるApproveが加わっても、テスト結果、仕様への適合、権限変更の妥当性、運用上の影響まで自動的に保証されるわけではありません。

本稿では、2026年9月21日時点のGitHub公式発表と公式ドキュメントを突き合わせ、設定によって確実に制御できる部分を検証しました。一方、実際の非公開リポジトリでCopilotへレビューを依頼し、指摘精度や見逃し率を測る製品テストは行っていません。そのため、以下では「公式仕様から確認できたこと」「導入環境ごとに試す必要があること」「AI活用ナビとしての推奨判断」を分けて説明します。

なぜ今、PR承認の扱いを決める必要があるのか

GitHubは2026年9月1日、Copilot code reviewがPRをApproveできる機能をパブリックプレビューとして発表しました。公式発表によると、機能は初期状態では無効です。企業、組織、リポジトリの各階層で管理でき、リポジトリでは承認を許可するファイルパスも指定できます。

さらに9月18日にはレビュー画面が更新され、Copilotの現在の評価、使用したレビュー強度、未解決の指摘、前回から解決した指摘、後のレビューで新たに見つかった指摘を概要から追いやすくなりました。これは単なる表示改善に見えますが、実務上は大きな変更です。AIの判定をマージ条件へ組み込むなら、最終結果だけでなく、レビューを繰り返す間に何が見つかり、何が解決され、何が後から追加されたかを追跡できなければならないからです。

公式情報はPR承認機能の発表とレビュー画面改善の発表で確認できます。

これまでのCopilotレビューは、主に人間へ材料を渡す補助機能として捉えられてきました。しかし、Approveが必須承認数に入ると、AIの出力が開発プロセスの「参考情報」から「状態を変える入力」になります。承認数を1件に設定しているリポジトリでCopilotのApproveだけを数える構成なら、AIの判断がマージ可能性へ直接影響します。導入前に必要なのは、レビュー性能の印象評価だけではなく、どこまで権限を与えるかという運用設計です。

最初に分けたい三つの状態

状態	意味	マージ要件への影響
承認評価	Copilotが概要コメント内で「承認可能」と判断する	単独では必須承認数に入らない
CopilotのApprove	設定を有効にした場合にCopilotが正式な承認レビューを送る	算入設定が有効なら必須承認数を満たし得る
マージ可能	承認数、テスト、会話解決、CODEOWNERSなど全ルールを満たした状態	実際のマージ操作へ進める

GitHubの利用手順には、すべてのCopilotレビューに承認評価が含まれる一方、評価だけではマージ要件を満たさないと明記されています。正式なApproveは別の設定です。

この区別が重要なのは、段階導入ができるからです。最初の試行では、承認評価を観察しながら、CopilotのApproveをマージ要件へ数えない状態を維持できます。AIの判断精度を確かめる前に、いきなり本番のゲートを緩める必要はありません。

公式仕様を突き合わせて確認できたこと

今回の確認では、発表ページだけでなく、利用手順、概念説明、管理者向け設定、GitHub rulesetの資料を比較しました。確認結果は次の通りです。

確認項目	確認結果	実務上の意味
初期状態	Copilotによる正式なApproveは無効	管理者が明示的に有効化しない限り、突然AI承認が必須承認数へ入る仕様ではない
設定階層	Enterprise、Organization、Repositoryで制御	上位階層で禁止したまま、一部環境だけに例外を設ける運用が可能
パス制限	リポジトリで最大15個のglobを指定可能	文書やテストデータなど、限定した変更から試せる
パス判定	変更された全ファイルが指定globのいずれかに一致する場合だけ算入	対象内の文書と対象外の本番コードを同じPRへ混ぜる抜け道を作りにくい
新しいコミット	Copilotの承認後に新しいコミットが追加されると承認は失効し、再レビューを依頼できる	古い差分への承認をそのまま使い続けない設計になっている
レビュー強度	LiteとBalancedを選べる	変更の重要度に応じて、速度・消費量と分析の深さを調整できる
自動再レビュー	設定しなければ通常は一度だけ。新しいpushごとのレビューは別途有効化が必要	修正後の差分が自動で再確認されると思い込んではいけない
対象外ファイル	dependency管理ファイル、ログ、SVGなど一部はレビュー対象外	CopilotのApproveが付いても、PR内の全内容を読んだとは限らない
提供状態	Approve機能はパブリックプレビュー	挙動、画面、提供条件が変わる可能性を運用計画へ含める必要がある

設定項目は管理者向け公式手順で確認できます。リポジトリ単位では「CopilotにApproveを許可する設定」と「そのApproveをマージ要件へ数える設定」が分かれています。この二段階を活用すると、正式なApproveは生成させるがマージ条件にはしない、という観察期間も設けられます。

今回の検証で分かった境界

本稿で実施したのは、AIのコード理解力を測る実行テストではなく、公式仕様の整合性を確認する机上検証です。次の四つの場面を設定し、どの制御が働くかを資料間で照合しました。

ケース1：承認評価は出すが、マージ条件には入れない

Approve機能を有効にしない状態でも、Copilotレビューの概要には承認評価が表示されます。この評価だけではrequired approvalsを満たしません。

したがって、最初の検証期間は既存のブランチ保護を変えずに始められます。人間のレビュー後に、Copilotの評価が一致したか、重要な指摘を先に出せたか、誤った指摘がどの程度あったかを記録できます。

確認できた結果：AIの判断を観察するだけの段階と、マージ要件へ組み込む段階は分離できます。

未確認点：実際のコードベースにおける承認評価の精度、言語やフレームワークによる差、評価が変動する頻度は公式仕様だけでは分かりません。

ケース2：文書だけを対象にし、本番コードが混ざったPRは対象外にする

例えば、対象パスを docs/** と *.md に限定します。文書ファイルだけを変更するPRならCopilotの承認を数え、本番コードである src/payment.ts が一つでも含まれれば数えない設計を想定できます。

公式手順では、変更された全ファイルが指定globのいずれかへ一致するときに限って、Copilotの承認をマージ要件へ数えると説明されています。対象ファイルを一つ含むだけでPR全体が許可される条件ではありません。

確認できた結果：パス制限は低リスク領域から試すための有効な境界になります。

未確認点：組織固有のディレクトリ構成で意図した通りにglobが一致するかは、テスト用PRで確認する必要があります。生成物、シンボリックリンク、サブモジュール、リネームを含む変更では特に慎重な確認が必要です。

ケース3：承認後にコードを追加する

CopilotがApproveした後にコミットを追加した場合、その承認は失効し、再レビューを依頼できると公式発表に記載されています。これは承認後の差し替えに対する基本的な防御です。

ただし、「承認が失効する」と「新しい差分が自動的にレビューされる」は別です。Copilot code reviewの概要によると、新しいpushごとの自動レビューを設定していない場合、Copilotは通常、一度だけレビューします。承認が消えた後に誰が再レビューを依頼するのか、あるいは自動レビューを有効にするのかを決めておく必要があります。

確認できた結果：古いCopilot承認を新しいコミットへ持ち越さない仕組みはあります。

未確認点：再レビューの待ち時間、AIクレジット消費、連続pushが多い開発フローでの運用負荷は環境依存です。

ケース4：依存関係ファイルを変更する

公式資料は、package.jsonやGemfile.lockなどのdependency management files、ログ、SVGをCopilot code reviewの対象外例として挙げています。ここは承認機能を使う際の重要な盲点です。

依存パッケージの更新には、既知の脆弱性、破壊的変更、ライセンス、ロックファイルとの整合性など、コード本文とは異なる確認が必要です。Copilotのレビュー結果が良好でも、対象外ファイルに対する検査が完了したことにはなりません。

確認できた結果：CopilotレビューはPR内の全ファイルを必ず読む万能ゲートではありません。

未確認点：対象外ファイルの一覧や扱いは将来変わる可能性があります。導入時には公式資料の現行リストを再確認してください。

安全に試すための4段階

第1段階：観察モードで基準値を取る

最初の20〜30件程度は、Copilotの承認を必須承認数へ数えません。通常の人間レビューと並行して、次を記録します。

人間が重大と判断した問題をCopilotも発見したか
Copilotが承認可能とした後に、人間が差し戻した理由は何か
High、Medium、Lowの重要度が社内基準と一致したか
誤検知の修正にどれだけ時間を使ったか
修正後の再レビューで問題が解決済みと判定されたか
「Previously missed」に後から現れた問題があったか

単純な一致率だけで評価してはいけません。誤った指摘を10件出すことより、認証回避やデータ消失につながる1件を見逃す方が重大な場合があります。問題ごとに影響度を付けて記録してください。

第2段階：低リスクなパスだけで正式なApproveを許可する

観察結果が許容範囲なら、次はREADME、社内手順書、サンプル、翻訳ファイルなど、失敗時の影響が限定される領域を候補にします。

適用候補は、次の条件をすべて満たすものです。

本番挙動を変更しない
誤りを公開後でも容易に戻せる
機密情報や認証情報を扱わない
法務、会計、医療、安全性の判断を含まない
正しさを人が短時間で確認できる
自動テストまたは明確な目視基準がある

反対に、認証・認可、決済、暗号、個人情報処理、インフラ権限、データベース移行、監査ログ、規約本文などは初期対象にしません。

第3段階：AIのApproveだけでマージ可能にしない

Copilotの承認を数える場合でも、人間の承認を残します。例えば必須承認数を2件とし、少なくとも1件は担当チームまたはCODEOWNERの承認を必要とする設計です。

GitHub rulesetの公式資料では、必須承認数、CODEOWNERSによる承認、最新pushを行った本人以外からの承認、古い承認の失効、ステータスチェックなどを設定できます。

推奨する基本構成は次の通りです。

制御	推奨初期設定
Copilot承認	低リスクパスのみ許可
必須承認数	2件以上を検討
人間の承認	CODEOWNERまたは担当チームを必須化
最新変更	最新push後の有効な承認を要求
自動テスト	ビルド、単体テスト、静的解析を必須化
会話	未解決の重要コメントがある状態ではマージしない
管理者の迂回	利用者と条件を限定し、実行を記録

ここでの目的は、AIと人間が同じ役割を二重に行うことではありません。Copilotは機械的な不整合や見落とし候補を広く探し、人間は要求仕様、事業影響、設計意図、例外の妥当性を判断します。

第4段階：月次で一致率と事故予兆を見直す

本番導入後も、対象範囲を自動的に広げないでください。少なくとも次を定期確認します。

Copilot承認後に人間が差し戻した割合
マージ後に発覚した不具合のうち、レビューで検出可能だった件数
Previously missedに分類された重要問題
対象外ファイルを含むPRの件数
再レビューされないまま止まったPRの件数
LiteとBalancedの利用量、所要時間、AIクレジット
パス設定やrulesetを変更した管理記録
パブリックプレビューの仕様変更

「指摘数が増えた」だけでは成功と判断できません。開発者が確認すべきコメントを読まなくなった、AIのApproveが付くまで人間がレビューを始めなくなった、誤検知への対応でリードタイムが伸びた、といった副作用も見ます。

LiteとBalancedはどう使い分けるか

公式資料では、Liteは一般的なバグ、セキュリティ問題、スタイル不整合などを素早く確認する標準レビュー、Balancedは複雑なロジック、セキュリティ上重要なコード、複数サービスにまたがる変更をより深く分析する設定とされています。Balancedはより多くのAIクレジットを使用し、GitHub Actionsの消費もわずかに増える可能性があります。

ただし、Balancedを選べば安全が保証されるわけではありません。これはレビューへ割く推論量の選択であり、人間の業務知識、動的テスト、脅威分析の代替ではありません。

実務では、次のように分けると判断しやすくなります。

文言修正、単純なリファクタリング、定型的なテスト追加：Lite
複数モジュールの変更、状態管理、並行処理、外部API連携：Balanced
認証、権限、決済、個人情報、データ移行：Balancedに加えて専門担当者のレビュー
仕様が曖昧、期待動作をテストで表現できない：AI承認の対象外

レビュー強度は、PRの行数だけで決めないことが大切です。1行の権限条件変更が、数百行のテスト追加より危険な場合があります。

導入時に使える確認チェックリスト

設定前

Copilotの承認評価と正式なApproveの違いを管理者が理解している
現在の必須承認数、CODEOWNERS、ステータスチェックを記録した
Copilot承認を数えても人間の必須承認が残る
最初に対象とする低リスクなパスを列挙した
対象外ファイルを含むPRの扱いを決めた
誤承認または見逃しを記録する場所と責任者を決めた
AIクレジットとActions使用量を確認する担当を決めた

テスト用PR

対象パスだけを変更するPRを作る
対象パスと対象外パスを混在させたPRを作る
意図的に軽微なバグを含むPRを作る
テスト失敗を含むPRを作る
Copilot承認後に新しいコミットを追加する
再レビューが自動または手動で正しく発火するか確認する
Copilotの承認だけでマージ可能にならないことを確認する

運用開始前

本番ブランチへ適用される全rulesetを第三者が確認した
対象globの意味をコード所有者が確認した
緊急停止手順を管理者以外にも共有した
パブリックプレビュー中であることを利用者へ明示した
Copilotのコメントを解決する基準を決めた
監査時に設定変更と承認履歴を追えることを確認した

失敗しやすい点

「Approveが付いたからテスト済み」と考える

Approveはコードレビュー上の判断です。実際の実行結果を示すものではありません。ビルド、テスト、静的解析、セキュリティスキャンは独立した必須チェックとして残します。

承認対象パスを広く指定しすぎる

**のような広い指定から始めると、限定導入の意味がありません。最初は具体的な文書ディレクトリなどから始め、対象を広げるたびにテスト用PRで境界を確認します。

自動レビューと自動再レビューを同じだと思う

PR作成時に一度レビューする設定と、新しいpushのたびに再レビューする設定は別です。修正後も古い結果を見続けないよう、再レビューの発火条件を確認します。

AIの指摘を消せば解決したと考える

9月18日の改善では、概要にOpen、Resolved since last review、Previously missedなどが整理されます。しかし表示上の解決と、テストや仕様確認による実質的な解決は同じではありません。「Won’t Fix」や「Incorrect」とした理由も、人間が追える形で残す必要があります。

人間のレビュー件数をすぐ減らす

観察期間なしに人間の承認を減らすと、効果測定の比較対象も失われます。まず同じPRをAIと人間が独立に確認し、重大な差分を記録してください。

適用しない方がよい条件

次の条件では、CopilotのApproveをマージ要件へ数えない運用が適しています。

一人しかレビューできず、AI承認を加えると実質的に単独マージになる
テストがなく、正しい動作を再現できない
PRが巨大で、複数の目的やサービス変更を含む
規制対象データや人命・健康に影響する処理を扱う
インフラ権限、秘密管理、認証境界を変更する
パスごとの所有者や責任者が決まっていない
誤承認を検知・報告・停止する手順がない
プレビュー機能の変更へ追随できない

これらの領域でもCopilotのコメントを補助情報として使うことはできます。ただし、正式なApproveをマージ条件へ算入することとは分けて判断します。

AI活用ナビの判断

今回の公式仕様確認から、CopilotのPR承認には段階導入に必要な基本部品がそろっていると判断できます。初期状態が無効であること、承認評価だけを観察できること、設定階層が分かれていること、パスを限定できること、追加コミット後に承認が失効することは、安全な試行に有利です。

一方、製品側に制御があることと、自社コードで十分な精度が得られることは別問題です。対象外ファイルもあり、レビュー強度を上げても、仕様の正しさや事業上の妥当性まで保証されません。したがって、現時点で推奨できるのは「AIのApproveで人間を置き換える導入」ではなく、「AIの判定を測定し、低リスク領域に限定して、人間とテストを残したまま追加する導入」です。

導入の成否を分ける指標は、何件のPRを自動承認したかではありません。重大な見逃しを増やさず、人間が設計や仕様の確認へ時間を使えるようになったかです。

確認日と主要な一次情報

本稿の確認日は2026年9月21日です。主に、GitHubが2026年9月1日に公開したCopilotによるPR承認機能の発表、9月18日のレビュー画面改善、同日時点のGitHub Docsにある利用手順、設定方法、code reviewの概念説明、rulesetの仕様を確認しました。

CopilotのApprove機能は確認日時点でパブリックプレビューです。実際に導入する日には、Copilot code reviewの概要と設定手順を再確認し、テスト用リポジトリまたは低リスクなリポジトリから始めてください。

PRIMARY SOURCES