AIコードレビュー、入れて本当に効いてる？ 指摘の正しさ・見逃し・人の手間・手戻りを分けて確かめる方法

AIコードレビューを入れた。指摘もたくさん出ている。

で、これ、本当に効いてるんでしょうか？

「指摘が増えた」は、効果じゃありません。「リバートが減った」も、AIレビューだけの手柄とは限りません。数字は出るのに、何が分かったのかがよく分からない。そんな状態になりやすいテーマです。

今回は、公式の運用報告と研究を原典まで当たって、「効いてる」を測るための分け方をまとめました。最後には、自分のチームで小さく試す手順と、そのまま使える記録表もつけています。

AIレビューを導入した開発チームの人、これから導入しようとしている人に向けて書いています。エンジニアでなくても、数字の読み方の話は役に立つはずです。

01先に結論

「効いてる？」は、1つの問いではありません。5つの別々の問いです。

1. 指摘は正しいか。 適合率（出した指摘のうち正しい割合）を見る。
2. 見逃していないか。 再現率（確認済みの問題のうち見つけた割合）を見る。
3. 修正につながるか。 直した・保留した・反論した、を数える。
4. 人の手間は減るか。 読む時間だけでなく、誤検知の調査や不要な修正まで足す。
5. 出荷後の品質は上がるか。 リバート、修正PR、障害を見る。

そして、公開されている証拠を全部読んで分かったことが、もう1つあります。

全チームに通用する「AIレビューでバグがX%減る」という数字は、今のところ出せません。 企業の運用報告、既知バグを探すベンチマーク、短いプログラムの修正実験は、対象も正解も予算も違うからです。だから「他社の数字を借りる」のではなく、「自分のチームで5つを分けて測る」のがいちばん確実です。

02用語を4つだけ

• 適合率（precision）：出した指摘のうち、正しいものの割合。
• 再現率（recall）：正解と確認できている問題のうち、見つけられた割合。
• 誤検知：問題ではないのに出した指摘。
• 見逃し：存在する問題を指摘しなかったこと。

適合率と再現率。この2つは、片方だけ見ると騙されます。静かなレビューは適合率が高く見えます。でも、重要なバグを黙って見逃しているかもしれません。逆に、大量に指摘するレビューは再現率が高く見えますが、人が確認する時間に見合うとは限りません。

031. 他社の数字は、どこまで信じていい？

まず、よく見かける数字を原典で読み直してみます。

Anthropicの「リバートが40%超減った」

2026年10月15日のAnthropic公式記事は、こう書いています。

From June to September, merged pull requests to Claude Code's codebase more than doubled while the share that had to be reverted fell by more than 40 percent.

6〜9月にマージされたPRが2倍超になり、リバートが必要になった割合は40%超下がった、という報告です。ここで読み取れることと、読み取れないことを分けます。

しかも「割合」と「件数」は別物です。説明用の架空例で見てみましょう。100件中10件のリバートが200件中12件になると、割合は10%から6%へ40%下がります。でも、あれ？ 件数は増えています。実際のAnthropicの件数を推定した例ではありません。

この事例から持ち帰れるのは、「AIレビューを足す」ではなく、実行できる検証、リスクに応じた人の判断、復旧までを含めて運用を作るという方向です。

「誤りとマークされた指摘が1%未満」

2026年3月9日の公式記事は、実質的なコメントが付くPRの割合が16%から54%になり、エンジニアが誤りとマークした指摘は1%未満だったと説明しています。

これは「適合率99%以上」ではありません。独立した人が全指摘を盲検で調べ、正しいかどうかを判定したわけではないからです。無反応だった指摘、面倒だから直した指摘、保留の指摘がどう数えられたかも分かりません。

「誤りと報告された率」「採用率」「適合率」は、別の欄に残しましょう。

なお、当時の記事にある「1レビュー15〜25ドル」という費用は、現行の固定単価ではありません。現行の公式文書では従量課金と説明されています。pushのたびに再レビューされると、回数も費用も増えると書かれています。

Alibabaの公開表：精度と見逃しはトレードオフになる

AlibabaのOpen Code Reviewは、READMEで評価表を公開しています。同じ基盤モデルでも、実行系によって結果が大きく変わります。数値は提供者が掲載したものを転記しており、こちらでの再測定はしていません。

分かるのは、この提供者の設定と採点では、精度・見逃し・費用の間に交換関係があることです。逆に、分からないこともあります。

