AIはミスを指摘されると暴走するのか ― AI補助開発における過剰修正とRecovery Scope Control

1. はじめに

AI coding agentに修正を依頼する場面を思い浮かべてください。「このパスの記載が間違っている、直して」「この記述はまだ検証されていない、事実として書かないで」――指摘そのものは局所的です。

ところが、その直後にAIから返ってくる提案が、指摘した箇所だけでなく、周辺の設計、関連文書、追加の検証項目、さらには新しい構成要素の提案にまで広がっていることがあります。逆に、指摘したことだけを過不足なく直して終わる場合もあります。

この違いを、単に「今回は運が良かった／悪かった」で片づけず、観測可能な軸として扱えないか、というのが本稿の出発点です。

2. 何が問題なのか

AI coding agentの成果を評価するとき、私たちはまず「直っているか」を見ます。これはもちろん重要です。しかし実際に手を動かしていると、「直っているかどうか」だけでは捉えきれない失敗が2種類あることに気づきます。

一つは、直すべきものは直っているのに、直さなくてよいものまで一緒に変わってしまう失敗です。もう一つは、「直しました」という報告と、実際にその状態が正しいことが確認されたかどうかが、別物であるという失敗です。

AIの修正を見るとき、確認したいのは単に「直せるか」ではありません。少なくとも次の2つがあります。

AIは、本来必要だった作業範囲からどこまで逸脱しそうになったか。

そして、その作業の結果、本来の目的を果たせたことを確認できたのか。

前者をScope Boundary（修正の範囲がどこまで広がってよいかという境界）、後者をVerification Boundary（「実行した」という事実と「検証された」という事実の境界）として、この記事では整理していきます。

3. 2つの境界という見方

一つは作業範囲、もう一つは結果の確認です。この記事では、それぞれをScope BoundaryとVerification Boundaryとして分けて見ます。両者の間に因果関係は仮定していません。独立した2つの評価軸として扱いますが、ここでいう「独立」は、統計的に実証された分離ではなく、評価をあえて別々に行うという意味です。

Scope Boundary
  defect
    ↓
  required correction（実際に必要だった修正）
    ↓
  proposed recovery scope（AIが提案した修正範囲）
    ↓
  unnecessary expansion（あれば）

Verification Boundary
  recovery action（実行された修正）
    ↓
  claimed completion（「完了しました」という報告）
    ↓
  observed actual state（実際に観測された状態）
    ↓
  verified recovery（検証済みかどうか）

この2つの境界をあわせて、便宜上「Recovery Scope Control」と呼ぶことにします。確立した理論や標準ではなく、あくまでこの記事の中だけで使う呼び方です。

以下、この2軸に沿って、実際の事例を見ていきます。

4. Scope Boundary ― 「直せたか」ではなく「範囲を守れたか」

ここでは、本来必要だった作業範囲からどこまで逸脱しそうになったかを見ます。まず、Scope Boundaryが守られた例から示します。過剰修正の話へ進む前に、範囲を守れた側の実例を先に見ておきます。

4.1 局所修正が局所修正のまま終わった例

Network Checkでの記録です。内部ファイルパスや実装の詳細は伏せていますが、架空の例ではありません。

DNS関連の修正では、確認できるcommit上の変更は5ファイルに限定されており、無関係なファイルへの変更は含まれていませんでした。

この記録から直接確認できるのは、最終的な変更範囲が局所的に保たれていたことです。Humanの具体的な指摘からAIの応答までの全シーケンスは、現在のGit記録だけからは再現できません。

本稿では、このようにRecoveryの変更結果が必要範囲に収まった状態を、便宜上Good Bounded Recoveryと呼びます。

4.2 局所修正のはずが、設計一式に広がった例

一方で、指摘された範囲を超えて修正提案・修正実行が広がった例もあります。本稿ではこの型をOver-Recoveryと呼びます。

Network Checkの「実行機能を含めて公開する」という当初の目標に対し、ある時点での提案は、既存アプリケーションの再利用で済む範囲を超え、事実上、新規アプリケーションを一から構築するに近い規模にまで広がっていました。

その後のやり取りを経て、最終的に実装されたのは、既存のcheck core・API contract・SSRF/TOCTOU処理等を一切変更せず、OSIIX向けのURL・表示文言・起動設定・ルーティング設定の追加だけに限定した最小限の変更でした。最終的に必要と判断され、実装された範囲はこの程度に限定されました。

指摘された「実行機能が進んでいない」という1点と、それに対して広がった提案の間には、範囲の食い違いがあったと言えます。

4.3 修復手段そのものが新しい目的になりかけた例

別の記録では、生成PDFからFigure 1–8が欠落しているというdefectに対し、正本からFigureを含む正しいPDFを再生成することが本来のrecovery goalでした。

