GitHub CopilotのコードレビューがPRを正式に承認可能に、承認票をマージ要件としてカウント

GitHubはCopilot code reviewの権限を拡大した。各レビューの概要コメントに、承認可能かどうかの判定が表示されるようになり、管理者はさらに、Copilotによる正式なApproveレビューの送信を許可できる。判定の表示だけではマージルールに影響しない。正式な承認を有効にした場合に限り、Copilotの承認票がリポジトリで要求される承認数に加算される。PRに新しいコミットが追加されると、人間によるレビューと同様に以前の承認は取り消され、レビューを再度依頼する必要がある。

この機能はデフォルトで無効になっており、企業、Organization、リポジトリの3階層で制御できる。企業は全面的に無効化することも、決定権を下位に委ねることもできる。Organizationは個別のリポジトリを指定でき、リポジトリ管理者はCopilotが承認できるファイルパスをさらに制限できる。現在、Copilot Pro、Pro+、Max、Business、Enterpriseプラン向けにパブリックプレビューとして提供されている。技術的な変化は単に要約が追加されたことではなく、モデルの出力が既存のbranch protectionにおけるrequired approvalsの条件を初めて直接満たせるようになった点にある。そのため、権限設定はソフトウェアサプライチェーン管理の一部となった。

GitHub上のイベントを対象とした最近の大規模研究からも、AIがコードを書き、AIがレビューするクローズドループが周辺的な現象ではないことが示されている。研究者は、AIエージェントが作成したPRを約283万件特定し、そのうち24万8,641件が少なくとも1回のAIレビューを受けていた。異なる製品間で行われたレビューは、特定されたエージェント作成PRの約1.6％を占めた。ただし、データは製品の署名に基づく帰属判定に依存しているため、件数は下限にすぎない。また、コメントの分類は、実際に欠陥を発見できたことを意味しない。

チームは、Copilotの承認をセキュリティレビューの直接的な代替として扱うべきではない。より慎重な運用方法は、まず低リスクのパスに限定し、人間または別のツールによる独立した承認を維持したうえで、見逃し、誤検知、新しいコミット追加後の再レビュー動作を測定することだ。今後の焦点は、GitHubが承認のしきい値やモデルのバージョン変更履歴を公開するか、さらにセキュリティ脆弱性、生成コード、同一製品内のクローズドループといった状況別の評価結果を提示するかどうかにある。