1,000体のサブエージェントに「大きさ」の手綱を──Claude Code v2.1.202が動的ワークフローに足した調整つまみと観測窓

7月6日、動的ワークフローに「サイズ調整」が付いた

Claude Code のバージョン2.1.202が2026年7月6日に公開されました。目立つ追加は、設定コマンド /config に入った「Dynamic workflow size（動的ワークフローのサイズ）」という項目です。Claude が動的ワークフローを組むときに、どれくらいの規模でエージェントを走らせるかの目安を、あらかじめ指定できるようになりました。

あわせて、ワークフローが生成したエージェントの動きを後から追えるようにする仕組みも入りました。地味な更新に見えますが、直前にきた大きな機能「動的ワークフロー」を、実運用で扱いやすくするための調整です。まずその土台から整理します。

Claudeが自分でオーケストレーションを書く

動的ワークフロー（Dynamic Workflows）は、ひとつの大きな指示を Claude が自分でサブタスクに分解し、複数のサブエージェントに並行して割り振る仕組みです。Claude はオーケストレーション用のスクリプトをその場で書き起こし、各エージェントの結果を照合してから統合します。別々のエージェントが違う角度から問題に当たり、別のエージェントがその結果に反証を試みる、という検算の流れも組み込まれています。

規模の上限は、公式ドキュメントで次のように示されています。

• 同時実行: 最大16体のサブエージェントが並列で走る
• 合計: 1回のワークフローで最大1,000体まで生成できる

提供範囲も研究プレビューから正式版（GA）に移り、Pro / Max / Team / Enterprise の各プランに加え、Claude API・Amazon Bedrock・Google Vertex AI・Microsoft Foundry でも使えるようになりました。とくに Pro プランに開かれたことで、対象が個人開発者まで一気に広がっています。

効果の分かりやすい例として、Bun の開発者 Jarred Sumner 氏による移植作業が挙げられています。Zig から Rust への書き換えで、およそ75万行の Rust コードを生成し、既存テストの99.8%が通る状態まで、11日で到達したとされます。1本のワークフローが各構造体のライフタイムを整理し、続く並列エージェントが挙動を保ったまま .rs ファイルを書き、各ファイルを2体のレビュー役が確認する、という分業でした。

small / medium / large という手綱

ここで v2.1.202 の新項目が効いてきます。「Dynamic workflow size」は、Claude が組むワークフローの規模感を、おおまかに指定する設定です。

注意したいのは、これが強制的な上限（キャップ）ではなく、あくまで「目安（advisory guideline）」だという点です。前述の1,000体という枠はそのままに、Claude が普段どのくらいの規模を選ぶかの傾向を、利用者の側から寄せておく、という位置づけです。大きな移植や全コード横断の調査には large を、日々の小さな作業には small を、といった使い分けが想定されます。

走った1,000体を後から追える

もうひとつの追加が、テレメトリ（OpenTelemetry）への属性 workflow.run_id と workflow.name です。ワークフローが生成した各エージェントが、この2つの情報を発信するようになりました。

これにより、あるワークフロー1回分の活動を、OpenTelemetry のデータから丸ごと再構成できます。16体が並び1,000体まで膨らむ処理は、何が起きたのかを後から把握しづらいものです。実行を一意に識別する ID と名前が付くことで、どのエージェントがどの実行に属していたかを、ログ側から突き合わせられるようになります。無人運用や組織での利用を想定した、観測性（オブザーバビリティ）まわりの手当てといえます。

同じ更新では、ワークフロースクリプトの解析エラーが「常に TypeScript のせいにする」表示をやめ、問題のある行を示すようになった点や、/workflows のエージェント一覧の表示が見やすく整理された点も入りました。いずれも、書いて回して直す、という運用の摩擦を減らす方向です。

速さの裏にあるトークンの請求書

数日を要する仕事が短時間で片づく一方で、見落とせない負の面もあります。Anthropic 自身が、動的ワークフローについて「通常の Claude Code セッションより大幅に多くのトークンを消費しうる」と明記しています。そのうえで、いきなり大規模な仕事に当てるのではなく、小さく範囲を絞ったタスクから始めることを勧めています。

数十から数百のエージェントが並走すれば、消費量はそれに応じて膨らみます。今回の small / medium / large という手綱は、単なる好みの設定ではなく、コストを手元で抑えるための実務的な弁でもある、と読むのが妥当です。従量課金への移行が広がるなか、規模を選べること自体が費用管理の一部になっています。「便利さの裏で、コストが読みにくくなる」という指摘は、この種の並列オーケストレーションに共通してついて回ります。

いま確認しておくこと

動的ワークフローを使う、あるいは無人でエージェントを回す運用を検討しているなら、次の3点を押さえておくと無駄が減ります。

• 既定のサイズを決める: 日常作業は small〜medium に寄せ、large は大規模な移植・監査など目的が明確なときだけに絞る。
• 観測を有効にする: OpenTelemetry を使っているなら、workflow.run_id / workflow.name で実行単位のコストと挙動を追える状態にしておく。
• 小さく試す: Anthropic の推奨どおり、範囲を絞った課題で挙動と消費量を確かめてから、規模を上げる。

単体モデルの賢さを競う段階から、多数のエージェントをどう束ね、どう手綱を握るかへ──開発の重心はそちらへ移りつつあります。v2.1.202の小さな設定項目は、その移り変わりに実運用の目盛りを一段付け足した更新だといえます。

参照: Claude Code changelog（v2.1.202） ／ Introducing dynamic workflows（Anthropic） ／ Orchestrate subagents at scale with dynamic workflows（Claude Code Docs） ／ Claude Code Adds Dynamic Workflows for Parallel Agent Coordination（InfoQ）