• 表のClaude CodeがAnthropicのマネージドCode Reviewと同じかは確認できません。
• 「トークン約1/9」は全組み合わせ共通の比率ではなく、同額予算での比較でもありません。
• 適合率の残り（100%−適合率）を「幻覚率」と呼ぶのも不正確です。正解集合にない妥当な指摘や、同じ問題への重複指摘も、採点上は「不一致」になり得ます。

042. 研究の数字は、何を測っている？

「再現率15%の研究と72%の研究があるから、モデルが5倍進歩した」とは言えません。研究ごとに、何を正解にして何を測っているかが違うからです。主な研究がそれぞれ何を測ったのか、並べてみます。

CRBugBenchの数字には、もう1つ大事な点があります。GPT-5.6-Sol xhighの設定では、単独で既知バグの65.6%を回収し、費用は1課題1.50ドルでした。5回のensembleでは70.4%を回収し、費用は8.07ドルでした。改善はありますが、費用は5倍以上です。 同額での比較ではなく、お金を足した場合の結果です。

人の手間・誤検知・手戻りを見た研究

ここからが冒頭の③〜⑤にいちばん近い研究です。

Atlassian（RovoDev）： 1,900超のリポジトリで54,000超のコメントを生成。PRの周期の中央値は、AIコメントがあるPRで14.35時間、ないPRで20.73時間でした。人のコメントはそれぞれ平均2.87件と4.45件です。ただし、この比較は無作為割付ではなく、AIコメントが付くPRは性質が違う可能性があります。「人のコメント35.6%減」を「時間が35.6%減」とも言えません。欠陥の再現率やマージ後の障害削減は、直接測られていません。

CodeRabbitへの開発者の反応（Melbourne・Monash）： 239リポジトリ、10,191PR、31,073組の指摘と応答を分析。受け入れ36.4%、議論7.3%、拒否56.3%でした。ラベルは10%（297件）を人が付け、残りはGPT-5.1が付けています。

つまり、「AIレビューの半分は嘘」とは言えません。

拒否には事実誤認だけでなく、重複、範囲外、チームの意図や慣習との不一致が含まれます。反応のあった指摘だけの分布なので、無反応の指摘や、黙って採用された指摘は含みません。ただ、「技術的に正しくても、現場の負担に見合うとは限らない」ことは、この研究からうかがえます。

正常なコードを壊すレビュー： HumanEvalなどの正常コードに対し、GPT-4oは「簡潔に判定」条件では26.2%を誤って否定し、「説明と修正案を求める」条件では73.2%に増えました。詳しい理由が付くほど、もっともらしく見えます。でも、説明の立派さと信頼度は別です。この研究は元のコードと提案された修正をテストで比べる方法を提案しています。ただし短い問題の設定なので、率をそのまま業務PRへ当てはめてはいけません。

別のモデルにレビューさせれば直る？： LiveCodeBenchの116課題で、Claude Opus 4.7がCodexのGPT-5.5の修正をレビューすると、71.6→89.7%に改善（26件を直し5件を壊す）。逆向きは91.4→82.8%に悪化（3件を直し13件を壊す）でした。別モデルを入れれば必ず良くなる、ではなく、直した数と壊した数の両方を数えることが大事、という教訓になります。

人の理解という成果： コードレビューには、バグ探し以外の役割があります。Microsoftの古典的な研究（Bacchelli・Bird、ICSE 2013）は、知識の共有やチームの理解もレビューの成果だと整理しました。AIで人の確認を減らすなら、要件の合意や所有者の理解がどこへ移るかも決める必要があります。

053. 正解ラベルは、どう作る？

評価でいちばん大変なのが、ここ。「正解」は自分たちで作る必要があります。 しかも、どの集め方にも盲点があります。

ラベルは3つにする

• confirmed：仕様・コード・再現で、この変更の問題だと確認できた。
• rejected：既存のガードや意図した仕様などで、問題ではないと言えた。
• unknown：仕様が足りない、再現できない、専門家の意見が割れた。

unknownを、都合よく正解にも不正解にも入れないでください。件数と理由を出して、「全部正解だったら」「全部不正解だったら」の両方で計算し直すと、結果の揺れ幅が見えます。

また「正しいが既存のバグ」「正しいが今回の範囲外」「正しいが対応は延期」はよくあります。真偽、価値、対応は別の欄にします。

手順

