エージェント型AIにコードの修正や実装を任せていると、いつまで経っても作業が終わらず、トークンだけが膨大に消費されてしまう現象に遭遇することがあります。これは「Infinite Loop（無限ループ）」または「Spinning（スピニング）」と呼ばれる、エージェント型コーディングシステムの既知の問題です。
本記事では、この現象がなぜ起きるのか、どう防ぐのか、そして万が一ループに入ってしまったときの対処法と、AIコストが人間コストを上回る条件についての研究動向まで解説します。
なぜ堂々巡りになるのか？ 主な原因
1. エラー修正の連鎖
最もよく見られるケースです。コードを修正するとテストが失敗し、別の箇所を修正すると今度は最初のテストが壊れる、という繰り返しが発生します。特に依存関係が複雑なコードベースで起きやすい傾向があります。
2. 曖昧な指示・ゴールの未定義
「うまく動くようにして」といった成功条件が不明確な指示では、エージェントが「完了」を自分で判断できず、改善を試み続けます。
3. ツール呼び出し結果の誤解釈
テスト結果やコンパイルエラーの出力を誤読し、「修正できた」と誤判断して先に進んだ結果、同じエラーに戻ってくるケースです。
4. コンテキストウィンドウの肥大化による判断精度の低下
会話が長くなるほどモデルの判断精度が落ちます。過去の試行錯誤を正しく参照できなくなり、同じ失敗を繰り返すようになります。
5. 相互依存するファイルの編集
ファイルAを直すとファイルBが壊れ、Bを直すとAが壊れる、という循環が生まれます。循環依存のある構造では特に顕著です。
6. 環境・実行環境の問題の見落とし
実は環境設定の問題なのに、コード側の問題という前提から抜け出せず、コードを修正し続けてしまうケースです。
起きやすい条件まとめ
| 条件 | リスク |
|---|---|
| テストスイートが不完全・矛盾している | 高 |
| 指示が自然言語のみ（受け入れ条件なし） | 高 |
| モノレポや大規模コードベース | 中〜高 |
| 型エラーと論理エラーが混在している | 中 |
| エージェントにタスク完了権限がない | 高 |
Infinite Loop / Spinning の回避方法
■ 指示を渡す前にやるべきこと
なぜその修正が必要かを明示する
「このバグを直して」だけでなく、「この処理はXという理由でYの動作をすべきだが、現状はZになっているため修正が必要」という背景を伝えることで、AIが「何を守るべきか」を理解し、過剰・的外れな修正を防げます。
指示に矛盾・機能コンフリクトがないか確認する
複数の指示が互いに矛盾していないか、既存機能と競合しないかを事前に確認します。矛盾した指示はそれ自体がループの原因になります。
人間が対象コードを目視し、構造を理解してから渡す
最も根本的な対策です。人間がコードの構造を把握していれば、AIが誤った前提で動いていることを早期に検出できます。
修正範囲をファイル名・関数名レベルで明示する
「このファイルのこの関数だけ直して」と明示することで、スコープ外への「余計な修正」を防ぎます。禁止事項（「このインターフェースは変更するな」など）を負の制約として伝えるのも有効です。
修正ファイルのコードをコピペして他のAIでその範囲でだけ修正させるのも有効です。
完了条件を明示する
「〇〇のユニットテストが全部通ったら終了」など、AIが自分で完了を判断できる基準を与えます。これがないとAIは永遠に「改善の余地がある」と判断し続けます。
■ 作業中にやるべきこと
修正計画を先に出させてから実行させる
コードを書く前に「何をどう直すか」を文章で答えさせ、人間がOKしてから実行させます。計画段階でおかしな方向に進んでいれば早期に気づけます。
差分レビューをこまめにはさむ
一気に任せず「まずここだけ直して、差分を見せて」と段階的に進めます。小さなサイクルにすることでループが大きくなる前に止められます。
同じAIに「この修正のリスクは何か」と問い返す
修正後に別ターンで批判的に評価させると、見落としや潜在的な問題が浮かびやすくなります。
■ 構造的なアプローチ
修正対象コードだけを抜き出して別のAIに渡す
長い会話で汚染されたコンテキストをリセットする非常に有効な手法です。関係するファイルだけを新しいセッションに貼り付け、クリーンな状態で依頼し直します。
TDD的アプローチ（テストを先に書かせる）
「まずこのテストを書いて」→「そのテストが通るコードを書いて」と分離することで、完了条件が自動的に明確になります。
型定義・インターフェースを先に固める
実装より先にシグネチャを確定させることで、AIが実装中に迷子になるのを防げます。
会話を意図的にリセットする
会話が長くなったら新しいセッションに「現状のコード＋問題点＋これまでに試したこと」だけを貼り直します。「Aを試したが失敗した」と明示することで同じ失敗の再試行を防げます。
回避策の3つの軸
堂々巡りの本質は「AIが自分の失敗を正しく認識できていない」か「ゴールが動いている」かのどちらかです。対策は以下の3軸で考えると整理しやすくなります。
- ゴールを固定する（完了条件・禁止事項・スコープの明示）
- コンテキストをクリーンに保つ（リセット・分割・別AIへの委譲）
- 人間がループに入る（差分レビュー・計画確認）
それでもループが抜けられなくなったら？
最終手段は人間の介入
現状のエージェント型AIの限界として、ループ脱出の最終手段は人間の介入です。具体的には以下のパターンが取られます。
- 完全リセット＋人間が問題を再定義して新しいセッションで渡し直す
- 人間がコードを直接修正してAIの膠着点を突破してから再度渡す
- 問題を分解し直す（AIが解けない粒度だったと判断して切り直す）
- 別のモデル・別のツールに切り替える（Claude → GPT-4、Cursor → Aider など）
実務では「3回ループしたら人間が見る」「30分経ったら切り上げる」といった経験則で運用されているケースが多いです。
AIコストが人間コストを上回る条件——研究の現状
理論的なフレームワーク
AnthropicやMETR（Machine-Evaluated Task Resolution）などの研究機関では、「AIが自律的に解けるタスクの長さ・複雑さ」を軸にコストを分析するアプローチが参照されています。
現状の知見では、エージェントが高い成功率を出せるのは数分〜数十分で完了するタスクまで。それを超えると成功率が急落し、コストが人間を上回りやすくなることが示されています。
AIコストが人間コストを上回りやすい条件
| 条件 | 理由 |
|---|---|
| 依存関係が広範囲に絡み合っている | 影響範囲の推論コストが指数的に増える |
| 正解が1つでない（設計判断が必要） | AIが収束できず試行が爆発する |
| 暗黙知・慣習が必要なコードベース | コンテキストを何度渡してもモデルが吸収できない |
| テストが不完全または矛盾している | 完了条件が揺れるため試行回数が青天井になる |
| ドメイン知識（業務ロジック）が必要な修正 | 外部から与えられる情報だけでは補えない |
コスト逆転が起きやすい具体的な目安
- ループ回数が5回を超えた時点で人間介入のほうがトータルコストで安くなるケースが多い（経験則）
- タスクの要件が自然言語のみで、受け入れ条件が定義されていない
- コードベースが10万行を超えて全体把握が必要な修正
- 修正が複数ファイルにまたがり整合性確認が必要な場合
- 人間なら30分で直せるバグをAIが数十万トークンかけても解けないケース（実務でも報告あり）
研究はまだ黎明期
エージェント型コーディングのROIやコスト逆転条件の定量的な研究は2026年時点でもまだ少ないのが現状です。主な理由は以下の通りです。
- 実務データが企業内に閉じている
- トークンコストが急速に変化していて比較が難しい
- 「人間の時間コスト」の計測方法が統一されていない
「自動化の逆説」として学術的にも議論されているこの問題。簡単なタスクではAIが圧倒的に安く、複雑・曖昧なタスクでは人間のほうが安くなる、という構図は直感とも一致しますが、その境界線を定量的に引く研究は今後の課題です。
まとめ
AIエージェントのInfinite Loop / Spinningは、指示設計・スコープ管理・コンテキスト管理の3軸で大部分を予防できます。それでもループに入った場合は人間の介入が最終手段であり、5回以上のループは人間が直接見たほうがコストも時間も節約できるケースが多いです。AIへの過信ではなく、「AIと人間の適切な役割分担」を意識した運用が、現状の最適解といえるでしょう。
