やす研究所 AI Lab
戻る

Claude Code 暴走対策2026:/forkとsubagent上限で無限ループを止める設定

Claude Code 暴走対策2026:/forkとsubagent上限で無限ループを止める設定

長時間エージェントを回していて、気づいたら subagent が subagent を呼び、WebSearch が延々ループしていた——という経験、あなたにもありませんか。私も先週、Sonnet 5 で調査タスクを走らせたまま昼食に出て、戻ったらセッションが50分近く自走していて青ざめました。

2026年7月、Claude Code v2.1.207 前後で追加された セッション上限系の環境変数 と /fork による background sessions を組み合わせると、この「暴走」を構造的に止められます。この記事では、私が実際に .claude/settings.json と環境変数に落とし込んだ設定を、そのまま貼れる形でまとめます。

結論:暴走対策は「上限」「隔離」「監視」の3層で組む

先に結論から書きます。Claude Code の暴走を止めたいなら、以下の3層で押さえてください。

  1. 上限: CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION と CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION でセッション単位のハードキャップを敷く
  2. 隔離: /fork で長時間タスクを background sessions に切り出し、メインの対話を汚さない
  3. 監視: workflow.run_id の OpenTelemetry 属性でワークフロー単位の挙動を後追いできるようにする

この3つを揃えると、「気づいたら暴走していた」という事故がほぼ起きなくなります。逆に、1つでも欠けると穴が残るんですよね。

なぜ2026年7月に「暴走対策」が急に必要になったのか

背景から書いておきます。2026年6月に Sonnet 5 が一般提供され、agentic な用途で Opus クラスに肉薄する精度が出るようになりました。Anthropic 公式によると、Sonnet 5 は agentic coding で Sonnet 4.6 を大きく上回り、複雑タスクでの持続力が伸びています。

これが何を意味するか。「途中で諦めない」から、暴走したときの被害が大きくなったんです。以前の Sonnet 4.6 なら10分ほどで自然に手詰まりになっていたループが、Sonnet 5 だと1時間走り続ける。effort パラメータのデフォルトが Claude API と Claude Code で high になっている点も、この傾向を押し上げます。

さらに、Cowork や Dynamic Workflows で複数エージェントを並列に回すのが当たり前になり、subagent が subagent を spawn する多段構成が現実的になりました。ここに上限を敷かないと、掛け算で API コストが跳ねます。私の体感で、無設定のまま Sonnet 5 で調査系タスクを回すと、Sonnet 4.6 時代の1.5〜2倍くらいはトークンが伸びる感覚があります。

セッション上限を敷く:2つの環境変数だけで足りる

2026年7月の Claude Code アップデートで、セッション単位の上限が正式に環境変数化されました。私は zsh の rc に以下を書いています。

# ~/.zshrc
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=40
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=30

デフォルトはどちらも200です。正直、200は個人開発だと大きすぎる。私の3週間の運用ログを見ると、真面目な調査タスクでも WebSearch は1セッション20回を超えることは稀でした。30 に絞っても実害はほぼ出ません。

ポイント: /clear を叩くとこのカウンタはリセットされます。つまり、「暴走の予感がしたら /clear で仕切り直す」という運用が回ります。カウンタが尽きたら Claude Code がツール呼び出しを拒否するので、ハードキャップとして効きます。

上限にひっかかったときの挙動

実際に上限を踏むと、Claude Code は該当ツールをその後は呼べなくなります。エラーで落ちるわけではなく、ツールが「使えない状態」として扱われるので、モデル側は別の手段を探す動きに切り替わります。ここが地味に良くて、暴走が「静かに止まる」んです。派手なエラーで作業ごと吹き飛ぶよりずっと扱いやすい。

/fork と /subtask で「長時間タスク」を隔離する

次の層は隔離です。2026年7月中旬のアップデートで /fork の意味が変わりました。以前は現在のセッション内で subagent を起動していましたが、今の /fork は会話全体をコピーして新しい background session として独立させる動きに変わっています。セッション内 subagent は /subtask に名前が分かれました。

私の使い分けはこうです。

/fork すると claude agents の一覧に別行として現れ、メインの対話は普通に続けられます。バックグラウンドで走っている側が API 上限や subagent 上限を食い潰しても、メイン側は無傷です。この分離が本当にありがたい。