1. 評価用のbase/headと、当時有効だった要件を固定する。
2. 履歴や事故記録から既知問題を集める（人のコメントだけにしない）。
3. 出力をまとめて、同じ根本原因の重複を整理する。どのツールの指摘かは採点者から隠す。
4. 可能なら二人が独立に、発生条件・影響・根拠・重大度を確認する。
5. 不一致は理由を残して裁定する。裁定前の一致率も残す。
6. 既知問題の回収と、新発見の妥当性を別に出す。
7. プロンプト調整に使う「開発用」と、最後に一度だけ見る「評価用」を分ける。

現実のバグを全部挙げることはできません。だから表記は「人手で確認した既知問題に対する再現率」にします。

064. 何を数える？

指摘の精度と見逃し

評価の単位は、コメントの数ではなく根本原因が1つの問題です。同じ問題に5コメント付けても、5バグ発見にはなりません。

TP = 妥当と確認した指摘（同じ問題は1つにまとめた後）
FP = 誤りと確認した指摘
FN = 固定した既知問題のうち、その条件で見つからなかったもの

precision = TP / (TP + FP)
recall    = 見つけた既知問題数 / 固定した既知問題数
F1        = 2 * precision * recall / (precision + recall)

落とし穴が3つあります。

• 指摘が0件なら、適合率は未定義です。0%として平均しないでください。
• 問題のないPRで指摘ゼロなのを「再現率100%」として平均しないでください。
• F1だけでは、重大な見逃しと軽い誤検知が同じ重さになります。重大度別の適合率・再現率と、上位k件で既知問題を見つけられた割合（recall@k）も並べます。

重大度は、AIが強い言葉を使ったかではなく、発生条件・影響・到達可能性で人が決めます。モデルの判定と人の判定を別の列にしておくと、「AIが重大と言ったものは本当に重大か」も後で確認できます。

誤検知の「率」と、確認にかかった時間

レビューでは「指摘しなかった可能な問題」を全部は列挙できません。そのため真陰性を定義しにくく、一般的な誤検知率（FPR）は出せません。代わりに、小さく運用するならこのあたりが分かりやすいです。

軽い誤警報10件より、複雑な競合状態の誤警報1件のほうが高くつくこともあります。件数だけで重みを決めないでください。

人の総作業時間

「人の手間」は読む時間だけではありません。

人の総作業分 = 通常の確認 + AI指摘の調査 + 対応判断・反論
              + 必要な修正 + 不要な修正 + 再確認
              + マージ後の調査・復旧

数字で見ると、「確認が減ったのに、総時間は増えた」という落とし穴がよく分かります。次は全て架空の例です（実在製品の実測ではありません）。同じ50PRを、AIなしとAIありで見たとします。

確認欄だけを見れば100分の減少。でも総作業は10分増えています。人件費を仮に1時間60ドルとすると、合計は現行360ドル、AI追加400ドルです。

ただし、これは「AIは損」という結論ではありません。AI追加で重大な不具合を防いでいれば、その価値は別に判断します。時間・費用・防いだ問題を、同じ紙面に並べるのがポイントです。

ほかにも気をつけたいことがあります。

• 機械の20分待ちを、人の20分節約と換算しない。人が待っている間に別の作業ができるなら、実作業分とは別に記録する。
• コメント数や承認数は補助にはなるけれど、時間の代わりにはならない。
• timeout、予算切れ、APIエラー、読めなかったファイルも、対象件数に残す。完了したレビューだけで精度を出すなら、完了率も併記する。

出荷後の品質

マージ日ではなく、実際にリリースされた日と、利用者への露出割合を記録します。まだ出荷していないPRと、全員に出たPRの「障害ゼロ」は同じではありません。観測期間が30日に満たないPRは、30日率に混ぜず「未成熟」にします。

075. 複数のAIを組むなら、何を切り分ける？

探索役、検証役、集約役……と役割を増やすなら、先に段階ごとの入口と出口を記録します。

多数決は、証拠による検証ではない

同じモデルを3回呼んで2回賛成でも、2回とも同じ誤った前提を共有しているかもしれません。3票は独立した専門家3人の検証とは違います。

検証役には「この結論に同意しますか」ではなく、次のものを渡します。

• 問題が成立する入力・状態・実行順序
• 既存のガード、呼出側、型、ライブラリの実際の仕様
• 誤りだとしたら何が観測されるか
• 可能なら、問題を示す最小のテストと結果

