GitHubは2026年9月1日、GitHub Copilot code reviewがプルリクエスト（PR）の承認を提出できる機能を発表しました。CopilotがPRを承認できる機能は公開プレビューで、Copilot Pro、Pro+、Max、Business、Enterpriseの各プランで利用できます。
これまでのCopilotレビューは、指摘や判断をコメントとして返す使い方が中心でした。管理者が設定を有効にすれば、Copilotの承認をリポジトリの必要承認数に算入できます。AIレビューを補助にとどめるか、マージ条件の一部にするかを、管理範囲とファイル単位で設計できるようになった点が変更です。
ただし、レビュー概要に表示される「approval assessment」は、承認そのものではありません。新しいコミットが入れば承認は失効するため、対象を絞り、人間レビューやCI/CDの必須チェックと組み合わせる運用が欠かせません。
※本記事は2026年10月14日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
GitHub CopilotのPR承認とは｜評価表示と実際の承認は別
GitHub Copilot code reviewは、PRの差分を確認し、問題点や修正案をコメントする機能です。2026年9月1日の変更後は、すべてのCopilotレビューの概要コメントにapproval assessmentが含まれ、CopilotがPRを承認できる状態と判断したかを示します。
ここで注意したいのが、approval assessmentとApproveレビューの違いです。assessmentはCopilotの判断を表示する情報であり、それだけではマージ要件に必要な承認数に数えられません。既定のCopilotレビューもCommentで、ApproveやRequest changesではありません。
管理者が承認機能を有効にすると、CopilotはApproveレビューを提出できます。さらに、Copilotの承認を必要承認に数える設定を有効にした場合、そのPRはリポジトリの承認ルールを満たす対象になり得ます。二つの設定を分けて確認することが、導入時の最初のポイントです。
AIが生成するコードの量が増えるほど、レビュー担当者がすべての差分を読む負荷も増えます。レビューの詰まりや役割分担は、AI生成コード時代のコードレビューでも扱われています。Copilot承認は、その負荷を減らす一手ですが、判断の根拠を人間が確認する責任まで消すものではありません。
ポイント
approval assessmentは「承認してよいか」という評価表示で、必要承認を満たすApproveレビューとは別物です。現在の設定がCommentだけなのか、承認を提出できる状態なのかを分けて確認します。
必須承認に数える設定｜Enterprise・Organization・リポジトリで制御
Copilotの承認設定は、Enterprise、Organization、リポジトリの3段階です。Enterprise管理者は「Organizationに判断を委ねる」「選択したOrganizationだけ有効」「全体無効」の3つから選択できます。Organization管理者が選ぶ項目は、全体有効、リポジトリへの委任、選択リポジトリのみ有効、全体無効の4つです。
リポジトリの設定では、少なくとも二つの項目を分けて確認します。一つは「Copilotに承認レビューを提出させる」設定、もう一つは「Copilotの承認をマージ要件に数える」設定です。前者だけを有効にしても、Copilotの承認は必要承認数には入りません。
設定変更前は、対象ブランチのrulesetを確認しておきましょう。必要承認数や対象ブランチ、新コミットで古い承認をdismissする条件を突き合わせ、Copilot承認の対象PRを決めます。全社一括ではなく、検証用か限定したリポジトリから始める方が、想定外のマージを見つけやすくなります。
設定の適用範囲は、管理者の権限だけで決まりません。Organization全体の方針が「無効」であれば、リポジトリ管理者が個別に有効化することはできません。逆に、Organizationが判断を委ねているなら、リポジトリごとに対象ブランチと運用責任者を明確にします。
ポイント
Enterpriseからリポジトリまで、上位方針と下位設定の両方を確認します。承認レビューの提出許可と、必要承認への算入は別のスイッチです。
任せる範囲を絞る｜ファイルパスとレビュー強度を組み合わせる
Copilotの承認を数える対象は、リポジトリ全体に広げる必要はありません。リポジトリ設定ではファイルパスのglobを指定でき、PRで変更されたすべてのファイルが、指定したglobのいずれかに一致する場合だけ、Copilot承認をマージ要件に算入できます。指定できるglobは最大15個です。
この条件は、PRの一部だけが対象になる仕組みではありません。対象外のファイルが一つでも混ざれば、PR全体が算入対象から外れるためです。たとえば、低リスクなドキュメントやテスト補助コードから始める場合は、対象globと混在PRの扱いを先に決めておきます。
レビュー強度も個別に選択可能です。Liteは標準的なレビューです。Balancedでは、複雑なロジック、セキュリティに関わるコード、複数サービスにまたがる変更をより深く分析します。BalancedはLiteより多くのAIクレジットを使う可能性があります。
2026年9月28日から、設定がDefaultの場合の組み込み既定値はBalancedです。Liteを明示していた設定は維持されます。対象範囲を狭く始めても、レビュー強度が意図せずBalancedになっていないか、クレジット消費とレビュー時間を確認してください。
| Copilotレビューの状態 | レビュー結果 | 必須承認への算入 | 向いている運用 |
|---|---|---|---|
| 既定状態 | Comment／approval assessment | 算入されない | AIの指摘を人間が確認する補助レビュー |
| 承認を許可 | Approveを提出できる | 算入設定がなければ算入されない | 検証環境・限定リポジトリ |
| 承認を許可＋必須承認に算入 | Approveを提出できる | 必要承認を満たす対象になり得る | 対象ファイルと例外ルールを定めた運用 |
| 新コミット後 | 既存承認がdismiss | 再レビュー・再承認が必要 | 差分更新後の再確認を必須にする運用 |
Copilot approvalsはpublic previewで、仕様変更の可能性がある点に注意が必要です。ファイルパス、レビュー強度、クレジット、設定変更者を記録すれば、本番移行を判断しやすくなります。
承認後も確認が必要な理由｜新コミットで承認は失効
CopilotがApproveレビューを提出した後に新しいコミットが入ると、承認は人間のレビューと同様にdismissされる仕組みです。承認済みの表示だけでマージへ進むと、後から変わった差分を見落とします。
変更後はCopilotへ再レビューを依頼し、新しい承認を取り直す流れです。自動レビューのrulesetでReview new pushesを有効にすれば、PRへの新しいプッシュごとに再レビューを依頼できます。有効にしない場合、自動レビューはPRごとに原則1回で、再レビューは手動です。
再レビューの自動化は便利ですが、確認を自動化したことと、変更内容が安全だと証明したことは別です。Copilotのレビューを監視・評価するログや担当を決める際は、AIエージェントの可観測性を扱ったAgentOpsの考え方も参照するとよいでしょう。
承認後の再確認では、少なくとも変更されたファイル、テスト結果、セキュリティチェックの結果を確認します。権限やデータ処理に触れる変更が混ざった場合は、ファイルglobの条件を満たしていても、人間の承認を追加する例外ルールが必要です。
ポイント
Copilot承認は新コミットで失効します。自動再レビューを使う場合も、差分・テスト・セキュリティ結果の確認者を残し、Approveの存在だけをマージの根拠にしないでください。
導入前に決めること｜AI承認と人間レビューの境界
Copilot承認を導入する前に、どのPRをAIだけで承認できる状態にするかを決めます。低リスクの変更から始める場合でも、対象リポジトリ、対象ブランチ、ファイルglob、レビュー強度、例外時の責任者を一つの運用表にまとめておきましょう。
重要ブランチでは、GitHubの公式ガイドが示すように、PRと少なくとも1件の承認を必須にするrulesetを設定します。CODEOWNERSによるレビュー要求、CI/CDの必須チェック、コードスキャン結果の必須化も、Copilot承認とは別の統制として残します。
- 対象を分ける：ドキュメントや限定されたテスト補助コードと、認証・権限・本番設定・個人情報処理を同じ扱いにしない。
- 人間の責任者を置く：AI承認を算入しても、例外PRを止める担当者と、最終的なマージ判断者を決める。
- 変更後の確認を残す：新コミットで承認がdismissされること、再レビューとCI結果がそろうことをチェックする。
- プレビューとして評価する：仕様変更時の停止・設定変更・ロールバック手順を用意し、監査記録を残す。
AIにどの権限と変更範囲を任せるかは、レビュー設定だけの問題ではありません。AIエージェントの権限管理を扱った非人間IDのように、誰の資格で何を実行し、どのログを残すかを分けて考えることが大切です。
最初の検証では、Copilot承認を算入しない状態でレビュー結果を記録し、指摘の種類、再レビューの頻度、担当者の確認時間を測ります。その後に対象ファイルを限定して算入を有効にし、マージ後の不具合や例外の発生を確認します。公開プレビューを全社標準にする判断は、この記録を見てから行うべきです。
よくある質問
Q. GitHub Copilotのapproval assessmentは、そのまま必須承認に数えられますか？
いいえ。approval assessmentだけでは必要な承認数に数えられず、管理者が承認機能と算入設定を有効にする必要があります。
Q. CopilotのPR承認は既定で有効ですか？
いいえ。Copilotの承認は既定で無効です。Enterprise、Organization、リポジトリの設定を確認して有効化します。
Q. Copilotが承認した後にコミットを追加するとどうなりますか？
既存の承認はdismissされます。変更後はCopilotへ再レビューを依頼し、必要な承認を取り直す流れです。
Q. Copilotの承認を特定のファイルだけで使えますか？
使えます。ファイルパスglobを指定すれば、PR内の全変更ファイルがいずれかのglobに一致する場合だけ、承認をマージ要件に数える制限が可能です。最大15個のglobを指定できます。
まとめ
GitHub Copilot code reviewは、approval assessmentの表示に加えて、管理者が許可した場合にPRのApproveレビューを提出できるようになりました。ただし、assessmentだけでは必要承認に入らず、承認提出の許可とマージ要件への算入を別々に設定する必要があります。
導入時はEnterprise、Organization、リポジトリの方針を確認し、ファイルパスglobで対象を限定する設計です。レビュー強度の既定値はBalancedですが、Liteを明示する選択もあるため、対象変更のリスクとクレジット消費を合わせて決めます。
承認後の新コミットでApproveはdismissされます。CODEOWNERS、CI/CD、コードスキャン、人間の確認を残し、まずは限定したリポジトリで結果を測ってから、AI承認を必須条件へ広げるか判断してください。
ポイント
AI承認を有効にする判断は、承認数を減らせるかだけで決まりません。対象ファイル、新コミット後の再確認、例外時の人間レビュー、公開プレビューの変更管理まで含めて運用を設計します。
関連記事
- Muse Codeを解説｜MetaのAI開発ツールと活用ポイント
- Codex vs Claude 1週間比較を解説｜開発パートナー選定の実感値
- AIエージェント実験の失敗事例を解説｜丸投げを防ぐ監督体制のポイント
- シャドーAIエージェント対策を解説｜検出・統制の進め方
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。