ところが、PDF再生成手段の調査が、Windows上のPandoc / LibreOfficeの確認から、winget、PATH、MSI、registry、installer/package diagnosisへと拡大しました。Humanからは「どうしても必要？ pandocとlibre 今まで何回もPDF生成してるよね」「今まで出したPDFは何だったんだ？」という問いが入り、選択した手段が本来のrecovery targetになっていないかが再確認されました。

その後に回収された事実は、Current Edition PDFの成功生成経路がWindows CodexではなくChatGPT Linux sandboxだった、ということです。したがって、current environmentでpathが見つからないことと、historical successful pathが存在しなかったことは同義ではありません。

この例で観測できるのは、選択されたrecovery meansが、元のPDF defectを直すための手段から独立したrecovery objectiveになりかけたことです。ただし、これは単一の追加事例であり、AI一般、発生率、内部原因、特定toolchainの原因へ一般化するものではありません。

4.4 ここから言えること

局所defectの検出は、それだけで広範な再設計や追加の人間判断への権限にはなりません（local defect != authorization for broad redesign）。

当たり前に聞こえるかもしれません。ただ今回のOver-Recovery事例（4.2のNetwork Checkと4.3のPDF再生成）では、指摘された局所的な問題が、より広い設計・品質上の問題や、選択した修復手段の環境整備の問題として読み替えられ、その結果としてRecovery Scopeが広がっていました。複数の観測があるからといって、これを一般的な発生メカニズムとまでは言えません。それでも、局所的な指摘と、それに応じて広がった再設計提案または環境整備との間にずれが生じることがある、という点は、これらの記録から見て取れます。

5. Verification Boundary ― 「実行した」と「確認できた」は別物

ここまで見てきたのは、修正がどこまで広がったかというScopeの問題です。ただ、範囲が適切だったとしても、それだけで「本来の目的を果たせたことを確認できた」とは限りません。修正を実行したことと、その結果が本当に正しいと確認できたことは別だからです。そこで、もう一つ見るのがVerification Boundaryです。

5.1 未検証の説明を仮説として保持した記録

その具体例として、次の記録があります。

内部向けのセキュリティ監視コンソールの記録には、ある技術的な挙動についての説明が残っています。直接比較で検証されるまでは「仮説」として扱う、というものです。実際に確認できる記述は「まだ説明できていない」「仮説であり確定した事実ではない」といった留保つきの表現で、ある比較（2種類のコマンド実行結果の比較）が済むまでは確定とも不確定とも判断しない、という方針がそのまま書かれています。

ここで問題になっているのは「修正の範囲」ではなく、「実行したこと」と「実際に検証済みであること」の区別です。文書の編集という作業そのものは成功していましたが、その中身の一部は、直接比較による検証を経るまで確定事実として扱わない、という判断が明示的に記録として残されていました。

actionの実行が成功したことは、それだけで目的の達成や事実の正しさを保証しません（recovery action != verified recovery）。

この記録がどう書かれ、どう指摘され、どう直っていったのか、詳しい経緯までは非公開の作業記録に依存する部分があり、こちらで確認できるのは、最終的にhypothesisとして明示的に保留された記録そのものです。それでも、この記録はVerification Boundaryをどこに置くべきかを具体的に示す例になっています。

実行完了と実際の達成状態を分けて確認する必要性は、外部の別領域でも指摘されています。家庭内タスクのシミュレーション環境を対象とした2026年のある研究は、エージェントが実際に置かれている環境の状態（world completion）と、エージェント自身が「完了した」と判断する基準（self-termination）の間に系統的なズレがあることを報告しています。また、Anthropicが公開した長時間稼働エージェントに関する研究記録では、複雑なタスクを任されたエージェントが完了を主張しても、その主張をそのまま受け入れず、「本当に完了したか」を確認し直す外部ループ（通称Ralph loop）を導入した例が紹介されています。どちらも対象領域（家庭内タスクのシミュレーション、科学計算向けの長時間稼働エージェント）は今回のAI補助開発の現場とは異なるので、直接の裏付けというより、似た論点が他の文脈でも出ている、という参考情報として書き添えます。

5.2 補足事例：Fail2Ban / nftablesの運用ケース

これはAI補助開発の事例ではなく、サーバ運用における別の補足事例です。ある環境で、ファイアウォールのルールセットが一度リセットされ、侵入防御サービス（Fail2Ban）側の実行時ルール構造が失われました。この時、サービスプロセス自体は稼働し続けており、直前まで有効なban（遮断）を保持していた一部のjail（監視対象）だけは必要になった時点で自己修復しましたが、その時点でbanを保持していなかったjailでは、構造が再生成されないまま残る可能性がありました。つまり、単純に「再構築を試みたが失敗した」という一様な失敗ではなく、jailごとに復元されるものとされないものが生じ得る、という状態でした。「サービスが起動している」ことだけをもって「防御は機能している」と判断すると、こうした部分的な未復元を見逃す可能性がありました。

この事例は、AI補助開発におけるOver-Recoveryと同じメカニズムだとは考えていません。あくまで別の文脈での補足事例です。ここから直接支えられるのは、限定的な設計上の教訓だけです。

