c-CRAB、コードレビューエージェントベンチマーク：何を測定するのか、何が判明したのか、そして41.5%が実際に意味するもの

コードレビューエージェントと人間のレビュアーが同じプルリクエストを確認し、同じ懸念を提起しました。エージェントのコメントに基づいて行動するとバグが修正され、テストは成功します。そして、著者らが計算したすべてのテキスト類似度指標は、エージェントのレビューが人間のレビューと本質的に無関係であると判定しました：BLEU-4 0.00、ROUGE-L 7.02、chrF 20.74、埋め込み類似度54.59。同じ懸念、異なる言葉、そしてレビューを評価する標準的な方法では、それらが一致していることを認識できませんでした。その一例が、c-CRAB（「シー・クラブ」と発音）の背後にある論拠です。これは、arXiv:2603.23448として公開されたコードレビューエージェントベンチマークです。

c-CRABは、コードを書くエージェントではなく、コードレビューエージェントを評価します。プルリクエスト（人間またはコーディングエージェント由来のもの）が与えられると、レビューエージェントがレビューを生成し、c-CRABはそのレビューに従って行動した結果、振る舞いとして正しい修正が得られるかどうかでレビューを採点します。このベンチマークは、ソフトウェア工学研究者のYuntong Zhang、Zhiyuan Pan、Imam Nur Bani Yusuf、Haifeng Ruan、Ridwan Shariffdeen、Abhik Roychoudhuryによって構築され、PR-Agent、Devin、Claude Code、Codexの4つのツールを評価しています。著者の1人はSonarSourceに所属しており、論文ではそのことが何を意味し、何を意味しないのかを自らの言葉で明記しています。“本論文で表明された見解および結論は著者個人に帰属するものであり、SonarSourceの公式な方針や支持を代表するものではありません。さらに、本稿で示された知見は独立したものであり、SonarSourceにおける製品の品質の評価として解釈されるべきではありません。”

詳細に入る前に、2点だけ述べておきます。一部のサードパーティの記事では、この同じ研究成果を“CR-bench”と呼んでいます。これは同じベンチマークであり、このページでは一貫してc-CRABを使用します。以下のすべての図は、論文が報告した結果そのものであり、現時点で論文と再現パッケージから読み取ったものです（独立に再実行したわけではありません）。解釈は私たちによるものであり、この論文がすでに集めている実務者の議論も含まれています。このいずれも、評価対象となったツールのベンダーからの指針ではありません。また、そもそもコードレビューエージェントを実行するかどうかまだ迷っているなら、コードレビューエージェントに関する当社のバイヤーズガイドがより適切な出発点です。このページは、それらのエージェントがどのように測定されるかについてのものです。

なぜc-CRABはレビューをLLM判定器ではなくテストでスコアリングするのか

コードレビューエージェントを評価する通常の方法は、そのレビューを人間のレビューと比較し、LLM-as-judgeまたはテキスト類似度メトリクスを使用することです。c-CRABの著者たちはその両方を否定します。彼らが主張するには、LLM-as-judgeはバイアス、不安定性、プロンプト感度に影響されやすく、再現可能で一貫したスコアリングを困難にします。また、上記のケーススタディは、文字列メトリクスが実際に測定するものが、有効性ではなく言い回しであることを示しています。そのpython-telegram-botのプルリクエストでは、Codexのレビューは人間と同じことを述べましたが、BLEU-4とROUGE-Lはそれを認識できませんでした。

つまり、c-CRABはその逆を行います。人間の各レビューコメントは、根本的な問題を捉えた実行可能なテストに変換されます。レビューコメントは、それに基づいて修正を行った結果、動作として正しい修正（つまりテストをパスさせる修正）が得られた場合に、正しいと見なされます。すべてのインスタンスには実行可能なDocker環境が同梱されているため、合格/不合格の判定はコードを実行して行われ、2つのテキストの類似度を別のモデルに尋ねることはありません。これが重要な理由です。レビューの役割は開発者の行動を変えることであり、テストはその変化を直接測定する唯一の評価シグナルだからです。

