GitHub CopilotのコードレビューがPR承認に対応

GitHubの発表をもとに、Copilotのレビュー判定がPR承認へどう関わるかを整理します。判定表示と、管理者が有効にする正式承認を分けて説明します。

レビュー判定の表示と正式な承認は別の機能

これまでのGitHub Copilotのコードレビューは、指摘やコメントを提供するだけで、レビュー承認そのものは人間が行う前提でした。今回追加された「承認アセスメント」機能では、すべてのコードレビューの概要コメントに、Copilotが承認可能と判断したかどうかが表示されます。マージ要件の必須承認数にカウントされる、正式な承認としてCopilotが判定を出せる点が最大の変化です。ただし公式チェンジログによれば、この判定は単独ではマージ要件を満たさないケースもある設計で、あくまで参考情報として扱われる場面がある点には注意が必要です。チームのブランチ保護ルールと組み合わせて、どこまでCopilotの承認に委ねるかを決める必要があります。

管理者設定は3階層、新しいコミットで承認を取り消し

承認機能はデフォルトで無効になっており、管理者が有効化して初めて使えます。設定はエンタープライズレベル(企業全体で統一するか各組織に委ねるか)・組織レベル(組織全体で有効化、リポジトリ管理者に委任、特定リポジトリのみ有効化、または無効化)・リポジトリレベル(有効・無効の切り替えに加え、Copilotが承認できるファイルパスの制限も可能)の3階層です。いきなり組織全体で解禁するのではなく、まずは特定のリポジトリ・特定のファイルパスから試す使い方が現実的です。対象プランはGitHub Copilot Pro・Pro+・Max・Business・Enterpriseの各プランで、執筆時点ではパブリックプレビュー段階です。運用上の重要な制限として、プルリクエストに新しいコミットがプッシュされるとCopilotの承認は自動的に取り消されます。これは人間のレビュアーと同じ挙動で、再度レビューをリクエストすれば新たな承認判定を得られる仕組みです。

出典・詳細: GitHub公式チェンジログ。

まとめ：承認表示とマージ要件を区別する

リポジトリ管理者は、まずレビュー判定の表示と、マージ要件に数えられる承認を区別するとよいでしょう。機能を有効にする範囲や対象ファイルを絞り、新しいコミット後に再レビューが必要になる運用も確認できます。

※ 2026年9月時点の情報です。パブリックプレビュー段階のため、仕様は今後変更される可能性があります。

差し戻されたレビューへの対応まで任せたい場合はPRの差し戻し対応をAIに任せる、GitHub CopilotのAgent Mergeが参考になります。レビュー以外の定型作業もあわせて自動化したい場合はGitHub Copilotに動的ワークフロー機能が追加もあわせてどうぞ。