Claude Codeの動的ワークフロー：並列化ではなく「オーケストレーションの自動生成」が本質¶

対象 / ポイント

対象: Claude Codeを業務で使う開発者、AIエージェント導入を検討するエンジニアリング責任者。サブエージェントの基本概念は既知とする。

ポイント:

本質は並列数ではなく、Claudeがオーケストレーション用スクリプトを書く点にある。
Bun移植事例は強いが、本番投入済みの成功事例としては読まない。
導入判断は能力よりコスト、権限、組織設定で決まる。

2026年5月28日、AnthropicがClaude Codeに「動的ワークフロー」を追加した。公式ブログは「四半期単位で計画する作業が数日で終わる」と表現している。ただ、実務で先に見るべきなのは宣伝文句ではない。何が自動化されたのか、どこに制限があるのか、どの運用条件なら使えるのかである。¹

この記事の問いは一つだ。動的ワークフローは、単なるサブエージェント並列化なのか、それともClaude Codeのハーネス設計を変える機能なのか。

何が変わったのか¶

変化の中心は、計画が会話コンテキストからワークフローのコードへ移ったことだ。

従来のサブエージェント運用では、Claudeが会話ターンごとに次の委譲を判断する。手組みのエージェントチームでは、人間が役割、順序、合流条件を設計する。動的ワークフローでは、Claudeがタスク用のJavaScriptワークフローを書く。それをバックグラウンドのランタイムが実行する。²

この違いは小さく見えて大きい。中間結果をすべて会話コンテキストに積むのではなく、スクリプト変数として保持できる。ループ、分岐、検証パス、サブエージェントの割り当てが、実行可能なオーケストレーションとして残る。

単純化すると、次の三段階で捉えられる。

形態	計画を持つ主体	向いている作業
単一サブエージェント	Claudeの会話ターン	小さな調査、局所レビュー
動的ワークフロー	Claudeが生成したスクリプト	大規模監査、移行、反証つき調査
手組みのエージェントチーム	人間が設計したチーム構成	継続運用、固定プロセス、組織標準

つまり本質は「たくさん並列実行できる」ことではない。オーケストレーションを書く主体が、実行時のClaudeへ移ったことにある。

ただし、無制限の並列実行ではない¶

公式Docs上の制約を見ると、動的ワークフローは「数百を同時に走らせる機能」ではない。

Anthropicのブログは「数十から数百の並列サブエージェント」と表現している。一方、Claude Code Docsはより具体的だ。同時実行は最大16エージェント、1回のワークフローで合計1,000エージェントまでと説明している。² したがって、実務上は「多数のサブエージェントを段階的に回す仕組み」と読むほうが安全だ。

この制約は悪い話ではない。ローカルマシンのCPU、ツール権限、トークン消費を考えると、同時実行数に上限があるほうが運用しやすい。重要なのは、最大数を誇ることではなく、調査、実装、検証をどの順序で流すかである。

ここで精度に効くのが反証の構造だ。公式ブログは、あるエージェント群が独立した角度から問題に取り組むと説明している。別のエージェント群がその結果を反証し、答えが収束するまで反復する設計である。¹

たとえばコードベース全体のバグ探索では、並列に探索したあと、見つかった指摘ごとに独立した検証を回す。単なる「探して集める」ではなく、「探す」と「崩す」を分離する設計である。

Bun移植事例をどう読むか¶

BunのZigからRustへの移植は、能力のショーケースとして強い。ただし、本番投入済みの成功例として扱うべきではない。

公式ブログによると、Jarred Sumner氏は動的ワークフローを使い、BunをZigからRustへ移植した。既存テストスイートの99.8%が通過した。 Rustコードは約75万行、最初のコミットからマージまで11日だったとされる。¹

数字だけ見れば強烈だ。 1つのワークフローが、Zigコードベース内の構造体フィールドに適切なRust lifetimeを対応づけた。

次のワークフローは各.zigファイルに対応する.rsファイルを書いた。ファイルごとに2人のレビュー担当エージェントを付け、修正ループでビルドとテストを通したと説明されている。¹

