GitHub Copilotの承認がプルリクエストの必須レビューに数えられる

GitHub Copilotにコードレビューを任せているが、結局は自分で読み直している。認証処理まわりの変更や、複数のサービスが依存する共有ライブラリの修正が来るたびに、そう感じているチームは多いはずだ。GitHubは2026-10-28、この「どこまで任せられるか」という線引きそのものを動かす変更を発表した。GitHub Changelogによると、Copilotの承認がプルリクエストの必須承認数にそのままカウントされる「Approvals」が一般提供になった。同時に、重要な変更に向けて複数のAIモデルが独立してレビューする最上位の強度「Max」も公開プレビューで加わった。

何が変わったのか

変わったのは2つある。

• コードレビューの「厳しさ」を選べるようになった(新しいレベル「Max」)
• レビューの先にある「承認」まで、Copilotが担えるようになった(「Approvals」のGA)

Copilot Code Reviewには、これまで「Lite」「Balanced」の2段階のレビュー強度があった。今回、3段階目として「Max」が公開プレビューで追加された。認証ロジックや、複数サービスが依存する共有ライブラリの変更など、間違えると被害が大きい変更がある。Maxは、そうした変更に向けた最も徹底したレビュー強度という位置づけだ(GitHub Changelog)。

そしてもうひとつが「Approvals」のGA(一般提供)だ。有効にすると、Copilotのレビューがそのまま正式な承認として扱われる。その承認は、リポジトリのブランチ保護ルールが求める必須承認数にカウントされる(GitHub Changelog)。

対象プランは次のとおりだ(GitHub Changelog)。

• 対象: Copilot Pro、Pro+、Max(サブスクリプションプラン名。レビュー強度のMaxとは別物)、Business、Enterprise
• 対象外: Freeプラン(記載がなく、対象外と見てよい)

では、新しく加わった「Max」は、LiteやBalancedと具体的に何が違うのか。

Maxは何を変えるのか

Lite・BalancedとMaxの違いは、レビューのやり方そのものにある。LiteとBalancedは、日常的なレビューを速く返すことを優先した強度だ。対してMaxは、異なるプロバイダーの複数のAIモデルが、それぞれ独立したレビューエージェントとして同じ変更を読む。各モデルには得意・不得意があり、1つのモデルだけでは見落とす問題を、複数の目で拾う狙いがある。各エージェントの指摘を集約エージェントが1つにまとめ、意見が食い違う箇所を調整し、正確性を再確認してから結果を返す(GitHub Changelog)。

その分、時間もAIクレジットもLite・Balancedより多く使う。GitHubは具体的な倍率は示していない。それでも、所要時間が長くなり、AIクレジットをより多く消費するとは明言している(GitHub Changelog)。3段階の違いを整理すると、次のようになる。

この表のとおり、Maxは「常用する強度」ではなく「ここぞという変更に使う強度」として設計されている。では、その「複数の目」は実際にどれだけ効果があるのか。GitHubはこの問いに、自社のベンチマークで答えようとしている。

精度の根拠はどこにあるのか

GitHubはUniverse 2026の発表で、Copilot code review Maxについて述べている。「ReviewBenchの高重大度の問題検出で、最高のF1スコアを記録した」という内容だ(GitHub公式ブログ「GitHub Universe 2026」)。原文は”posted the highest F1 score on ReviewBench for high-severity issues”だ。F1スコアとは、問題を見つけ漏らさない度合い(再現率)と、見当違いの指摘をしない度合い(適合率)を1つの数字にまとめた指標だ。高いほど、両方をバランスよく満たしていることになる。

ただし、具体的なスコアの数値や、どの競合製品と比べての結果かは、この発表に書かれていない。根拠として引かれているReviewBenchは、次のようなベンチマークだ(GitHub公式ブログ「ReviewBench」)。

• 作成: GitHubとMicrosoftのチームが共同で作ったオープンベンチマーク
• 公開時期: 2026年10月、研究プレビュー版として
• データ: 19のプログラミング言語にまたがる187のオープンソースリポジトリから集めた219件のプルリクエスト
• 測定方法: AIコードレビューエージェントが、人間のレビュアーやその後の修正と同じ問題を見つけられるかを、Claude Sonnet 5による審査で判定する

