コードレビューエージェントベンチマーク：レビュアーの評価方法と、c-CRABを自分のコードで実行する方法

コードレビューエージェントが優れているかどうかは、どうすれば分かるのか。この分野の短い歴史のほとんどにおいて、その答えは「人間のレビュアーのコメントにどれだけ近いかを測る」ことだった。それは聞こえはいいが、実際に試してみると問題が見えてくる。なぜなら、2人のレビュアーが同じ問題をまったく異なる言葉で指摘し得るからだ。Code Review Agent Benchmark — 論文はarXiv:2603.23448、データセットはc-CRAB — は、コメントの言い回しではなく、そのコメントに従って行動した結果によってレビューを評価する最初の本格的な試みである。このベンチマークは234件の人間のレビューコメントを実行可能なテストに変換し、PR-Agent、Devin、Claude Code、Codexという4つの広く使われているレビュアーをそれらのテストに対して実行した。その結果、4つすべてを合わせても、それらのテストの41.5%しか通過せず、論文の言葉を借りれば「わずか約40%」である。このページはその結果を歪めずに読み解く方法、c-CRABを自分で実行する方法、そして自分のコードベースがベンチマークにまったく含まれていない場合にどうすべきかを示すプレイブックである。

見出しの数字は、このページで最も役に立たないものです。役に立つのは手法と失敗の様態です。すなわち、なぜ以前のどの採点方式も間違ったものを測定していたのか、実行可能なテストでレビューを採点する場合のコスト、「レビューエージェントはバグの40%しか捕捉しない」という主張が実際の結果を三重的に誤読しているのか、ということです。ここにあるものはすべて、公開されたベンチマークとそれを実行した実務者の経験に対するコミュニティによる解釈であり、関与したツールメーカーによるベンダー指針ではありません。

なぜ明白なメトリクスが機能しないのか

c-CRAB以前、コードレビューエージェントの評価は少数の系統に分類されており、論文自身の比較表（表1）がその系譜を示している。最も古いのはテキストオーバーラップ、すなわちBLEU、ROUGE、chrFなどの手法であり、CodeReviewerやContextCRBenchといったベンチマークで使用されている。その考え方は、エージェントのコメントが人間のコメントとn-gramが一致するときに良いとみなすものである。しかし、この考え方はコードレビューでどこにでもあるケース、つまり同じ欠陥が異なる言葉で記述される場合に崩壊する。

この論文のケーススタディが最も明確な例です。python-telegram-botのプルリクエスト（PR #3514）において、人間のレビュアーとCodexはどちらも同じネストされたインデックス処理の堅牢性バグを指摘しました。Codexのレビューは行動としては正しく、それに基づいて行動したコーディングエージェントは実行可能なテストに合格する修正を生成しました。しかし、テキスト指標では、BLEU-4 0.00、ROUGE-L 7.02、chrF 20.74、埋め込み類似度54.59と評価されました。n-gramの重なりはゼロであり、それでもレビューは正しかったのです。同じ懸念を異なる言葉で表現しただけで、文字列指標はそれを認識できませんでした。埋め込み類似度は部分的な前進ではありますが、54.59という値は、確認済みの合格に対してまだ実用的なしきい値には到底達しておらず、同じ問題をよりソフトな形で受け継いでいます。

LLMを審判とする手法、すなわちモデルがエージェントのレビューと人間のレビューを比較して投票する仕組みは、語彙問題を解決する一方で、新たな3つの問題を持ち込む。論文はそれらを直接名指ししている：バイアス、不安定性、そしてプロンプト設計への感度である。同じ比較を2回実行すれば、審判は異なる判定を下し得る。判定プロンプトを言い換えれば、ランキングが動く。同じベンチマークで3点差の2つのレビュアーのどちらかを選ぶとき、そのようなばらつきを持つ審判は決定を裏付けることはできない——そして、再現できないスコアはスコアではない。

実行可能なオラクルがもたらすもの — そしてその代償

c-CRAB が基盤としている考え方は、単純であると同時に抜本的です。すなわち、「レビューが人間のもののように聞こえるか？」と問うのではなく、「レビューに従って行動した場合、コードは修正されるか？」と問うのです。保持された各人間のレビューコメントは、根本的な問題を捉えた実行可能なテストに変換されます。レビューコメントは、それに従って行動することで、テストを通過する行動的に正しい修正が生成される場合に正しいと見なされます。そして、すべてのインスタンスには実行可能な Docker 環境が付属しているため、「テストを通過する」ことは判断ではなく事実なのです。