• 実行コマンドが成功したことは、目的の達成を意味しない
• サービス・プロセスが稼働していることは、それに依存する実効的な状態が正しいことを意味しない

6. 実務設計への示唆

ここまで見てきた2つの軸――作業範囲は逸脱していないか、本来の目的は確認できたか――を、実務ではどう使えるか。ここからは、AIに修正を依頼するときに使える簡単なチェック項目を、叩き台として示します。今回取り上げた追跡可能な事例から作ったもので、確立した標準でも万能な手順でもありません。

DEFECT:
RECOVERY GOAL:
REQUIRED CORRECTION:

[Scope Boundary]
SELECTED MEANS:
DO NOT CHANGE:
RECOVERY SCOPE:

[Verification Boundary]
CLAIMED COMPLETION:
OBSERVED ACTUAL STATE:
VERIFIED RECOVERY: yes / no / unknown

STOP IF:
- correction requires scope expansion
- authority is unclear
- expected state cannot be verified
- selected means is becoming a separate objective

「直してほしい範囲」と「触ってほしくない範囲」を先に分けておくこと、そして「実行した」という報告をそのまま「検証済み」として受け取らないこと。この2点が要点です。今回のケースから言えるのは、AIが「完了しました」と言った後、もう一段階「その状態は実際に観測して確認したものか」を独立したGateとして確かめる、というのが対策候補になり得るということです。ただし、この手順がVerification Boundaryに関する誤りの発生率を実際に下げるかどうかまでは、本稿では検証していません。

7. 何がまだ分からないか

ここまでで分かっていないことも残っています。

まず、ここで取り上げた事例は、当初の内部整理ではもっと候補がありました。公開にあたって、今も元のリポジトリやcommit履歴まで独立に遡って確認できるものを優先して選んでいます。つまり統計的なサンプルではなく、発生率やモデルごとの傾向、他の開発者への一般化は、この記録だけからは言えません。

Scope Boundaryの逸脱とVerification Boundaryに関する問題が、同じ内部原因から生じるのかどうかも分かりません。ここで扱った事例だけから、両者の関係を判断することはできません。

外部の文献を調べた限り、「Humanが誤りを指摘したことをきっかけに、AIの修正範囲がどう変化するか」を直接扱った研究は見つかりませんでした。近い領域の研究――自己修正の不安定性、複数ターンでの性能劣化、自動プログラム修復におけるパッチの過大化――は個別にありますが、これらを組み合わせて検証した研究は、探した範囲では確認できていません。見つからなかったからといって、存在しないとは言えません。

最後に一点。当初の作業仮説では、「未検証のまま確定事実として記録される失敗」をさらに「Premature（時期尚早な完了宣言）」と「Silent（気づかれない失敗の温存）」に分けて捉える案がありました。しかし今回の記録からも外部文献からも、この2つを別のfailure modeとして分ける根拠は得られていません。ここでは両者を分けず、一つの失敗方向として扱っています。

8. まとめ

では、AIはミスを指摘されると「暴走」するのでしょうか。少なくとも今回の記録から、そう一般化することはできません。一方で、訂正後の提案範囲が必要以上に広がった事例は確認できました。だから見るべきなのは、AIが「暴走するか」ではなく、訂正後のRecovery Scopeがどこまで広がったかです。

そのうえで、もう一つ見ておきたいことがあります。範囲が適切だったとしても、それだけでは本来の目的を果たせたことを確認できたかどうかは分かりません。だからこの記事では、Recoveryを

• 本来必要だった作業範囲からどこまで逸脱しそうになったか（Scope Boundary）
• その結果、本来の目的を果たせたことを確認できたのか（Verification Boundary）

という2つの問いで見てきました。整理し直すと、

• 局所的な欠陥の指摘は、広範な再設計への権限を自動的には与えない
• 実行されたことは、検証されたことを意味しない

という2点になります。今回取り上げた記録では、変更範囲が局所的に保たれていた結果と、提案範囲が広がった事例の、両方がありました。指摘の直後に必ずScope BoundaryやVerification Boundaryが崩れるわけではありません。どういう条件で境界が崩れ、どういう条件で守られるのか――それを観察し続けるほうが、実務的には意味があるように思います。

出典・参考情報

• Chen, Y. et al. "Done, But Not Sure: Disentangling World Completion from Self-Termination in Embodied Agents." arXiv:2605.08747, 2026.
• Mishra-Sharma, S. (Anthropic). "Long-running Claude for scientific computing." Anthropic, 2026年3月23日。本稿で参照した「完了主張を外部ループで再確認する」という記述（通称Ralph loop）は、同記事内の該当箇所に基づく。
• Huang, J. et al. "Large Language Models Cannot Self-Correct Reasoning Yet." ICLR, 2024.
• 上記以外にも複数の関連研究を参照したが、いずれも本稿の主張を直接裏付けるものではなく、隣接領域の背景情報として位置づけている。