自分はここで一度止まった。「最高のF1スコア」とまで言い切るなら、第三者が検証した数字だろうと思って出典をたどったからだ。実際には、GitHub自身が運営する、まだ研究プレビュー段階のベンチマークでの結果だった。独立した第三者機関による検証ではない。Maxをどこまで信頼して高リスクな変更に使うかを判断するなら、この前提は踏まえておく必要がある。

その一方で、手がかりがまったくないわけでもない。同じReviewBenchのブログ記事には、複数の独立したモデルの実行結果を統合する手法を本番環境でA/Bテストした結果が載っている(GitHub公式ブログ「ReviewBench」)。

• 判定につながったレビューコメントの割合: +8.0%
• 再現率: +13.6%
• 重大度の高いコメント: ベンチマーク上の予測で+227%、実際の運用で+262%
• レビュー1件あたりのコスト: −8.0%

この数値は「Max」という名前が付く前の、複数モデルを束ねるという手法そのものの本番テスト結果だ。Max自体の公式スコアと同じとは、記事中で明言されていない。それでも、Maxが採る「複数モデル+集約」というやり方の裏付けにはなっている。

承認まで任せるとどうなるのか

ここまでが、レビューの「中身」の話だ。もうひとつの変更であるApprovalsは、レビューの「扱われ方」を変える。

多くのチームは、ブランチ保護ルールで「マージ前に2人の承認が必要」のように必須承認数を決めている。これまでのCopilotのレビューコメントは、どれだけ的確でも、この「2人」には数えられなかった。承認するかどうかを決めるのは、常に人間だった。

Approvalsを有効にすると、この前提が変わる。Copilotの判定がマージ可能だと示された場合、Copilot自身がその承認を出せるようになる。その承認は、ブランチ保護ルールが求める必須承認数の1人分として数えられる(GitHub Changelog)。「2人の承認が必要」なチームなら、Copilotの承認と人間1人の承認で、その条件を満たせるようになる。

ただし、この権限は無条件には渡らない。GitHubが示している条件は次のとおりだ(GitHub Changelog)。

• 既定では無効。有効にするには、エンタープライズ・組織・リポジトリのいずれかの階層で管理者が設定する
• リポジトリ管理者は、Copilotが承認してよいファイルパスを指定でき、範囲を絞って運用できる
• 承認を得たあとに新しいコミットがプッシュされると、Copilotの承認は取り消される。人間の承認と同じ扱いで、再びレビューを依頼し直す必要がある

管理者設定がエンタープライズ・組織・リポジトリの3階層すべてに用意されている。これを軽い変更とは見ていないGitHubの姿勢の表れだと自分は見る。

使うにはどうすればよいか

Maxの設定方法は、用途に応じて3通りある(GitHub Changelog)。

• プルリクエストごとに「Reviewers」バーから選ぶ。重要な変更のときだけ指定する使い方
• リポジトリ・組織・エンタープライズの各単位でデフォルトのレビュー強度を設定する。下位の設定が上位を上書きできるので、組織全体ではBalancedを既定にしつつ、特定のリポジトリだけMaxを既定にする、といった運用もできる
• 管理者が利用可能な最大レビュー強度を制限する。Maxを使わせたくないリポジトリでは、ここで制限をかけられる

2026-11-04時点で、Maxは公開プレビュー、Approvalsは一般提供だ。プレビュー段階の機能であることを踏まえると、まずは認証ロジックのような高リスクな変更に絞って試すのが、現実的な使い方になる。

まとめ

GitHub Copilotのコードレビューに、2つの変更が同時に入った。ひとつは、高リスクな変更向けに複数のAIモデルが独立してレビューする「Max」。もうひとつは、Copilotの承認がブランチ保護ルールの必須承認数にカウントされる「Approvals」のGAだ。Maxはプルリクエストごとに、またはリポジトリ・組織単位のデフォルトとして指定でき、Approvalsは管理者が有効化してファイルパスの範囲を絞りながら使える。認証ロジックのような、間違えると被害が大きい変更から試していけば、どこまでAIに任せるかを自分たちの基準で決められる。