この論文は2種類のテストを定義している。行動テストは「テスト対象コードを実行時にインポートして実行」し、「特定の入力」で関数を呼び出して、「出力を確認する、または例外を検証する」。構造テストは「ソースコードのテキストを検査し、パターンにマッチさせ、APIサーフェスをチェックして、意図したコード変更が行われたかどうかを判断する」。最終的な内訳は、行動テストが42件（17.9%）、構造テストが192件（82.1%）である。そして、この偏りには正直な言及が必要だ：このオラクルの大部分はソースコードのパターンマッチングであり、コードを実行しているわけではない。ゴールドスタンダードは行動テストであり、データセットの大部分はその実用的なバージョンである。

オラクルを構築するのは4段階のファネルであり、どの段階でも何かを捨て去ることになる：

• 初期データセット — 671件のPR、1,313件のレビューコメント。

• レビューフィルタリング — 410件のPR、595件のコメント。手動でアノテーションされた100件のコメントからなるゴールドセットに対してキャリブレーションされたLLM分類器は、客観的に検証可能な問題のみを保持し、会話的または主観的なフィードバックを除外します。

• 実行可能環境の構築 — 410 PR、595 コメント。PRごとに1つのDockerイメージを作成し、依存関係の解決は自動化が失敗した場合にコーディングエージェントへフォールバックします。

• 自然言語コメントのテストへの変換 — 339件のPR、481件のコメント。GPT-5.2を使用し、実行ガイド付き改良ループ（最大3回の試行）で生成。テストは、変更前のバージョンで失敗し、変更後のバージョンで成功する場合にのみ保持されます。

• コーディングエージェントによる検証 — 184件のPR、234件のコメント（最終）。Sonnet-4.6バックエンド上のClaude Codeは、人間のレビューコメントのみを与えられてコードの修正を試みる。テストをパスできない場合、その事例は破棄される。

約27%の初期プルリクエストが生き残る。それを率直に述べるべきだ。なぜなら、それはテストベースのオラクルが払う正直な代償だからだ。コメントが失敗するテストになるほど具体的でない場合、環境を構築できない場合、あるいは有能なコーディングエージェントがコメントだけからコードを修正できない場合、そのインスタンスは破棄される。また、これがベンチマークが小さい理由でもある。184件のPRインスタンスと234件の検証済みコメントは、溺れるようなコーパスではなく、読めるデータセットだ。そして、実際のDocker環境を実行しなければならないオラクルにとって、小ささは利点なのだ。

参考までに、平均的なインスタンスは変更行数418.1行、テストは平均31.8行、インスタンスあたり1.27件のテストがあります。2人のアノテータは、生成されたテストが人間のレビュアーの懸念を忠実に捉えているかどうかについて、50件のサンプルインスタンスで84%の一致率を示しました。

自分で論文を読むと直面するであろう書誌上の厄介な点が一つあります。データセットの表（表4）は67件のリポジトリを列挙している一方、Threats to Validityの節は「56のリポジトリにわたる、234の検証可能なオラクルを伴う184のプルリクエスト事例」と述べています。論文は両方の数値を異なる箇所で示しており、それらを整合させていません。どちらかを好んだり平均したりせず、それぞれが現れる箇所で引用してください。このような不整合こそ、読者がベンチマークに時間を費やす価値があるかを判断する際に注目する詳細なのです。

独立性に関するデューデリジェンスとして、この論文は著者の1人がSonarSourceと提携していることを開示し、調査結果は「SonarSourceにおける製品の品質の評価」として解釈されるべきではないと述べている。それが彼らの免責事項であり、言い換えではなく引用されている。

c-CRABでスコアを誤って引用せずに読む方法

主要な指標は合格率です。すなわち、各インスタンスについて、そのPRのテストのうち合格した割合を、184のインスタンス全体で平均したものです。以下は論文の完全な結果表で、レビューアごとに1行です。人間の行は競争相手ではなくスケールの指標です。人間がオラクルを作成したため、そのスコアは当然100%になります：

• Claude Code — 1,336件のコメント、PRあたり7.3件、全体32.1%（行動的38.1%、構造的30.7%）。

• Devin — コメント1,344件、PRあたり7.3件、全体24.8%（行動的31.0%、構造的23.4%）。

• PR-Agent — コメント524件、PRあたり2.8件、全体で23.1%（挙動38.1%、構造19.8%）。

