Claude Code Dynamic Workflows 完全ガイド — 最大1,000並列サブエージェントの仕組みと実践
2026年5月発表のClaude Code Dynamic Workflowsを徹底解説。通常のサブエージェント・Agent Teamsとの使い分け判断、/deep-researchコマンドの動作、カスタムワークフロー設計、Maxプランでのコスト感まで。
エンジニアのゆとです。
2026年5月28日、Claude Code にひっそりと大きな機能が追加された。Dynamic Workflows という名前で、一言で言うと「最大1,000のサブエージェントを並列起動して、大規模タスクをエンドツーエンドで自動実行する仕組み」だ。
Bun プロジェクトが Zig から Rust への移植を11日で完了させた事例では、75万行の Rust コードを生成して既存テストの99.8%をパスしている。規模感がおかしい。
ただ「すごそう」だけで使うと、普通のタスクにトークンを大量消費して終わる。従来のサブエージェントや Agent Teams との使い分けポイントをきちんと理解してから使わないと、Max プランの枠が一瞬で消える。
2026年6月時点の公式ドキュメントを読み込んで、実際の動作と設計思想を整理した。
Dynamic Workflows とは何か
4つのエージェント実行方式の整理
Claude Code にはいくつかの並列処理アプローチがある。公式ドキュメントの比較をそのまま引用する。
| アプローチ | 何をするか | 使うべき場面 |
|---|---|---|
| Subagents | 1セッション内で委譲、結果だけ返す | サイドタスクがメインコンテキストを汚染する場面 |
| Agent view | バックグラウンド起動・進捗監視 | 独立した複数タスクをhandoffして確認したい |
| Agent teams | 共有タスクリスト＋エージェント間通信（実験的） | Claudeに計画・割り当て・監視をやらせたい |
| Dynamic workflows | スクリプトが計画を保持、複数サブエージェント＋相互検証 | 数百ファイル移行・コードベース全体監査・相互検証が必要 |
Dynamic Workflows の特徴は「計画をコードとして保持する」点だ。
通常のサブエージェントや Agent Teams では、Claude のターン内判断（turn-by-turn judgment）が計画を持つ。セッションが長くなるほど、計画がぶれたり忘れたりする。Dynamic Workflows は JavaScript のスクリプトに計画を落とすことで、「途中でクラッシュしても再開できる」「何度でも再現可能なパターンを適用できる」という性質を持つ。
サブエージェントとの本質的な違い
通常のサブエージェント（Task tool 経由）はメインエージェントが動的に生成する。タスクが増減しても柔軟に対応できるが、数が増えると調整コストも増える。
Dynamic Workflows は違う。スクリプトに「何をするか」を事前に定義しておいて、そのスクリプトが大量のサブエージェントをオーケストレーションする。スクリプトが決定論的なので、「同じ入力に対して同じ手順が走る」再現性がある。
工場の組み立てラインに例えると、サブエージェントは「現場の判断で動く職人」、Dynamic Workflows は「設計図通りに動くライン」だ。どちらが優れているかではなく、タスクの性質次第。
対応プランと利用環境（2026年6月時点）
利用できるプランとインターフェースは以下の通り。
- Max・Team プラン: デフォルト有効
- Claude API: デフォルト有効
- Enterprise: 管理者による有効化が必要
- Pro プラン: 非対応
環境は Claude Code CLI、Desktop アプリ、VS Code 拡張、Amazon Bedrock、Vertex AI、Microsoft Foundry に対応している。
重要な制約として、2026年6月時点ではリサーチプレビュー段階。仕様・料金・挙動は変更される可能性がある。
動作の仕組み — 5フェーズで何が起きているか
/deep-research コマンドを例に
組み込みの Dynamic Workflow として /deep-research がある。「徹底的な調査を複数エージェントで実行する」用途に特化したワークフローで、内部では以下のフェーズが順番に走る。
- Scope — 調査対象の範囲と問いを定義する
- Search — 複数のサブエージェントが並列で検索を実行する
- Fetch — 各サブエージェントが情報源を取得・精読する
- Verify — 3投票制の敵対的検証（2票以上の反証で主張を却下）
- Synthesize — 統合して最終成果物を生成する
「Verify フェーズで3投票制の敵対的検証」という部分が面白い。別のエージェントが「この主張は本当か」を独立して検証し、反証が2票以上あれば主張をドロップする。単一エージェントでは起きない交差検証が、スクリプトの設計で実現できる。
進捗の追跡方法
ワークフロー実行中は /workflows コマンドで状況を確認できる。
実行中のワークフロー一覧、各フェーズの状態、完了済みエージェント数重要なのは進捗の逐次保存だ。途中でセッションが切れても、同じポイントから再開できる。数時間かかる大規模処理で「3時間走らせたら電源落ちた」が怖くない設計になっている。
カスタムワークフローの書き方
基本的な作成方法
プロンプトに「workflow」という単語を含めてリクエストすると、Claude が JavaScript のスクリプトを生成してくれる。
認証モジュール全体をリファクタリングするワークフローを書いて。
セキュリティ、パフォーマンス、テストカバレッジをそれぞれ独立して検証してから実装に入りたい。生成されたワークフローは以下のパスに保存できる。
- プロジェクト単位:
.claude/workflows/配下 - ユーザー単位（全プロジェクト共通）:
~/.claude/workflows/配下
保存したワークフローは /workflows からコマンドとして再利用できる。
適しているタスクの具体例
実際の用途として公式ドキュメントと実践例から整理した。
コードベース全体の監査 500ファイル以上のコードベースに対して、セキュリティ・パフォーマンス・テストカバレッジを並列で監査する。単一エージェントでは文脈が溢れるタスクを分散処理できる。
大規模マイグレーション
ESLint + Prettier → Oxlint + Oxfmt のような全ファイル対象の移行。各ファイルを独立したサブエージェントが担当して、コンフリクトなく並列処理する。
相互検証が必要なリサーチ 複数の情報源から事実を収集して、矛盾がないか交差検証する調査タスク。
通常のサブエージェント・Agent Teams との使い分け判断
どれを選ぶかの判断フロー
実際の判断は以下のフローで考えると迷わない。
タスクが数十ファイル以下 → 通常のサブエージェント（Task tool）
タスクが大きくて、ワーカー同士のコミュニケーションが必要 → Agent Teams（実験的機能、デフォルト無効）
タスクが大規模で、計画の再現性・相互検証・再開可能性が必要 → Dynamic Workflows
「プロジェクトを複数の独立した機能に分割して並列実装」という場合は Agent Teams が向いている。「コードベース全体をある条件でスキャンして修正」という場合は Dynamic Workflows の方が合っている。
コストの現実
Dynamic Workflows はトークン消費が跳ね上がる。公式も「通常セッションより著しく多くのトークンを消費する」と明記していて、小規模タスクから試すことを推奨している。
Max プランのトークン枠を意識するなら、まず /deep-research を小さめのトピックで動かしてコスト感を掴んでから、本番の大規模タスクに適用するのが現実的だ。
体感として、数十ファイルの調査タスクなら通常セッションの数倍〜10倍程度のトークンを覚悟した方がいい。ただし品質と速度は比例して上がるので、「クライアント向けの技術調査を1日で完了させる」という場面では十分に元が取れる。
実行前の確認と注意事項
初回確認プロセス
Dynamic Workflows を実行しようとすると、必ずユーザーへの確認が入る。実行内容のサマリーを提示した上で承認を求める設計になっていて、「知らないうちに大量処理が走った」は起きない。
Enterprise プランでは、管理者が managed settings から Dynamic Workflows を無効化することもできる。組織ポリシーによっては利用制限がかかる場合があるので、エンタープライズ環境では事前確認が必要。
向いていないタスク
シンプルなタスクに Dynamic Workflows を使うのはやりすぎだ。
- 単一ファイルの修正
- 10ファイル以下の変更
- ユーザーとの対話が必要な実装
- 短時間で終わる調査
これらは通常のセッションかサブエージェントで十分。「すごい機能だから使ってみよう」でコストを溶かすのが一番もったいない使い方になる。
よくある疑問
Q. /batch コマンドとの違いは何ですか？
/batch はスキルとして提供される機能で、大きな変更を5〜30のworktree分離サブエージェントに分割してそれぞれがPRを開くもの。Dynamic Workflows の特定ユースケース向けパッケージ版に近い。汎用的なオーケストレーション基盤が Dynamic Workflows で、/batch はその上に乗ったツールのイメージ。
Q. サブエージェントの isolation: worktree との組み合わせは？
Dynamic Workflows から生成されるサブエージェントも worktree で分離できる。並列で複数ファイルを書き換えるタスクでは、各サブエージェントに isolation: worktree を設定することでコンフリクトを防げる。
Q. ワークフローのデバッグ方法は？
/workflows でフェーズごとの状態を確認できる。特定のフェーズで止まっている場合、そのフェーズのサブエージェントに直接介入することができる。
Q. Pro プランで試す方法は？
2026年6月時点では Pro プランは非対応。Max プランへのアップグレードが必要になる。
まとめ
Dynamic Workflows は「コードが計画を持つ」というアプローチで、大規模タスクの再現性・相互検証・再開可能性を実現する機能だ。
使うべき場面は明確で、数百ファイル規模の移行・コードベース全体の監査・相互検証が必要な調査、このどれかに当てはまる時だ。数十ファイル以下のタスクや対話が必要な実装には通常のサブエージェントの方が合っている。
2026年6月時点ではリサーチプレビュー段階なので、仕様が変わる可能性はある。が、/deep-research は今すぐ使える形になっているので、まずそこから試してみるのがいい。
