Claude Code Dynamic Workflowsとは──計画をコードに移し、サブエージェントを並列実行する仕組み¶

対象 / ポイント

対象: Claude Codeを実務で使うエンジニア。サブエージェント、スキル、エージェントチームとの違いを判断したい読者。

ポイント:

Dynamic Workflowsは、Claudeが生成したJavaScriptで多数のサブエージェントを並列に統括する仕組みである
違いの核心は、計画と中間結果をClaudeの文脈窓ではなくスクリプト側に置く点にある
大規模監査や移行には効くが、トークン消費・権限・再開条件を先に設計する必要がある

サービス全体にまたがるバグ調査、数百ファイルの移行、設計案の反証レビュー。こうした仕事は、一回の会話で「次はこれ」と判断し続けるほど取りこぼしが増える。

この記事の問いは、いつ通常のサブエージェントではなくDynamic Workflowsへ移すべきかである。 答えは、計画そのものを成果物にしたいときだ。

会話ではなくコードが段取りを持つ¶

Dynamic Workflowsでは、Claudeがタスクに応じてオーケストレーション用のJavaScriptスクリプトを生成する。 Claude Codeの専用ランタイムがそのスクリプトをバックグラウンドで実行し、サブエージェントを並列に起動する¹。

流れは単純だ。 Claudeがスクリプトを書き、ランタイムが実行し、統合結果だけが会話へ返る。

重要なのは速さだけではない。ループ、分岐、チェック対象リスト、中間結果がスクリプト変数に残るため、Claude本体の文脈窓を巨大な途中経過で埋めにくい。「50件をすべて確認する」「各指摘を別エージェントで反証する」といった段取りも、会話の勢いではなく実行されるコードとして保持できる。

サブエージェントと何が違うのか¶

違いは、誰が次の手を決め、中間結果をどこに置くかである¹。

方式	次の手を決める主体	中間結果の置き場
サブエージェント	Claude本体	Claudeの文脈窓
スキル	Claude本体	Claudeの文脈窓
エージェントチーム	リード役	共有タスクリスト
Dynamic Workflows	JavaScriptスクリプト	スクリプト変数

通常のサブエージェントでは、Claudeが手番ごとに「次に誰へ何を頼むか」を判断する。 Workflowでは、その判断の大部分がスクリプトへ移る。そのため、ワークフローは一度きりの会話ではなく、読める、直せる、再利用できる段取りになる。

ここで期待値を間違えると危ない。スクリプト化は「全項目を処理したか」を追いやすくするが、「統合結果が正しい」ことまでは保証しない。正解の基準は、テスト、仕様、レビュー観点として別に置く必要がある。

効く用途は大規模・横断・反証つき¶

Anthropicが挙げる用途は、大きく3つに分けられる²。

コードベース全体の監査: 認証漏れ、入力検証、セキュリティ境界、性能劣化を横断的に調べる
大規模な移行: フレームワーク差し替え、API廃止対応、言語移植など、対象が多数ファイルに広がる変更を進める
二重チェックが要る作業: 複数の独立試行と、結果を壊しにいく反証エージェントを組み合わせる

象徴的な事例が、BunのZigからRustへの移植である。 Anthropicの告知では、Jarred SumnerがDynamic Workflowsを使い、Rustで約75万行の書き換えを進めた。既存テストの99.8%が通過し、最初のコミットからマージまで11日間だったと説明されている²。

ただし、この事例は「本番投入前」と明記されている。成果としては強いが、品質基準の最終判断までWorkflowへ丸投げできる証拠ではない。大規模化するほど、実行計画と同じくらい検証基準が重要になる。

使い始める入口は3つある¶

最初の入口は、同梱済みの/deep-researchである。問いを複数の角度から調べ、情報源を相互照合し、残った主張だけを出典つきレポートにまとめる。

/deep-research Node.jsのpermission modelはv20とv22で何が変わったか

自分のタスクをWorkflow化するなら、プロンプトにultracodeを含めるか、「ワークフローで」と自然文で頼む。その一回だけ、ClaudeがWorkflow化の要否を判断して実行する。

ultracode: src/routes/配下の全APIエンドポイントを認証チェック漏れの観点で監査して

セッション全体で使いたい場合は、/effort ultracodeを設定する。これは推論努力度を高くしつつ、ClaudeにWorkflow化の判断を任せる設定である。実行状況は/workflowsで追跡でき、うまく動いた実行は.claude/workflows/配下に保存して再利用できる¹。

導入前に見るべき制約¶

最大の注意点はトークン消費である。 Workflowは多数のサブエージェントを起動するため、通常の会話より利用量とレート制限を大きく消費し得る。公式ドキュメントも、小さい範囲から試すことを推奨している¹。

実行上の制約も先に押さえる。

同時実行は最大16エージェントで、CPUコアが少ない環境では少なくなる
1回のWorkflow実行では最大1,000エージェントまで起動できる
実行中にユーザー入力を挟めないため、承認を分けたい場合は段階ごとに別Workflowへ分ける
再開できるのは同一セッション内だけで、Claude Codeを終了すると最初からになる

提供範囲も確認しておく。

利用にはClaude Code v2.1.154以降が必要である
Pro、Max、Team、Enterprise、API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundryで利用できる¹
Max、Team、Enterprise、APIでは既定で有効、Proでは/configから有効化する
組織管理者は管理設定で無効化できる

権限面では、Workflowが起動するサブエージェントは常にacceptEditsモードで動く¹。ファイル編集は自動承認される一方、許可リスト外のシェルコマンドやMCPツールは確認を求める場合がある。長時間実行する前に、必要なコマンドと触ってよい範囲を絞る設計が要る。

まとめ¶

Dynamic Workflowsの本質は、エージェントを増やすことではない。段取りを会話の流れから取り出し、読めて、再実行できて、レビューできるコードに変えることだ。

大企業の文脈では、この「段取りの資産化」が特に効く。 .claude/workflows/に保存されたスクリプトは、レビュー対象にもバージョン管理対象にもなる。毎ブランチで走らせる監査や、移行時の検証手順を、属人的な手順書ではなく実行可能な資産として共有できる。

一方で、Workflowは判断基準まで肩代わりしない。何を正解とみなすかは、人間がテスト、仕様、レビュー基準として先に置く必要がある。ここを取り違えなければ、Dynamic Workflowsは大規模なAI開発作業を「速くする道具」ではなく、「抜け漏れを減らしながら並列化する道具」として使える。