Claude Codeに大きめのタスクを投げると、サブエージェントを何体か呼んで進めてくれます。ただ、対象が数百ファイルに及ぶ移行や、ソースを突き合わせる調査になると、途中で計画がぶれたり、中間結果がコンテキストを食い尽くして失速したりします。ダイナミックワークフロー（dynamic workflows）は、その計画をClaudeが書いたJavaScriptのスクリプトに移し、会話の外側で裏で回す機能です。結論から言えば、「サブエージェントで足りるか、workflowに移すべきか」は”誰が計画を持つか”で決まります。判断をClaudeがターンごとに握るならサブエージェント、スクリプトに固定して何度も回すならworkflowです。
この記事の要点
- workflowは、多数のサブエージェントをスクリプトで束ねて裏で並列実行する仕組み。中間結果はコンテキストでなくスクリプト変数に残る
- サブエージェントとの決定的な違いは「計画をClaudeが持つか、スクリプトが持つか」。再現性が要るならworkflow
- 起動は「use a workflow」や「ultracode」のキーワード、
/effort ultracode、ビルトインの/deep-researchの3系統 - 🔴自動実行（
claude -p）・スケジュール・webhookでは、キーワードでは起動しない。Workflow許可ルールが要る（v2.1.210以降） - 上限は同時16体・1ラン最大1,000体。25体超か推定150万トークン超で「Large workflow」警告が出る
この記事では、workflowがサブエージェント・スキル・エージェントチームとどう違うか、起動と監視の手順、そしてサイト制作や自社ツール開発でどう使うかを、公式ドキュメントの仕様に沿って書きます。特に、毎日claude -pで自動実行している編集部がつまずいた「キーワードで起動しない」問題まで踏み込みます。
Claude Codeのworkflow（ダイナミックワークフロー）とは？何ができる機能か
ダイナミックワークフローは、多数のサブエージェントを一度に束ねるJavaScriptのスクリプトです。あなたが依頼したタスクに対してClaudeがスクリプトを書き、専用のランタイムがそれをバックグラウンドで実行します。実行中もセッションは応答可能なままで、あなたは別の作業を続けられます。
向いているのは、1つの会話では抱えきれない数のエージェントが要るタスクか、オーケストレーション自体を読める・再実行できるスクリプトとして残したいときです。公式が挙げる例は、コードベース全体のバグ掃討、500ファイルの一括移行、複数ソースを相互に突き合わせる調査、1つに絞る前に複数の角度から計画を起草する場面です。対応するのはすべての有料プランとAnthropic APIで、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryでも使えます。Proの場合は/configの「Dynamic workflows」の行からオンにします。
サブエージェント・スキル・エージェントチームとの違い｜使い分け表
サブエージェント・スキル・エージェントチーム・workflowは、どれも複数ステップのタスクを回せます。違いは1点、誰が「次に何を動かすか」の計画を持つかです。ここを押さえると、どれを使うべきかが自然に決まります。
| サブエージェント | スキル | エージェントチーム | workflow | |
|---|---|---|---|---|
| 正体 | Claudeが生む作業役 | Claudeが従う指示書 | リード役が仲間を統括 | ランタイムが実行するスクリプト |
| 次を決めるのは | Claude（ターンごと） | Claude（指示に従う） | リード役（ターンごと） | スクリプト |
| 中間結果の置き場所 | Claudeのコンテキスト | Claudeのコンテキスト | 共有タスクリスト | スクリプト変数 |
| 再現できるもの | 作業役の定義 | 指示書 | チームの定義 | オーケストレーション自体 |
| スケール | ターンごとに数体 | サブエージェントと同じ | 数体の長時間ピア | 1ランで数十〜数百体 |
| 中断すると | ターンをやり直す | ターンをやり直す | 仲間は走り続ける | 同一セッション内で再開可 |
workflowを選ぶべきなのはどんなときですか？
目安は3つです。1つ目は、タスクが1つのコンテキストに収まらないほど大きいとき。サブエージェントは中間結果がコンテキストに載るため、規模が大きいと溢れます。workflowは中間結果をスクリプト変数に逃がすので、Claudeのコンテキストには最終的な答えだけが残ります。2つ目は、同じ手順を何度も回したいとき。3つ目は、結果の信頼性を上げたいときです。workflowは、独立したエージェントに互いの発見を反証させたり、複数角度で起草した案を突き合わせたりできます。サブエージェント側の整理はサブエージェントとスキルの違いにまとめています。
workflowの起動方法と監視（3つのトリガー）
workflowの入口は大きく3系統です。スクリプトは自分で書きません。タスクを言葉で伝えれば、Claudeがスクリプトを書いて回します。
① プロンプトで「use a workflow」または「ultracode」と書く
セッションの努力レベルを変えずに、そのタスクだけをworkflowとして走らせたいときは、プロンプトにultracodeというキーワードを含めます。「use a workflow」「run a workflow」のように自分の言葉で頼んでも、同じ意思表示として扱われます。
ultracode: src/routes/ 配下の全エンドポイントを
認証チェック漏れがないか監査して。各指摘は
別エージェントに反証させてから報告して。キーワードがハイライトされ、Claudeはターンごとに処理する代わりにworkflowのスクリプトを書きます。なおv2.1.160より前は、トリガーの語がworkflowそのものでした。自然文での依頼はどちらのバージョンでも通ります。
② /effort ultracode でClaudeに判断させる
ultracodeは、xhighの推論レベルと自動のworkflow編成を組み合わせた設定です。オンにすると、Claudeがタスクごとにworkflowを組むべきか自分で判断します。1つの依頼が、理解用・変更用・検証用と複数のworkflowに分かれることもあります。/effort ultracodeで有効化でき、これにはv2.1.203以降が必要です。セッション中ずっと有効なので、通常作業に戻るときは/effort highに落とします。
③ ビルトインの /deep-research を使う
いちばん手早く挙動を確かめられるのが/deep-researchです。質問を投げると、複数の角度でWeb検索を広げ、見つけたソースを相互に突き合わせ、出典つきのレポートを1本返します。相互チェックで生き残らなかった主張は落とされ、レート上限などで検証できなかった主張は「未検証」として残ります。
実行中の監視と、コマンド化
/workflowsで進捗を見る
workflowは裏で走るので、走らせたまま/workflowsでいつでも一覧を開けます。進捗ビューは各フェーズのエージェント数・トークン合計・経過時間を表示し、フェーズやエージェントに潜って何を見つけたか読めます。pで一時停止・再開、xで停止、sでそのランのスクリプトを保存できます。
保存して /名前 コマンドにする
保存すると.claude/workflows/（プロジェクト共有）か~/.claude/workflows/（自分専用）に置かれ、次から/名前のコマンドとして呼べます。保存したworkflowはargsで入力を渡せます。使えるスラッシュコマンドの全体像はClaude Codeのスラッシュコマンドも参考にしてください。
これまでのサブエージェント運用と何が変わるのか
workflowが変えるのは、機能の数ではなく「計画の置き場所」です。これまで複数のサブエージェントを回すときは、Claudeがオーケストレーターとして、ターンごとに次に何を生むかを判断していました。その中間結果はすべてコンテキストに着地します。workflowはこの計画をコードに移します。
| 項目 | これまで（サブエージェントを手動編成） | workflow | 実務での意味 |
|---|---|---|---|
| 計画の保持者 | Claude（ターンごとに判断） | スクリプト（ループ・分岐を保持） | 大規模でも計画がぶれにくい |
| 中間結果 | コンテキストに載る | スクリプト変数に載る | コンテキストは最終結果だけで済む |
| 再現性 | 作業役の定義のみ | 編成そのものを再実行できる | 同じ処理を毎回コマンドで回せる |
| 品質パターン | 1パスで通す | 相互反証・多角起草を組み込める | 結果の信頼性を上げやすい |
アウトプットにどんな差が出るかは、編集部が同一タスクで実測した数値はありません。ただ仕様の差から言えば、大規模タスクでコンテキスト溢れによる劣化が起きにくくなり、相互反証を挟むぶん結果の信頼性が上がると想定されます。理由は、中間結果がコンテキストを圧迫しない設計であることと、独立したエージェントが互いの発見を検証してから報告する仕組みが用意されているからです。
【実践】サイト制作・自社ツール開発でworkflowをどう使うか
ここからは、編集部が普段の制作・自動化でworkflowをどう差し込んでいるかを、そのまま渡せるプロンプトつきで書きます。スクリプトは書かず、依頼文だけで回します。
サイト制作での使いどころ
制作で効果が大きいのは、量が多くて1体では抱えきれない検査です。たとえば、全ページのリンク切れやアクセシビリティ違反の一括監査、コンポーネントの大量移行が該当します。
use a workflow: src/components/ 配下の全コンポーネントを
JavaScriptからTypeScriptへ移行して。各ファイルは
独立したコピー上で作業して、変更が衝突しないようにして。1ファイル1エージェントで並列に走り、各結果を検証してから集約します。PRのレビューも同じ形で、変更ファイルごとにレビュー役を立て、最後に1体が指摘を順位づけして1本のサマリーにまとめられます。
自社ツール開発・自動化での使いどころ
自動化では、毎回同じ処理を回すものをworkflow化して保存し、コマンドにするのが効率的です。ブランチごとに走らせるレビューや、競合の公開ドキュメントを横断で読む定点調査は、一度回してsで保存すれば、次から/名前で同じ編成を呼べます。
use a workflow: 競合3社のレート制限の扱いを調べて。
各社の公開ドキュメントと直近のchangelogを並列で読み、
アプローチを比較表にまとめて。保存したworkflowはargsで対象を差し替えられるので、調べる相手を変えるだけで使い回せます。プラグインに同梱すればチームやリポジトリ間で共有もできます。
自動実行（claude -p）でworkflowを使うときの落とし穴
ここは、毎日claude -pで記事生成を自動実行している編集部が実際につまずいた点です。結論として、自動実行では「workflow」「ultracode」のキーワードでは起動しません。
公式ドキュメントは、キーワードによるオプトインが有効なのは「自分でタイプした人間のプロンプト」に限る、と明示しています。具体的には、対話プロンプト・IDE拡張・リモートコントロール・人間入力として印を付けたAgent SDKアプリだけです。次の経路では起動しません。
-pで渡したプロンプト（ヘッドレス実行）- スケジュール実行のタスクプロンプト
- webhookのペイロードやプルリクエストのコメント経由
これはv2.1.210以降の挙動で、それ以前はこれらの経路でも起動していました。では自動実行でどうworkflowを走らせるかというと、キーワードに頼らず、Workflowの許可ルールで明示的に起動を通します。許可ルールにWorkflowを入れれば全workflowを、Workflow(<名前>)を入れれば保存済みの特定workflowを承認できます。ほかに、オートパーミッションモードの分類器に通す、バイパスモードにする、PreToolUseフックでallowを返す、という手もあります。使用量上限まわりの挙動は使用量上限で自動再開する設定もあわせて確認しておくと安全です。
workflowのコスト・上限と、トークンを溶かさない設定
workflowは多数のエージェントを生むため、同じタスクを会話で進めるより、1ランで大幅に多くのトークンを消費します。使用量とレート上限には通常のセッションと同じくカウントされます。まず押さえるべきは、ランタイムがかける上限です。
| 制約 | 値 |
|---|---|
| 同時実行エージェント数 | 最大16体（CPUが少ないとさらに減る） |
| 1回のparallel/pipelineの項目数 | 最大4,096項目 |
| 1ランの合計エージェント数 | 最大1,000体 |
トークンを溶かさない3つの手
コストを溶かさないための実務的な手は3つです。1つ目は、大きなタスクの前に小さなスライスで試すこと。リポジトリ全体でなく1ディレクトリ、広い問いでなく狭い問いで回し、/workflowsでエージェントごとのトークン消費を見てから本番に移します。2つ目は、サイズガイドラインを絞ることです。/configでsmall（5体未満）・medium（15体未満・既定）・large（50体未満）を選べます。3つ目は、警告を無視しないこと。1ランが25体を超えるか、推定トークンが150万を超えると「Large workflow」警告が出るので、/workflowsで中身を確認します。ルーティン作業では/modelで軽いモデルに切り替えておくのも有効です。
よくある質問（FAQ）
workflowはどのプランで使えますか？
すべての有料プラン（Pro／Max／Team／Enterprise）と、Anthropic API、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryで使えます。Proでは/configの「Dynamic workflows」からオンにします。
workflowとサブエージェントはどちらを使うべきですか？
1会話で計画を抱えきれる規模ならサブエージェント、抱えきれない規模か、編成を何度も再実行したいならworkflowです。判断をClaudeがターンごとに持つか、スクリプトに固定するか、で選びます。
workflowはコマンドとして保存できますか？
できます。/workflowsで対象のランを選びsを押すと、.claude/workflows/か~/.claude/workflows/に保存され、次から/名前で呼べます。argsで入力を渡せます。
workflowを止めるにはどうしますか？
自分だけ無効化するなら/configでオフにするか、settings.jsonに"disableWorkflows": true、またはCLAUDE_CODE_DISABLE_WORKFLOWS=1を設定します。組織全体は管理設定でオフにできます。
1ランで何体まで並列に動きますか？
同時に動くのは最大16体で、CPUが少ない環境ではさらに減ります。1ランの合計は最大1,000体、1回のparallelやpipelineは最大4,096項目までです。
まとめ：まず /deep-research で挙動をつかむ
workflowを使うかどうかは、「そのタスクを1つの会話で計画しきれるか」で決まります。しきれるならサブエージェントで十分で、しきれない規模か、同じ編成を何度も回したいならworkflowに移す、という順で考えると迷いません。まずは/deep-researchを1本回して、裏で並列にエージェントが動く感覚をつかむのが手堅い入り方です。自動実行に組み込むなら、キーワードでなくWorkflow許可ルールで起動する点だけ先に押さえておきます。サブエージェント側の使い分けはサブエージェントとスキルの違いにまとめています。
出典：Claude Code 公式ドキュメント「Orchestrate subagents at scale with dynamic workflows」（code.claude.com/docs、2026年8月時点）