Claude Dynamic Workflowsの実務整理:並列サブエージェントで大規模タスクを処理する
はじめに
Anthropicが2026年5月28日に発表した Dynamic Workflows は、Claude Codeがオーケストレーションスクリプトを作成し、多数のサブエージェントへ処理を分配する機能です。発表後に一般提供へ移行し、2026年6月14日時点ではClaude Code CLI、Desktop、VS Code拡張、Claude APIなどで利用できます。[1]
公式事例では、BunのZigからRustへの移植で、約750,000行のRustコードを生成し、既存テストの99.8%を通過した状態まで11日で進めたと報告されています。[1] この記事では、規模の大きさだけでなく、どのような構造のタスクに適しているかを整理します。
この記事は機能の仕様、適用条件、制約を扱います。コードレビューへの具体的な適用はサブエージェントを使ったコードレビューの並列実行に分けています。
Dynamic Workflowsとは
Dynamic Workflowsとは、Claude Codeがタスクを分解するJavaScriptワークフローを生成し、複数のサブエージェントを並列実行して結果を検証・統合する仕組みです。
通常の会話ではClaudeがツール呼び出しと中間結果を会話コンテキスト内で管理します。Dynamic Workflowsでは、オーケストレーションが会話から分離された実行環境で動き、中間結果をスクリプト変数に保持します。[2]
通常の会話との違い
| 項目 | 通常のClaude Code会話 | Dynamic Workflows |
|---|---|---|
| 処理方式 | 会話内で逐次的に進める | 複数エージェントを並列調整する |
| 中間結果 | 会話コンテキストへ入りやすい | ワークフローの変数に保持する |
| 適した規模 | 小規模から中規模の作業 | 大規模な調査、移行、検証 |
| 中断・再開 | セッション履歴を基に再開する | 同じセッション内で完了結果を再利用して再開する |
| コスト | 標準的 | 複数エージェント分だけ大きくなりやすい |
アーキテクチャの仕組み
1. JavaScriptスクリプトによるオーケストレーション
ユーザーがワークフロー作成を依頼すると、Claudeはタスクをフェーズへ分け、JavaScriptスクリプトを生成します。実行前にはフェーズ構成を確認でき、CLIでは生のスクリプトを開いて確認することもできます。[2]
ユーザーがタスクを説明
↓
Claudeがワークフロースクリプトを生成
↓
実行計画を確認して開始
↓
サブエージェントが並列で作業
↓
結果を検証・統合
↓
最終結果を会話へ返す中間結果を会話へ順番に貼り付けず、スクリプト内で保持できるため、大量の探索結果を整理しやすくなります。
2. 並列実行の上限
公式ドキュメントでは、1回のワークフローにつき最大16エージェントを同時実行し、合計1,000エージェントまで起動できます。CPUコアが少ない環境では、同時実行数が16未満になる場合があります。[2]
上限まで使うことが目的ではありません。独立した作業単位を必要な数だけ作り、検証に必要なエージェントを追加する設計が重要です。
3. 独立した試行と検証
Dynamic Workflowsは、複数のエージェントが独立した角度から問題を調査し、別のエージェントが結果を反証・検証する構成を取れます。[1]
- エージェントAが問題を調査する
- エージェントBが別の仮説で調査する
- 検証エージェントが両方の結果を確認する
- オーケストレーターが結果を統合する
この構造は、コードベース全体のバグ調査やセキュリティ監査のように、見落としのコストが高い作業に適しています。
4. 同一セッション内での再開
停止したワークフローは、同じClaude Codeセッション内で再開できます。完了済みエージェントの結果は再利用され、未完了部分だけが動きます。Claude Codeを終了した場合は、次のセッションで最初から実行されます。[2]
この制約があるため、長時間の処理ではセッションを終了する前に完了状況を確認する必要があります。
公式事例:BunをZigからRustへ移植
Anthropicの公式ブログでは、Bunの作者Jarred SumnerがDynamic Workflowsを使い、BunをZigからRustへ移植した事例を紹介しています。[1]
プロジェクト概要
- タスク: BunのコアをZigからRustへ移植
- 成果物: 約750,000行のRustコード
- 期間: 最初のコミットからマージまで11日
- テスト: 既存テストスイートの99.8%が通過
- 状態: 公式記事の公開時点では本番未導入
処理の内訳
公式記事によると、ワークフローは次のように分けられました。[1]
- Zigコード内の各構造体フィールドに対応するRustのライフタイムを整理する
.zigファイルに対応する.rsファイルを並列作成する- 各ファイルを2つのレビュー担当で確認する
- ビルドとテストが通るまで修正ループを実行する
- 移植後に不要なデータコピーを調査し、修正PRを作成する
この事例は、移植対象をファイル単位へ分けられ、テストで結果を検証できた点が重要です。同じ規模であっても、分割できない作業や自動検証できない作業には、そのまま適用できません。
向いているタスクと向いていないタスク
Dynamic Workflowsが向いているタスク:
- 大規模コード調査: バグ、セキュリティ問題、不要コードを並列探索する
- 移行・モダナイゼーション: 多数の独立ファイルを同じ規則で変更する
- 複数視点のレビュー: 独立した仮説や反証を組み合わせる
- テスト拡充: 対象単位ごとにテスト生成と検証を分ける
- 独立した文書処理: 多数のファイルを同じ品質基準で変換する
別の方法を優先したいタスク:
- 順序依存が強い作業: 前工程の判断が次工程を大きく変える
- 同じファイルへ集中する編集: 並列変更が競合しやすい
- 小規模な修正: ワークフロー生成と調整のコストが見合わない
- 途中で人の判断が必要な作業: 実行中に通常のユーザー入力を受け取れない
効果的なタスク記述のコツ
ワークフローへ渡す依頼では、対象範囲、独立して処理できる単位、検証方法を明示します。
改善してください:
このコードベースを改善してください。
推奨:
src/以下のPythonファイルを対象に、ファイル単位で以下を実行してください。
1. 型ヒントを追加する
2. Google styleのdocstringを追加する
3. 未使用インポートを削除する
各ファイルの変更後にmypy --strictを実行し、失敗したファイルだけを修正してください。
最後に、別のエージェントが変更内容と型チェック結果をレビューしてください。「何を並列化できるか」と「何をもって完了とするか」が明確であれば、Claudeはフェーズと検証担当を設計しやすくなります。
コストと運用上の制限
Dynamic Workflowsは通常のClaude Codeセッションより多くのトークンを消費します。公式ドキュメントも、最初は1つのディレクトリや狭い問いで試すことを推奨しています。[1][2]
- 小さな範囲で実行し、エージェント数とトークン使用量を確認する
/workflowsで各エージェントの使用量と進捗を監視する- 不要な実行を停止し、完了結果を再利用する
- 反復する処理は保存済みワークフローとして管理する
また、ワークフロー本体はファイルシステムやシェルへ直接アクセスせず、実際の読み書きやコマンド実行はサブエージェントが担当します。実行中に通常のユーザー入力を受け取れないため、承認が必要な工程は別ワークフローへ分ける必要があります。[2]
まとめ
Dynamic Workflowsの主な特徴は次のとおりです。
- 並列化: 独立した作業を複数のサブエージェントへ分配する
- コンテキスト分離: 中間結果をワークフロー実行環境へ保持する
- 検証: 独立した試行と反証を組み合わせる
- 規模: 最大16同時、合計1,000エージェントまで実行できる
- 再開: 同一セッション内で完了結果を再利用できる
有効性を左右するのはエージェント数ではなく、タスクを独立した単位へ分けられるか、自動検証できるかという点です。最初は狭い範囲で使用量と結果を確認し、再現性のある作業だけを保存済みワークフローへ広げる進め方が適しています。
参考文献
- Anthropic, Introducing dynamic workflows in Claude Code, 2026年5月28日
- Anthropic, Orchestrate subagents at scale with dynamic workflows, Claude Code Docs