• Codex — コメント324件、PRあたり1.8件、全体20.1%（挙動38.1%、構造16.1%）。

• 人間 — コメント234件、PRあたり1.3件、構造的に100%。

3つの訂正をします。というのも、アブストラクトの「約40%に過ぎない」という数字は、今のAIコーダー界隈の会話で最も誤って引用されている数字だからです。第一に、41.5%という数字（234件中97件のテストが少なくとも1つのツールで合格）は、4人のレビュアー全員にわたる合算です。つまり、いずれかのエージェントが合格したテストは1回として数えられます。単一のエージェントが41.5%を獲得したわけではなく、最高の単一スコアはClaude Codeの32.1%です。第二に、人間の行はオラクルであって、競技者ではありません。「人間がボットに勝った」と繰り返すのはカテゴリーミスです。第三に、そして最も重要な点ですが、c-CRABは人間のレビュアーが指摘しなかった正当な問題には一切の点を与えません。オラクルは人間のレビュー意図です。誰も言及しなかった実際のバグをエージェントが発見しても、そのスコアはゼロです。したがって、「AIレビューエージェントはバグの40%しか発見できない」というのは、3重に間違いです。これは合算であり、バグ発見率ではなく、人間のレビュアーとの一致度を測るものであり、全体的な正しさを測るものではありません。

コメント量が罠だ。

結果の中で最も興味深い数字は、勝者ではない。Claude CodeとDevinはそれぞれ1,300件以上のコメント（PRあたり約7.3件）を投稿し、32.1%と24.8%に達した。Codexは324件のコメント（PRあたり約1.8件）を投稿し、20.1%に達した。人間のベースラインはPRあたり1.3件のコメントである。量はカバレッジではない。コメント数が約5倍でも、合格率は2倍にすら遠く及ばない。レビューアを選ぶなら、その余分なコメントの真のコストは人間のレビュー疲れである。エージェントが投稿するコメントはすべて、人間が振り分けを迫られる判断なのだ。

有用性の調査結果は逆方向を示しており、この部分があるからこそ、これは安直な「ボットはノイズが多い」という話にはならない。著者らは6件のPRにわたって92件のコメントを手作業で検査し、84%（77/92）が有用だと判断した——PR-Agent 94%、Codex 88%、Devin 85%、Claude Code 78%。つまり、テストを通過できないコメントの大半はノイズではなく、人間のレビュアーが指摘しなかった何かに関するものなのだ。サンプルは小さい——92件のコメント、6件のPR——そしてこのことは、パーセンテージと同じ文脈で述べる価値がある。

両者が実際に何を話題にしているのかが、結果の形を説明している。人間のレビュアーは保守性、設計、ドキュメンテーションに重点を置く傾向があり、ツールは堅牢性、テスト、エラー処理に重点を置く傾向があった。この論文はこれを、人間とエージェントの置き換えではなく協働を支持する論拠として読んでいる——そしてこれは、スコアが低く見える理由として最も妥当な説明でもある。エッジケースには鋭いが設計には無頓着なレビュアーは、人間が指摘するカテゴリーを体系的に見落とすことになる。そしてオラクルは完全に人間の指摘から構築されているのだ。

このプロセスを経験した実践者は皆、同じ地点にたどり着く。Daniel Vaughan による詳細な記事は、その取り組みを CR-bench と呼び、同じ結論に達した上で、それをワークフローにしている。すなわち、堅牢性と正確性のスイープはエージェントに任せ、設計、規約、アーキテクチャ — エージェントが最も低いスコアを出すカテゴリ — には人間を関与させ、弱点となるカテゴリを明示したレビュー指示によってエージェントを導くのである。リーダーボードを読む人にとって彼の最も有益な注意点は、「有用性は合格率と同じではない」というものだ。なぜなら、テストスイートは人間が意図した修正と一致することを求めており、たとえ有効な代替修正でもテストには失敗するからだ。彼の見解では、20% から意義のある高いスコアへ向かう道はモデルのアップグレードではなく、設定作業なのである。

c-CRAB を自分で実行する

上記はすべて、他人の結果を読んだものです。再現パッケージはベンチマークを実行可能にします（それはc-CRAB-Benchmark/datasetとしてGitHub上にあります）。そしてREADMEはそれに必要なことを正直に説明しています。

