Claude Code に Dynamic Workflows(ダイナミックワークフロー)Research Preview が登場した。Claude がタスクに応じてオーケストレーションスクリプト(JavaScript)を動的に生成し、専用のランタイムがバックグラウンドで実行する仕組みだ。1 セッション内で数十から数百の並列サブエージェントを走らせ、結果を取り込む前に検証する。これまで週単位かかっていた複雑なエンジニアリング作業を、数日で完了させることを狙った機能だ。
単一エージェントの 1 パスでは大きすぎる問題――サービス全体にまたがるバグ探索、数百ファイルに触れるマイグレーション、あらゆる角度からストレステストしたいプラン――こうしたタスクを end-to-end で扱えるのが特徴になっている。
第3のオーケストレーションプリミティブ
Dynamic Workflows を理解する鍵は、Subagents・Skills との違いを「プランの保持者が誰か」という軸で捉えることだ。いずれもマルチステップのタスクを実行できるが、計画を抱える場所が異なる。
| Subagents | Skills | Workflows | |
|---|---|---|---|
| 正体 | Claude が spawn するワーカー | Claude が従う指示 | ランタイムが実行するスクリプト |
| 次の実行を決めるのは | Claude(ターンごと) | Claude(プロンプトに従う) | スクリプト |
| 中間結果の保管場所 | Claude のコンテキスト | Claude のコンテキスト | スクリプト変数 |
| 再現できるもの | ワーカー定義 | 指示 | オーケストレーション自体 |
| スケール | 数タスク/ターン | 同左 | 数十〜数百/run |
| 中断時 | ターン再起動 | ターン再起動 | 同一セッション内でレジューム可能 |
Subagents や Skills では Claude がオーケストレータを務め、ターンごとに次に何を spawn するかを決め、すべての結果が Claude のコンテキストに着地する。一方 Workflows では、ループ・分岐・中間結果をスクリプト自身が抱えるため、Claude のコンテキストには最終回答だけが残る。
プランをコードに移すことは、単にエージェントの数を増やす以上の意味を持つ。独立したエージェントに互いの findings を敵対的にレビューさせたり、複数の角度からプランを起草して互いに比較検討させたりと、再現可能な品質パターンを適用できる。これが単一パスよりも信頼できる結果につながる。
動く仕組み
ワークフローが起動すると、Claude はプロンプトをもとに動的に計画を立て、サブタスクに分解し、並列で走るサブエージェントに work を fan-out する。結果は取り込まれる前に検証され、ユーザーには 1 つの調整済みの回答が返る。エージェントが独立した角度から問題に取り組み、別のエージェントがその発見を反証しようとし、答えが収束するまで反復が続く――これが単一パスでは到達できない結果に至る仕組みだ。
レジューム: 進捗は run の進行中に保存される。中断されたジョブは最初からやり直すのではなく、中断地点から再開する。調整が会話の外側で行われるため、タスクがどれだけ大きくなってもプランは軌道を保つ。ただしレジュームは同一 Claude Code セッション内のみ有効で、Claude Code を終了すると次セッションでは fresh で再起動する。
3つの起動方法
ワークフローを始める方法は大きく 3 つある。最も手軽なのは組み込みの /deep-research を実行することだ。
bundled workflow を使う
/deep-research は質問を複数の角度に fan-out し、見つけたソースを fetch・クロスチェックして、引用付きのレポートを生成する。クロスチェックを生き残らなかった主張は除外される。
プロンプトに workflow と書く
セッションの effort レベルを変えずに単発のタスクをワークフローとして実行したいときは、プロンプトのどこかに workflow という単語を含める。Claude がその単語をハイライトし、ターンごとの処理ではなくワークフロースクリプトを書く。
ultracode で自動判断させる
/effort ultracode は xhigh の推論 effort と自動ワークフローオーケストレーションを組み合わせた設定。ON にすると Claude がセッション内の substantive なタスクごとにワークフローを計画する。現セッション限りで、新セッションでリセットされる。
実行した run が望み通りの動作をしたら、/workflows でその run を選び s キーでコマンドとして保存できる。.claude/workflows/(プロジェクト共有)または ~/.claude/workflows/(個人・全プロジェクト)に保存され、次回以降は /<name> として呼び出せる。
主なユースケース
Anthropic 社内や早期アクセスのチームでは、すでに幅広い用途で使われている。
コードベース全体の監査
バグ探索、プロファイラ駆動の最適化監査、セキュリティ監査。サービスやリポジトリを並列探索し、各 finding を独立検証してから報告する。auth チェックや入力バリデーションの hardening パスにも同じ形が使える。
大規模マイグレーション
フレームワークの swap、API 廃止対応、言語ポートなど、数千ファイルにまたがる作業を end-to-end で処理する。
二重チェックが必要な作業
誤答のコストが高いとき、ワークフローは問題に対する独立した試行と、結果を破ろうとする敵対エージェントを与える。
クロスチェック付きリサーチ
互いに突き合わせる必要のあるソースを横断的に検証し、引用付きの調査レポートにまとめる。
事例:Bun の Zig → Rust 書き換え
スケールで何が解き放たれるかを示す例が、Bun の書き換えだ。
11 日でのフルポート
Jarred Sumner が Dynamic Workflows を使い、Bun を Zig から Rust へポートした。既存テストスイートの 99.8% がパスし、約 75 万行の Rust、初コミットからマージまで 11 日。1 つのワークフローが Zig コードベースの全 struct field に対する正しい Rust lifetime をマッピングし、次のワークフローが各 .rs ファイルを .zig の挙動と同一になるよう書いた――数百のエージェントが並列で動き、各ファイルに 2 人のレビュアーがついた。その後 fix loop が build とテストスイートを clean になるまで駆動した。ポート完了後は、夜間のワークフローが不要なデータコピーに対処し、最終レビュー用の PR を 1 つずつ開いた。
提供状況と制限
Dynamic Workflows は Claude Code v2.1.154 以降が必要で、CLI・Desktop アプリ・VS Code 拡張・claude -p(非対話モード)・Agent SDK で利用できる。全有料プラン(Pro / Max / Team / Enterprise)に加え、Anthropic API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry で使える。Max・Team・API ではデフォルト ON、Enterprise はローンチ時 OFF(admin が変更可能)、Pro は /config の Dynamic workflows 行から ON にする。
使う前に押さえておきたい制約
- トークン消費が桁違いに大きい。同じタスクを会話で処理するより大幅に消費し、プラン使用量・レート制限にカウントされる。まずはスコープを絞ったタスクから始めるのが公式推奨
- run 中のユーザー入力は不可(エージェントの permission prompt のみ pause 可能)。ステージ間の承認が要るなら各ステージを別ワークフローにする
- ワークフロー自体は直接のファイルシステム/シェルアクセス不可。実際の読み書き・コマンド実行はエージェントが行い、スクリプトは調整役に徹する
- 同時実行は最大 16 エージェント(CPU コアが少ないマシンではより少ない)、1 run あたり合計 1,000 エージェント上限
- サブエージェントは常に acceptEdits モードで動作し、ツール allowlist を継承する。allowlist 外の shell コマンド・web fetch・MCP ツールは run 中に prompt が出ることがあるため、長時間 run では事前に追加しておく
- 無効化は
/configのトグル、settings.jsonの disableWorkflows、環境変数 CLAUDE_CODE_DISABLE_WORKFLOWS で可能。組織全体は managed settings で制御
所感
Dynamic Workflows は Subagents・Skills に続く第 3 のオーケストレーションプリミティブで、「プランの保持者が誰か」という軸で整理すると腑に落ちる。中間結果がスクリプト変数に隔離され、Claude のコンテキストには最終回答だけが返るという設計は、コンテキスト効率や KV キャッシュ最適化の観点からも示唆に富む。
特筆すべきは「量産」ではなく「再現可能な品質パターン」をコードに codify できる点だ。/deep-research のクロスチェック → 投票 → 生存しない主張を除外という流れは、技術記事を書く際のリサーチ工程にもそのまま応用できそうだ。
一方で運用コストは無視できない。1 run 最大 1,000 エージェント・同時 16 という規模感は、個人開発ではコスト管理が要になる。/model で安いモデルに切り替えたり、ステージごとにモデルを使い分けるよう指示したりするのが現実的な落としどころになるだろう。