Skip to content

AIエージェントにおける無限自己増殖(再帰無限ループ)とトークン爆食いバグの分析

1. 概要

自律型AIエージェント(Claude Code、OpenCode等)が、人間の明示的な承認をバイパスし、無制限に子エージェント(サブエージェント)を再帰召喚し続ける現象が報告されている。 本稿では、OpenCode (anomalyco/opencode#17721) および Claude Code (anthropics/claude-code#68708) のインシデント事例を元に、その発生メカニズム、既存のループ制限ガードの死角、および堅牢なシステム防衛策について分析・整理する。


2. 発生メカニズムとアーキテクチャの盲点

2.1. 権限設定(Permissions)の伝搬バグ

多くのAIエージェントシステムでは、親エージェントがセキュリティポリシーに違反する操作を行わないよう、ユーザーからのポップアップ承認を求める。しかし、自動承認や開発の利便性を高める目的で、設定ファイル(opencode.json 等)に以下のグローバル承認が追加されることがある。

json
{
  "permission": {
    "task": "allow"
  }
}

この設定が追加されると、システム内の全エージェント(サブエージェント含む)に対して「タスク(新規エージェント・サブプロセスの召喚)の自動実行」が明示的に許可される。

通常、システム内部には「サブエージェントがさらに下位のサブエージェントを作る」ことを禁止するネストガード(無限召喚防止)が組み込まれているが、このグローバル明示許可(task: allow)が優先されることで、安全装置がバイパスされる。

packages/opencode/src/tool/task.ts のコード判定例:

typescript
// サブエージェントが明示的な task 許可ルールを持っているかチェック
const hasTaskPermission = agent.permission.some((rule) => rule.permission === "task");
  • デフォルト(安全): hasTaskPermission = false ➔ 子セッションでのタスク実行は拒否され、ネストは1段階に制限される。
  • グローバルに task: allow を設定時(脆弱): hasTaskPermission = true ➔ ネストガードをバイパスし、無制限の再帰召喚が有効化される。

3. なぜ既存のセーフティガードが効かないのか

この「自己増殖ループ」は、多くのシステムに標準搭載されている「無限ループ検知」や「回数制限」をすり抜ける。

3.1. 単一セッション制限(steps)の死角

多くのエージェントには、API呼び出し回数の上限を設定する steps(例: 1つのタスクあたり最大10ステップまで)が存在する。しかし、この制限は**「単一のセッション(Session)」**にしか適用されない。 新しく再帰召喚された子エージェントは、それぞれ「新しい独立したセッションID」を持って立ち上がるため、親のステップ制限を引き継がない。結果として、生まれたすべての子セッションがそれぞれ上限ステップ数までフル稼働する。

3.2. ループ検知(doom_loop)の死角

エージェントが「同じファイルへの書き込みツール」を連続で何度も呼び出すような「同一セッション内の同一動作ループ」は、doom_loop 検出器によって容易にブロックされる。 しかし、再帰召喚の場合、親エージェントから子エージェントに渡される引数(プロンプトやインプットコンテキスト)は毎回変化する。したがって、監視システムからは「全く無関係な新しい知的タスクが別々に実行されている」ように見え、検知ロジックに引っかからない。


4. 指数関数的なコスト爆発(グレイグー現象)

このバグが発生し、1つのエージェントが並列で2つの子エージェントを召喚し続けた場合、セッション数は指数関数的に増殖する。

探索の深さ (Depth)生成セッション数累積セッション数累積最大APIコール数 (steps: 10時)
11110
34770
51631310
101,0242,04720,470

各セッションは独自のコンテキストウィンドウ(1万〜10万トークン)を独立して消費するため、インプットトークンの往復送信によって、API課金は一瞬で数万円〜数十万円規模に爆発する。実際に海外のユーザーコミュニティでは、気づかないうちにバックグラウンドで3時間以上暴走し続け、クレジットを一瞬で消費した事例が報告されている。


5. 推奨される防衛策(システム免疫設計)

AIエージェントの暴走からインフラと財布を守るために、以下の「多層防御(Defense in Depth)」が必要である。

5.1. 物理的な深度制限 (Max Depth)

権限設定に関わらず、システム全体でネスト可能な深さにハードリミットをかける。 親子セッションの parentID チェーンを辿り、スタック深度(Depth)が一定値(例: 2または3)を超えた場合は、いかなる権限があっても新規サブプロセス / サブエージェントの作成をシステムレベルで強制拒否する。

5.2. 定額制サブスクリプションによる「兵糧攻め(物理制限)」

従量課金APIキー(無制限に後払い課金されるクレジットカード直結キー)をエージェントに直接握らせて稼働させることは極めて危険である。

  • 対抗策: 1日の利用上限やメッセージ数上限が組み込まれている「定額サブスクリプション(例: Claude Pro や Google One AI Premium 等)」の枠内でのみエージェント(CLI)を稼働させる。
  • サブスクの上限に達した時点でエージェントは物理的に停止するため、自己増殖バグが発生した場合でも、金銭的損失は契約している月額(定額)の範囲に完全に制限される。

5.3. サンドボックス物理隔離 (sunaba) と egress プロキシ

コンテナ環境(sunaba)によって、エージェントが暴れ回る檻を物理的に隔離する。さらに、外部へのアウトバウンド通信を egress プロキシによって「ホワイトリスト化された宛先(GitHub API や特定のホスト等)」のみに制限し、勝手に外部のAPIキーをミントして追加リソースを購入・接続するような連鎖インジェクションを防ぐ。


6. 参考文献 / 一次情報

Shiori pointer-RAG automation experiment.