フィルタは「減らした手間」と「捨てた本物」の両方で測る

厳しいフィルタをかけると、静かになります。でも難しい本物の指摘も一緒に捨てるかもしれません。同じ候補集合に対して、フィルタあり・なしを比べます。

真の指摘の保持率 = 検証後に残った真の指摘 / 検証前の真の指摘
誤指摘の除去率   = 除去した誤指摘 / 検証前の誤指摘
フィルタの純費用 = フィルタの機械費用 + 残った指摘の人の確認費用

説明用の架空例（既知問題30件）で見ます。

厳しいフィルタはF1も適合率も上げました。でも、真の指摘を3件捨てています。その3件が重大な問題なら、F1だけでは導入を正当化できません。この表を見て「3件は何だった？」と聞けることが、数字を読む力です。

再レビューの暴走を止める

新しいcommitのたびにレビューすると、直したコードを壊したり、同じ指摘を繰り返したりします。Anthropicの記事では、3ラウンドを超えたら方針を見直す仕組みが説明されています。「3」が最適という証拠はなく、製品や変更のリスクで決める設定値です。ただし、上限に達したことを「問題なし」と報告せず、人が判断するのは共通して大事です。

08既存のテストやlintとの分担

AIは魔法の検査器ではありません。まず、再現性の高い検査を優先します。

既存のCIが確実に止めるエラーを、AIが言い換えただけなら、それは「追加のバグ検出」とは分けて数えます。ただし、早く知らせて修正を前倒しできた価値は別に測れます。

指摘をテストで確かめる手順

1. 指摘が主張する契約と発生条件を、文章にする。
2. その契約を、仕様や呼出側から確認する。
3. 修正前のheadにテストを当てて、主張した理由で失敗するか見る。
4. 最小の修正を当てて、同じテストが通るか見る。
5. 周辺の既存テストで回帰しないか見る。
6. 採用したテストを残し、修正理由と結ぶ。

失敗→成功だけでは足りない場合があります。テストが誤った仕様を要求していないか。別の理由で通っていないか。そこも確認します。また、既存テストを削除・緩和して通した修正は、通常の修正と分けて見ます。「テストで示せなかった」からといって、すぐに誤検知とは言えません。観測しにくい競合や仕様不足は、unknownで残します。

手元で試せる、ごく小さな教材

ラベル付けの練習用に、小さな教材を作りました。仕様は「discount_cents(total, percent)は、非負の整数金額と0〜100の整数割引率を受け取り、切り捨てた整数を返す。範囲外はValueError」です。

def discount_cents(total, percent):
    if total < 0 or not 0 <= percent <= 100:
        raise ValueError("out of range")
    return total * (100 - percent) // 100

def buggy_discount_cents(total, percent):
    if total < 0 or percent < 0:  # 上限の検査を欠く
        raise ValueError("out of range")
    return total * (100 - percent) // 100

このコードはローカルで実行して、全assertが通ることを確認しました（buggy_discount_cents(1000, 101)は-10を返します）。正常版とバグ版の両方を、同じプロンプトでAIにレビューさせてみてください。採点例は次のとおりです。

真の問題を見つけるかだけでなく、正常な0%や丸め方に、誤った修正を求めないかも見られます。ただし、この教材1件で業務のレビュー精度は測れません。AIレビューの実験はこの記事では行っていません。

09自分のチームで小さく試す

ここから先は公開研究から組み立てた提案です。件数や期間は、最適値ではなく始めやすい初期値です。

最初に決める：製品選びか、仕組みの研究か

• 製品を選ぶなら、各製品を実際の設定・費用・所要時間で比べます。モデルが違ってもかまいません（「システム全体の比較」と呼びます）。
• 複数エージェントの効果を調べるなら、同じモデル・同じ差分・同じ要件・同じツール権限で、呼び出し回数と検証だけを変えます。モデルが違うと、改善を「エージェントを増やしたから」とは言えません。

最低限の比較は3条件から始めます。

最初から条件を増やすと、人のラベル付けが破綻します。

予算と注意量をそろえる

1PRあたりの金額上限・時間上限・人が読む指摘の上限kを先に決めます。違うモデルでは、同じトークン数が同額・同計算量とは限りません。上限で打ち切られた分は未完了として集計に残します。

段階1：過去PRでオフライン評価

目安は開発用10PR、手を付けない評価用30PRです。評価用には既知バグのあるPRと、確認した範囲で問題のないPRを混ぜ、サイズ・領域・リスクを散らします。

