c-CRAB（「シー・クラブ」と発音する）は、自動コードレビューツールを評価するためのベンチマークであり、 コードレビューエージェント・ベンチマーク で導入された。各インスタンスは、レビュー対象のパッチを持つ実際の プルリクエストと、人間のレビュアーが実際にそのプルリクエストへ残したコメントから導出された実行可能なテストの集合とを 組にしたものである。各テストは、元のパッチでは失敗し、対応する issue が解消されると通過するように構築されており、 レビュアーが提起した issue に対する客観的なオラクルとして機能する。著者らはこれを、人間のコメントの文言ではなく、 テストによって確認されるプログラムの動的な振る舞いをオラクルとする唯一のコードレビューデータセットと位置づけており、 この主張は先行するベンチマークについての彼ら自身の調査に基づいている。
内容
1 件のレコードは 1 つのプルリクエストインスタンスであり、レビュー対象のパッチ、プルリクエストの説明、検証済みの実行可能な テスト 1 件以上、そしてそのテストを実行できる隔離された Docker 環境から成る。公開されたベンチマークには 184 件の プルリクエストインスタンスが含まれ、それらに 234 件の検証済みレビューコメントが付随する。インスタンスあたりのテスト数は 平均 1.27 件、変更行数はインスタンスあたり平均 418.1 行、テストあたり平均 31.8 行である。
234 件のテストは 2 種類に分かれる。振る舞いテスト（behavioral test）は、テスト対象のコードをインポートして実行し、 特定の入力で関数を呼び出して出力を確認したり例外を検証したりするもので、42 件（全体の 17.9%）ある。 構造テスト（structural test）は、ソースコードのテキストを検査し、パターンを照合し、API の表面を確認することで、 求められるコード変更が行われたかどうかを判定するもので、192 件（全体の 82.1%）ある。
来歴
このベンチマークは SWE-CARE データセットの上に構築されている。SWE-CARE は、パイプラインが必要とするコミットの メタデータを備えたプルリクエストインスタンスをすでに提供している。著者らは、キュレーションのパイプライン自体は それ以外の点ではデータセットに依存せず、そのメタデータを持つ任意のプルリクエストに適用できると述べている。
キュレーションは 4 段階で行われる。レビューのフィルタリングでは、具体的で対応可能かつ客観的に検証可能な issue を 表すコメントのみを残し、説明の要求、了承、称賛といった会話的な内容は除外する。これは LLM による分類器で行われ、 そのプロンプトは 2 人の著者が独立にラベル付けした 100 件のコメントからなるゴールドセットに照らして改良された。 実行環境の構築では、プルリクエストごとに隔離された Docker イメージを構築する。ビルドツールを検出し、仕様ファイルから 依存関係を推定してインストールスクリプトを生成し、過去のプロジェクト自身の仕様が緩すぎる場合には、自動化された コーディングエージェントにフォールバックして正確な依存バージョンを固定する。自然言語のコメントからテストへの変換では、 コメント、関連する diff hunk、修正前後のファイル内容をモデルに与えてプロンプトし、候補テストを両方のリポジトリ状態に 対して実行して、修正前のバージョンで失敗し修正後のバージョンで通過する場合にのみ採用する。失敗した場合は、 実行トレースとエラーメッセージをフィードバックする実行誘導型の改良ループが回る。コーディングエージェントによる検証では、 元の人間のコメントをガイダンスとして与えられたコーディングエージェントがテストを通過させる修正を生成できない インスタンスをすべて除外する。これにより、後の失敗をエージェントではなくレビューに帰することができる。
報告によれば、このパイプラインは当初の 671 件のプルリクエスト（コメント 1,313 件）を、フィルタリング後に 410 件のプルリクエストと 595 件のコメントへ、テスト変換後に 339 件と 481 件へ、検証後に 184 件と 234 件へと 絞り込んだ。著者らはレビューのフィルタリングとコメントからテストへの変換に GPT-5.2 を用い、実行フィードバック付きで 最大 3 回の試行を許した。また、検証と評価の両方で、Sonnet-4.6 をバックエンドとする Claude Code を コーディングエージェントとして用いた。テストの品質を確認するため、2 人の著者が無作為に抽出した 50 インスタンスについて、 各テストがレビューコメントを忠実に捉えているかを独立に判定し、84% の一致に達した。著者らは残りの不一致の原因を、 コメントの部分的なカバーと、テストが特定の実装に時折過剰適合していることに帰している。
ソースコード、ベンチマークデータセット、結果を含むレプリケーションパッケージは https://github.com/c-CRAB-Benchmark で公開されている。
利用
c-CRAB を導入した研究では、4 つの自動レビューツール（オープンソース 1 つ、プロプライエタリ 3 つ）の評価に c-CRAB が用いられている。同研究は、人間の通過率 100% に対して各ツールの通過率が 20.1% から 32.1% の範囲に あったこと、そして 234 件のテストのうち 97 件（41.5%）は 4 つのツールの少なくとも 1 つが通過したことを報告している。 さらに、通過率は issue のカテゴリによって異なり、堅牢性と機能的正しさで最も高く、ドキュメントと設計で最も低いと 報告している。
著者らは、この指標が何を測り何を測らないかを明言している。通過率は、人間のレビューを正解とみなしたうえで、 人間のレビュアーが見つけた issue をレビューツールがどの程度特定できるかを反映するものであり、ベンチマークは、 人間が誰も提起しなかったがツールが生成しうる追加の有益なコメントは評価しない。