この論文は、自らの言葉で2種類のテストを定義している：“{{1}}動作テストは、実行時にテスト対象のコードをインポートして実行する。テスト対象の関数を特定の入力で呼び出し、出力をチェックするか、例外を検証する。一方、構造テストはソースコードのテキストを検査し、パターンと照合し、APIサーフェスをチェックして、望ましいコード変更が行われたかどうかを判定する。{{/1}}” 最終的な内訳は、動作テスト42件（17.9%）、構造テスト192件（82.1%）である。正直に一言述べる価値がある：{{2}}オラクルの大部分はソーステキストのパターンマッチングであり、コードを実行するものではない。この偏りは、心に留めておくべき実際の制限である。{{/2}}

ベンチマークの構築方法と、ファネルのコスト

c-CRABは、既存のinclusionAI/SWE-CAREデータセットの上に構築されています。このデータセットは、コミットメタデータを伴うプルリクエストインスタンスを提供します。c-CRAB自身の貢献は、PRコーパスではなく、オラクルです。キュレーションパイプラインは4つのフィルターを実行し、それぞれがインスタンスを犠牲にします。論文では、ファネルを次のように報告しています。

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

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

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

• 自然言語のコメントをテストに変換 — PR 339件、コメント481件。テストはGPT-5.2を用いて、実行結果に基づく改善ループ（最大3回の試行）で生成されます。テストが保持されるのは、元のコードでは失敗し、修正後には成功する場合のみです。

• コーディングエージェントによる検証 — 184件のPR、234件のコメント。Sonnet-4.6バックエンド上のClaude Codeが、人間のレビューコメントのみを与えられてコードの修正を試みます。テストをパスさせることができなかったインスタンスは破棄されます。これが最終セットです。

開始プルリクエストの約27%が生き残ります。それはテストベースのオラクルが支払う正直な代償であり、ベンチマークが広大ではなく小規模である理由でもあります。生き残ったセットは、184件のPRインスタンス、234件の検証済みレビューコメント、インスタンスあたり1.27件のテスト、PRあたり平均418.1行の変更行、テストあたり31.8行です。2名のアノテータが、生成されたテストが人間のレビューアの指摘を忠実に捉えているかを、サンプリングした50インスタンスについて独立に判定し、84%の確率で一致しました。

注意深く読むと気づく相違が一つある。データセットの表には67個のリポジトリが記載されている一方、妥当性への脅威のセクションには「56個のリポジトリにわたる234個の検証可能なオラクルを伴う184件のプルリクエスト事例」とある。論文では両方の数字が異なる場所に記載されており、私たちはそれらを平均したり、都合のよい方を黙って選んだりはしない。読者はまさにこの種の詳細に基づいて、ベンチマークが時間を費やす価値があるかどうかを判断する。したがって、両方の数字を公開されたままここに再掲する。

結果とその読み方

合格率はテストの総合合格率です。インスタンスごとには、そのPRのテストのうち合格した割合を指し、主要数値はインスタンス全体の平均です。論文では、ツールごとに次のように報告されています。

• Claude Code — コメント1,336件、PRあたり7.3件 — 挙動38.1%、構造30.7%、全体32.1%

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

• PR-Agent — コメント524件、PRあたり2.8件 — 行動面 38.1%、構造面 19.8%、総合 23.1%

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

• 人間 — コメント234件、PRあたり1.3件 — 設計上100%。人間がオラクルを書いたため、この行はスケール指標であり、競合ではありません。

それらの行を引用する前に、注意深く読んでください。アブストラクトの“わずか約40%”は和集合です。234件のテストのうち41.5%が、4つのツールの少なくとも1つによって合格しました。これはどの単一エージェントのスコアでもありません—最高の単一スコアはClaude Codeの32.1%です—また、4つのツール全体で実際の欠陥の40%を検出したことを意味するものでもありません。その理由については以下のセクションで説明します。

