GitHubは2026年9月1日、GitHub Copilot code reviewに「PRを承認できる」機能を追加しました。今回の要点は2つです。1つ目は、すべてのCopilotレビューにapproval assessmentが表示され、Copilotが「承認してよい状態か」をoverview commentで判断するようになったこと。2つ目は、管理者が設定を有効化すると、Copilotの承認を実際のapproving reviewとして送信し、条件次第でrequired approvalsにも数えられることです。レビュー自動化の範囲が広がる一方で、どこまで任せるかの設計が重要になります。
結論: 何が変わるのか
これまでのCopilot code reviewは、PRに対してコメントを返し、開発者がその内容を見て人間が承認する流れが中心でした。9月1日の更新後は、overview commentにapproval assessmentが常時表示されるため、レビュー担当者は「修正待ちなのか、承認候補なのか」を一目で把握できます。さらに、auto-approvalを有効化したリポジトリでは、Copilot自身が承認レビューを送信できます。ただし初期状態ではoffで、明示的に設定しなければ有効になりません。
対象プランと影響を受けるチーム
GitHubの公式案内では、この機能はpublic previewとしてGitHub Copilot Pro、Pro+、Max、Business、Enterpriseで利用できます。個人利用では「自分のPRに自動レビューを入れる」設定が中心ですが、実務上のインパクトが大きいのはBusinessとEnterpriseです。理由は、organizationやrepository単位で承認の可否を決められ、required approvalsに算入するかまで制御できるからです。複数チームでmonorepoを運用している組織ほど、レビュー速度と統制の両立が課題になりやすく、今回の変更はその判断材料になります。
設定できる3つの範囲
承認設定はenterprise、organization、repositoryの3階層で管理されます。enterpriseでは「全社で無効のままにする」か「各organizationに判断を委ねる」かを選べます。organizationでは「org全体で有効」「repository管理者に委任」「特定repositoryだけ有効」「org全体で無効」といった粒度で制御できます。repositoryでは最終的にon/offを決めるだけでなく、Copilotが承認対象にできるfile pathも絞れます。GitHub Docsではglobを1行ずつ指定し、最大15件まで設定可能です。
「どのrepositoryまで自動承認を許すべきか」「インフラや認証まわりを除外したい」といった運用設計が難しい場合は、 AI導入やレビュー運用の設計相談 から要件整理を先に進めると安全です。
required approvalsに数える前の判断ポイント
GitHubは、Copilotのapproval assessmentだけではmerge要件を満たさないと明記しています。実際にrequired approvalsへ数えるには、repository設定で「Allow Copilot to approve pull requests」と「Allow Copilot approvals to count toward merge requirements」を有効化する必要があります。さらに、新しいcommitがpushされるとCopilotの承認は人間の承認と同様にdismissされ、再度reviewを要求しなければなりません。つまり、承認の自動化は「一度通したら終わり」ではなく、変更差分の再評価を前提に設計されています。
おすすめは、まずdocsやtests、UI文言など変更影響が限定的な領域だけでcount有効を試し、認証、決済、権限、インフラ構成など高リスク領域はfile pathで除外する運用です。GitHub Docsにはreview effort levelとしてLiteとBalancedも用意されており、Balancedは複雑ロジックやsecurity-sensitiveな変更をより深く見る一方、AI credits消費が増え、GitHub Actions minutesもわずかに増える可能性があります。レビュー品質だけでなくコストも一緒に見ておくべきです。
導入前に決めておきたい運用ルール
実務では、承認を有効化する前に3つ決めると混乱が減ります。1つ目は、Copilot承認を「人間1名の代替」とみなすのか、「人間承認に加える補助」とみなすのか。2つ目は、対象repositoryをどこまで広げるか。3つ目は、レビュー再実行の基準です。rulesetでは新しいpushのたびにレビューする設定や、draft PRにもレビューする設定を選べます。早い段階で指摘を受けたいチームはdraft reviewを有効にし、本番影響の大きいrepositoryはまず補助運用から始めるほうが安全です。
FAQ
Q. approval assessmentが出れば自動でmergeできますか。A. いいえ。assessmentは判断表示であり、merge要件に数えるには承認送信とcount toward merge requirementsの両方を有効化する必要があります。Q. commit追加後も承認は残りますか。A. 残りません。新しいcommitがpushされるとdismissされます。Q. すべてのファイルで使うべきですか。A. GitHub Docs上もfile pathで範囲制御できるため、まずは低リスク領域から始めるのが現実的です。
管理者向けチェックリスト
2026年9月2日時点で確認しておきたいのは、対象プランがpreview対象か、enterpriseとorganizationのどちらで権限を握るか、required approvalsへ数える範囲をfile pathで制限するか、Balanced利用時のAI credits増加を許容できるかの4点です。Copilot code reviewは、単なるコメント補助から承認ワークフローへ踏み込んだ段階に入りました。速さだけでなく、どのPRなら任せられるかを先に言語化できるチームほど、この更新の恩恵を受けやすくなります。
