AIレビューの指摘、全部直したら良くなる？ 直して壊す・昔の問題が湧く・往復が終わらないときの止めどころ
AIレビューの指摘を「全部直して、指摘ゼロになるまで回す」と、何が起きるのか。Anthropicの50回超の往復、論文が測った「直して壊す」、自分で回した48回のレビュー→修正ループ（43行のコードが193行に）から整理しました。止めどころの決め方、仕分けの軸、コピペできる依頼文つき。
文・ニコ
AIにコードを書かせて、別のAIにレビューさせる。指摘が出たら、そのまま直させる。そしてまたレビューさせる。
便利ですよね。ぼくも「指摘がゼロになるまで回せば、そのうち完璧になるでしょ」と、ちょっと思っていました。
でも、本当にそうでしょうか？
- 直したせいで、前は動いていたものが壊れたりしない？
- 2周目、3周目で「そこ、前からあったよね？」という指摘が出てこない？
- そもそも、ゼロになる日は来るの？
この3つの心配を一次資料で確かめ、さらに自分でもレビュー→修正のループを48回まわしてみました。その結果をもとに、「いつ止めるか」を決める方法をまとめています。
先に結論
- 「指摘ゼロになるまで直す」は終わりの条件として弱い。 指摘は、直すたびに別のものが出てきます。
- 「直して壊す」は起きる。 論文でも、ぼくの実験でも、元は正しかったコードが修正で壊れました。
- 「昔の問題が湧く」も、起きる。 Anthropicの運用報告では、往復のなかでレビュー役が指摘し続けた箇所の約59%は、最初のレビューの時点からあったコードでした。
- ぼくの実験では、「全部の問題を挙げて」と頼むと、最もコードが膨らんだランでは、正しい43行のコードが6回の修正で193行になった。 一方「仕様に違反しているものだけ、具体的な入力つきで」と頼むと、正しいコードには指摘が出ないのが大半でした。
- 止めどころは「確認済みの、今回の変更が原因の、要件違反」で決める。 指摘の数ではなく、中身で数えます。
こんな人に向けて書いています。
- AIの指摘を直す作業を、そのままAIに回し続けている人
- 「AIレビューが終わらない」「直したら別のところが壊れた」を経験した人
- 自分のチームで、レビューの回数や止め方を決めたい個人開発者・小規模チーム
用語を3つだけ
エンジニアの人は読み飛ばしてOKです。
- レビュー役・修正役：コードを見て指摘する役と、指摘を受けて直す役。この記事では、どちらもAIです。
- 回帰（リグレッション）：直したせいで、前は動いていた部分が壊れること。
- 既存の問題（pre-existing）：今回の変更とは関係なく、前からコードの中にあった問題。
起きること1：直して壊す
まず「直す作業は、ちゃんと良くなる方向に働くのか」から見ます。
外から答えをもらえないと、正解を不正解に変えやすい
Huang et al.（ICLR 2024）は、外から正解の情報を与えず、AIに「さっきの答えを見直して」と頼むだけで答えが良くなるかを調べました。常識問題のCommonSenseQAでは、GPT-3.5の正答率は、見直し前が75.8%、1回見直した後は38.1%になりました。
論文の説明が印象的です。モデルは「誤答を正解に直す」より、「正解を誤答に変える」ことのほうが多かったというのです。コードではなく推論の課題ですが、「見直せば良くなる」は自動では成り立たないことを示しています。
コードでも、直す回数が増えると正解が減る
コードの話に近い研究を3つ挙げます。どれも小さめのモデルや限られた課題での結果なので、「いまのAIがこうなる」とは言えません。「こういう壊れ方が測られている」という材料として読んでください。
| 資料 | 何を測ったか | 結果 |
|---|---|---|
| Wang-Lin et al.（2026年9月、arXiv 2609.10123） | バグを探して直すループを繰り返す。Gemini 2.5 Flash-LiteとQwen2.5-7B。競技プログラミングのC++ | バグのないコードにも「バグがある」と言い続け、直した結果、正解のコードが壊れる確率が、壊れたコードが直る確率を上回った。同じ変更を足しては戻す「疑似バグ修正の循環」にも入る |
| Gao et al.（Alibaba Cloud、arXiv 2607.24604） | 「生成→テスト→修正」を3回。HumanEvalの30課題、小型モデル | 1回目の修正後に正解だった軌跡は82.0%。2回目は67.3%、3回目は69.3%。途中で一度正解を出したのに、後で失った軌跡が16.0% |
| Shukla et al.（IEEE ISTAS 2025） | GPT-4oに「コードを改善して」を10回繰り返す。400サンプル | 5回目までに重大な脆弱性が37.6%増えた。著者は、人の確認なしにAIだけで繰り返すのは最大3回までと提案 |
Wang-Lin et al.は1回に1か所ずつ直す形式のGemini 2.5 Flash-Liteで、正しいコードから始めた場合の1ステップあたりの確率も出しています。正しい状態から壊れる確率は約29%、壊れた状態から直る確率は約6%でした（表2、温度0）。直す側に「直す先」がなければ、動かし続けること自体がリスクになるんです。
Gaoらは壊れる原因のひとつに「古い実行結果」を挙げています。いまのコードではなく、前のコードの結果に基づいて直すと、直したはずの部分が元に戻ることがあるのです。レビューの指摘にも当てはまります。前のラウンドの指摘を、直した後のコードに当てはめ直さずに使い回すと、同じ状況が起きます。
1回のレビューでも、壊すことはある
前の記事（AIが書いたコード、別のAIに見せれば客観的？）で紹介したXiang et al.（2026）の116問の実験は、レビューが1回だけの結果です。同じ論文の表で、Claudeが書いたコードをCodexにレビューさせると、直ったのは3問、壊れたのは13問でした。1回の見直しでも、レビュー役と作者の組み合わせによっては、差し引きでマイナスになるんです。
ここまでの話をまとめると、こうなります。
- 修正は「良くなる方向」にだけ働くわけではない。
- 回数を重ねるほど、壊れるチャンスも重なる。
- 外から「正しい基準」（テスト、要件、人の判断）を持ち込まないと、AIは自分で正解と不正解を見分けにくい。
Olausson et al.（ICLR 2024）も、AIが自分のコードを直す「自己修復」は、費用も含めて考えると、改善が小さかったり、無かったりすると報告しています。ボトルネックは自分のコードに対するフィードバックの質でした。強いモデルや人間のフィードバックを入れると、改善は大きくなっています。
起きること2：昔の問題が湧く
次に「2周目で、前からあった問題が出てくる」現象です。
Anthropicは2026年10月15日の記事「How the Claude Code team does code review」で、自社のレビュー運用を公開しています。そのなかに、こんな話があります。
夜のうちに、レビューと修正を50回以上往復したCLIのPRがあった。作者が止めた。 レビュー役が指摘し続けた箇所に
git blameをかけたら、約59%は、レビュー役が最初に見た時点からあったコードだった。レビュー役は、新しいバグをほとんど見つけていない。毎回、古いバグを少しずつ見つけていた。
（要約です。原文は英語）
ここで気をつけたいのは、「59%が誤検知」という意味ではないことです。古いコードに本物のバグがあることもあります。ただ、今回の変更とは別の話を、今回のPRの中で延々と直し続けることになっていたわけです。
Anthropicはこの運用の反省として、次のように書いています。
- 毎回「新しいものが見つかるから」と、複数ラウンドを既定にしていた。リスクの高い変更ならそれも価値があるが、全部のPRに必要ではない。
- 「ラウンド数」も「見つけた数」と並べて測るようにした。
- 再レビューのやり方を変えた：3ラウンドで「方針を見直して」と作者に返す／数回目以降は追加差分に絞る／同じ種類のバグは種類ごとまとめて指摘する／すでに出した指摘は繰り返さない。
結果は同社の社内PRでの前後比較です。これだけで因果関係があるとは言えません。
| 変更前 | 変更後 | |
|---|---|---|
| 1回のレビュー・修正で通る | 65% | 78% |
| 5回以上かかる | 8.9% | 1.5% |
| 通るまでの平均レビュー回数 | 2.08 | 1.32 |
Claude Codeの製品ドキュメントにも、同じ考え方が見えます。重要度は「Important（マージ前に直すべきバグ）」「Nit（細かい指摘）」「Pre-existing（この変更で入ったものではない、既存のバグ）」の3段階。そして、あとから自動で始まる再レビューは、前回から変わった部分に絞り、nitや既存の指摘を減らすと書かれています。同じ種類の指摘が繰り返し出るときは、REVIEW.md にルールを足すことも勧めています（2026年10月23日に確認）。
つまり、「昔の問題」を今回のループから外す仕組みが、製品側にもあるわけです。
起きること3：往復が終わらない
3つめは、そもそも往復が終わらないことです。
Wang-Lin et al.はバグ探し→修正を最大100回繰り返したとき、同じ変更を足しては戻す循環に入りやすいことを報告しています。1つずつ直す形式のほうが、ファイル全体を書き直す形式より、循環に入る回数も長さも大きくなっていました。
Anthropicの「50回超」も、レビュー役と作者AIがお互いを動かし続けた例です。原文には、こんな文があります。
ノイズは、作者がエージェントのときのほうが高くつく。人間なら、nitは数秒で受け流せる。エージェントは、直す。つまり、もう1回のコミットと、もう1回のレビューが生まれる。
（要約）
ここが大事なところです。人間なら「まあいいか」で流す指摘を、AIは全部直しに行きます。 直せば差分が増えて、差分が増えれば、また指摘が増えます。
実験：レビュー→修正を、自分で回してみた
ここまでは、他の人たちの研究や運用の結果でした。「いまのClaudeでも、同じことが起きる？」は、公開された資料では分かりません。そこで、ぼくも小さな実験をしました。
やったこと
- 小さなPythonモジュールを4つ用意しました。2つは正しいコード、2つは仕様と食い違う本物のバグを1つずつ仕込んだコードです。どれも、要件を書いたdocstringがついています。
- 要件から先に、隠しテストを書きました（請求書17件、レート制限15件、範囲10件、アクセス権10件）。レビュー役・修正役には見せません。
- レビュー役と修正役を、毎回新しい会話で交互に動かします。 履歴もツールも渡しません。修正役は指摘を全部直して、ファイル全体を返します。
- 指摘が0件になるか、修正が6回になるまで回します。毎ラウンドの前に、隠しテストを実行して記録します。
- モデルは Claude Sonnet 5.5 と Haiku 4.5。レビュー役への頼み方を2通り試しました。
- 全部挙げて：「見つけた問題を全部挙げて」
- 仕様違反だけ：「docstringが仕様。仕様に違反する欠陥だけ。具体的な入力と、期待値・実際の結果を添えて。スタイル、性能、予防的な提案、仮定の話は挙げない。0件でも構わない」
- 4モジュール × 2モデル × 2頼み方 × 3回 = 48ラン。使った料金はAPI換算で約9.3ドルです（実際の請求額ではありません）。
結果1：正しいコードに、指摘が出続ける
まず、隠しテストに全部通る、正しいコードの12ラン（2モジュール×2モデル×3回）です。
| 全部挙げて | 仕様違反だけ | |
|---|---|---|
| 最初のレビューで指摘0件 | 0 / 12 | 11 / 12 |
| 修正を回した回数（12ランの合計） | 49 | 2 |
| 上限の6回まで回った | 4 / 12 | 0 / 12 |
| 途中で、全テスト通過→失敗になった | 4 / 12 | 0 / 12 |
| 最後にテスト失敗のまま終わった | 3 / 12 | 0 / 12 |
| API換算の費用（12ランの合計） | 約5.7ドル | 約0.6ドル |
「全部挙げて」では、最初のレビューで0件になったランが1つもありませんでした。Sonnetは最初のレビューで平均5.7件（4〜7件）、Haikuは平均1.8件（1〜3件）を挙げました。正しいコードなのに、です。
ひとつ正直に書いておくと、レート制限器の仕様に「使われなくなった時刻の記録が、ずっと溜まり続けてはいけない」という一文があり、使われなくなったキーの扱いは、仕様があいまいでした。ここを突く指摘は完全な言いがかりとは言えません。「仕様違反だけ」でも、Haikuの1ランが同じ指摘を出し、3行の修正でテストは通ったままでした。ただ、困ったのは、そこから先が止まらなかったことです。
結果2：直すたびに、コードが膨らむ
これは、Sonnetでコードが最も膨らんだ1ランです。43行の正しいコードが6回の修正で193行になりました。最後の状態では、隠しテストが1件落ちています。
面白いのは、回を追うごとに指摘の中身が変わっていくことです。
- 最初（元のコード）：キーが溜まり続ける／NaNを渡すと時刻チェックが効かない／真偽値が通る／スレッドセーフでない
- 途中：「古い状態を消す処理が、まだ有効な記録まで消すので、上限を超えられる」「全体のロックの下で、全件走査している」
- 最後の方：「ロックの中で、キーの
__hash__が再入すると、デッドロックしうる」「ヒープに古いエントリが溜まる」「遅延クリーンアップは、呼び出しが続くことが前提」
後半の指摘は元のコードには無かった仕組み（ロック、ヒープ、掃除処理）についての指摘です。 前のラウンドの修正で持ち込んだものが、次のラウンドでは指摘の的になっています。Anthropicが言う「新しいバグをほとんど見つけていない。古いバグを少しずつ」とは少し違う姿ですが、構造は同じです。「全部直す」が次の指摘の材料を作っています。
12ランの最終的なコードの長さはSonnetで元の2.2〜6.2倍、Haikuで1.0〜1.8倍でした。修正で書き換えた行数（累計）の平均は、Sonnetが347.7行、Haikuが28.5行です。このお題では、強いモデルほど指摘が細かく、修正も大きくなりました。 ただし、モデルは2つ、お題は4つだけなので、「Sonnetはこうなる」という一般論にはしません。
結果3：「直して壊す」「ゼロなのに壊れている」
「全部挙げて」の24ラン（正しいコード12、バグ入り12）で、隠しテストが全部通る状態から、失敗に変わったことが5回ありました。
| ラン | 何が壊れたか | 元の指摘 |
|---|---|---|
| Haiku・レート制限器 | 時刻が巻き戻ったときのエラーが、出なくなった（次の修正で戻った） | キー辞書の肥大化、型チェックの書き方 |
| Sonnet・アクセス権 | suspended キーが無いdocで、共有されたユーザーまで閲覧を拒否されるようになった | 「不足・不正なフィールドが黙って既定値になる」 |
| Sonnet・レート制限器 | 時刻のチェックが「キーごと」から「全体」に変わり、別のキーより古い時刻を渡すとエラーになった。最後まで直らなかった | 古い状態の掃除が、まだ有効な記録まで消す |
| Sonnet・レート制限器（2件） | 隠しテストが、内部の記録用変数を直接見ていた。修正で持ち方が変わって落ちた | メモリの肥大化 |
最後の2件は、ぼくが書いたテストの側に原因がありました。実装の中身に依存していたんです。振る舞いの壊れ方ではないので、割り引いて読んでください。 上の3件が仕様どおりの振る舞いが変わってしまった例です。
2行目はまさに「修正が契約を変える」例です。「不足したフィールドが黙って既定値になる」は、指摘として筋が通っています。でも、直した結果、いままで通っていた呼び出しが拒否されるようになりました。
もうひとつ気になるのが、3行目のランです。最後のレビューで「指摘0件」を返して終わっているのに、隠しテストが1件落ちたままでした。48ランのなかで、「指摘ゼロ」で止まったのに壊れていたのは、この1件だけです。でも、1件あれば十分です。「指摘ゼロ」は「正しい」の証明ではありません。
累計編集行数は各修正stepの追加行＋削除行の和です。1行の置換は2行と数え、再編集や取り消しも毎回数えます。保存データのcum_changedは元コードからのnet diffであり、累計ではありません。本文と集計はstep_changedの和へ訂正しました。
結果4：本物のバグは、1回目の修正で直った。その後は
バグを仕込んだ24ランでは、どちらの頼み方でも、本物のバグは、全ランで1回目の修正で直りました（24/24）。「全部挙げて」のほうが、見つける力が高いわけでも、低いわけでもありません。
違いは、その後です。
| バグ入り12ラン | 全部挙げて | 仕様違反だけ |
|---|---|---|
| バグが直った後に、さらに回した修正（1ランの平均） | Sonnet 2.3回／Haiku 1.0回 | 0回 |
| バグが直った後に、書き換えた行数（1ランの平均） | Sonnet 106.7行／Haiku 8.3行 | 0行 |
| バグが直った後に、テスト失敗に戻ったラン | 1 / 12 | 0 / 12 |
| API換算の費用（12ランの合計） | 約2.3ドル | 約0.7ドル |
初回green後の行数は、最初にテスト失敗が0になったrowから末尾までの修正stepの和です。greenになる直前の修正は含めません。green未到達runは平均から除外しますが、保存済みデータは全24ランが到達し、表のモデル別平均は各6ランです。
この実験では、バグが直った後に修正を重ねても、隠しテストで測れる範囲では、ひとつも良くなりませんでした。 あったのは、コードの膨張と、1件のテスト失敗です。
この結果を、どう読むか
- 「全部挙げて」より「仕様違反だけ」のほうが良い、とまでは言い切れません。ぼくの実験は、仕様がdocstringに完全に書いてある小さなモジュールです。実際のPRでは、仕様が一部しか文章になっていません。「仕様違反だけ」と頼むと、仕様に書かれていない要件の抜けは、見えなくなります。
- 言えるのは、「仕様に照らした根拠（入力と期待値）を要求すると、少なくともこのお題では、延々と続くループが起きなかった」ことです。
- 修正役も「全部直す」ではなく、「確認できたものだけ、最小限に」にすると、結果は変わるかもしれません。それは今回は測っていません。
実験の限界は記事の最後にまとめます。
止めどころの決め方
さて、どこで止めればいいのでしょう？ ここからがこの記事のメインです。研究と実験をもとに、止めどころの決め方を5つに整理しました。
1. 終わりの条件を、「指摘ゼロ」から変える
「指摘がゼロになるまで」の代わりに、こう決めます。
確認済みの、今回の変更が原因の、要件違反が残っていない。
3つの条件が全部入っています。
- 確認済み：再現するか、コードを読んで裏が取れた。AIが「そう思う」だけではない。
- 今回の変更が原因：変更前のコード（base）では起きず、変更後（head）で起きる。
- 要件違反：好み、予防的な提案、スタイルではない。
この条件に当てはまらない指摘は、「直さないもの」として扱います。捨てるのではなく、別の列に入れます。
2. 指摘を、直す前に仕分ける
修正役に渡す前に、指摘を1件ずつ次の3つの軸で仕分けます。仕分けるのは人でも、別のAIでもかまいません。
| 軸 | 値 | 直すか |
|---|---|---|
| 真偽 | 確認済み／否定／不明 | 確認済みだけ |
| 変更との関係 | 今回で入った／既存／今回の変更で到達可能になった既存／不明 | 「今回で入った」と「今回の変更で到達可能になった既存」だけ。「既存」は別のissueへ |
| 種類 | 要件違反／予防的な提案／好み | 要件違反だけ |
「既存」は、行が古いかどうかだけでは決まりません。変更されていない行でも、新しい呼び出し元から初めて到達して問題になることがあるからです。「今回の変更で到達可能になった」は、直す対象です。
詳しく分類するときは、前の記事の評価票も使えます。
3. 修正は「その指摘だけ」、確認は「元の要件テスト」
修正役にはこう頼みます。
- 直すのは、仕分けで「直す」になった指摘だけ。
- 公開している関数名・引数・挙動は変えない。
- テストの削除、skip、assertの緩和は禁止。
そして修正後は指摘を再現したテストと、元の要件・回帰テストの両方を回します。前者だけだと、「指摘されたテストだけ通す」過適合が起きます。実験でも、指摘を直したら別の振る舞いが変わった例がありました。
テストが無いなら、せめて直す前に「どの振る舞いを変えてはいけないか」を3つ書いて、修正役に渡します。
4. 上限を、ラウンドを始める前に決める
上限は1つではなく、複数を併用します。どれか1つに達したら止めます。
| 上限 | 初期値の例 | 根拠 |
|---|---|---|
| 修正の回数 | 最大2回、レビューは3ラウンドまで | Anthropicは3ラウンドで方針の見直し。Shuklaらは、人の確認なしのAI反復を最大3回に |
| 差分の大きさ | 書き換えた行数の累計が、元のコードの行数を超えたら止める | 実験のSonnetは、累計347.7行の書き換えで、コードが2〜6倍に膨らんだ。目安であって、実証された値ではない |
| 同じ指摘の繰り返し | 同じ指摘が2回出たら止めて理由を残す | 同じ変更の足し戻し（Wang-Linらの循環）、A→B→Aの往復 |
| 金額・時間 | 1変更あたりの上限を先に決める | 費用は実験で、同じ「正しいコード」でも約10倍の差が出た（約5.7ドル対約0.6ドル、12ラン合計） |
これらはぼくの提案で、最適値として実証されたものではありません。 自分のチームの数字で調整してください。「止めた」ことがどう記録されたかも、残します。
5. 止めた理由を、「問題なし」と分けて残す
前の記事（AIエージェントの「完了しました」は信じていい？）と同じ考え方です。終わった理由と、確認できたことは別に書きます。
| 終了の理由 | 意味 | 人に返す？ |
|---|---|---|
no_confirmed_findings | 確認済みの要件違反が残っていない | 出荷判断だけ |
round_cap | 回数の上限に達した | 返す（問題なしではない） |
budget_exhausted | 金額・時間の上限に達した | 返す |
cycle_detected | 同じ指摘・同じ変更の往復 | 返す。要件の食い違いの可能性 |
diff_grew | 差分が想定を超えた | 返す。別の変更として扱う |
needs_human | 再現できない／要件が不明 | 返す |
特に、round_cap と budget_exhausted を「指摘ゼロ」に混ぜないことです。
指摘を出す側の設定も、見直す
ループを短くするには、直す側だけでなく、指摘を出す側の設定を見直すのも効きます。実験で一番効いたのは、レビュー役への頼み方でした。
レビュー役への依頼文（そのまま使えます）
目的：この変更が導入した、要件を破る欠陥だけを探してください。
base=<SHA>、head=<SHA>、要件=<文書または添付>。
初回は、作者の会話や他のレビュアーの出力を参照しないでください。
各指摘には次を付けてください。
- 対象headのコード位置
- 要件のどの部分を破るか
- 成立する具体的な入力・状態と、期待値・実際の結果
- 変更前（base）から存在するか、変更で生じたか
- 再現手順（実行していなければ「未実行」と書く）
次のものは挙げないでください。
- スタイル、命名、性能、予防的な堅牢化、仮定の話
- 要件に書かれていないこと（気になるなら「要確認」の欄へ）
- 変更前から存在する問題（別欄に1行だけ）
0件でも構いません。件数を満たす必要はありません。
2周目以降の依頼文
前回の指摘と、その後の修正差分を渡します。
やること：
1. 前回の各指摘が、修正で解消したか確認する。
2. 修正差分そのものが、元の要件を壊していないか確認する。
3. 修正差分がつなぐAPI・状態・データへの影響を確認する。
前回と無関係な箇所の新しい指摘は、「今回の範囲外」の欄に1行で書く。
「修正差分だけを見る」と書くと、接続先への影響を見落とします。差分に絞っても、つながる先は見るようにします。
製品を使う場合の設定
Claude CodeのCode Review（Team／Enterprise向け）は、レビューをいつ走らせるかを、リポジトリごとに決められます（PR作成時に1回／push後ごと／手動）。手動にしたPRで @claude review always を使うと、以後のpushごとにレビューが走ります。止めるときは @claude review stop です。
REVIEW.md に、次のように書くこともできます（公式ドキュメントの例から）。
- 「nitは1回のレビューで最大5件」
- 「CIがすでに見ているもの（lint、整形、型エラー）は挙げない」
- 「挙動の主張には、命名からの推測ではなく、ソースの
file:lineを添える」
このうち最後はまさに実験の「仕様違反だけ」と同じ考え方です。根拠を求めると、外れた指摘が減る。公式ドキュメントも、それが作者の無駄な往復を減らすと書いています。
小さく試す手順
自分のチームで試すなら、こんな順番がおすすめです。
- 最近の変更を5〜10件選ぶ。AIが書いたものを含める。
- 同じ変更に、2通りのレビューをかける（「全部挙げて」と「要件違反だけ」）。
- 指摘を、前の節の3軸で仕分ける。
- 「全部直す」と「確認済みの要件違反だけ直す」で、修正を分ける。どちらも元のheadから始める。
- 修正のたびに、元の受入テストを全部回す。落ちたものを数える。
- 直した数、壊した数、書き換えた行数、かかった時間と金額を、表に残す。
まず1回やってみると、自分のコードでどこまでが「必要な修正」なのか、感覚がつかめます。
この記事の限界
- 実験は小さい。 4つのモジュール（43行前後）、2モデル、3回ずつの48ランです。統計的な結論ではなく、「こういう現象が起きた」という観察です。割合の差も少数のランの話です。
- お題が単純で、仕様が全部docstringにある。 実際のPRとは違います。「仕様違反だけ」が良い結果になったのも、仕様が文章で完結している条件だからです。仕様の抜けを見つける力は、測っていません。
- レビュー役・修正役はツールなし、毎回新しい会話、修正はファイル全体の書き直し。 実行して確かめられるエージェント型の運用とは違います。実際のエージェントはテストを動かして直すので、結果は変わるでしょう。
- 隠しテストは、ぼくが書いた。 実装の内部を見るテストが1つあり、実験で2回落ちました。結果3の表に書いたとおり、振る舞いの壊れ方とは分けて読んでください。仕様があいまいだったレート制限器の1行（使われないキーの扱い）は、指摘が正しい可能性があります。
- 論文は、小型モデル・限られた課題での結果が多い。 Wang-Linらが使ったのはGemini 2.5 Flash-LiteとQwen2.5-7B、Gaoらも小型モデルです。いまの最新モデルで同じ数字になるとは言えません。論文の数字は、ぼくが追試したものではありません。
- Anthropicの数字は同社の運用報告。 前後比較であり、AIレビュー単独の効果ではありません。絶対件数や対象PRの統一もされていません。
- 答えが見つかっていないこと： 実際のコーディングエージェントが実リポジトリでレビュー→修正を回したときの、膨張率と壊す確率。ぼくの上限の初期値がどのくらい妥当か。
まとめ
- 「指摘ゼロまで直す」は終わりの条件として弱い。修正が次の指摘の材料を作ります。
- 直して壊す、昔の問題が湧く、往復が終わらない。3つとも、資料と実験で確認できました。
- 実験では、本物のバグは1回目の修正で直り、2回目以降はコードの膨張と1件のテスト失敗しか生みませんでした。
- 止めどころは「確認済みの、今回の変更が原因の、要件違反」。回数・差分・同じ指摘・金額に上限を置き、止めた理由は「問題なし」と分けて残します。
- レビュー役には根拠（入力と期待値）を求める。修正役にはその指摘だけを最小限に直させる。
AIレビューは回数を増やすものではなく、止めどころを決めて使う道具です。
関連記事
- AIが書いたコード、別のAIに見せれば客観的？ 新しいセッション・別モデル・テスト・人で「直るもの」と「残るもの」：レビュー役を何にするか。評価票もこちら。
- AIにPRレビューさせるなら、何を渡せばいい？ バグ入りPR 15本で試してみた：レビュー役に渡す情報の実験。
- AIエージェントの「完了しました」は信じていい？：止まった理由と、確かめられたことを分けて記録する。
- AIは「テストの改ざん」より「間違ったテストへの忖度」をする：修正役がテストを通すために何をするか。
実験の素材
再現scriptは、レビュー応答が不正なJSONやfindings形式ならparse_errorで停止し、修正を呼びません。有効な空のfindingsだけを「指摘ゼロ」と数えます。保存済み143ラウンドは全てparse成功しており、この区別で当時の収束数・テスト結果・費用は変わりません。
参考にした一次情報（確認日：2026年10月23日）
- Anthropic, How the Claude Code team does code review（2026-10-15）：50回超の往復、59%、3ラウンド上限、前後比較
- Claude Code公式ドキュメント「Code Review」「Read and request reviews on a pull request」「Customize Code Review」
- Wang-Lin, Isopoussu, Mahon, If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-fixing with LLMs, arXiv 2609.10123v1
- Gao, Yang, Yang, Looping Is Not Reliability: State-Bound Evidence and Typed Revision Contracts for Agentic Code Repair, arXiv 2607.24604v1
- Shukla, Joshi, Syed, Security Degradation in Iterative AI Code Generation, arXiv 2506.11022（IEEE ISTAS 2025）
- Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet, arXiv 2310.01798（ICLR 2024）
- Olausson et al., Is Self-Repair a Silver Bullet for Code Generation?, arXiv 2306.09896（ICLR 2024）
- Xiang et al., Cross-Model LLM Code Review, arXiv 2607.21656v1