一方で、評価には留保が必要だ。

本番投入はまだされていない。 公式ブログ自身がそう明記している。
99.8%のテスト通過は品質指標の一つであり、本番エッジケースの保証ではない。
高いドメイン知識を持つ開発者の事例であり、組織の平均的な再現性とは分けて考える必要がある。

この事例から学ぶべきことは、AIが人間を置き換えた話ではない。強い専門家が意図と境界を与えたとき、Claude Codeが生成するワークフローは移植作業の一部を大規模に分解・検証できる。

ハーネス階層で見る¶

動的ワークフローは、プロンプトの改善ではなくハーネス層の自動生成に近い。

ハーネスとは、モデルに仕事をさせるための足場である。どのツールを、どの順序で、どの権限で、どの検証を挟んで動かすか。この外側の設計が、AIエージェントの品質と安全性を大きく左右する。

動的ワークフローでは、この足場の一部をClaudeが実行時に書く。ワークフロー自体はファイルシステムやシェルへ直接アクセスしない。読み書きやコマンド実行はサブエージェント側が担う。 Docsは、サブエージェントがツール許可リストを継承し、ファイル編集は自動承認されるとも説明している。²

この設計は便利だが、同時に運用上の論点を生む。ワークフローを有効にする前に、許可するツール、編集してよい範囲、長時間実行時の停止判断を決めておく必要がある。

利用者に求められるスキルも変わる。以前は「どう並列化を設計するか」が重要だった。これからは、何を達成したいか、どこまで任せてよいか、何を成功条件にするかを明確に渡す能力がより重要になる。

導入判断はコストとガバナンスで決まる¶

導入可否は、機能の派手さではなく運用条件で判断する。

まずコストだ。公式ブログとDocsはいずれも、動的ワークフローが通常のClaude Codeセッションより大幅に多くのトークンを消費しうると注意している。多数のサブエージェントと反証ループを動かす以上、これは例外ではなく仕様である。¹²

次に提供範囲である。 2026年5月30日時点のDocsでは、Claude Code v2.1.154以降が必要だ。

全有料プラン、Anthropic API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundryで利用可能と説明されている。 Proプランでは/configのDynamic workflows行から有効化する。²

一方、ローンチ時点の公式ブログでは、MaxとTeamは既定で有効と説明されている。 Enterpriseは管理者が有効化した場合に対象となり、API経由も利用可能だ。¹ 公開直後の機能なので、プラン別の既定値は公式Docsと管理画面で確認する前提にしておくのが安全だ。

起動方法は主に二つある。

プロンプトにworkflowを含める。 Claudeがそのタスク用のワークフローを書く。
/effort ultracodeを有効にする。 xhigh推論努力と自動ワークフロー判断を組み合わせる。

ultracodeは便利だが、すべての実質的なタスクでワークフロー化を検討する設定でもある。日常作業に戻るときは/effort highへ戻す運用が必要だ。²

最初に試すなら何を選ぶか¶

最初のタスクは、編集よりも読み取り中心の監査がよい。

たとえば、認証漏れの探索、未使用コード候補の洗い出し、移行計画の反証、リリース前レビューが向いている。影響範囲が見えやすく、結果の正誤を人間が確認しやすいからだ。

逆に、初回から数百ファイルの自動編集や本番設定の変更に使うのは避けたい。ワークフローは強力だが、ファイル編集が自動承認される場面もある。権限とレビュー境界を固める前に、大規模変更へ直行する必要はない。

まとめ¶

動的ワークフローの価値は、並列数の多さでは測れない。 人間が毎回手で組んでいたオーケストレーションを、Claudeが生成し、実行可能なハーネスとして走らせる。この一点が、Claude Codeの使い方を変える。

最初の一歩は大きな移植ではない。小さく区切った監査タスクで、コスト、権限、検証品質を測ることだ。その測定なしに導入判断を下すと、能力評価ではなく請求と権限事故の話になる。