注意が2つあります。

• 意図的にバグ入りPRを半分にした集合の適合率を、日常業務の適合率として使わない。実運用ではバグの出る割合が違います。「発見力の試験」と「普段の負担の試験」は分けます。
• 古いcommitをcheckoutしても、未来の履歴が残っていることがあります。base/headより後のgit履歴、PRの解決済み会話、後続の修正が、正解の漏洩になります。

手順は次のとおりです。

1. 目的、重大度基準、対象PR、予算、主指標、中止基準を、出力を見る前に固定する。
2. PRごとにbase/headを記録して、再現用のコピーを用意する。
3. 当時のレビュー時点のコードと情報だけを渡す。正解は別に保管する。
4. 条件BとCを独立に実行する。前の条件の出力を混ぜない。
5. 不安定さを見たい数PRは2〜3回実行して、平均だけでなく散らばりも残す。
6. 条件名を隠して、confirmed / rejected / unknown を判定する。
7. 人の通常レビューが見つけたものと比べる。AIだけが見つけた妥当な問題は、別に記録する。

評価用のPRでプロンプトの調整を続けると、数字は良くなっても、未知の変更にどれだけ強いかは分からなくなります。失敗事例を調整に使ったら、次回の評価用は入れ替えます。

段階2：シャドー運用で人の時間を測る

次は普段のPRを連続して30〜50件ほど対象にします。期間よりも、恣意的に選ばないことと、出荷後の観測期間を確保することを優先します。

• 既存のCI・人の承認要件は維持する。
• AIの指摘を別に保存し、人がAIを見る前に最初の判断を残す。
• そのあとAIを見せて、追加で見つかった妥当な問題、確認時間、必要・不要な修正を記録する。
• AIを見た後に判断が変わったかも残す。AIに引きずられた誤修正を拾えます。

ただし「人が先に見る」方式は、人が独立して問題を見つける力を測るには向いています。一方、この方式ではAIによる時間の節約は測れません。時間効果を知りたければ、次の段階で、担当者・領域・サイズを考慮して「AIあり／なし」にPRを割り付けます。無作為割付が難しければ、対応する群や時系列を使い、どんな交絡が残るかを書きます。

高リスクの変更で、評価のために必要な検査を外してはいけません。予備実験の結果を、人の承認を減らす根拠にそのまま使うのも避けます。

結果は、1つの点数で決めない

次の軸を同じ紙面に並べます。

「適合率80%以上なら導入」のような普遍的なしきい値は置きません。見逃した場合の影響と使える予算から、事前に決めてください。

小標本の落とし穴

30件のPRで重大な事故が0件だったとします。「ゼロ件なら安全」ではありません。独立・同確率という強い仮定を置いた概算でも、事故率の95%上限は約3/30＝10%です（1-0.05^(1/30)で計算して9.5%）。実際はPR同士が関係し、出荷後にも未発見の問題があるので、この近似を安心材料にしないでください。

信頼区間を出すなら、コメントを独立標本とせず、PR単位で再標本化するなどの方法を検討します。小標本ではパーセントより「分子・分母・具体的に見逃した内容」を見てください。

10そのまま使える記録表

実行単位（1回のレビュー実行ごと）

pr_id,base_sha,head_sha,condition,run_id,model_id,harness_version,prompt_hash,context_policy,tools_policy,effort,budget_usd,budget_seconds,status,files_expected,files_reviewed,input_tokens,output_tokens,cache_read_tokens,cache_write_tokens,cost_usd,elapsed_seconds

statusはcompleted / timeout / budget_exhausted / api_error / partialなど。files_reviewedは、出力の自己申告だけに頼らず、ファイルへのツールアクセス履歴と照らしてください。

問題単位（指摘ごと）

pr_id,condition,run_id,finding_id,root_cause_id,path,line,ground_truth_id,origin,new_or_preexisting,severity_model,severity_human,verdict,in_scope,evidence,triage_minutes,decision,decision_reason,fix_commit,regression_test,regression_result

PR・出荷単位

pr_id,condition,opened_at,first_human_review_at,merged_at,released_at,exposure,review_minutes,fix_minutes,recheck_minutes,postmerge_minutes,review_rounds,release_age_days,reverted_7d,reverted_30d,fix_forward_count,incident_count,incident_severity,attribution_status