/fork のありがちな落とし穴

実際に運用して踏んだ落とし穴を3つ書いておきます。

1. /rename の反映が消える問題 2026年7月の changelog に修正が入りましたが、background session を /rename した後にジョブが再起動されると名前が戻ってしまう不具合がありました。名前でセッションを指す運用をしているなら、Claude Code を最新版(v2.1.212 以降推奨)に上げてください。

2. WebSearch 上限は fork 前後で共有されない /fork で作られた background session は、上限カウンタが親から独立します。つまり、親で20回使っていても子は0からのカウント。便利ですが、コストが読みにくくなる面もあるので、--forward-subagent-text フラグでログを取り込んでおくと後で追いやすいです。

3. background でも auto mode の deny rules は効く 個人的にここは詰まりました。auto mode の Agent(type) deny rules が named subagent spawn に効いていなかったバグが7月半ばに修正済みです。古い Claude Code を使っていると、思ったより広い権限で background 側が走る可能性があります。

OpenTelemetry で workflow.run_id を追う

監視層は OpenTelemetry で押さえます。Dynamic Workflows から spawn されたエージェントの telemetry には workflow.run_id と workflow.name の属性が付与されるようになりました。これは地味ですが決定的な変更で、「どのワークフローの、どの実行が、どのエージェントを呼んだか」がイベントストリームだけで再構成できます。

最小構成の設定例です。

// .claude/settings.json
{
  "telemetry": {
    "otel_endpoint": "http://localhost:4318",
    "include_workflow_attributes": true
  },
  "limits": {
    "web_search_per_session": 30,
    "subagents_per_session": 40
  }
}

OpenTelemetry Collector を localhost で受けて、Grafana Tempo か Honeycomb に流すだけで、暴走が起きたときの後追いが劇的に楽になります。私は無料枠の Honeycomb に流していますが、月あたりのイベント量は個人利用なら余裕で収まる範囲です。

監視で最低限見るべき3つの指標

この3つをダッシュボードに並べておくだけで、翌朝「請求書見て青ざめる」パターンをかなり防げます。

Sonnet 5 と Opus 4.8 で上限値を変える運用

もうひとつ、モデルごとに上限を変える運用も試しています。Sonnet 5 は effort が Claude API と Claude Code で high デフォルト、Opus 4.8 は全サーフェスで high デフォルトです。つまり、両方とも「深く考えて多く動く」寄りの設定になっている。

私の経験則としては、Opus 4.8 を使うときは subagent 上限を Sonnet 5 のときより低めにしています。Opus は $5/$25 per MTok と Sonnet 5 の $3/$15(2026年8月末までは introductory $2/$10)より高いので、subagent が呼ばれる回数を絞ったほうが費用対効果が良い。逆に、Sonnet 5 は introductory 期間中は積極的に subagent を使わせる、みたいなメリハリを付けています。

価格差を意識せずに Opus で全力運用すると、月末にびっくりします。地図で言えば、Opus は高速道路、Sonnet は下道みたいなもので、目的地までの距離感で使い分けるイメージです。

まとめ:今日からやる4つのアクション

最後に、この記事を読み終わったあなたが今日中にできることを4つ挙げます。

  1. ~/.zshrc に CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=40 と CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=30 を追記する
  2. Claude Code を最新版(v2.1.212 以降)に更新して、/fork と /subtask の分離を有効化する
  3. 長時間タスクは /subtask ではなく /fork で background sessions に切り出す癖をつける
  4. OpenTelemetry Collector をローカルで立ち上げて、workflow.run_id を可視化する

1と2は5分で終わります。3は今日の作業から即実践できる。4は週末に1〜2時間確保できれば十分です。この4つが揃えば、Sonnet 5 と Opus 4.8 の速度と精度を活かしながら、暴走事故のリスクを構造的に下げられます。

暴走を「気合と目視」で防ぐのはもう無理な時代です。設定で押さえきりましょう。

参考リンク

この記事をシェア:
X で共有 Facebook で共有 Telegram で共有
前の記事
Cursor CLIをターミナルで使い倒す手順2026:agent -pとPlanモード実践
次の記事
Claude Cowork業務代行副業の始め方2026|デスクトップ操作を売る新ルート