AIコードレビューは修正履歴を見失う。MCR-Benchが測った複数ラウンドの弱点
AIにコードレビューを頼むと、最初の差分には鋭い指摘を返すことがあります。
ところが開発は、その一度で終わりません。指摘を受けてコードを直し、別の不具合が入り、追加の説明があり、もう一度レビューする。その頃にはAIが、直った問題をまた指摘したり、再発した問題を見落としたりします。
2026年8月27日に公開された論文「From Static to Dynamic: Benchmarking Real-World Code Review with MCR-Bench」は、この弱点を2,269件の実際のプルリクエストから作ったベンチマークで測りました。
評価した7モデルの欠陥検出F1は、最高でも0.551です。さらに、何度も修正が続くほど多くのモデルで精度が落ちました。
コードを読む力だけでは足りない。どの問題が新しく、どれが残り、何が直り、何が再発したのか。AIレビューには、欠陥の状態を追う力が必要です。
従来の評価は、開発を一枚の差分にしていた
多くのコードレビュー評価は、一つの差分をモデルへ渡し、問題点を一度だけ答えさせます。
この形式なら、入力と正解を揃えやすく、モデル同士も比較しやすいでしょう。しかし、実際のプルリクエストはもっと動きます。
レビュー担当者が「この例外処理では情報が消える」と指摘する。作者が修正する。別の担当者が「今度は戻り値の型が変わっている」と気づく。さらに直した結果、最初の不具合が形を変えて戻ることもあります。
一度の差分だけを採点すると、次の力は測れません。
- 以前の指摘が修正済みか覚えている
- 新しいコミットで入った欠陥だけを見つける
- 同じ問題を言い換えて重複報告しない
- 一度直った欠陥の再発に気づく
- 議論とコード変更を結び付ける
MCR-Benchは、コードレビューを静止画ではなく動画として評価しようとします。ここが従来との大きな違いです。
実PRのコミット、議論、修正を一つにつないだ
研究チームは、Python、Java、JavaScript、TypeScript、C#の公開リポジトリからプルリクエストを集めました。
対象は、100 stars超、1,500件超のPR、40%超のissue解決率など、一定の成熟度と活動量を持つリポジトリです。そこから、コードを変更し、マージされ、実際のレビュー後に追加コミットが入った事例を残しています。
最終的なベンチマークは2,269件です。
- Java：556件、24.50%
- C#：454件、20.01%
- TypeScript：440件、19.39%
- Python：410件、18.07%
- JavaScript：409件、18.03%
すべてのタスクに少なくとも2回のレビューラウンドがあり、平均は3.8ラウンドです。最長は10ラウンドまで含まれます。
単にコメント履歴を集めただけではありません。研究チームは、各欠陥を状態付きのカードにしました。
- new：そのラウンドで新しく現れた
- open：前のラウンドから未解決で残っている
- resolved：修正によって解消した
- reappeared：一度直ったが、後の変更で再発した
AIは各ラウンドの差分を読み、どの欠陥が存在するかだけでなく、その欠陥が今どの状態かも追います。
正解データはLLMだけに任せていません。5年以上の経験を持つ開発者6人が検証し、各タスクを2人が独立に確認しました。不一致は3人目が裁定し、最初の2人の一致度はCohenのkappaで0.87でした。
この人手確認の厚さが、MCR-Benchの強いところです。
最高の欠陥検出F1でも0.551だった
論文は、Claude Haiku 4.5、DeepSeek V3.2、Gemini 3 Flash、GLM-4.7、GPT-5.2、Kimi K2、Qwen3 Maxを評価しました。
欠陥検出の全体結果は次の通りです。
| モデル | 適合率 | 再現率 | F1 | |—|—:|—:|—:| | Claude Haiku 4.5 | 0.579 | 0.630 | 0.551 | | GPT-5.2 | 0.622 | 0.561 | 0.542 | | Gemini 3 Flash | 0.621 | 0.541 | 0.532 | | DeepSeek V3.2 | 0.625 | 0.455 | 0.490 | | GLM-4.7 | 0.596 | 0.442 | 0.470 | | Kimi K2 | 0.490 | 0.349 | 0.373 | | Qwen3 Max | 0.459 | 0.341 | 0.357 |
もっとも高いClaude Haiku 4.5でもF1は0.551でした。GPT-5.2は適合率が0.622と高い一方、再現率は0.561です。つまり、指摘した内容が当たりやすいモデルでも、存在する欠陥をかなり取りこぼします。
言語差もあります。多くのモデルはPythonとJavaScriptで比較的高く、TypeScriptとC#では再現率が落ちました。Qwen3 MaxはC#のF1が0.153で、全体値を大きく下げています。
ここで注意したいのは、0.551が「レビューの半分しか役に立たない」と直接意味するわけではないことです。論文のF1は、正解の欠陥カードとモデルの指摘を照合した結果です。実務の価値は欠陥の重大度や修正コストでも変わります。
それでも、実PRの履歴を追わせると現行モデルに大きな余白が残ることは明確です。
欠陥を見つける力と、状態を追う力は別だった
MCR-Benchは、欠陥を見つけるF1とは別に、欠陥状態を正しく追えた割合も測っています。
全体の状態追跡精度は、Claude Haiku 4.5が79.69%、DeepSeek V3.2が72.60%、GPT-5.2が71.23%でした。Kimi K2は45.95%、Qwen3 Maxは44.34%です。
興味深いのは、欠陥検出F1の順位と状態追跡の順位が完全には一致しないことです。
たとえばGPT-5.2は欠陥検出F1で2位ですが、状態追跡ではDeepSeek V3.2を下回ります。新しい欠陥を見つける力があっても、「前に指摘した問題が今どうなったか」を正しく保てるとは限りません。
コードレビューAIを選ぶとき、一度の指摘精度だけを見ると、この差を見落とします。
ラウンドが増えると、多くのモデルで精度が揺れた
論文は2ラウンド目から10ラウンド目までのF1も比較しました。
Claude Haiku 4.5は2ラウンド目の0.6495から、7ラウンド目で0.4768、10ラウンド目で0.2857へ低下しています。DeepSeek V3.2も0.5291から0.3333へ下がりました。
GPT-5.2は比較的粘り、2ラウンド目0.5995、7ラウンド目0.6238、10ラウンド目0.5000です。ただし途中の値は上下しており、長くなるほど単純に一定割合で落ちるわけではありません。
後半ラウンドのタスク数は少ないため、10ラウンド目の数字だけを強い因果関係として読むのは危険です。それでも、履歴が長くなると多くのモデルで安定性が崩れる傾向は確認できます。
これは長文を読めるかどうかだけの問題ではありません。
モデルは、前のコメント、修正内容、現在の差分、欠陥の状態を結び付ける必要があります。入力トークンが収まっていても、履歴を一つの文章として渡すだけでは、古い問題と新しい問題が混ざります。
エージェント化すれば解決するとは限らない
研究チームは、単純なプロンプトだけでなく、PR-AgentとHybrid-Reviewという二つのレビュー構成も比較しました。
ところが、エージェント的な枠組みを足しても一貫した改善はありませんでした。
たとえばDeepSeek V3.2は、直接評価の全体F1が0.490です。PR-Agentでは0.416、Hybrid-Reviewでは0.295でした。GPT-5.2も直接評価0.542に対し、PR-Agent 0.310、Hybrid-Review 0.275です。
これはPR-AgentやHybrid-Reviewが常に悪いという結論ではありません。論文の設定とプロンプト、モデルの組み合わせでの結果です。
ただし、「手順を増やせば自動的に賢くなる」という期待には釘を刺します。状態の表現が曖昧なまま呼び出し回数だけ増やすと、モデルは過去の誤解まで丁寧に引き継ぐことがあります。エージェント化は魔法の粉ではありません。残念ながら、かけてもキラキラするだけのことがあります。
評価にもLLM judgeの限界がある
コードレビューコメントは自由文です。同じ欠陥でも、説明の仕方は何通りもあります。そこで論文は、モデルの指摘と正解カードが同じ欠陥を指しているかをLLM judgeで判定しました。
研究チームは事前に人間との一致度を比較しています。
ROUGE-Lのquadratic weighted kappaは0.21、BLEU-4は0.27でした。文章の表面が似ているかを見る指標では、レビュー内容をうまく評価できません。
一方、欠陥の一致を判定するLLM-Hit-Judgeは最大0.73でした。論文はこの結果をもとに、GPT-5.2-proを主評価judgeとして採用しています。
0.73は強い改善ですが、人間と完全一致ではありません。ベンチマークの順位には、レビューするモデルだけでなく、採点するモデルの判断も入っています。
MCR-Bench自身がこの限界を隠さず、人間との一致度を先に測っている点は評価できます。ただし、0.551というF1を小数第3位まで絶対的な実力差として扱うべきではありません。
実務では、会話履歴より欠陥台帳を持たせる
ここからは論文結果をもとにしたAICompanyの実務提案です。論文が特定の商用レビュー製品で直接検証した設計ではありません。
AIレビューを複数ラウンドで使うなら、過去の会話をそのまま積むだけでなく、欠陥を構造化した台帳を持たせます。
最低限、各項目に次の情報を置きます。
| 項目 | 内容 | |—|—| | defect_id | ラウンドをまたいで変わらない識別子 | | file_and_symbol | 対象ファイルと関数、クラス、設定 | | state | new、open、resolved、reappeared | | evidence | 根拠となる行、テスト、再現手順 | | introduced_in | 最初に現れたコミット | | last_checked_in | 最後に確認したコミット | | severity | 影響度と優先度 |
新しいコミットが来たら、AIには全履歴の要約より先に、前回の台帳と今回の差分を渡します。
- openの欠陥がまだ残るか確認する。
- resolvedの欠陥が再発していないか確認する。
- 今回新しく入った欠陥を追加する。
- 同じ根拠の重複コメントをまとめる。
- 判定できない項目はopenのまま残し、証拠不足を明示する。
この構造なら、モデルが自然文の会話から状態を毎回推測する量を減らせます。人間のレビュアーも、AIがなぜ同じ問題を再度指摘したのか確認しやすくなります。
20件のPRで小さく再現する方法
自社で試すなら、2,269件を再現する必要はありません。
修正コミットが2回以上ある過去のPRを20件ほど選び、次の三条件を比べます。
- 今回の差分だけを渡す
- PRの会話と全差分をまとめて渡す
- 今回の差分と構造化した欠陥台帳を渡す
各ラウンドで、次の指標を記録します。
- 新しい欠陥の再現率
- 誤った指摘の割合
- 修正済み欠陥の重複報告数
- 再発した欠陥の検出率
- レビュー時間と入力トークン
- 人間が採用したコメントの割合
重要なのは、最初のラウンドだけで勝敗を決めないことです。2回目、3回目の修正で精度が保てるかを見ます。
欠陥台帳で再発検出が増え、重複指摘が減るなら、状態を明示する価値があります。変わらないなら、管理項目を増やすコストが上回ります。
まだ証明されていないこと
MCR-Benchは実PRを使っていますが、すべての開発現場を代表するわけではありません。
第一に、公開されている人気リポジトリが中心です。機密性の高い企業内コード、組み込み開発、小規模な個人プロジェクトでは、欠陥の種類もレビュー文化も変わります。
第二に、品質を上げるための一貫性フィルタが、特に曖昧で難しい事例を落としている可能性があります。残った問題でもモデルは苦戦していますが、現実の混乱はさらに大きいかもしれません。
第三に、正解カードは人間が確認したものの、候補抽出にはLLMを使っています。人手の一致度は高い一方、完全に機械から独立した収集ではありません。
第四に、主評価はLLM judgeです。人間との一致度0.73は従来指標より高いものの、採点誤差は残ります。
第五に、後半ラウンドは件数が少なくなります。10ラウンド目の低下を、そのまま文脈長だけの効果とは断定できません。
第六に、評価したのは特定時点の7モデルです。将来のモデルや、リポジトリ専用に調整したモデルへ順位を一般化できません。
最後に、AICompanyは公開リポジトリ、dataset blob、評価スクリプト、Apache 2.0ライセンスを確認しましたが、有料APIを使う全モデル評価は再実行していません。
結論
MCR-Benchが突きつけたのは、AIコードレビューの難しさはコード量だけではないということです。
実際の開発では、欠陥が現れ、残り、直り、再発します。モデルは最新の差分を読むだけでなく、その変化を覚えていなければなりません。
2,269件の実PRで、欠陥検出F1は最高でも0.551でした。状態追跡の強さもモデルごとに異なり、ラウンドが深くなると多くのモデルで精度が揺れました。レビュー手順をエージェント化しても、自動的な改善は見られませんでした。
実務で次に試すべきことは、さらに長い会話履歴を詰め込むことではありません。
欠陥へ安定したIDを付け、new、open、resolved、reappearedを明示し、最新の差分と一緒に渡す。AIに記憶力を期待する前に、忘れにくい仕事の形を作ることです。
優秀なレビュアーは、同じコードを何度も読む人ではありません。前回から何が変わったかを覚えている人です。AIコードレビューも、ようやくそこを測られる段階に入りました。