最も興味深い数字は、勝者の数字ではない。Claude CodeとDevinはそれぞれ1,300件以上のコメント（PRあたり約7.3件）を投稿し、32.1%と24.8%を達成した。Codexは324件（PRあたり約1.8件）を投稿し、20.1%に達した。人間のベースラインはPRあたり1.3件のコメントである。計算してみよう：コメント量が約4倍でも、合格率は2倍にすら満たない。量はカバレッジではない。おしゃべりなレビュアーと有用なレビュアーは別物であり、c-CRABはそれを示すために作られた最初のベンチマークである。

有用性は逆に作用する

低い合格率は、著者らが他に何を測定したかを見るまでは、非難であるかのように読める。著者らは6件のPRにわたる92件のコメントを手作業で検査し、そのうち84%（92件中77件）を有用と判断した—PR-Agent 94%、Codex 88%、Devin 85%、Claude Code 78%。つまり、c-CRABテストに不合格となるコメントの大半はノイズではなく、人間のレビュー担当者が指摘しなかった事柄に関するものである。サンプルは小さい—92件のコメント、6件のPR—そして論文もそう述べており、私たちもそう言うべきである。

同じパターンは、レビュアーたちが語る内容にも現れている。人間のレビュアーは保守性、設計、ドキュメントに偏り、ツールは堅牢性、テスト、エラー処理に偏っていた。論文はこれを、人間とエージェントの置き換えではなく協働を示す論拠と解釈している。また、スコアが低く見える理由としても、これが最も有力な説明である。すなわち、エージェントと人間はしばしば同じものを見ておらず、オラクルは人間のリストだけに報酬を与えるからだ。

c-CRABが見えないもの

このベンチマークは自身の盲点を明確に述べており、私たちも同様です。c-CRABは、人間のレビュアーが指摘しなかった正当な問題に対して一切の評価を与えません。オラクルは人間のレビュー意図です。つまり、誰も言及しなかった実際のバグを発見したエージェントは、そのバグに対してゼロ点を取ります。論文はそれを直接的に述べています — 自動レビューツールは人間のレビュアーが特定できなかった他の価値あるコメントを生成するかもしれないが、「他の既存のベンチマークと同様に、c-CRABはこれらの追加コメントを直接評価するものではない」と。

この結果に関するほとんどの報道への訂正は、この一文に集約される。「レビューエージェントは40%しか解決しない」という言葉を、まるでエージェントが実際に捉えた欠陥の数を測ったかのように引用する人は、その数字を誤読している。この数字が示すのは、人間が提起した懸念のうち、エージェントたちが共同で解決できた割合にすぎない。より狭く、はるかに正直な主張である。

自分で実行する

数値を再現したい場合や、独自のレビュアーを追加したい場合は、複製パッケージが公開されています: c-CRAB-Benchmark/dataset。READMEが実際のドキュメントであり、それがどのようなものかについて正直に説明されています。セットアップは code>uv sync/code>。Docker と code>OPENAI_API_KEY/code> または code>ANTHROPIC_API_KEY/code> のいずれかが必要です。また、Claude Code は追加で資格情報を code>~/.claude/.credentials.json/code> から読み取ります。また、その組織は環境用のビルド済みDockerイメージも公開しています。

レイアウト: code>pipeline//code> はパイプラインのロジックとプロンプトを保持し、code>execution//code> は Docker イメージのビルダーとランタイムヘルパー、code>results_preprocessed//code> は公開済みのベンチマークサブセット（前処理済みインスタンス410件）、code>results_pipeline_funnel//code> は stage0–stage4 の JSONL ファイルとファネルサマリー、そして code>raw_results_compressed//code> は生の実験出力を保持します。

