サブエージェントは200体まで、検索は200回まで──Claude Code v2.1.212が暴走に置いた「予算」
Claude Code v2.1.212 が、サブエージェントの起動とWeb検索に1セッション200回の上限を設けました。30分で120万トークンを溶かした暴走報告を背景に、/fork のバックグラウンド化やプランモードの権限漏れ修正も入っています。
Anthropic が Claude Code v2.1.212 を公開しました。目立つ新機能というより、自律的に動くエージェントに数の上限を設ける変更が中心です。サブエージェントの起動もWeb検索も、1セッションあたり既定で200回まで。無人でエージェントを回している開発者にとっては、地味ですが効き目の大きい更新です。
200という数字が入った場所
今回追加された上限は2つです。どちらも環境変数で調整でき、既定値は200に設定されています。
| 環境変数 | 何を数えるか | 既定値 |
|---|---|---|
CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION | 1セッション内で起動するサブエージェントの数 | 200 |
CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION | 1セッション内のWebSearchツール呼び出し回数 | 200 |
変更履歴には、それぞれ「暴走する委譲ループを止めるため」「暴走する検索ループを止めるため」と目的が明記されています。サブエージェントの上限は /clear で復活する仕組みで、会話をリセットすれば予算も戻ります。
なぜ「数える」必要があったのか
背景には、実際に報告されていた事故があります。Claude Code のリポジトリに立っている報告では、サブエージェントが自分の子エージェントを次々に起動し、止まらなくなる事象が挙げられています。報告者によれば、権限を拒否されたサブエージェントが失敗を返さずに別の子エージェントを起こしてしまい、その子も同じ壁に当たって、さらに子を起こす──という連鎖が生じていたとされます。
報告に添えられた数字は具体的です。約30分で120万トークン以上を消費し、成果物は何も残らなかったケース。5分足らずで上位プランの5時間分の枠を使い切ったケース。いずれも個別の報告であり、すべての利用者に起きる話ではありませんが、「自律性を上げると、失敗も自律的に増える」という構図はうかがえます。今回の上限は、この構図に対して最後の砦を1本立てたものと読めます。
/fork が席を立ち、/subtask が残った
同じリリースで、会話を複製する /fork の役割が変わりました。これまで /fork はセッション内でサブエージェントを起動していましたが、v2.1.212 からは会話をコピーして独立したバックグラウンドセッションを作るコマンドになりました。作られたセッションは claude agents の一覧に自分の行を持ち、その裏で走っている間も手元の作業を続けられます。
従来の「セッション内サブエージェント」としての /fork は /subtask という名前に移りました。つまり両方の使い分けが名前で分かれた形です。手元の会話を止めずに別方向を試したいなら /fork、いまの流れの中で下請けに出したいなら /subtask と考えると整理しやすいでしょう。
2分を超えたMCPは裏へ回る
MCP(Model Context Protocol)まわりにも待ち時間の改善が入りました。2分を超えて実行が続いているMCPツール呼び出しは、自動的にバックグラウンドへ移ります。長いビルドやデータ取得でセッション全体が固まる、という状況が減る見込みです。しきい値は CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS で変更でき、無効化もできます。
安全面では、プランモードの穴がひとつ塞がれています。計画を立てるだけのはずのプランモードで、touch や rm といったファイルを変更するBashコマンドが、権限確認を挟まずに実行されてしまう不具合が修正されました。SDK の canUseTool コールバックも呼ばれていなかったため、プランモードを「読むだけの安全なモード」として運用に組み込んでいた場合は、影響の有無を確認しておく価値があります。
無人運用でまず触るところ
cron やCIでエージェントを走らせている場合、今回の変更は次の順で見ておくとよさそうです。
- 既定の200が自分の用途に合うか確認する。数十体規模のワークフローを常用しているなら200は当たりませんが、動的ワークフローで大量に分岐させる設計だと上限に触れる可能性があります。
- 止めたい方向に振るなら小さくする。無人運用では、200より厳しい値(たとえば20〜50)を明示しておくほうが、事故の被害額を見積もりやすくなります。
- プランモードの前提を見直す。「プランモードだからファイルは変わらない」という想定でガードを省いていた箇所があれば、権限ルール側でも二重に塞いでおきます。
- MCPの2分ルールを把握する。バックグラウンドへ移る挙動が前提と合わなければ、しきい値を調整します。
上限は解決ではなく、気づくための線
ここで見落としたくないのは、200という上限が問題を直したわけではない点です。上限は、暴走が起きたときの損失を頭打ちにするだけで、暴走そのものをなくすものではありません。200体のサブエージェントと200回の検索は、それ自体が十分に大きなコストにもなり得ます。
むしろ有効なのは、上限に到達したという事実を「設計が想定を外れた合図」として扱うことでしょう。エージェントに任せる範囲を広げるほど、失敗は静かに、そして高速に積み上がります。今回のリリースは、その速度に対して人間が気づくための線を引いた、と捉えるのが実態に近いように見えます。エージェントの自律性を上げる作業と、暴走時の上限を決める作業は、セットで進めておくのが安全です。
参照: Claude Code Changelog(v2.1.212 / v2.1.211) / anthropics/claude-code CHANGELOG.md / Issue #68619: Subagent spawning and subagent pattern bugs trigger infinite recursion / Releasebot: Claude Code Updates