要件: code>uv sync/code>、Docker、および code>OPENAI_API_KEY/code> または code>ANTHROPIC_API_KEY/code>（Claude Code はさらに code>~/.claude/.credentials.json/code> から認証情報を読み取ります。このファイルはデフォルトでコンテナにマウントされます）。レイアウトは以下の5つのディレクトリです: code>pipeline//code>（パイプラインロジックとプロンプト）、 code>execution//code>（Dockerイメージビルダーとランタイムヘルパー）、 code>results_preprocessed//code>（リリース済みベンチマークサブセット）、 code>results_pipeline_funnel//code>（stage0–stage4 JSONLファイルとファネル要約）、および code>raw_results_compressed//code>（生の実験出力）。5つのステップは順に以下のとおりです:

1. Docker環境を構築する — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>。ビルドをスキップしたい場合は、プリビルドイメージも c-CRAB-Benchmark GitHub packages org で公開されています。

2. テストを生成する — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. ベースラインレビューを収集 — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. このステップの前に、対応する外部ツールの認証情報を設定してください。

4. エージェント解決を実行 — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. 評価 — ツールごとに1回繰り返す: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

READMEには書かれていないことが2つある。5人目のレビュアーを追加するには、code>run_batch_baselines.py/code>を編集する必要がある——そこにツールごとのベースライン・レビューのプロンプトが置かれており、プラグイン・インターフェースは存在しない。READMEには、よりすっきりした拡張ポイントは記載されていない。さらに、このリポジトリには明示的なライセンスファイルがないため、コードがMITやApacheであると決めつけてはならない。論文はCC BY 4.0だが、コード自体の利用条件は明示されていない。

コストももう一つの非公表事項です。論文にはパイプライン実行のためのトークン数やドル金額が一切記載されていないため、オンラインで引用されているコスト数値はすべて未検証として扱ってください。構造が示唆することは十分に明確です：184インスタンスにわたってPRごとに1つのDockerイメージが作成され、さらに各ツールにつきコーディングエージェントの解決パスと評価パスがそれぞれ1回実行されます。これはノートPCで午後に済む規模の作業ではありません。本格的な計算リソースの予算を組みましょう。

実行可能なオラクルを用意できない場合

ほとんどのチームの正直な立場は、LLM判定者がレビューを採点できないという点でベンチマークは正しいが、自社のPR用にテストベースのオラクルを構築するのは大きな負担だ、というものです。ここで区別する価値があるのは、スコアラーとしてのLLM判定者とフィルターとしてのLLM判定者です。c-CRABが判定者をオラクルとして拒否しても、判定者がレビューア内で無用になるわけではありません。重複する指摘をクラスタリングし、弱い指摘を除外する判定者は、依然として精度を高めることができます。設計時に防ぐべき障害モードは、独立性です。

レビュアー自身のモデル上で動くジャッジは自己一致する。すなわち、レビューを読み、もっともらしいと判断し、何も変えずに成功を報告する。別ベンダーのジャッジはその自己一致を減らす。ジャッジをテストに変えるわけではないが、ゴム印的な承認を止める。私たち自身のハーネスはオープンなので、このガードレールの具体的で検証可能な実例を示せる：Orca-Code-ReviewはGitHub上でMITライセンスであり、そのルーティングレシピはリポジトリ自身の言葉でルールを述べている。すなわち、ジャッジは「デフォルトのモデルを名指ししてはならない」。なぜなら「レビュアー自身のモデル上では自己一致するため、パスは不活性化しながらも成功を報告し続ける」からである。Actionはモデルを決して名指しせず、レシピが決定する。プロビジョニングされた状態では、レビュアーのデフォルトは deepseek/deepseek-v4-flash-0731 であり、次のcode>x-cr-lens: judge/code> ヘッダーに一致するルールが、ジャッジのパスを z-ai/glm-5.3 — 別ベンダー — へ送る。これは c-CRAB の主張に並行する設計であって、結果ではない。私たちはベンチマークに含まれておらず、私たちのレビュアーに対する c-CRAB スコアは存在しない。しかしこれは、実行可能なオラクルを構築できない誰にでも利用可能な実用的な緩和策であり、ジャッジとレビュアーが一つのキーの背後で異なるプロバイダーに置ける場合には安価である。それがルーターの役割だ。OrcaRouter では、レビュアーとそのジャッジはルーティングDSLの2行であり、プロバイダー定価をマークアップなしで支払う。

あなたのコードがベンチマークに含まれていない場合

