CopilotがPRを承認可能に、判定表示だけではマージ条件を満たさない

GitHubは2026年9月1日、GitHub Copilot code reviewがPull Request（PR）へ正式な承認レビューを送れる機能をパブリックプレビューとして公開した。GitHubの発表 では、Copilot Pro、Pro+、Max、Business、Enterpriseが対象で、承認機能は既定で無効とされている。

この9月1日のプレビューで追加されたのは、すべてのレビューに出る「承認可能」という判定と、管理者が許可した場合に提出される正式なApproveだ。前者だけではブランチ保護やルールセットの必須承認数を満たさず、後者を送信し、さらにマージ要件へ算入する設定まで有効にする必要がある。

承認判定と正式なApproveは別の状態

Copilotの各レビューでは、概要コメントにapproval assessmentが表示される。これは、CopilotがそのPRを承認可能と判断したかを示す情報であり、GitHub上のレビュー状態をApproveへ変える操作ではない。肯定的な表示があっても、required approvalsの残数は減らない。

正式な承認を許可すると、Copilotは通常のコメントとは別にapproving reviewを提出できる。その承認をマージ要件へ算入する設定も有効で、かつPRがリポジトリ側の条件を満たす場合に限り、人間の承認と同じように必須承認数の一件として扱われる。

確認すべき場所は概要コメントの文言だけではない。レビュー一覧にCopilotのApproveが提出されているか、required approvalsの表示が実際に更新されたかを分けて見る必要がある。タイトルの「判定表示だけではマージ条件を満たさない」とは、この状態の違いを指す。

有効化はEnterpriseからRepositoryまで連動する

承認機能はEnterprise、Organization、Repositoryの三階層で制御され、上位の方針が下位の選択肢を決める。Enterpriseでは、Organizationに判断を委ねる、選択したOrganizationだけで許可する、全面的に無効にする、というポリシーを選べる。全面無効が既定のため、上位で許可されていなければRepository管理者だけでは有効化できない。

Organizationでは、すべてのRepositoryでCopilot承認をマージ要件へ算入する、Repository側へ判断を委ねる、選択したRepositoryだけを対象にする、全面的に無効にする、という範囲を設定する。RepositoryではSettingsのCopilot、Code reviewにあるAuto-approvalへ進む。

GitHubの設定手順 によれば、Repositoryには「Copilotによる承認レビューの送信」と「その承認をマージ要件へ算入」の二つの切り替えがある。前者だけを有効にした場合、Approve自体は表示されても、必須承認数を満たす票にはならない。

自動レビューも別の設定だ。ブランチのrulesetでAutomatically request Copilot code reviewを有効にしなければ、PRごとにReviewers欄からCopilotへ依頼する。追加のpushも自動で再レビューさせる場合は、同じrulesetでReview new pushesを選ぶ必要がある。

パス制限はPR内の全変更ファイルを判定する

Repository管理者は、Copilotの承認をマージ要件へ算入できるPRをファイルglobで限定できる。指定は一行につき一つ、最大15件で、空欄なら全ファイルが対象になる。これはCopilotがコメントできるファイルの範囲ではなく、承認を必須承認数へ数えられるPRの範囲を制御する設定だ。

算入されるには、PRで変更されたすべてのファイルが、指定したglobのいずれかに一致しなければならない。たとえば文書用パスだけを許可しているとき、同じPRにアプリケーションコードの変更が一つでも含まれれば、CopilotのApproveはそのPRのマージ要件を満たす票として数えられない。

この仕組みなら、文書や生成ファイルなど限定した領域から導入し、製品コードでは判定表示を参考情報にとどめる構成を作れる。ただし、承認レビューの送信を許可する設定、算入を許可する設定、ファイルglobの三条件は別々に確認する必要がある。

追加コミット後の失効と人間の承認を設計する

CopilotがApproveを提出した後に新しいコミットが追加された場合、その承認は更新前の差分に対するものになる。9月6日の独立解説 は、人間の古い承認を破棄する設定と同様にCopilotの承認も失効すると整理しているため、チームはstale review dismissalの設定と再レビューの動作を一緒に確認すべきだ。

Review new pushesが無効なら、新しいpushの後にCopilotが自動で再レビューするとは限らない。その場合はReviewers欄から再度依頼し、最新差分へのApproveが提出されたかを確認する。パス制限を使っている場合は、追加されたファイルも含めて全変更が許可範囲内に収まっていなければ、再提出された承認もマージ要件へ算入されない。

人間の最終確認を残すかどうかは、Copilot側ではなくリポジトリのルール設計で決まる。必須承認数が一件でCopilotの承認を算入すれば、その一件をCopilotだけで満たし得る。人間の承認を必須にするなら、必要承認数をCopilotの一票だけでは満たせない数にするか、Code Ownersによる承認など、人間に割り当てた要件を別に維持する必要がある。

現段階の提供状態は一般提供ではなくパブリックプレビューであり、設定や適用範囲は変更される可能性がある。確定している境界は、承認判定だけではマージ条件に影響せず、正式なApproveの送信とrequired approvalsへの算入には明示的な許可が必要だという点だ。

関連記事:

• GitHub CopilotがPRを承認可能に、初期設定ではマージ要件を満たさない