ラルフ・ウィガムループ — エージェントが同じ失敗を繰り返す時

コーディングエージェントにバグ修正を頼んだら、こうなる：

1. コード修正
2. テスト実行 → 失敗
3. 同じコードを少し違う形で修正
4. テスト実行 → 同じエラー
5. また似たように修正
6. ...（10回繰り返し、トークン$3消費、進展ゼロ）

これがRalph Wiggumループだ。

なぜ発生するか

LLMは「試行回数」を数えない: メッセージ履歴に失敗記録が積み重なっても、LLMは「もう5回同じアプローチを試したから別の方法にすべき」と自ら気づけないことが多い。

コンテキストウィンドウの限界: 履歴が長くなると初期の試行の失敗理由がカットされる。LLMが過去の試行を「忘れて」同じ間違いを繰り返す。

エラーメッセージが不十分: テストエラーが「assertion failed」だけ返すとLLMが原因を把握しにくい。情報不足 → 同じ推測の繰り返し。

ツール設計の問題: ツールが「成功/失敗」だけ返してコンテキストを提供しない。LLMがなぜ失敗したか判断する材料がない。

検出方法

反復検出: 直近N回のツール呼び出しが同じツール + 類似パラメータなら ループ検出 → 介入。

トークン予算: 1タスクにトークン上限を設定。超過したら「これは解決が難しい」と正直に報告させる。

進捗メトリクス: 各ループイテレーション後に「何が変わった？」を評価。変化なし → ループ脱出。

防止戦略

システムプロンプトに明記: 「同じアプローチが2回以上失敗したら別の戦略を試せ」「解決が難しければユーザーに助けを求めろ」

失敗履歴の要約: N回ごとに「これまでの試行と結果」を要約してLLMに注入。コンテキストを失わないように。

エスカレーション機構: 一定回数失敗 → ユーザーに「ここで詰まっています。A、B、Cを試しましたが...」と報告して判断を委ねる。

ツール結果の改善: エラーメッセージに考えられる原因、関連ファイル、試すべきアプローチなどのコンテキストを含める。