はじめに
GitHubは2026年10月5日、AIによるコードレビューのエージェントを評価する公開ベンチマーク「ReviewBench」を発表しました。実際のプルリクエストの分布に沿ったデータと、複数の情報源から作った正解集が特徴です。本稿では、その構成と評価方法、自分のエージェントを登録する手順を整理します。
参考記事
- タイトル: ReviewBench: An open benchmark for AI code review
- 著者: Michelle Zhou、Alejandro Carderera de Diego
- 発行元: GitHub Blog
- 発行日: 2026年10月5日
- URL: https://github.blog/ai-and-ml/github-copilot/reviewbench-an-open-benchmark-for-ai-code-review/
関連記事
要点
- ReviewBenchは、1億390万件のGitHubのプルリクエストの分布をもとに選んだ、19言語・219件の公開プルリクエストで構成されるコードレビューのベンチマークである
- 正解集（ゴールデンセット）は、人間のレビュアー、複数の最先端LLM、静的解析ツールの指摘を集め、重複を除いたうえで共通の基準で検証して作られている
- 既知の指摘だけで測る「grounded」と、正解集にない新たな指摘も評価する「augmented」の2系統の指標で評価する
- ベンチマーク作成に関わっていないシニアエンジニアによる再判定では、正解集の判定と96.6%一致した
- GitHubは、Copilotのコードレビューの改良で、ReviewBenchの結果が本番のA/Bテストと同じ方向に動くことを確認したとしている
詳細解説
AIコードレビューを測る難しさ
GitHubによれば、エージェント型のコードレビューは、プルリクエストを点検し、問題を見つけ、出荷前に注意すべき点を判断するうえで、開発に欠かせない要素になりつつあります。GitHub Copilotのコードレビューは3月時点で6,000万件を超えており、利用の広がりとともに品質をどう測るかが課題になっています。
ただし、既存のAIレビュアーの品質は測りにくいとGitHubは指摘します。多くの問題を挙げるもの、ノイズの少ないもの、重大な問題に強いもの、小さな改善点まで拾うものなど、レビュアーごとに特徴が異なり、利用者がワークフローの中でコードレビューに求める役割もさまざまです。
そのため、何を見つけ、何を見落とし、どのようなトレードオフがあるのかを比較できることが重要になります。GitHubは、良いコードレビューのベンチマークの条件として、実際のプルリクエストの多様さを反映すること、幅広い指摘を捉えること、重大度やカテゴリ、精度と再現率の好みに応じた分析ができることを挙げています。さらに、エージェントを開発するチームにとっては、変更が本番の体験を改善しそうかを確実に予測できるオフラインの指標であることも求められます。既存のベンチマークは、ラベルの品質、網羅性、実際のコードレビューの代表性の間でトレードオフがあり、それらを両立した厳密で再現可能な評価方法が欠けていた、というのが開発の背景です。
記事で使われる用語
記事では、次の用語が定義されています。
- ベンチマーク: 共通のプルリクエストと同じ採点方法でコードレビュアーを試す標準化された評価
- 指摘（Finding）: コードレビューで挙げられた具体的な問題
- 正解集（ゴールデンセット）: プルリクエストごとに検証済みの既知の指摘を集めたもの。レビュアーが何を見つけ、何を見落としたかを評価する基準になる
- 精度（Precision）: レビュアーが挙げた指摘のうち、妥当なものの割合。高いほどノイズが少ない
- 再現率（Recall）: 既知の妥当な問題のうち、レビュアーが見つけた割合。高いほど網羅的
- F1スコア: 精度と再現率を同じ重みで両立させた1つのスコア
- Fβスコア: F1の変形で、好みに応じて精度か再現率のどちらかを重視できる
Fβスコアは一般に、精度をP、再現率をRとすると「(1+β²)×P×R ÷ (β²×P＋R)」で計算され、βが1より大きいと再現率を、小さいと精度を重視する指標になります。機械学習の分類モデルの評価でもよく使われる考え方で、「見落としを減らしたいのか、誤検知を減らしたいのか」という利用者の優先順位を数値に反映できる点が、この指標の利点だと思います。
5つの設計原則
ReviewBenchは、次の5つの原則に基づいて作られています。
1. デモ用ではなく、代表的なプルリクエスト
GitHubは、実際のコードレビューの作業量の分布を把握するため、1億390万件のプルリクエストを分析しました。ReviewBenchは、オープンソースのライセンスを持つ187の公開リポジトリから選んだ19言語・219件のプルリクエストで構成され、言語とリポジトリの規模の分布はGitHub全体とよく一致しています。データセットはすべて公開されています。
1点だけ意図的な調整があり、プルリクエストの規模は、レビューする価値のある中規模以上に重みを置いています。1ファイルだけの小さな変更が過剰に含まれるのを避け、レビューの質が最も問われる複数ファイルにわたる変更を残すためです。データセットの概要は次のとおりです。
- 主な言語: TypeScript 68件、Python 41件、C# 25件、Go 19件、JavaScript 15件、その他51件
- 変更の規模（追加＋削除行数）: 50行以下17件、51〜200行40件、201〜500行44件、501〜1,000行40件、1,000行超78件
- プルリクエストの種類: タイトルと説明から推定したもので、人手によるラベルではない。 機能追加79件、バグ修正59件、ドキュメント15件、性能改善14件、リファクタリング12件、その他40件
- リポジトリの偏り: 1リポジトリあたり平均1.17件、最大10件で、最も多いリポジトリでも全体の4.6%にとどまる
2. 幅広い正解の発見と、独立した判定
人間でもモデルでも、1人のレビュアーがプルリクエストの指摘すべき点をすべて見つけることはできません。そこでGitHubは、次の3段階で正解集を作っています。
- 多様な情報源から候補を集める: 実際の人間のレビュー、作成者が後から行った修正コミットから推定される問題、決定的に動く解析ツール、異なるモデルファミリーの複数の最先端LLMから指摘を集める
- 意味的に重複を除く: 同じ問題を指す指摘をまとめる。複数の情報源が同じ指摘をしても正解集が水増しされず、特定の情報源の見落としにも依存しないようにする
- 共通の基準で検証する: 指摘の出どころでは正誤を決めず、「事実であり、関連性があり、些細でない」場合にだけ正解とする。判定役のLLMにはClaude Sonnet 5を使い、すべての提出物に同じ評価基準を適用する。透明性と再現性のため、評価基準（ルーブリック）と判定役の設定も公開している
3. 既知の問題と新たな問題の両方を測る指標
多くのベンチマークは、固定した正解集に対する精度と再現率を報告します。ReviewBenchは、2系統の指標を報告します。
- Grounded（正解集に基づく）精度・再現率・F1: 既存の正解集のラベルだけを使う、厳密で同条件の比較。既知の問題のうち何件を見つけたか、エージェントの指摘のうち既知の問題と一致したのはどれくらいかを測る
- Augmented（拡張）精度・再現率・F1: 正解集のどれとも一致しない指摘も評価する。判定役が独立して正誤を判断するため、正解集を作ったどの情報源も見つけなかった妥当な問題を見つけたレビュアーも評価される
エージェントの能力が上がるほど、固定した正解集は、作成者が想定しなかった問題をエージェントが見つけることで不完全になっていきます。Augmentedの指標は、そうした発見を自動的に減点するのではなく評価に反映するための指標です。ただし、Augmentedの再現率は各エージェントが見つけたものに応じて分母が広がるため、システム間の比較の代表値にはGroundedの再現率を使い、Augmentedの指標はシステムごとの補助的な診断に使うとしています。
なお、記事の概要図では評価指標を「4つ」（GroundedとAugmentedの精度・再現率）としている一方、本文では「6つ」（それぞれのF1を含む）と説明しており、数え方の違いと考えられます。
4. 好みに応じて設定できる評価
万人にとって最適なレビュー体験はありません。重大な問題だけに集中したい開発者もいれば、軽微な指摘も歓迎する人もいます。網羅性を重視する人もいれば、精度と少ないノイズを優先する人もおり、セキュリティやプライバシーに特化したレビューを求める人もいます。
ReviewBenchでは、結果を重大度（Critical、Medium、Low）とカテゴリ（正しさ、セキュリティ、信頼性、保守性、テストなど）で絞り込めます。Fβスコアのβを調整して、網羅性を重視するなら再現率に、ノイズの少なさを重視するなら精度に重みを置くこともでき、設定に応じてリーダーボード（順位表）が並び替えられます。
5. 内部監査と再現可能な評価
公開前に、データセットの作成に関わっていないシニアエンジニアに、すべての正解の指摘を一から判定し直してもらったところ、正誤の判断は96.6%の割合でReviewBenchと一致しました。データセット、判定役、指摘を照合する仕組み（マッチャー）はバージョン管理されており、同じ設定のもとで結果を比較でき、ベンチマークが変わったときには再検証できます。検証の方法、一致率の測定結果、妥当性に対する既知の懸念も公開されています。
LLMを判定役に使う評価は、判定役のモデルの癖に結果が左右されるという課題が指摘されてきました。本稿としては、判定役の設定と基準を公開し、人間の専門家との一致率を示している点は、この課題に対する誠実な対応だと受け止めています。一方で、判定役が特定のモデルであることが、そのモデルと同じ系統のレビュアーに有利に働かないかは、利用者の側でも意識しておきたい点だと思います。ベンチマークの信頼性については、SWE-bench Verifiedの汚染をOpenAIが分析した事例もあり、評価方法の透明性への関心は業界全体で高まっていると考えられます。
ReviewBenchでできること
ReviewBenchの研究プレビュー版は、ReviewBenchのWebサイトで公開されています。主に次の3つができます。
- データセット全体の確認: プルリクエスト、指摘、ラベル、重大度とカテゴリの注釈を含む全データが公開されており、何で評価されているかを確かめ、結果を再現できる
- リーダーボードでの比較: 全データで評価したコードレビューのエージェントの結果が共通の順位表に公開され、全体の性能、重大度別、カテゴリ別、精度と再現率の好み別に見られる
- 自分のエージェントの評価と改善: データセット、評価方法、判定役のプロンプト、判定役のモデル設定、セルフサービスの実行ツールが公開されており、自分のエージェントを評価し、強みと弱みを調べながら同じ設定で改善を繰り返せる
Copilotのコードレビューでの活用
GitHubは、Copilotのコードレビュー（CCR）の改良の各段階でReviewBenchを使い、進捗の測定、性能の後退（リグレッション）の検出、有望な変更の優先順位づけに役立ててきました。最も大きな利点は、製品の変更が本番でどう働くかを、オフラインで早めに予測できることだとしています。A/Bテストの前にReviewBenchで評価した実験では、オフラインの変化が、後に本番で見られる結果と一貫して同じ方向を示してきたといいます。
最近の例として、軽量版（lite tier）で、1回の実行に頼らず、複数の独立したモデルの実行結果を1つのレビューにまとめる「マルチモデルのアンサンブルレビュー」を導入した実験が紹介されています。ReviewBenchは、精度、再現率、コメント数の向上と、レビュー1件あたりのコストの低下を予測していました。
本番での比較には、対応するオンラインの指標を使います。精度に当たる「対応率（addressed rate）」は、差分、スレッド、リアクション、解決状況、レビュー後のコードをもとに、CCRのコメントが開発者の修正につながったとLLMが判断した割合です。再現率には、人間による追加のレビューがどれだけ必要だったかを使います。
本番の制御群（従来の単一レビュー）と比べた結果は次のとおりです。
| 指標 | ReviewBench（オフライン） | 本番のA/Bテスト |
| 精度 | +4.45% | +8.00% |
| 再現率 | +12.88% | +13.58% |
| コメント数 | +40.0% | +25.0% |
| レビュー1件あたりのコスト | −23.7% | −8.00% |
なお、本文ではA/Bテストのコメント数の増加を「61%」としている一方、グラフでは「+25.0%」と示されており、食い違いがあります。
コメント数だけでは、コメントの質は分かりません。重大な指摘が増えることと、軽微な指摘が増えることでは意味が大きく異なります。ReviewBenchは重大度別の評価でもこの変化を捉えていました。
| 重大度 | ReviewBench（オフライン） | 本番のA/Bテスト |
| 重大（Critical）なコメント | +227.4% | +262.0% |
| 中程度のコメント | +121.0% | +18.00% |
| 軽微な指摘（Nit） | −15.69% | −45.0% |
GitHubは、オンラインの実験が利用者への影響を測る最終的な基準であることに変わりはないとしつつ、ReviewBenchによって、どの変更を本番の実験に回す価値があるかをより確信を持って判断できるようになったとしています。
変化の方向はそろっている一方で、中程度のコメントのように変化の大きさにはかなりの差がある項目もあります。本稿としては、ReviewBenchは「どの程度良くなるか」を正確に当てる道具というより、「良くなるか悪くなるか」の方向を早く見極める道具として受け止めるのが適切だと考えています。
自分のエージェントを登録する手順
自分のコードレビューのエージェントを評価し、結果を提出する手順は次のとおりです。
- サインイン: ReviewBenchのWebサイトにGitHubのアカウントでサインインする
- エージェントの登録: コンテナイメージ、設定、自分のモデルのAPIキーを登録する。判定役はReviewBench側で用意される
- テストセットでの試行: 25件のプルリクエストからなるテストセットで実行し、プルリクエストごとの詳細を確認しながら、設定の調整を繰り返す
- 本番の実行: 準備ができたら、219件の全プルリクエストで3回の実行を行い、他のすべての提出物と同じ判定役で採点される
- リーダーボードへの公開: スコアはメンテナーが確認して承認するまで非公開のまま。そのエージェントの現在のスコアを上回った場合か、初めての登録の場合にだけ公開される
注意: エージェントはコンテナイメージとして登録し、モデルのAPIキーは利用者自身のものを使うため、219件×3回の実行にかかるAPIの費用は利用者側の負担になると考えられます。まず25件のテストセットで所要時間と費用の目安をつかんでから本番の実行に進むのが安全だと思います。
GitHubは、ReviewBenchを探索し、自分のシステムを評価し、前提に異議を唱え、ベンチマークの改善に協力してほしいと呼びかけています。ReviewBenchは、GitHubとMicrosoftのチームの共同の取り組みとして作られました。
自社でAIコードレビューを導入する立場から見ると、リーダーボードの総合順位だけでなく、自分たちが重視する重大度やカテゴリ、精度と再現率のバランスで並べ替えて比べられる点が、ツール選定の実務で役立つと思います。
まとめ
ReviewBenchは、実際のプルリクエストに近いデータ、複数の情報源による正解集、公開された判定基準によって、AIコードレビューを比べるための共通の物差しを目指しています。自社の優先順位に合わせて結果を読み解くことが、ツール選びの助けになると考えています。
