締めた手綱を、2日で少し緩める──Claude Code v2.1.219が入れ子サブエージェントを「既定で深さ3」へ戻し、ワークフローに「15体未満」の目安を入れた
Claude Code v2.1.219が、2日前に既定オフにした入れ子サブエージェントを「既定で深さ3」へ戻し、動的ワークフローに「15体未満」の目安を新設。自律性と安全性の綱引きと、無人運用での当てどころを整理します。
Opus 5の陰で動いた、子エージェントの手綱
Claude Code は7月24日にv2.1.219、翌25日にv2.1.220を公開しました。見出しを飾ったのは既定モデルに昇格した Claude Opus 5 ですが、日々エージェントを回す開発者にとって効いてくるのは、その裏で静かに調整された「子エージェント（サブエージェント）をどこまで自由に走らせるか」という設定群です。しかもその一部は、わずか数日前に加えたばかりの制限を早くも緩める内容でした。
「入れ子は既定オフ」から2日で「既定で深さ3」へ
7月20日前後のv2.1.217で、Claude Code はサブエージェントの同時実行を既定20体に抑え、サブエージェントがさらに子を生む「入れ子（ネスト）」を既定でオフ（深さ1）にしました。暴走や使いすぎを防ぐための引き締めです。ところがv2.1.219は、この入れ子を既定で深さ3まで許可する方向へ戻しました。無効化したいときは環境変数 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 を指定します。
数日で締めて、また緩める。ちぐはぐに見えますが、これは自律性と安全性のちょうどいい落としどころを、実運用のなかで手探りしている過程と読めます。入れ子を完全に塞ぐと、役割ごとに小さなエージェントを積み上げる多段のワークフローが組みにくくなります。かといって無制限では歯止めが利きません。折衷点として選ばれたのが「既定は深さ3、必要なら1段に戻して止められる」という設計です。
動的ワークフローに入った「15体未満」という目安
もう一つの調整が、動的ワークフロー（1回の指示で多数のエージェントを動的に生成し、並列で走らせる仕組み）の規模に関する既定値です。v2.1.219から、動的ワークフローは「エージェント15体未満をめざす」中サイズの目安を既定で採るようになりました。新設の設定キー workflowSizeGuideline を使えば、任意の設定ファイルからこの目安を指定でき、指定した場合は /config の該当行が隠れます。目安を変えたい、あるいは無制限にしたいときは /config の「Dynamic workflow size」で選び直せます。
ポイントは、これが強制ではなく助言（advisory）だという点です。実行時には別途、同時実行は最大16体程度（CPUコアが少ないマシンではさらに減る）、1回あたりの総数は最大1,000体という安全上限が効きます。目安の役割は、規模が大きいワークフローに出す警告のしきい値を、既定の25体からこの目安の体数へ引き下げること。つまり「そもそも大きく広げすぎない」ようモデルの初期設定を寄せる工夫です。実行中のワークフローには現在の既定サイズがステータス行に表示され、/config への導線も添えられます。
締めるだけでなく、見えるようにする
今回の更新は、制限と同じくらい「観測」に寄っているのが特徴です。無人運用で効きそうな変更を整理します。
| 変更点 | 内容 |
|---|---|
| 入れ子の可視化 | 深さ2以上で生成された子エージェントの出力が、--forward-subagent-text 指定時に stream-json へ現れる。生成元エージェントの tool_use id で紐づけられる。 |
| MCPエラーの明示 | ヘッドレスの stream-json 初期化イベントに mcp_server_errors を追加。設定検証で弾かれた --mcp-config のエントリを列挙し、端末実行では起動時に警告を表示する。 |
| ネットワークの厳格化 | sandbox.network.strictAllowlist を追加。サンドボックス実行時、許可リストにないホストへの接続を、確認を挟まずに拒否できる。 |
| 作業ディレクトリの捕捉 | DirectoryAdded フックを追加。/add-dir やSDKの登録要求で作業ディレクトリが途中追加された直後に発火する。 |
無人運用でどう効くか
これらは、cron などで人が張り付かない自動運用にこそ効きます。従来はヘッドレス実行中にMCPサーバーが設定不備で無言のまま外れ、原因が分からないことがありました。今回、外れたエントリが初期化イベントに載るため、後追いで気づけます。strictAllowlist を使えば、生成されたコードが想定外の外部ホストへ通信するのを既定で遮断でき、情報の持ち出しリスクを下げられます。入れ子が既定で深さ3まで開いたことで、「調べる係」「直す係」「検算する係」を段に分ける多段設計も、特別な設定なしに組めるようになりました。
導入時の当てどころは次のとおりです。
- 入れ子を使わせたくない無人ジョブは
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1で従来どおりに固定する。 - 規模を絞りたいチームは
workflowSizeGuidelineを設定ファイルに書き、既定の目安を共有する。 - 外部送信を厳しく制限したい環境では
sandbox.network.strictAllowlistを有効化し、許可ホストを明示する。
便利さの裏にある注意点
入れ子の解禁とワークフロー規模の拡大は、そのままトークン消費とコストの膨張につながりやすい面があります。深さ3の入れ子は、1つの指示から生まれる実行が指数的に増えうるため、上限に達する前でも請求額が読みにくくなる、という指摘もできます。加えて、規模の目安はあくまで助言であり、モデルがそれを超えて広げる場面では効かない点にも留意が必要です。多段の入れ子は、どの子エージェントが何をしたのかという監査・原因追跡を難しくする側面もあります。今回追加された可視化やフックは、こうした「見えにくさ」を補うための備えとも読め、便利さと制御しやすさを同時に確保しようとする綱引きが続いていることがうかがえます。
参照: Claude Code changelog（v2.1.219 / v2.1.220）、Orchestrate subagents at scale with dynamic workflows、Releasebot: Claude Code updates、anthropics/claude-code CHANGELOG.md
