7月13日、Hexmosが「Perfectly Hitting the Wrong Target: The Story of an AI Code Review Benchmark」と題した記事を公開した。「よくできたベンチマークが、解くべき問題の定義をそもそも誤っている」——この逆説的な批判が記事の核心だ。対象はCode Review Benchと題された論文で、AIコードレビューを単一の問題として評価しようとする設計そのものに根本的な欠陥があると著者は論じる。

「正確に的外れを射抜いている」——ベンチマークの根本的欠陥

著者はHexmosの創業者であるShrijith Venkatramana氏。UC Irvineでソフトウェア工学を学び、Amazon勤務を経て、現在はAIコードレビューツールLiveReviewを開発している。その立場から、Code Review Benchのメソドロジーを詳細に検証した結果が本記事だ。

ベンチマークは一見すると客観的で精緻で権威があるように見える。しかしVenkatramana氏の主張は明快だ。「このベンチマークはよくできているが、解くべき問題の定義をそもそも誤っている」。

問題の核心：AIコードレビューはすでに2つの問題に分裂している

記事の最も鋭い指摘はここにある。Code Review Benchは「AIコードレビュー」を単一の問題として扱っているが、Venkatramana氏はそれがすでに2つの全く異なる問題に分岐していると論じる。

問題①：人間の理解支援

人間のエンジニアには注意力の限界がある。すべての問題を列挙することは最適ではなく、以下の文脈に応じて情報を優先度づけする必要がある：

• エンジニア個人のスキルや役割
• チームや組織のビジネス優先度
• 開発フェーズや運用文脈

この問題の本質は「検索」ではなく「レコメンデーション」であり、成功指標は「人間がより良いエンジニアリング判断を下せたか」だ。

問題②：マシンによる自動検証

一方、AIエージェントが消費者になる場合、話は全く変わる。エージェントは数百・数千の指摘があっても疲れない。むしろ網羅的な分析の方が望ましい。 多くの指摘は人間に見せる必要すらなく、そのまま修正エージェントに渡せばよい。

Venkatramana氏が指摘するのは、この「未来」がすでに現在進行形だという点だ。多くの開発者はすでにレビューコメントを直接コーディングエージェントに渡し、その結果を確認するというワークフローに移行している。

精度（Precision）、再現率（Recall）、コメント量、「ノイズ」といった指標は、人間の理解支援問題には意味を持つ。しかし消費者がAIエージェントである場合、これらの指標の意味は根本的に変わる。

なお、ここで言うPrecision（精度）とは「AIが出したレビューコメントのうち本当に有用なものの割合」、Recall（再現率）とは「コード中に存在する問題のうちAIが実際に検出できた割合」を指す。人間向けのレビューではこの両指標のバランスが重要になるが、エージェント向けでは低Precisionを許容してでも高Recallを追うべき場面が生まれる。

Code Review Benchはこの2つを単一のフレームワークで評価している。Venkatramana氏は、まずこの区別を行うことで全く異なるベンチマーク設計が導かれると主張する。

人間レビューを「ゴールドスタンダード」にすることの問題

ベンチマークは実際の人間レビューのパフォーマンスを基準として評価する設計になっている。しかしVenkatramana氏はこれに疑問を呈する。

現実の人間によるコードレビューは、締め切りのプレッシャー、レビュアーの疲労、不完全なコンテキストの下で行われる。マシンはこれらの制約を持たず、一貫して全件を検査できる。

人間とマシンは「同じ能力スケールの上下」ではなく、補完的な強みを持つ異なる存在だ。人間の熟練エンジニアはアーキテクチャ上の問題、ビジネストレードオフ、組織的な調整といった「コードの外側」を読む。これは機械が苦手な領域だ。制約のある人間レビューをゴールドスタンダードに置く限り、ベンチマークはその制約ごと正当化してしまうという構造的な問題がある。

ベンチマークが測っているのはプロキシであって、ソフトウェアの品質ではない

記事はGoodhart's Law（「測定値が目標になると、良い測定値でなくなる」という経済学・社会科学の法則）の問題にも触れる。ベンチマークが測定しているのは：

• レビューコメントの内容
• 開発者のアクション
• 人間によるゴールドセット
• 本番バグのトレース

これらは個別には合理的だが、本当の目標（より良いソフトウェアを作ること）そのものではない。歴史的なレビュアーとの一致度は、本番障害の削減と必ずしも同じではない。

また、開発者の「コメントへのアクション」をコメント品質の証拠として使う手法についても懐疑的だ。AIアシスト開発が普及するにつれ、エージェントが自動で対応したのか人間が判断したのか区別がつかなくなり、このシグナル自体がノイズ化していく。

「多くの未解決問題を認めながら、なぜベンチマークを出せるのか」

Venkatramana氏がこの論文で評価している点もある。バグ定義の曖昧さ、重要度の設定、エンタープライズ対OSSリポジトリの違い、ベンチマーク汚染、LLMジャッジの品質——これらの課題を論文自体が率直に認めていることだ。

しかしその上で、これだけ多くの未解決の前提を抱えながらベンチマークという形式を採用すること自体が問題だとも指摘する。ベンチマークはその数値の精度が、問題への理解の深さを超えているように見えてしまうからだ。数値が独り歩きし、設計上の前提が問われなくなるリスクは、AIベンチマーク全般に共通する構造的な落とし穴でもある。

まとめ：解くべき問題の定義から始めよ

Venkatramana氏の結論は、「ベンチマーク自体が悪い」ではなく「まだベンチマークを作るフェーズではない」というものだ。AIコードレビューツールを作る側は、ベンチマークのスコアを追いかける前に、「誰のためのコードレビューか」「その顧客が本当に必要としているものは何か」というファーストプリンシプルからの分析が必要だ。精緻な測定より先に、測定すべき問題の定義が問われている。

詳細はPerfectly Hitting the Wrong Target: The Story of an AI Code Review Benchmarkを参照していただきたい。