GitHub CopilotがPRを承認可能に、初期設定ではマージ要件を満たさない
GitHubは2026年9月1日、GitHub Copilotのコードレビューがプルリクエスト（PR）へ正式なApproveを送れる機能をパブリックプレビューで公開した。GitHubの変更告知 によると、対象はCopilot Pro、Pro+、Max、Business、Enterpriseで、承認機能は既定では無効になっている。
結論は、通常のレビュー概要に出る「承認可能」という評価だけではマージ要件を満たさない、ということだ。管理者が正式なApproveと、その承認を必須承認ルールへ算入する設定を許可して初めてマージ条件に影響する。翌9月2日の QATechToolsの解説 も、評価、正式承認、マージ要件への算入を別の状態として整理している。
評価表示と正式なApproveは別のもの
すべてのCopilot code reviewには、レビュー概要の中にapproval assessmentが表示されるようになった。これは、Copilotが変更内容を承認可能と判断したかを示す評価であり、詳細な指摘と合わせて人が判断するための情報になる。
assessment自体は、PRの承認イベントではない。既定状態ではCopilotはApproveを送信せず、肯定的な評価が表示されても、ブランチルールやルールセットが求める必須承認数は増えない。「問題なしという評価」と「マージゲートを通過させる承認」は、画面上でも設定上でも異なる。
管理者が承認を許可すると、Copilotは正式なapproving reviewを送信できる。ただし、リポジトリ側にはApproveの送信を認める設定と、そのApproveをマージ要件へ数える設定が別々にある。前者だけが有効な場合、承認はPRに記録されるものの、必須承認ルールの達成には使われない。
企業、組織、リポジトリの三層で有効化する
承認権限は、企業、組織、リポジトリの三層で管理される。上位ポリシーが承認を禁止していれば、下位の管理者だけで有効にはできない。企業では組織への委任、対象組織だけでの有効化、全体での無効化を選べ、企業階層の既定値は「Disabled everywhere」だ。
組織では、全リポジトリでCopilot承認をマージ要件へ数えるか、リポジトリ管理者へ判断を委ねるか、対象リポジトリを限定するか、全体で無効にするかを選ぶ。リポジトリでは「Allow Copilot to approve pull requests」と「Allow Copilot approvals to count toward merge requirements」を個別に切り替える。具体的な選択肢と階層は、GitHubの設定手順 に記載されている。
自動レビューの設定は、この承認権限とは役割が違う。PR作成時や新しいpushの後にCopilotへレビューを依頼するルールは、レビューを開始するタイミングを決める。一方、承認設定はCopilotがApproveを送れるか、そのApproveを既存のマージ要件へ数えるかを決める。
PRで見分けるべき三つの状態
Copilotの表示が肯定的でも、PRがマージ可能になるとは限らない。実際の状態は、次の三つに分けて考えると境界が明確になる。
- 評価表示だけ：概要コメントに承認可能というassessmentが出るが、正式なApproveではなく、必須承認数には加算されない。
- 正式承認を有効化：CopilotがApproveを送信する。さらに上位ポリシーと算入設定が有効で、対象パスの条件も満たす場合、その承認がrequired-approval ruleを満たすものとして扱われる。
- 承認後に新コミット：Copilotによる既存の承認は取り消される。更新後の差分を対象に、新しいレビューが必要になる。
Approveの送信だけを許可し、マージ要件への算入を無効にしておく構成も可能だ。この場合、Copilotの判断はPR上に残るが、マージゲートは変化しない。算入まで有効にすると、Copilotの承認が人間のチームメンバーによる承認と同様に、リポジトリの必須承認ルールを満たし得る。
新コミット後の再レビューは、常に自動で始まるわけではない。手動運用ではCopilotへ再度レビューを依頼する必要がある。自動レビューを設定し、ルールセットで「Review new pushes」を選択している場合は、新しいpushのたびにレビューを要求できる。
重要パスを避ける設定は許可リストとして働く
リポジトリ管理者は、Copilotの承認をマージ要件へ数えられるPRをファイルパスで限定できる。「File paths」欄には1行につき一つのglobを最大15個まで入力でき、空欄ならすべてのファイルが対象になる。
この指定は、実質的に許可リストとして働く。PRで変更されたすべてのファイルが指定したglobのいずれかに一致した場合だけ、Copilotの承認をマージ要件へ数えられる。文書や翻訳ファイルに限定する条件例は次のようになる。
- docs/**：docs配下を対象にする。
- *.md：一致するMarkdownファイルを対象にする。
- locales/**：locales配下の翻訳リソースを対象にする。
認証、決済、デプロイ設定などを許可globへ含めなければ、それらのファイルを変更するPRではCopilotの承認を必須承認数へ算入しない構成にできる。文書と重要コードを同じPRで変更した場合も、全変更ファイルが条件を満たさないため算入対象にならない。
パス設定が制御するのはCopilot承認の算入範囲であり、人間によるレビューやほかの必須チェックを置き換える設定ではない。また、公開情報が明示しているのは一般のrequired-approval ruleを満たせることまでで、CODEOWNERSが要求する特定所有者の承認を代替できるかは説明されていない。
現時点でCopilotによるPR承認はパブリックプレビューで、仕様は変更される可能性がある。確認できる境界は、assessmentだけではマージ要件を満たさないこと、正式承認と算入を管理者が階層別に制御できること、パスで対象を限定できること、新コミット後に承認が失効することだ。正式提供への移行時期や、CODEOWNERSを含む追加の承認ポリシーは公表されていない。
関連記事:
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。