本論文は、AI システムが生成するコードの量がますます増える一方で、人間のレビュアーの処理能力はそれに見合って拡大しておらず、レビューが開発パイプラインのボトルネックになっていると論じる。そして、それに対応して提案されている自動レビューツールは、現状ではうまく評価できないと主張する。著者らは主流の評価手法に異を唱えている。BLEU、ROUGE、chrF、埋め込み距離といった類似度指標は、レビューが実際の問題を特定しているかどうかではなく言い回しの類似性を測るため、妥当な問題をまったく異なる言葉で指摘したレビューが低いスコアになりうる。位置特定の指標は、問題について何が述べられたかではなく、どこで問題が指摘されたかだけを評価する。そして LLM-as-a-Judge のアプローチはプロンプト設計や本質的なランダム性に左右されやすく、その判定を再現するのが難しい。
本論文の回答は、c-CRAB（「シー・クラブ」と発音）と呼ばれるベンチマークとして具体化された、テストに基づく評価である。人間のレビューフィードバックを体系的に実行可能なテストへと変換し、レビュアーが指摘した根本的な問題を捉える。各テストは、元のパッチでは失敗し、問題が解決されると成功するように書かれている。レビューツールを評価する際には、ツールにプルリクエストを与えてレビューコメントを生成させ、別のコーディングエージェントがそのコメントを手がかりにパッチを修正し、修正後のコードを整備済みのテストに対して実行する。テストの成功は、そのレビューが人間の指摘した問題に対応する、対処可能な問題を特定したことの証拠とみなされる。
著者らは具体例を用いてこの設計の動機を説明している。ある例では、人間のレビュアーとツールが生成したレビューが同じインデックスに関する懸念を異なる言葉で指摘しており、BLEU-4 で 0.00、ROUGE-L で 7.02 というスコアになる一方、テストに基づく評価ではその懸念が捉えられたと記録される。別の例では、レビュアーがあるフィールドの型の変更を求めているのに対し、ツールは長さ制限の引き上げだけを提案している。LLM ジャッジは両者を同じ懸念を指摘したものとして扱うが、実行可能なテストは、提案された修正が根本的な問題を解決しないため両者を区別する。
主なポイント
- コードレビューコメントを、人間のコメントとのテキスト上の類似性や LLM の判定によってではなく、振る舞いとして正しい修正につながるかどうかによって評価することを提案している。その根拠として、人間のレビューコメントはノイズの多い成果物であり、その言い回しが指摘された問題と確実に対応するわけではないと論じている。
- 評価した 4 つのツールの成功率は 20.1% から 32.1% であり、人間の成功率 100% に及ばないと報告している。また 4 つすべての和集合をとると、234 件のテストのうち 97 件（41.5%）が少なくとも 1 つのツールによって成功したという。
- この差を、生成されたレビューの品質が低いことを意味するものと読むべきではないと論じている。ランダムに選んだ 6 件のプルリクエストにわたる 92 件のレビューコメントを人手で調べたところ、2 名のアノテーターが 77 件（84%）を有用、すなわち妥当な問題を指摘しているか改善を提案しているとラベル付けした。
- 問題カテゴリの分布がツールと人間とで異なると報告している。自動ツールは人間よりも頑健性やテストに関する懸念を多く指摘する一方、設計、ドキュメント、保守性を扱う頻度は大幅に低い。著者らは、これらのカテゴリが過小に表れる理由を、それらが個々のリポジトリに固有の慣習に依存していることに求めている。
- 成功率はカテゴリによって異なり、頑健性と機能的正しさで最も高く ── 著者らは、これらはレビュー対象のパッチ内により局所化されているためではないかと示唆している ── ドキュメントと設計で最も低く、保守性はツールによって 7.9% から 27.0% の幅があると報告している。
- 自動レビューツールは人間のレビュアーの代替ではなく補完として捉えるべきだと結論づけている。そして、リポジトリ固有のルールをツールが読める成果物に文書化することや、アーキテクチャ文書、過去のレビュー履歴、命名規則といったより豊かなプロジェクトコンテキストにレビューエージェントを根拠づけることが、この差を埋める道筋になると示唆している。
- レビューから導出された実行可能なテストは評価以外にも有用でありうると示唆している。すなわち、検証可能なコード改善につながる問題特定に報酬を与える訓練シグナルとしてである。
注記
著者らは妥当性への脅威を 3 つ挙げている。内的妥当性については、評価がパッチの修正をコーディングエージェントに依存しているため、結果がレビューの品質だけでなくエージェントの能力も反映しうると指摘している。これを緩和するため、各ベンチマークインスタンスを収録前に元の人間のコメントで検証し、検証と評価の両方で同じコーディングエージェントを用いたと報告している。外的妥当性については、ベンチマークが既存のデータセットから構築されており、その整備は信頼性を高める一方で、より広いソフトウェアエコシステムに対する代表性を制限しうると指摘している ── ただし、このパイプラインは新たなプルリクエストにも適用できる。構成概念妥当性については、フィルタリング段階で LLM ベースの分類器を用いているため境界的なコメントが残りうること、またレビューの人手による分析には人間の判断が含まれることを指摘しており、後者は 2 名の著者が独立にラベル付けを行うことで緩和したとしている。
本論文は、この研究がシンガポール教育省の Tier 3 助成金による部分的な支援を受けたと報告しており、また、示された見解は著者ら自身のものであって SonarSource の公式な方針や支持を表すものではなく、SonarSource の製品の品質評価として解釈されるべきではない旨の免責事項を記載している。