Michael JohnsonAIレビュアーが何十件もコメントを残しても、リリースに影響する欠陥を見逃すことがあります。2026年10月5日、GitHubは、検出した問題、見逃し、指摘の適合率に基づいてエージェントを比較するベンチマーク、ReviewBenchの研究プレビューを発表しました。
開発者にとって重要なのは、コメント数を数えることから、指摘の内容を評価することへと軸足が移る点です。このベンチマークはエージェントの出力をプルリクエストの問題に関する正解データと照合し、検出された問題の深刻度とカテゴリーも個別に考慮します。
ReviewBenchが評価する内容
データセットには、オープンライセンスの187リポジトリから集めた公開プルリクエスト219件が含まれ、コードは19言語にわたります。GitHubによると、データセットの構築にあたり、1億390万件を超えるPRの分布を分析しました。リポジトリと言語の構成比はGitHub全体のサンプルを参考に調整され、変更規模については、レビューに適した内容のあるPRが多くなるよう意図的に偏りを持たせています。
各PRには、深刻度とカテゴリー（正確性、セキュリティ、信頼性、保守性、テストなど）のラベルを付けた正解の指摘が登録されています。ReviewBenchは、エージェントのコメントのうち実際の問題に該当する割合である適合率と、既知の問題のうちエージェントが検出した割合である再現率を算出します。Fβスコアを使うと、これら2つの基準の相対的な重みを変更できます。再現率を重視すればより多くの問題を探し、適合率を重視すればノイズとなる指摘を減らすことを目指せます。
GitHubの数値の読み方
発表によると、ReviewBenchのアノテーションと、シニアエンジニアによる独立した再検証との一致率は96.6%でした。これは正解データに含まれる問題について専門家の評価がどの程度一致したかを示す指標であり、AIエージェントの適合率ではありません。
GitHubは別途、Copilotのコードレビューに用いるモデルアンサンブルの社内A/Bテストについて説明しています。同社によると、対照群と比べて、対応するコード変更につながったコメントの割合は8.0%、再現率は13.6%、コメント数は61%増加し、レビューコストは8.0%低下しました。これらはGitHubが実施した1つの実験の結果であり、すべてのエージェントを評価したものでも、他のチームで同じ効果が得られるという保証でもありません。
指標を分けて見ることは、チームがレビューの設定を選ぶ際に特に役立ちます。指摘数の増加に伴って有用な発見が増えることはありますが、件数だけでは、そのうち何件が妥当だったかは分かりません。ReviewBenchでは結果を深刻度やカテゴリー別にも分けているため、重大な欠陥やセキュリティ上の問題などを個別に確認できます。
ベンチマークを試す方法
GitHubの説明によると、研究プレビューではデータセット全体の確認、公開済みの結果との比較、独自エージェントの実行が可能です。予備実行ではPRを25件使用し、全件実行では3ラウンドにわたり219件を評価します。参加者はコンテナイメージ、設定、モデルの独自キーを提供し、評価には共通のジャッジが使われます。結果は確認と提出の承認が済むまで非公開です。
この実行で得られる実務上の意義は、比較可能な出発点を得たうえで、自分たちのレビュー規則やリポジトリに特徴的な変更を使ってシステムを検証できることです。言語、アーキテクチャ、深刻度のしきい値、許容できるノイズの水準といった個々のチームの条件は、共通データセットの構成とは異なる場合があります。
GitHubは、自社の実験ではReviewBenchのオフライン評価の変化が実運用の結果と同じ方向を示したとしています。公開された測定値は同社独自のテストに基づくものです。したがって、現時点で最も確実なベンチマークの活用法は、共通のデータセットを用いたエージェント同士の比較と、強みの診断です。導入の判断には、チーム固有のワークフローでの検証も含めるべきでしょう。