56または67の公開リポジトリにまたがる184件のPRは、あなたのコードベースではありません。そもそもそうなるはずもなかったのです。移転可能な部分は方法論であり、それを自分自身の履歴に対してはるかに小さな規模で実行することができます。人間によるレビューコメントが付いたマージ済みPRを取り上げます。それらのコメントのサンプルについて、レビューが反映される前は失敗し、反映後は成功するテストを書きます。失敗してから成功するという性質がすべての核心です。レビュー前のdiffに対して、候補となるレビュアーを実行します。次に、そのレビュアーのコメントに従って変更を加えるとテストが通るかどうかを確認します。得られるのは、実際に出荷するコードに対して計算された数値であり、それはリーダーボードの順位よりも価値があります。そのコストは、まさに論文が直面した壁です。つまり、PRごとに再現可能な環境が必要です。なぜなら、自分のラップトップでしか通らないテストはオラクルではないからです。

234個のテストは必要ない。チームが実際に議論したPRに対する、厳選された12個のテストの方が、ベンチマークのスコアよりもレビュアーについて多くを教えてくれる。そして、このベンチマークファミリーに対する並行する実務者分析は、関門について率直に述べている。コメントが有効で検証可能な問題であるかどうかに関するLLM分類器の精度は66%から85%の間に収まる。したがって、機械によるフィルタリングは候補リストとして扱い、何かをテストにする前に人間による判定ステップを残しておくべきだ。同じ分析によると、同じコメントからテストへのアイデアに基づいて独立に構築されたLangChainのReviewBenchは、ベースラインの問題のせいぜい約30%を回復するにすぎない——これはc-CRABの20〜32%と同じ範囲であり、ツール間の一桁台のリーダーボード差は、自社のセットアップにおけるノイズよりも小さいことが多いということを思い出させる。

そもそもどのレビューツールを購入するかを決めているのであれば、それはまた別の話です。コードレビューエージェントの購入ガイドでは、ボット対エージェント、シート単位対トークン単位の料金設定、セルフホスティングが有利なケースを解説しています。また、ツールを導入したら、すべてのプッシュでレビューハーネスを実行する際のランニングコストについては、自動コードレビューの解説記事で説明しています。このページは測定のみを扱い、関連記事ではベンチマークの構造(構築ファネル、データセット統計、完全な結果表)を詳しく説明しています。

よくある質問

41.5%が最高のエージェントのスコアですか？いいえ。41.5%は4つのツールすべての和集合です。テストは、いずれかのツールが合格した場合に1回としてカウントされます。最高の単一スコアはClaude Codeの32.1%です。

c-CRABは、レビュアーがどれだけ多くのバグを発見したかを測定するものですか？いいえ。これは、人間のレビュアーが指摘した内容を実行可能なテストに変換し、レビューがそれにどれだけ一致しているかを測定します。人間が言及しなかった実際の欠陥は、たとえ正当なものであっても、ゼロと評価されます。

人間のレビュアーはボットに「勝った」のか？ 100%人間による行はオラクルそのものだ——テストを書いたのは人間なので、これは基準を示すマーカーであって、競争相手ではない。

c-CRABはCR-benchと同じものですか？はい。データセットはc-CRABです。一部のサードパーティの報道ではCR-benchと呼ばれていますが、ここにあるベンチマークは1つだけです。

実行するのにどれくらいコストがかかるのか？論文にはコストの数字は記載されていない。184のインスタンスにわたってPRごとに1つのDockerイメージ、さらにエージェント解決パスが必要なことを考えれば、実際の計算リソースを要する——ラップトップで午後に済む規模ではない。

結論

c-CRABの貢献はリーダーボードではない — それは、レビューがそのアドバイスを実行することでスコアリングできるという実証であり、それ以前のテキスト類似度やLLM判定方式は間違ったものをスコアリングしていたという実証でもある。もし一つだけ持ち帰るなら、それが3つの部分からなる修正だ：41.5%は和集合であり、人間の行はオラクルであり、ベンチマークは人間が一度も挙げなかった欠陥に対してクレジットを与えない。そして、実行に移せる数値が欲しいなら、この方法は転用できる — 自分のマージ済みPRで失敗→成功のテスト、人間による判定ステップ、そして実行可能なオラクルを構築できない場合は、少なくともレビュアーのモデルから独立したモデルを持つ判定者。

レビュアーについて議論するより、測定したいのであれば、読めるハーネスから始めましょう。OrcaCode Reviewは、シート単位ではなくトークン単位で、レビューパスに加えて独立した検証ジャッジを実行し、その中のすべてのプロンプトが公開されています。そのため、このようなベンチマークに適用すれば、私たちの数値ではなく自分自身の数値を得ることができます。