GitHub、AIコードレビュー評価のオープンなベンチマークReviewBenchを公開

公開されたもの

GitHubは、AIによるコードレビューエージェントの品質を比較・評価するためのオープンなベンチマーク「ReviewBench」を研究プレビュー版として公開しました。ReviewBenchのウェブサイトでは、ベンチマークのデータセット全体を見たり、評価済みのエージェントをリーダーボードで比較したり、自前のエージェントを持ち込んで評価したりできます。データセットや評価手法だけでなく、判定に使うLLMのプロンプトやモデル設定、実行用のランナーも公開されている点が特徴です。

ベンチマークの土台には、GitHub上の1億390万件のプルリクエスト（PR、変更をレビューして取り込んでもらう提案単位）の分析があります。実際に公開されているベンチマークは219件のPRで構成され、187のパブリックなオープンソースライセンスのリポジトリ、19言語にまたがります。言語とリポジトリサイズの分布はGitHub全体に近づけてあり、PRのサイズだけは「レビューしがいのある中間と裾」に意図的に重み付けしています。小さすぎる単一ファイルの変更が過剰に含まれるのを避けるためだと説明されています。

背景として、既存のコードレビュー用ベンチマークには課題があると述べられています。正解ラベルの品質、網羅性、現実のコードレビューをどこまで再現できているかの間でトレードオフが生じ、厳密で再現可能な評価手法が空白になっていたという整理です。ReviewBenchはその空白を埋めることを目的に設計されました。

正解データの作り方

正解データ（ゴールデンセット）は、単一の情報源に頼らず3段階で作られています。まず人間のレビュアー、著者の後続コミットから推定した問題、決定論的な解析ツール、複数のモデルファミリーにまたがるフロンティアLLMから候補の指摘を集めます。次に、同じ根本的な問題を指す指摘を意味的に統合し、特定の情報源の見落としに依存しないようにします。最後に、共通の評価ルーブリックで検証します。

注目すべきは、指摘の出どころが正しさを決めないという方針です。ある指摘は「真であり、関連があり、取るに足らないものではない（true, relevant, non-trivial）」場合にのみ真陽性とされます。判定にはClaude Sonnet 5がLLMジャッジとして使われ、すべての提出物に同じルーブリックが適用されます。再現性のために、ルーブリックとジャッジの両方が公開されています。

評価指標と調整の仕組み

指標は2つの系統に分かれ、合計6つが報告されます。grounded precision・recall・F1は既存のゴールデンセットのラベルだけを使う厳密な比較で、既知の問題のうちどれだけ見つけられたか、出した指摘のうちどれだけが既知の問題と一致したかを示します。一方、augmented precision・recall・F1は、ゴールデンセットに一致しない指摘もジャッジが独立に真偽判定し、誰も見つけていなかった有効な問題にも評価を与えます。

固定されたゴールデンセットは、エージェントが想定外の問題を見つけるほど不完全になります。augmented指標は、そうした挙動を減点せずに評価するための仕組みです。ただしaugmented recallは各エージェントが見つけたものによって分母が変わるため、システム間の見出し比較にはgrounded recallが使われ、augmentedは各システムの追加診断として位置付けられています。

評価は用途に合わせて調整できます。結果は重大度やカテゴリで切り分けられ、Fβスコアのβを変えることで、網羅性を重視する（recall寄り）か、ノイズの少なさを重視する（precision寄り）かを選べます。設定を変えるとリーダーボードの順位も並べ替わり、利用者が自分のレビュー方針に合うシステムを見つけやすくなります。

Copilotでの実例

GitHubはReviewBenchをCopilot code review（CCR）の継続的な評価に使ってきました。製品変更のオフラインでの動きが、後に行う本番実験と同じ方向を示す傾向があると報告しています。本番実験がユーザーへの影響を測る最終的な手段である一方、ReviewBenchはどの変更を本番に持っていく価値があるかを判断する確信度を高める役割を担います。

具体例として、複数の独立したモデル実行を1つのレビューにまとめる「マルチモデルアンサンブルレビュー」を導入したliteティアの実験が挙げられています。ReviewBenchは適合率、再現率、コメント量の上昇と、レビュー1件あたりコストの低下を予測しました。本番のA/Bテストも同じ方向に動き、addressed rate（適合率に対応するオンライン指標）は8.0%上昇、再現率は13.6%上昇、コメント量は61%増加、レビュー1件あたりコストは8.0%低下しました。

コメント量だけでは品質は測れません。そこで重大度別の評価も行われ、重大なコメントが227%増えると予測し、本番では262%増となりました。中程度のコメントが増え、些細な指摘（nits）が減るという傾向も一致したとされています。

注意点と不明な部分

信頼性を担保するため、GitHubはベンチマーク構築に参加していないシニアエンジニアに、すべての正解ラベルを独立に再ラベルしてもらいました。その真偽判定はReviewBenchと96.6%一致したと報告されています。データセット、ジャッジ、マッチャーはバージョン管理され、検証手法や一致率、妥当性への脅威も公開されています。

ただし、これは研究プレビュー版であり、原文には利用料金や商用利用の条件についての記載がありません。また、オフラインのスコアは本番のユーザー影響そのものではなく、あくまで方向性を予測するシグナルだと位置付けられています。自前のエージェントを提出する手順は、25件のPRからなるテストセットで設定を調整し、その後に219件すべてを3ラウンド実行するという流れが示されていますが、採点条件の細部や日本語環境での扱いは公開された情報だけでは判断できません。