GitHub のプロダクトマネージャーとソフトウェアエンジニアリング担当シニアディレクターが 2026 年 3 月 5 日に GitHub のブログで公開した記事で、前年 4 月の最初のリリース以降、GitHub Copilot コードレビュー がどのように変わってきたかを説明している。記事の前提は、AI がコード変更のペースを加速させており、チームはその規模でコードをレビューし信頼するための支援を必要としている、というものである。記事によれば、この機能の利用はリリース以降 10 倍に増え、現在では GitHub 上のコードレビューの 5 件に 1 件以上を占めている。
記事の大部分は、「良い」コードレビューについての GitHub 自身の定義がどう変わったかの説明に充てられている。チームが 2024 年にこの機能の構築を始めたとき、掲げられた目標は網羅性だった。記事によれば、開発者が実際に重視していたのは、プルリクエストを素早く前に進める、シグナルの高いフィードバックであることが判明し、チームは現在、正確性、シグナル、速度という 3 つの品質に照らした継続的な評価ループを通じてエージェントを調整している。続いて記事は、この機能を支える再設計された エージェント型コードレビュー のアーキテクチャと、プルリクエスト内でのフィードバックの提示方法に関する一連の変更を説明している。
要点
- 正確性は 2 つの方法で評価されている。既知のコード上の問題に対する社内テストと、実際のプルリクエストから得られる本番環境のシグナル、すなわちコメントへのサムズアップとサムズダウンのリアクション、および指摘された問題がマージ前に解決されたかどうかである。
- シグナルについて、記事はコメントが多ければレビューが良くなるわけではないと論じている。Copilot のコードレビューはレビューの 71% で対応可能なフィードバックを示し、残りの 29% では何も言わない（「ノイズよりも沈黙のほうがよい」）。1 レビューあたりのコメント数は平均約 5.1 件だと報告している。
- 速度について、GitHub はシグナルを優先する意図的なトレードオフを説明している。ある変更では、より高度な推論モデルを採用したことでポジティブなフィードバックの割合が 6% 上がった一方、レビューのレイテンシーが 16% 増加したが、記事はこれを正しい交換だとしている。
- 作り直されたエージェント型の設計は、コンテキストを取得し、リポジトリを探索して、ロジック、アーキテクチャ、不変条件を理解する。記事は、この移行だけで当初ポジティブなフィードバックが 8.1% 増加したとしている。
- 記事はその向上の理由として 4 つを挙げている。エージェントが最後にまとめてではなく読み進めながら問題を記録すること（以前はこれにより初期の発見を「忘れて」しまうことがあった）、レビューをまたいで記憶を保持できること、長いプルリクエストに対してはレビュー戦略を事前に計画できること、そして関連する Issue やプルリクエストを読むことで、単体では妥当に見えてもプロジェクトの要件に合わないコードを見つけられることである。
- 説明されている提示方法の変更は、単一の行ではなく論理的なコード範囲に付けられる複数行コメント、同じパターンの誤りが繰り返し現れる箇所を 1 つのコメントにまとめること、そして提案された修正の 1 つの種類全体を一度に適用する一括自動修正である。
- 記事は、12,000 を超える組織がすべてのプルリクエストで Copilot のコードレビューを自動的に実行していると述べ、それをすべてのリポジトリのデフォルトにした WEX の顧客事例を引用している。この裏付けは GitHub 自身の顧客向け資料によるものである。
- 今後のステップとして挙げられているのは、より深いパーソナライズ（チームの明文化されていない好みを学習すること）と、開発者がマージ前に修正を洗練させたり代替案を検討したりできる双方向の対話である。
背景
これはベンダーが自社製品について語ったものであり、レビューに占める割合、フィードバック率の変化、組織数といった記事中の数値はすべて GitHub 自身の測定によるもので、記事はそのいずれについても外部の出典を示していない。この機能の設定、エフォートレベル、カスタマイズの手段については GitHub Copilot コードレビュー を参照。