- Published on
AIコードレビューは実際に使い物になるのか — 測定された証拠が語る精度と偽陽性
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに — 「AIがバグのN%を見つけた」という文が、それ自体では無意味な理由
- AIレビューコメントは実際どれだけ反映されるのか — 0.9%か73.8%か
- なぜ同じ指標が80倍も開くのか
- 偽陽性はどれほど高くつくのか — テンセントの76%
- Googleはこの問題を20年近くどう管理してきたのか
- レビューボットはPRを殺すのか — ノイズとPR放棄
- ベンダーの数字は何を測っているのか
- 測定そのものが崩れる地点 — 「解決済み」は正解ではない
- では、チームは実際どう設定するのか
- いつ使うべきでないか
- 決定ルール
- おわりに
- 参考資料
はじめに — 「AIがバグのN%を見つけた」という文が、それ自体では無意味な理由
まず結論から言います。2026年7月現在、汎用AIコードレビュアーを実際のプロダクションでベンダーと無関係に測定した精度・偽陽性率の数値は、公開されたものが事実上ありません。公開されているのは3種類だけです — ベンダーが自ら作ったベンチマーク、開発者がコメントに反応したかどうかを代わりに測る代理指標、そして1社限りのケーススタディ。本稿はその3つをそれぞれ分解します。
そして、この事実自体が実務的に重要です。「AIレビュアーがバグのN%を捕まえた」という主張は、次の2つがセットで示されなければ判断できません。
- どのデータセットで測ったのか、正解(ground truth)を誰がどう作ったのか
- 偽陽性率はいくらか — つまりそのN%を得るために、開発者が何件のノイズを読まされたのか
2つ目が欠けた再現率(recall)は、タダで100%にできます。すべての行に「ここにバグがあるかもしれません」とコメントを付ければいいのです。レビューツールの価値は、捕まえたものではなく捕まえながら生み出さなかったノイズから生まれます。だから以下では、数字を見るたびに分母と正解の出所を先に確認します。
本稿はAI コーディングモデルの評価で信号とノイズを見分けるの問題意識をコードレビューに移したものです。あちらではベンチマークが、こちらではレビューコメントが対象になるだけで、「数字が何を測っているのかをまず問え」という原則は同じです。
AIレビューコメントは実際どれだけ反映されるのか — 0.9%か73.8%か
最も広く使われる代理指標は「開発者がそのコメントどおりにコードを直したか」です。この指標で測った公開測定値が2つあり、互いに真っ向から衝突します。
測定A — オープンソース(Ganら、arXiv 2508.18771)。 GitHubワークフロー用のAIコードレビューActionを16種選び、PRが50件以上ある成熟したリポジトリ178箇所で、AIが生成したレビューコメント22,326件を収集しました。そのうち5,652件をGPT-4.1で有効性判定して3,955件を「有効(具体的で実行可能)」に分類したうえで、o3-miniで実際に反映されたかどうかを判定しました。結果はこうです。
- 有効なAIコメントのうち実際のコード変更につながった割合：ツールによって0.9〜19.2%
- 同じ基準で測った人間のレビューコメント：60%
- ハンク(hunk)単位でコメントするAction：6.5〜19.2% / ファイル単位のAction：0.9〜4.2%
- 最高は
coderabbitai/ai-pr-reviewerの19.2%、最低はmattzcarey/code-review-gptの0.9%
測定B — ある企業の内部(Cihanら、arXiv 2412.18531)。 多国籍家電企業のBekoが、オープンソースのQodo PR-Agentベースのレビューボット(GPT-4 Turbo)を導入した事例です。10プロジェクトの238名がアクセス権を持ち、そのうち3プロジェクトのPR 4,335件(自動レビューが付いたのは1,568件)を分析しました。ボットのコメント4,408件からフィルタリングを経て、マージされたPRに付いた1,408件を集計した結果です。
- 「Resolved」とラベルされたコメント：73.8%(「Won't Fix」は21.3%)
- プロジェクト別では55%から90%まで開く
同じ名前の指標が、0.9%と73.8%の間にあります。最大80倍の差です。どちらも間違ってはいません — 互いに別のものを測っているだけです。
なぜ同じ指標が80倍も開くのか
差はツールの性能ではなく、測定条件から生まれます。4つの点が違います。
第一に、分母が違います。 測定Bの73.8%はマージされたPRに付いたコメントだけを数えます。放棄されたPRに付いたコメントは、そもそも集計に入りません。レビューが悪くてPRが死んだケースが分母に入らないので、この数字は構造的に上方へ偏ります。測定Aは逆に、成熟したオープンソースリポジトリ全体の有効コメントを見ます。
第二に、ラベルを作る力が違います。 BekoではPRをマージするには、すべてのレビューコメントの状態を開発者が明示的に確定しなければなりません。つまり「Resolved」は自発的な同意ではなく、マージ条件を通過するための手続き行為でもあるのです。オープンソースの貢献者には、そうした強制はありません。
第三に、正解を作る主体が違います。 測定Aの「反映された」ラベルは、人間ではなくLLM(GPT-4.1 + o3-mini)がコミットを見て推論したものです(手作業アノテーションの部分集合で検証したと明記されています)。測定Bは開発者本人が付けたラベルです。
第四に、ツールとモデルが違います。 測定AはGitHub Actionの16種、測定BはQodo PR-Agentの1つです。
ここから得られる実務ルールは単純です。「コメント反映率N%」という数字を見たら、マージされたPRだけを数えたのか、ラベルを強制したのか、正解を誰が作ったのかをまず問うてください。この3つが分からなければ、その数字は他の組織の数字と比較できません。自分のチームの数字とも比較できません。
偽陽性はどれほど高くつくのか — テンセントの76%
偽陽性が「コストの大部分」だという話はよく出ますが、実際に測った数字はまれです。その1つがテンセントから出ました(arXiv 2601.18844、2026年1月)。
テンセントは自社開発の静的解析器BkCheckを、広告・マーケティングサービス(AMS)事業部のコードベースに回しています。2024年9月から2025年6月までの実際のアラームのうち、コードの文脈が確保できたものを選り分けて433件のデータセットを作りました。その構成が核心です。
- 偽陽性328件、真のバグ105件 → 偽陽性率76%
- 論文はここに但し書きを付けます。コードの文脈が不完全で除外されたケースまで勘案すると実際の偽陽性率は90%を超えると著者らは推定しています(これは測定ではなく著者の推定です)
- アラーム1件あたりの手動レビュー時間：ラウンドあたり約10分、最大2ラウンド → 10〜20分(開発者・レビュアー5名へのインタビューに基づく)
なぜこれほど高いのか。論文の説明は設計上の選択です — 企業向けの静的解析器はバグを見逃さないために精度より再現率を優先します。そのため実行不可能なパスまで保守的に警告し、結果としてオープンソースの解析器よりも偽陽性率が高くなります。
算数をしてみるとコスト構造が見えます。アラームが100件あればそのうち76件は空振りで、1件あたり10〜20分なら空振りだけで12.7〜25.3時間かかります。捕まえた24件の価値がこの時間を上回ってはじめて、ツールは得になります。「バグをN個見つけた」ではなく、この引き算が実際の損益計算書です。
LLMを偽陽性フィルタとして使うとどうなるか
同じ論文が続けて興味深いものを測定します。LLMに「このアラームは本物か」と尋ねるとどうなるでしょうか。基本プロンプトだけを与えた場合です。
| 手法 | モデル | 正解率 | 精度 | 再現率 | F1 |
|---|---|---|---|---|---|
| 基本プロンプト | GPT-4o | 0.50 | 0.28 | 0.66 | 0.39 |
| 基本プロンプト | Claude-Opus-4 | 0.40 | 0.26 | 0.83 | 0.40 |
| 基本プロンプト | Qwen-3-Coder | 0.55 | 0.29 | 0.62 | 0.40 |
| 基本プロンプト | DeepSeek-R1 | 0.43 | 0.27 | 0.84 | 0.41 |
| LLM4PFA (静的解析と結合) | GPT-4o | 0.93 | 0.93 | 0.75 | 0.83 |
| LLM4PFA (静的解析と結合) | Claude-Opus-4 | 0.93 | 0.83 | 0.88 | 0.85 |
| LLM4PFA (静的解析と結合) | Qwen-3-Coder | 0.94 | 0.93 | 0.79 | 0.86 |
| LLM4PFA (静的解析と結合) | DeepSeek-R1 | 0.93 | 0.84 | 0.86 | 0.85 |
基本プロンプト行の精度を見てください。0.26から0.29の間です。ところがこのデータセットでは真のバグのベースレートが105/433 = 24.2% です。つまり、すべてのアラームに「本物です」と答えるだけのダミー分類器の精度が24.2%だということです。最新モデル4つは、ベースレートより2〜5%ポイントましな程度です。これはシグナルではなく、ノイズに近いものです。
逆に、静的解析から抽出したパス制約(path constraint)をLLM推論に結合したLLM4PFAは、正解率0.93〜0.94まで跳ね上がります。論文の表現では、偽陽性の94〜98%を除去します。モデルを変えて得た結果ではなく、構造を変えて得た結果だという点が重要です。
ただし、アブストラクトの「高い再現率を維持しながら」という表現は、表を見ると注意して読む必要があります。LLM4PFAの再現率は0.75〜0.88です。真のバグの12〜25%がフィルタに引っかかって静かに消えるという意味です。論文の著者らもこれを分かっていて、企業は再現率を優先するのでClaude(0.88)やDeepSeek-R1(0.86)の組み合わせが実務にはより適していると書いています。偽陽性フィルタはタダではなく、偽陰性との交換です。
コストはアラームあたり2.1〜109.5秒、金額では0.0011〜0.12ドルです。人間が10〜20分かけるのに比べれば桁が違います。限界も明白です — データはテンセントのC/C++コードに限られ、機密のためデータセットは公開されていません。
Googleはこの問題を20年近くどう管理してきたのか
偽陽性ガバナンスについて、今なお最も具体的な公開資料はLLM以前の時代のものです。GoogleのTricorder論文(Sadowskiら、Communications of the ACM 2018年4月号、61巻4号)です。LLMの話は一行もありませんが、本稿のテーマにはむしろこちらのほうが正確です。
核心は「実効偽陽性(effective false positive)」という定義です。論文の定義を移すとこうなります — 開発者がそのイシューを見ても何の対処もしなかったなら、実効偽陽性である。解析器が間違った指摘をしたのに開発者が可読性のためにどのみち直したなら、それは実効偽陽性ではなく、逆に解析器が本物の欠陥を正確に指摘したのに開発者が理解できずスルーしたなら、それは実効偽陽性です。論文はこの区別の理由を明記しています — ツールの作者ではなく、開発者がそのツールの偽陽性率を決める。
その上にGoogleが打ち立てたルールがあります。
- コードレビュー段階に表示されるチェックは実効偽陽性10%まで許容(コンパイルタイムのチェックはより厳格)
- レビューチェックの4条件：理解可能であること、実行可能で直しやすいこと、実効偽陽性が10%未満であること(開発者が少なくとも90%は本物の問題を指摘したと感じられること)、コード品質に実質的な影響があること
- Tricorderはレビュアーの「Please fix」対「Not useful」のクリック比率を追跡します。この比率が10%を超えたら、その解析器を止めます — 作者が改善するまで
- 「Not useful」のクリックは自動的にイシューを生成し、解析器を所有するチームへルーティングされます
2018年1月時点の規模も併せて公開されています。1日およそ50,000件のコードレビュー変更を分析し、ピーク時には毎秒3回の分析が回っていました。レビュアーは1日5,000回以上「Please Fix」を押し、自動修正は1日およそ3,000回適用され、「Not useful」のクリックは1日250回でした。250割る5,000は5%です — 自分たちが決めた10%のしきい値の下です。数字がポリシーと噛み合っています。
ここから2つ持ち帰れます。1つは10%という具体的な基準線がすでに存在するということ、もう1つは止めるメカニズムがあってはじめて基準線が意味を持つということです。今日、どのAIレビューベンダーも「うちのツールの実効偽陽性率はX%で、超えたら自動的にチェックを止めます」とは言いません。
そして正直に付け加えると、Googleのこの定義には後で見る弱点があります — 実効偽陽性は開発者の行動で定義されますが、開発者の行動が常に品質判断だとは限りません。
レビューボットはPRを殺すのか — ノイズとPR放棄
最も新しい測定はMSR '26に掲載された研究です(arXiv 2604.03196、DOI 10.1145/3793302.3793614)。AIDevデータセットのPRレビューコメント19,450件から、実際のコードレビューエージェント(CRA)がレビューしたPR 3,109件を抽出し、そのうち「Commented」状態の2,456件を見ました。
| レビュアー構成 | PR数 | マージ率 | クローズ(放棄)率 |
|---|---|---|---|
| CRA単独 | 281 | 45.20% (127件) | 34.88% (98件) |
| 人間単独 | 1,176 | 68.37% (804件) | 21.60% (254件) |
差は23.17%ポイントで、カイ二乗検定の結果は84に近い統計量(83.0319、自由度8)、p値は0.001未満です。
続けて著者らは、放棄されたCRA単独PR 98件のコメントを「シグナル対ノイズ比」で分類しました。ランタイムエラー・クラッシュ・コンパイル失敗・API破壊・セキュリティ脆弱性を一次シグナル、アーキテクチャ・性能・保守性の問題を二次シグナルとして、コメント全体に対するシグナルコメントの割合を計算する方式です(研究者2名による独立分類、コーエンのカッパ0.75)。
- 98件中59件(60.2%)がシグナル比率0〜30%の区間 — コメントの3分の2以上が実行可能でない
- 31〜59%：14件(14.3%) / 60〜79%：7件(7.1%) / 80〜100%：18件(18.4%)
- CRA 13種のうち12種(92.31%)は平均シグナル比率が60%未満
- 個別ツール：Copilot 19.79%、
github-advanced-security[bot]27.62%、codefactor-io[bot]0.00%、entelligence-ai-pr-reviews[bot]52.29%(7件)、cursor[bot]43.40%(5件)
数字は印象的ですが、この研究の限界をそのまま書き写しておくことが重要です。まず、論文自身が「脅威」の節に書いているものから。
- 相関関係は因果関係ではない — 著者らが明示的に書いています。CRAが付いたからPRが死んだのか、もともと死にそうなPRに人間が付かずボットだけが付いたのか、この設計では区別できません
- シグナル分類がキーワードベースなので、キーワードのない有効なフィードバックを取りこぼしうる
- データがAI生成コードのあるGitHubリポジトリに限定される
そして、論文が書いていないことを1つ、私から付け加えます。シグナル比率を測った対象は「放棄された」PR 98件だけです。マージされたCRA単独PR 127件のシグナル比率は測定されていません。比較群がなければ「低いシグナル比率が放棄の原因」という結論をデータは支持できません — マージされたPRのシグナル比率も同じように低かったかもしれないからです。この研究が確実に示しているのは「CRA単独レビューのPRはより多く捨てられる」と「捨てられたPRのコメントはおおむね低シグナルだった」の2つで、その2つをつなぐ矢印はまだ仮説です。
この論文が狙った業界の主張も確認しておく必要があります。論文は「業界レポートは、CRAを有効にすればPRの80%に人間のコメントが不要になると主張している」と書いています。原典はQodoの2025 State of AI Code Qualityレポートです。
ベンダーの数字は何を測っているのか
Qodoのレポートを直接開いてみると、構造はこうです。
- レポートの骨格は開発者609名への調査です。「AIレビューを使う人の81%が品質改善を実感した」「10倍のスピード向上を主張するチームのうち69%が品質が良くなったと答えた」 — すべて自己報告の認識であって、測定ではありません
- 問題の80%は調査ではありません。「Qodo product insight」という別のタグが付いたベンダー自身の製品データであり、文言は「AIレビューツールを有効にすると、PRの80%に人間のコメントもレビューも付かない」です。分母も、期間も、リポジトリの母集団も、「人間のコメント」の定義も公開されていません
- 同じ形式の別の主張もあります — 「高深刻度(9〜10点)のイシューがPRの17%で見つかった」。深刻度を付けたのはQodo自身のモデルです
そして、確認できる事実を1つ。このレポートの全文に「false positive」「precision」「recall」という単語は0回登場します。品質を論じるベンダーの代表レポートに、精度も偽陽性率もないのです。
ここで公正のために付け加えることが2つあります。1つはMSR論文側の誇張です。「人間のコメントが付かなかった」と「人間なしで処理できる」は同じ意味ではありません — コメントなしで承認されたPRも、人間が見たものだからです。ベンダーの主張を批判する論文が、その主張を少し膨らませて引用したことになります。どちら側も注意して読む必要があります。
もう1つはQodoへのクレジットです。Qodoはあのレポートとは別に、方法論を公開したベンチマークを運営しています(2026年2月4日公開、3月12日修正)。
Qodoベンチマーク — 方法論があることと、信頼できることは別物だ
方法はこうです。実際にマージされたプロダクション級のオープンソースPRを持ってきて、LLMで欠陥を注入します。リポジトリごとのベストプラクティス規則を先に抽出してコンプライアンス違反を仕込み、さらに論理エラー・エッジケース・競合状態・リソースリークなどの機能バグを1〜3個追加で仕込みます。そうして作ったPR 100件、イシュー580件に8つのツール(Qodo + 競合7種)をデフォルト設定で回し、LLM-as-a-judgeで採点します。ベンチマークのリポジトリはGitHubに実際に公開されています(cal.com、tauri、redis、Ghost、aspnetcoreなどのフォーク)。
結果はQodoがF1 60.1% で1位です。ベンダー自己測定です。
この数字をどう読むべきか。まず、方法論とデータを公開したというだけで大半の競合よりましです。しかし、設計に構造的な問題があります。
- 偽陽性の定義がこの設計では壊れます。 Qodoの定義は「正解リストにないイシューを指摘したら偽陽性」です。ところが正解リストは注入した欠陥のリストです。ツールが元からそのPRにあった本物のバグを見つけると、偽陽性として集計されます。Qodoもこれを分かっていて、検証段階で自然発生のイシューを正解に手動追加すると明かしていますが、Qodoの検証者が見逃した本物のバグは依然としてツールの減点です。つまりここでの「精度」は、開発者が体感する偽陽性率と同じ代物ではありません
- 注入されたバグは自然発生のバグではありません。 欠陥の分布を注入器が決めます。注入器と同じ「欠陥観」を持つツールが有利です。その注入器を作ったのも、競争に参加したのもQodoです
- 採点がLLM審査です。 すぐ次の節で見ますが、コードレビューコメントに対するLLM審査は信頼性が測定されたことがあり、結果は良くありません
- 自分だけ設定が2つです。 競合ツールはデフォルト設定1つで回し、QodoはPreciseとExhaustiveの2構成を報告します
- 精度が低いことへのQodoの弁明は「精度は後処理でチューニング可能な次元であり、再現率こそが根本的な制約」というものです。一理ありますが、精度に難がある側がいかにもしたくなる主張でもあります
それでも、このベンチマークで最も引用に値する事実は別にあります。自分が設計し自分が採点したベンチマークで、1位のF1が60.1% だということです。マーケティング文句(「PRの80%に人間が不要」)と同じ会社が出した数字です。そしてQodo自身の観察によれば、残りのツールの大半は精度は高く再現率は極端に低い側に寄っています — いちばん分かりやすいものだけ指摘して黙っている戦略です。
測定そのものが崩れる地点 — 「解決済み」は正解ではない
ここまでの測定は、ほぼすべて「開発者がコメントに反応したか」に寄りかかっています。Googleの実効偽陽性も、Ganらの反映率も、Cihanらの73.8%も同じです。では、そのラベルは信頼できるのか。
2026年4月の論文が、まさにこれを検証しました(arXiv 2604.24525)。対象は先ほど出てきたBekoのまさにあのデータです。開発者がfixed/wontFixでラベルしたボットコメント2,604件(fixed 1,733件約66%、wontFix 871件約34%)にG-EvalとLLM-as-a-Judgeをそれぞれ二値/リッカート方式で回し、開発者ラベルとどれだけ一致するかを測りました。
| モデル | G-Eval 二値 | G-Eval リッカート | Judge 二値 | Judge リッカート |
|---|---|---|---|---|
| GPT-5.2 | 0.45 | 0.59 | 0.44 | 0.58 |
| GPT-4.1-mini | 0.48 | 0.62 | 0.57 | 0.61 |
| Gemini-2.5-pro | 0.51 | 0.57 | 0.53 | 0.55 |
一致率は0.44〜0.62。最高成績はG-Eval リッカート + GPT-4.1-miniの0.62です。興味深いことに、最も新しく最強のモデルであるGPT-5.2が最高ではありません。
その最高構成の詳細指標が、本稿で最も重要なくだりです。
| 指標 | GPT-5.2 | GPT-4.1-mini | Gemini-2.5-pro |
|---|---|---|---|
| 一致率 | 0.59 | 0.62 | 0.57 |
| F1 | 0.72 | 0.76 | 0.68 |
| 精度 | 0.67 | 0.66 | 0.67 |
| 再現率 | 0.78 | 0.90 | 0.69 |
| MCC | -0.0020 | -0.0590 | 0.0106 |
F1 0.76はもっともらしく見えます。一致率62%も悪くなさそうです。ところがMCC(マシューズ相関係数)はすべて0付近で、一部は負です。MCCはクラス不均衡を補正した相関係数で、0なら正解と何の相関もないという意味です。論文の表現どおり、一致率とF1だけを見ると審査者の信頼性が過大評価されるということです。
論文が報告した数字で直接算数をしてみると、より明確になります。正解の66.5%が「fixed」なので、すべてのコメントに無条件で「有用」と答えるダミー審査者の成績はこうなります。
ダミーベースライン (常に「有用」と答える):
精度 = 1733/2604 = 0.665
再現率 = 1.0
F1 = 2(0.665)(1.0)/(0.665+1.0) = 0.799
一致率 = 0.665
MCC = 0
最高成績のLLM審査者 (G-Eval リッカート + GPT-4.1-mini):
精度 = 0.66 再現率 = 0.90
F1 = 0.76 一致率 = 0.62 MCC = -0.059
ダミーベースラインは、F1(0.799対0.76)でも一致率(0.665対0.62)でも、最高のLLM審査者に勝ちます。これは私が論文の公開数値から計算したものであって、論文が明示している文章ではありません。ただ、論文がわざわざMCCを報告した理由(「データセットが不均衡なので」)と正確に同じ方向を指しています。
より根本的な問題は、なぜそうなるのかです。論文は、開発者ラベルそのものが正解ではないと見ています。
- BekoではPRのマージ前にすべてのコメントの状態を確定しなければなりません。つまりラベリングは義務です
- ソフトウェアエンジニアリングディレクターへのインタビューで出てきた話 — 特にwontFix側は開発者が非常に素早く選ぶ傾向があり、優先順位はたいてい、変更をプロダクションに入れることにあるからだ、ということです
- 評価パイプラインはPR diffと限られたメタデータしか見ませんが、開発者はランタイムの挙動・アーキテクチャ上の制約・PRの外にある安全装置まで総体的に考慮します。そのため切り離して見れば技術的に妥当なコメントが、実際にはすでに別の場所で処理済みだったり、チームが意図的に受け入れると決めたものだったりする可能性があります
論文の結論はこうです — 開発者の行動(解決/無視)はコメントの品質だけでなく、文脈的な制約、優先順位の決定、ワークフローの力学を併せて反映するので、客観的な正解として扱うことはできない。
これがGoogleの定義に戻ってきます。Googleの実効偽陽性は「開発者が対処しなかった」で定義されます。Bekoの研究は、その定義が組織の圧力を一緒に測ってしまうことを示しています。Googleの定義が間違っているという話ではありません — Googleは開発者の認識を測るために意図的にそう定義したのであり、それはツールを止めるかどうかを決めるにはまさに正しい指標です。ただ、その数字を組織間で比較したり「正確度」として読んだりしてはいけない、という意味です。
ここで本稿全体の骨格が現れます。レビューコメントの有用性を安価に自動で測る方法は、まだ存在しません。代理指標は組織の圧力に汚染されており、LLM審査はベースレートに勝てません。だから「AIレビューはうちのチームの役に立つのか」という問いには、今のところサンプルを抜き取って人間が直接読む以外に、信頼できる方法がありません。
では、チームは実際どう設定するのか
公開された証拠を総合すると、うまくいく設定には共通点があります。以下はすべて、上で引用した測定に基づくものです。
1. 狭く設定する。 汎用の「このPRをレビューして」が最悪です。テンセントで基本プロンプトLLMの精度がベースレート水準(0.26〜0.29対0.242)だったのが、この話です。逆に、静的解析のパス制約を結合して判断範囲を狭めたLLM4PFAは、正解率0.93〜0.94まで上がりました。モデルではなく構造を変えた結果です。
2. コメントをコードの位置に付ける。 Ganらの測定では、ハンク単位のActionの反映率(6.5〜19.2%)がファイル単位のAction(0.9〜4.2%)より一貫して高かったのです。同じ研究では、簡潔でコードスニペットを含むコメントのほうがよく反映されました。
3. 自動トリガーより手動トリガーのほうがよい。 これもGanらの結果です。人間が要請したときのほうがコメント反映率は高い。望まないときに押し込まれるフィードバックは、あまり読まれません。
4. 偽陽性予算を決め、超えたら止める。 Googleの10%が唯一検証された基準線です。重要なのは数字ではなく止めるメカニズムです — 「Not useful」ボタン、所有チームへの自動ルーティング、しきい値超過時の無効化。この3つがなければ、10%はただのスライドの数字です。
5. サンプルを抜き取って人間が読む。 Beko後続研究の勧告そのままです — 自動スコアは正解ではなく弱いシグナルとして扱い、何を検査するかの優先順位を決めるトリアージだけに使い、承認/棄却の決定には使わないでください。そして、モデルやプロンプトを変えるたびに再評価してください(同じ論文より：モデルとルーブリックによって一致率は0.44から0.62まで揺れます)。
6. 人間を外さない。 MSR研究の実務勧告は、CRAは人間のレビュアーを置き換えるのではなく補強するべきだというものです。同じデータで、人間が混ざったレビュー(61.09〜67.99%)はCRA単独(45.20%)より人間単独(68.37%)にずっと近い値でした。
いつ使うべきでないか
正直に、使うべきでない場合を書きます。
- 人間のレビューをなくす目的なら。 これを支持する公開された証拠はありません。ある証拠は逆方向です。
- スピードを得る目的なら。 Beko事例で、PRクローズ時間は5時間52分から8時間20分に延びました(p値0.001未満)。プロジェクトごとに分かれた点は重要です — プロジェクト#1は2時間48分から4時間38分に、#3は20時間22分から30時間51分に延びましたが、#2は6時間6分から3時間7分に縮みました。しかも、PRあたりの人間のレビューコメント数は有意には減りませんでした。論文の結論は、時間・労力の節減について一貫した証拠は見つからなかったというものです。
- レビュー文化がすでに緻密なら。 これはRust標準ライブラリ検証キャンペーンの回と同じ構造の話です。既存のテストとレビューがすでによく機能しているコードベースでは、新しいツールが拾えるものは大して残っていません。元が取れる場所は、既存の防衛線が薄い側です。
- 偽陰性が致命的なドメインでフィルタとして使うなら。 LLM4PFAの再現率0.75〜0.88を思い出してください。偽陽性を減らすフィルタは、真のバグの12〜25%も一緒に捨てます。
- 止める方法がないなら。 ノイズが出ても誰も止められないチェックは、数週間で全員に無視されるようになり、そこからは本物の発見まで一緒に埋もれます。Google論文の表現でいう「警告盲目(warning blindness)」です。
決定ルール
「状況による」で終わらせはしません。こうしてください。
- まず狭いチェック1つから始めてください。 セキュリティ規則でもスタイルでも、正解が機械的に確認できるもの。汎用レビュアーから始めると、最初の2週間のノイズでチームの信頼を失って終わります。
- 有効にする前に、偽陽性予算を文書で決めてください。 Googleの10%をデフォルト値として使ってください。別の数字を使うなら、根拠を書いてください。
- 止めるメカニズムを同じ日に作ってください。 「Not useful」に相当するボタン、所有者、しきい値超過時の無効化ルール。これがなければ1〜2番は無意味です。
- 自動スコアで判断しないでください。 4週間、コメントを無作為に50〜100件抜き取り、人間が直接読んで有用/無用を付けてください。そのサンプルが、あなたの唯一の信頼できるデータです。LLM審査パイプラインを立てたいなら、まずその審査者が多数クラスのベースラインに勝つかを確認してください。Bekoのデータでは勝てませんでした。
- スピードではなく欠陥で正当化してください。 時間節減には証拠がありません。捕まえた欠陥の数に、その欠陥がプロダクションに出た場合のコストを掛け、そこから開発者がノイズを読むのに使った時間を引いてください。これが正の値であってはじめて、点け続ける理由があります。
- 範囲を広げるのは、5番が正の値になってからです。
一文に縮めるとこうです。AIコードレビューは「レビュアー」として使うと失敗し、「狭くて止められるチェック」として使うと元が取れます。
おわりに
本稿を始めたときの問いは「AIコードレビューは使い物になるのか」でした。公開された測定値をすべて集めて眺めると、答えは「イエス/ノー」ではなく、こうなります。
証拠は薄い。ただし特定のやり方で薄いのです。研究はかなりあり、方向もおおむね一致しています — オープンソースでのAIコメント反映率(0.9〜19.2%)は人間(60%)にはるかに及ばず、静的解析アラームの76%は空振りで、レビューボットだけが付いたPRはより多く捨てられます。欠けているのは、汎用AIレビュアーのプロダクションでの精度・偽陽性率をベンダーと無関係に測った数字です。その場所にあるのは、ベンダーが自分のベンチマークで自分が1位になったF1 60.1%、組織の圧力に汚染された代理指標、そしてベースレートにも勝てないLLM審査者だけです。
だから、今度「AIレビュアーがバグのN%を捕まえました」というスライドを見たら、2つだけ尋ねてください。どのデータセットですか。そして偽陽性率はいくらですか。どちらか1つでも答えがなければ、そのN%は何も語っていません。
そして、この質問はベンダーだけにするものではありません。4週間後にあなたのチームのダッシュボードに表示される数字にも、同じように問うべきです。
参考資料
- Does AI Code Review Lead to Code Changes? A Case Study of GitHub Actions (Ganら、arXiv 2508.18771) — Action 16種・リポジトリ178箇所・コメント22,326件、反映率0.9〜19.2%対人間60%
- Automated Code Review In Practice (Cihanら、arXiv 2412.18531) — Beko事例、73.8%解決、PRクローズ5時間52分 → 8時間20分
- Understanding the Limits of Automated Evaluation for Code Review Bots in Practice (arXiv 2604.24525) — 同じBekoデータ2,604件、LLM審査の一致率0.44〜0.62、MCCほぼ0
- From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests (MSR '26、arXiv 2604.03196) — CRA単独マージ率45.20%対人間単独68.37%、シグナル対ノイズ比の分析
- Reducing False Positives in Static Bug Detection with LLMs: An Empirical Study in Industry (arXiv 2601.18844) — テンセント433件中偽陽性76%、LLM4PFAが94〜98%除去(再現率0.75〜0.88)
- Lessons from Building Static Analysis Tools at Google (Sadowskiら、CACM 2018年4月、61巻4号) — 実効偽陽性の定義、10%しきい値、Tricorderの運用規模
- Qodo — 2025 State of AI Code Quality (ベンダーレポート、調査n=609) — 「PRの80%に人間のコメントなし」の原典
- Qodo — How we built a real-world benchmark for AI code review (ベンダー自己測定) — PR 100件・イシュー580件の注入、Qodo F1 60.1%
- AI コーディングモデルの評価で信号とノイズを見分ける(関連記事)
- Rust標準ライブラリ検証キャンペーンが見つけたメモリ安全性バグは0件だった(関連記事)