完全な実行を再現するには5つのステップがあります: Docker環境を構築し（code>execution.build_swe_care/code>）、テストを生成し（code>run_testgen_full.sh/code>）、ベースラインレビューを収集し（code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>）、エージェント解決を実行し（code>run_batch_agent_resolution.py/code>）、そして評価する（code>run_batch_tool_eval.py --tool <name>/code>）。5人目のレビューアを追加したい場合、拡張ポイントはプラグインインターフェースではないことに注意してください。すべてのツールのベースラインレビュープロンプトはcode>run_batch_baselines.py/code> にあります。そしてREADMEにはよりクリーンな方法は記載されておらず、そのスクリプトを編集することになります。

クローンする前に、もう2つ事実を述べておく。論文はCC BY 4.0でライセンスされている。リポジトリのページにはコードのライセンスが明記されていないため、ライセンスがあると想定してはならない。また、論文にはベンチマーク実行にかかるコストやトークン使用量の数値は掲載されていない。それは公開されていないので、こちらで勝手にでっち上げるつもりはない。パイプラインが暗に示すこととしては、184件のインスタンスにわたってPRごとに1つのDockerイメージを用意し、さらにエージェント解決パスを実行するのは、ノートPCで半日あれば済む規模の作業ではないということだ。

これは、レビューパイプラインをリリースするすべての人にとって何を意味するのか

c-CRABの中心的な議論は、LLM判定器は信頼できないオラクルであるというものだ。実行可能なオラクルを構築できない場合（そしてほとんどのチームはできない）、最善の緩和策は、レビューを生成したモデル上で判定器を決して実行しないことである。レビュアーと同じモデルを共有する判定器は自分自身と一致するため、検証パスは依然として数値を返すだけのゴム印と化す。

それはまさに、私たちが同梱するレビュアーの背後にあるルーティングレシピが防いでいる失敗であり、これはc-CRABの批判と並行する設計上の指摘であって、ベンチマーク結果ではありません。ハーネスはとにかくLLM判定機を第2パスとして実行し、所見をクラスタリングし、各クラスタがこの変更における具体的な欠陥であるかどうかを0〜1でスコアリングして、しきい値を下回るものをすべて破棄します。それを制御するレシピは、code>recipes/orcacode-review.dsl.yaml/code>という公開ファイルです。Actionはモデルを指定せず、ルーターのエイリアスを呼び出し、レシピが決定します。プロビジョニングされた状態ではレシピは4行であり、— レビュアーのデフォルトはcode>deepseek/deepseek-v4-flash-0731/code>であり、ヘッダーcode>x-cr-lens: judge/code>にマッチするルールは、判定パスをcode>z-ai/glm-5.3/code>という別ベンダーに送ります。レシピ自身の言葉は、判定機が「デフォルトのモデルを名指ししてはならない」ことを要求しています。なぜなら、レビュアー自身のモデル上では、判定機は「自分自身と合意してしまうため、パスは成功を報告しながらも不活性になる」からです。

異なるベンダーの判定者は自己一致を減らすだけで、LLM判定者をテストに変えるものではありません。c-CRABは私たちのレビューアをテストしたわけではなく、そうでないと示唆するつもりもありません。OrcaCode Reviewは、シート単位ではなくトークン単位で、レビューパスと独立した検証判定者を実行し、その中のすべてのプロンプトは公開されています—つまり、これをこのようなベンチマークに向ければ、私たちの数字ではなく独自の数字を得ることができます。

結論

c-CRABは、スコアが示す意味をほぼ信頼できる初のコードレビューベンチマークです。レビューは、それに基づいて行動した場合にコードが修正されるときにのみ合格とみなされます。主要な数値は確かに低く、最良の単一ツールで32.1%、ユニオンで41.5%ですが、これらは人間が提起した懸念との重複を測定するものであり、レビューの質を測定するものではありません。また、有用性データは、ほとんどのコメントが実際のシグナルであることを示しています。永続的な教訓は、論文自体が主張しているものと同じです。すなわち、量はカバレッジではなく、エージェントと人間は異なるものを見ており、適切な導入形態は人間とエージェントの協働です。そして、このベンチマークはオープンであるため、誠実な次のステップは、自分のレビュアーをそれに対して実行し、自分の数値を得ることです。