既視感の正体
複数のサブエージェントを並列で走らせる。それなら去年からやっている。だから動的Workflows（dynamic workflows）の発表を見たときの第一声は「で、何が新しいんだ?」だった。
公式ドキュメントによれば、本体の差はオーケストレーション（計画）を誰が持つかにある。並列実行の速さは副次的な違いにすぎない。
サブエージェントの司令塔はClaude自身だ。「次に何をspawnするか」をターンごとに推論で決める。賢く判断できる一方、同じ依頼でも何を何個どの順で呼ぶかがその場の推論で変わりうる。段取りが固定される保証がない。
動的Workflowsはこの計画をJavaScriptのスクリプトに書き出す。スクリプト自体はClaudeが都度生成する確率的な産物だが、いったん書き出されればループも分岐もファンアウトもそのコードが持つ。決定論的になるのは「どの段を何個、どの順で回すか」という制御フローであって、各エージェントが返す中身ではない。骨格はコードに固定され、肉（LLMの出力）は依然ブレる。再現するのはこの段取りだ。
献立を考えるのは料理人の勘でいい。だが一度決めた段取りは、誰がやっても同じ順で回ってほしい。動的Workflowsは生成をLLMに、実行の段取りをランタイムに分けた。これがサブエージェントには無かった構造だ。
| サブエージェント | スキル | Workflow | |
|---|---|---|---|
| 正体 | Claudeが生むworker | Claudeが従う指示書 | ランタイムが実行するスクリプト |
| 次の実行を決めるのは | Claude（ターンごと） | Claude | スクリプト |
| 中間結果の置き場所 | Claudeのコンテキスト | Claudeのコンテキスト | スクリプト変数 |
| スケール | 数個/ターン | 同左 | 数十〜数百/run（同時16・上限1,000） |
動的Workflowsはリサーチプレビューで、v2.1.154以降が必須。有料プランとAPI、Bedrock/Vertex/Foundryで使える。
検証: 冷蔵庫の余り物で最強の一皿を決める
金曜の夜、冷蔵庫には卵が2個、昨日の冷やごはん、しなびかけたキャベツ1/4玉、ベーコン2枚。調味料はしょうゆ・塩・こしょう・サラダ油だけ。10分で一皿にしろ。これを7体のエージェントに競わせた。
- propose: 和食・洋食・中華の3シェフが独立に一皿を提案する
- verify: 各レシピを別エージェントが辛口で検証する（10分で作れるか / 無い材料を勝手に足していないか / 味の落とし穴は何か）
- synthesize: 審査員長が優勝を1つ選び、検証で出た注意点を反映した最終レシピを出す
（ここでworkflowの文字列が虹色に輝く）
Claudeが生成したスクリプトの抜粋を載せる。pipeline / agent / phase / schema は公式のAPIリファレンスに載っておらず、この版のものだ。
phase('Propose')
const reviewed = await pipeline(
CHEFS,
// 段1: 各シェフが構造化スキーマでレシピを提案
(chef) => agent(chef.prompt, { phase: 'Propose', schema: RECIPE_SCHEMA }),
// 段2: そのレシピを辛口検証（作れるか/禁止材料/味の落とし穴）
(recipe, chef) => agent(
`この余り物レシピを辛口で検証して。10分でこの材料だけで作れる? 無い材料を勝手に足してない? ...`,
{ phase: 'Verify', schema: CHALLENGE_SCHEMA }
).then((challenge) => ({ recipe, challenge }))
)
phase('Synthesize')
const synthesis = await agent(`あなたは審査員長。優勝の一皿を選び、検証の注意点を反映した最終レシピを...`)
実測は所要約76秒、エージェント7体、消費トークン約19万。メインのチャットに戻ってきたのは最終JSONだけで、19万トークン分の中間やり取りはこちらのコンテキストに乗らなかった。Workflowが中間結果をスクリプト変数に逃がすからだ。
結果: シェフの提案と、検証エージェントのツッコミ
| シェフ | 一皿 | 検証判定 |
|---|---|---|
| 和食 | ベーコンキャベツの和風あんかけ卵チャーハン | flawed（脱落） |
| 洋食 | しょうゆ風味チャーハン風オムライス | ok（優勝） |
| 中華 | キャベツとベーコンの卵チャーハン | ok |
3人とも結局チャーハン的な何かに収束した。面白いのはその先で、検証エージェントが何を拾ったかにある。
3案すべてに、ほぼ同じダメ出しが返ってきた。「卵に塩こしょう、しょうゆ、仕上げにまた塩こしょう。塩が三重がけになる。ベーコン自体も塩辛いので、ほぼ確実にしょっぱくなる」。和食案はこれに加えて「あんかけと名乗るのにとろみ材料が無い」を突かれ、flawed判定で脱落した。
審査員長は洋食案を選び、全員が指摘した塩分三重がけを解消するため、最終レシピでは溶き卵への塩を省いた。
ここが体感した新規性だ。単発で「余り物でレシピ考えて」と頼むだけなら、塩の入れすぎに気づかないまま完成形のレシピが出てくる。検証段を構造として挟んだことで、別の独立したエージェントが塩分過多を発見し、その指摘が最終レシピに反映された。
ただしこれは n=1 の観察で、しかも塩分過多は材料から予測しやすい欠陥だ。「このパターンが常に効く」証明ではなく、検証段が提案段の見落としを拾って最終出力に反映する経路が実在する、という存在証明として読んでほしい。コードレビューや大規模監査への外挿は、公式が掲げるユースケースに対する仮説だ。
外部のワークフロー基盤との違い
LangGraphやn8nでも多段のエージェント処理は組める。本質的な差は、別途インフラを構築せず、セッションの権限とMCPを継承したまま自然言語の一語で起動できる統合度にある。プロンプトに workflow と入れるだけでClaudeがスクリプトを書き起こす。同じ fan-out → 検証 → 統合の構造は、公式も /deep-research として製品化済みだ。
試すには
Claude Code v2.1.154以降を用意し（Proは /config の Dynamic workflows をオン）、Workflow ツールにスクリプトを渡す。数百エージェントを回すrunは会話で進めるより大幅にトークンを食い、レート制限にもカウントされる。規模を上げる前に消費量を見ておくこと。
実測値・出力は本検証時点（Claude Code 2.1.156 / Opus 4.8）のもの。バージョンで挙動・コスト・出てくるレシピは変わる。
冷蔵庫の余り物に7人がかりは過剰だ。だがその過剰さの中で見えたのは一点だった。「次に何をするか」をLLMの勘から外し、段取りをコードに固定した瞬間、エージェントは賢いがブレる相棒から、同じ手順で回る道具に変わる。前からあったのは並列だ。新しいのは、段取りを誰が握るかだった。