未入力と0は分けます。観測期間が終わっていない30日欄は、空欄のまま「未成熟」として扱います。

探索レビューの依頼文（例）

対象はbase=<SHA>、head=<SHA>の変更です。
目的と有効な契約は添付の要件です。仕様が不明なら推測で追加しないでください。
対象変更が新しく導入した問題を探し、既存問題とは分けてください。
lint・型・既存テストで検出済みの問題は、重複と分かるようにしてください。

指摘ごとに次を出してください。
- 成立する具体的な入力・状態・実行順序
- 破られる契約と利用者への影響
- 根拠となるファイル・最小の行範囲・呼出関係
- 既存の防御・型・テストで防がれていないことの確認
- 反例または再現テスト。実行した場合は結果、しなければ未実行
- 重大度と、その理由
- 情報不足の点

指摘数の最低件数はありません。問題が確認できなければ、なしと答えてください。
コードは変更せず、許可された読取・検証だけを行ってください。
上限は<金額>/<時間>。未完了なら、読めた範囲と残りを報告してください。

再検証の依頼文（例）

これは候補指摘です。結論への同意ではなく、成立条件を独立に確認してください。
対象SHAと要件は同じです。呼出側・既存ガード・ライブラリ仕様も確認してください。
反証を探し、再現できるなら最小のテストで確かめてください。
出力は confirmed / rejected / unknown と、その根拠。
確認できないことだけを理由にrejectedへ落とさないでください。
重大度と新規性を、真偽とは別に答えてください。
未実行のテストを、実行済みと書かないでください。

この2つの依頼文の効果はこの記事では実測していません。使うときはプロンプトのhashを記録して、単独と再検証の比較で確かめてください。

11数字の言い換えチェック

最後に、記事やSNSで数字を見かけたときの読み替え表です。

12この記事で確認できていないこと

• 各研究・運用報告の数字は原典の記述の整理です。こちらでベンチマークを再実行したり、製品を比較したりはしていません。
• AnthropicとAtlassianの数字は、提供企業自身の運用報告です。因果効果ではありません。
• 同じモデル・同じ変更・同じ予算で、複数AI、決定的な検査、人のレビューを全部そろえて比べた公開データは、確認できた範囲では見つかりませんでした。
• AIレビュー単独でマージ後の障害を減らせるかを一般化できる証拠も、確認できていません。
• ここで提案した手順やプロンプトの効果は、未測定です。
• 検証したのは、教材コードの期待動作と、「事故0件の上限」の計算だけです。

13まとめ

• 「効いてる？」は、正しさ・見逃し・修正・人の手間・出荷後の品質の5つに分ける。
• 他社の数字は何を正解にして何を分母にしたかを確かめてから読む。
• 正解は自分たちで作る。confirmed / rejected / unknown の3つにして、unknownを隠さない。
• 人の手間は読む時間だけでなく、誤検知の調査・不要な修正・マージ後対応まで足す。
• フィルタや多数決は、減らした手間と捨てた本物の両方で測る。
• まず過去PR（開発10＋評価30）、次にシャドー運用で試す。

問いはシンプルです。そのレビューで、人は何を確認しなくてよくなって、何を余計に確認することになったか。そして、実際にどんな問題が残ったか。

まずは、直近のPRを5本だけ選んで、上の記録表の「問題単位」を埋めてみてください。5本でも、「見逃し」と「手戻り」が見えてきます。

14参考にした一次情報

• Anthropic, Solving code review at Anthropic（2026年10月15日）
• Anthropic, Code Review（2026年3月9日）／現行の概要／費用
• Alibaba, Open Code Review
• Yang et al., CRBugBench
• Zhang et al., c-CRAB
• Zeng et al., SWR-Bench
• Kumar, SWE-PRBench
• GitHub, ReviewBench
• Zhang et al., AACR-Bench
• Tantithamthavorn et al., RovoDev Code Reviewer
• Lin et al., Is Agentic Code Review Helpful?
• Jin and Chen, Are LLMs Reliable Code Reviewers?
• Xiang et al., Cross-Model LLM Code Review
• Vijayvergiya et al., AI-Assisted Assessment of Coding Practices in Modern Code Review
• Bacchelli and Bird, Expectations, Outcomes, and Challenges of Modern Code Review

関連記事：

• AIにPRレビューさせるなら、何を渡せばいい？
• プルリクエストのレビュー、どこまで見たら「完了」？
• AIが作る大量のPR、人間はどうレビューする？