Claude Code に Dynamic Workflows 登場 — Plan の所有者を Claude から script に渡す設計とは
はじめに
Anthropic が Claude Code に Dynamic Workflows を追加した。Hacker News では発表当日に 600 ポイント超を集め、賛否両論で大きな議論になっている。一見すると「Subagents を並列でたくさん動かせる機能」に見えるが、本質はもっと深い。「Plan を誰が持つか」という設計上の境界線を、Claude 自身から JavaScript の script に明け渡したのがこの機能の正体だ。本記事では、公式ドキュメントを基に Subagents や Skills との違い、内部の仕組み、Bun の Rust 移植という実例、そして HN コミュニティで指摘された現実的なコストまで掘り下げる。
Dynamic Workflows とは何か
Dynamic Workflows は、Claude Code v2.1.154 以降で利用できる新しいオーケストレーション層だ。仕組みはシンプルで、ユーザーがプロンプトに workflow という単語を含めるか、/effort ultracode を有効にすると、Claude は会話で逐次回答する代わりに JavaScript のスクリプトを書く。そのスクリプトをランタイムがバックグラウンドで実行し、数十から数百のサブエージェントを並列に走らせて、最終結果だけがセッションに戻ってくる。
ランタイムには明確な制約がある。同時実行は最大 16 エージェント、1 run あたり合計 1,000 エージェントまで。スクリプト自体はファイルシステムやシェルに直接触れず、すべての I/O は spawn したエージェント経由で行う。途中でユーザー入力を挟むことはできず、ステージ間で承認が必要なら別ワークフローに分割する設計になっている。利用は Pro / Max / Team / Enterprise の各プラン、API、Bedrock、Vertex AI、Microsoft Foundry で可能。
Subagents との根本的な違いは「Plan の所有者」
Subagents や Skills を使ったことがある人ほど、「Dynamic Workflows って結局 Subagents を並列実行するためのラッパーじゃないの？」と感じるかもしれない。公式ドキュメントはこの問いに正面から答えていて、「次に何を実行するかを誰が決めるか」が決定的に違うと説明する。
| Subagents | Skills | Workflows | |
|---|---|---|---|
| 次の一手を決めるのは | Claude（turn 単位） | Claude（指示に沿う） | スクリプト |
| 中間結果の置き場所 | Claude のコンテキスト | Claude のコンテキスト | スクリプト変数 |
| 再現性があるのは | worker 定義 | 指示書 | オーケストレーション自体 |
| スケール | 1 turn 数件 | 同上 | 1 run 数十〜数百 |
| 中断時の挙動 | turn を再開 | turn を再開 | 同一セッション内で resume 可 |
ここが本質だ。Subagents や Skills では Claude が司令塔で、結果はすべて Claude のコンテキストウィンドウに戻ってくる。一方 Workflows は ループ・分岐・中間結果の保持をすべて script 側が抱えるため、Claude のコンテキストには最終回答だけが届く。コンテキスト汚染を構造的に防げるのが、単なる並列化との根本的な違いだ。
そして副産物として、「結果を別エージェントが反駁レビューする」「複数の角度から計画を立てて重み付けする」といった反復可能な品質パターンをコード化できるようになる。1 回の Claude 呼び出しでは難しい「自分の出力を疑う」プロセスを、スクリプトという外部の仕組みが強制できるわけだ。
実例：Bun の Zig → Rust 移植 750,000 行
Anthropic はこの機能で達成された実例として、Bun の作者 Jarred Sumner による Bun ランタイムの Zig から Rust への移植 を挙げている。750,000 行の Rust コード、既存テストスイートの 99.8% パス、初回コミットから merge まで 11 日。社内事例では token 使用量を 15% 削減する最適化、WASM モジュールの TypeScript 移植、69 件のコード簡素化 PR の出荷など、いずれも「個別ファイルへの細かい変更が大量に積み重なるタイプ」のタスクで成果を出している。
ここで重要なのは、いずれも 「正解の判定が機械的に可能」 なタスクである点だ。テストが通るか、ベンチが速くなるか、リンタが黙るか。Workflows は判定基準が客観的なほど威力を発揮する。
エンジニアへの影響：何を任せるか、何を任せないか
HN のトップコメントは冷ややかだ。「私のボトルネックは Claude が自分でコードをこねくり回すスピードじゃない。Claude が正しく動くかどうかだ」。実際、ある利用者は Java ゲームの C# 移植で 20 億トークンを消費した報告を投稿しており、「tokenmaxxing disguised as a product（製品の皮を被ったトークン最大化）」という辛辣な評価も目立つ。
この機能をどう使うかは、結局のところエンジニア側の判断力に戻ってくる。**向いているのは「機械的に検証可能で、かつ広い範囲をカバーする必要があるタスク」**だ。コードベース全体のセキュリティ監査、profiler 主導の最適化、500 ファイル規模のマイグレーション、auth チェックの全 endpoint 横断検査。これらは独立した検証エージェントを並列に走らせることで、人間が逐次確認するより高い網羅性を得られる。
逆に **向いていないのは「正解が曖昧で、文脈の理解が報酬になるタスク」**だ。UI の細かな違和感の修正、ビジネスロジックの設計判断、ユーザー体験を左右する API スキーマの命名。これらは並列化で品質が上がるどころか、「slop debt（雑な実装の借金）」を高速で積み上げる装置になりかねない。
なお、/effort ultracode を有効にすると Claude が毎タスク自動で Workflow を計画する。便利だが、毎リクエストのコストとレイテンシが跳ね上がるため、ルーチン作業に戻ったら /effort high で抜けるのが現実的だ。
まとめ
- Dynamic Workflows は「Subagents の並列実行版」ではなく、Plan の所有者を Claude から script に移す設計変更
- 中間結果がコンテキストに戻らないため、大規模タスクでも文脈が汚染されない
- 反復可能な品質パターン（反駁レビュー、多角的プランニング）をコード化できる
- 一方でトークン消費は 1〜2 桁増える。Bun の Rust 移植のような検証可能タスクには劇的に効くが、曖昧なタスクに投入すると slop が高速で積み上がる
- 使い分けの軸は「正解を機械的に判定できるか」。判定基準が客観的なほど Workflows は強い
オーケストレーションを Claude 任せにせず、スクリプトという読める・再実行できる成果物として残す。この発想自体は OMC や ralph などコミュニティ製のオーケストレータが先行していた領域だが、それが公式ランタイムに組み込まれた意義は大きい。今後 .claude/workflows/ に資産が貯まり、チームで共有・改良される文化が育つかが本機能の真価を決めるだろう。