Claude Code を毎日の運用インフラとして使っていて、いちばん「これは今までと違う」と感じたのが Dynamic Workflow でした。きっかけは単純で、私が運営している 4 つの技術ブログの記事をまとめて下調べするとき、サブエージェントを手で何度も呼び直すのが面倒だったからです。v2.1.154 で入ったこの機能は、その「呼び直し」の部分を JavaScript のスクリプトに固定してくれます。
最初に誤解していたのですが、Dynamic Workflow は「サブエージェントの数を増やす機能」ではありません。計画そのものをコードに移して、実行順序と途中結果をランタイム側に持たせる仕組みです。会話のコンテキストには最終結果だけが返ってくるので、長い調査でも手元の文脈が汚れません。ここを取り違えると、ただトークンを大量消費するだけで終わります。
サブエージェント・スキル・ワークフローの線引き
公式ドキュメントでは三者を「誰が計画を握るか」で区別しています。私なりに噛み砕くと、こうなります。
- サブエージェント: Claude がターンごとに「次に何を spawn するか」を判断します。途中結果は Claude のコンテキストに溜まります
- スキル: Claude がプロンプト（SKILL.md）に従って動きます。判断の主体はやはり Claude です
- ワークフロー: ループも分岐も途中結果も、スクリプトが保持します。Claude はスクリプトを書く役と、最後の結果を受け取る役に回ります
規模感もはっきり違います。サブエージェントが 1 ターンに数個なのに対し、ワークフローは 1 回の実行で数十から数百のエージェントを動かせます（上限は同時 16、合計 1,000）。「数百ファイルの移行」「複数ソースを突き合わせる調査」のように、1 つの会話では捌ききれない規模になったら、ワークフローの出番だと考えています。
まず /deep-research を動かしてみる
自分でスクリプトを書く前に、組み込みの /deep-research を動かすのが理解の近道でした。これは「質問を複数の角度に分解 → 並列で Web 検索 → ソースを取得して主張を抽出 → 敵対的に検証 → 統合してレポート化」という一連のフェーズを背景で回してくれます。
有効化は /config の「Dynamic workflows」の行をオンにするだけです。Pro 以上の有料プランと API アクセス、主要クラウド（Bedrock / Vertex AI / Foundry）で使えます。準備ができたら、調べたいことをそのまま渡します。
/deep-research Node.js の permission モデルは v20 と v22 で何が変わったか実行すると、ワークフローを起動してよいか確認が入ります。ここで「多数のサブエージェントを並列実行するためトークン消費が多い」という注意も明示されます。私は最初これを軽視して、普段の小さいモデルのまま大きな調査を投げてしまい、想定よりトークンを食って驚きました。/model を確認してから走らせるのが安全です。
確認ダイアログで「View raw script」を選ぶと、実際に走る JavaScript を読めます。中身を一度眺めておくと、後で自分のワークフローを書くときの設計図になります。
/workflows で進行状況を追う
ワークフローはバックグラウンドで走るので、セッションは止まりません。進行を見るには /workflows を実行します。
/workflows各フェーズがエージェント数・累計トークン・経過時間つきで一覧表示されます。矢印キーでフェーズを選び、Enter で中に入ると、個々のエージェントがどの URL にアクセスして何を見つけたかまで追えます。私はここで Search フェーズのエージェントの出力を見て、「思ったより検索クエリの角度が偏っているな」と気づき、質問の渡し方を直すことが何度もありました。
操作キーで覚えておくと便利なのは次の 4 つです。p で一時停止と再開、x でエージェントまたはワークフロー全体の停止、r で停止中エージェントの再実行、s で実行スクリプトの保存です。停止してもすでに完了したエージェントの結果はキャッシュされるので、再開時はそこから続きます（ただし再開は同一セッション内のみで、Claude Code を終了すると次回は最初からになります）。
自分のタスクをワークフローにする
組み込みを触ったら、次は自分のタスクです。Claude にワークフローを書いてもらう方法は 2 つあります。
- プロンプトに
workflowという単語を含める: その単語が入力欄でハイライトされ、Claude がターンごとに処理する代わりにワークフロースクリプトを生成します /effort ultracodeを有効にする: xhigh 相当の推論に加え、セッション中の実質的なタスクすべてに対して Claude が自動でワークフローを計画します
私は普段、明示的に workflow を入れる 1 番目を使っています。ultracode は 1 つのリクエストが「理解 → 変更 → 検証」のように複数のワークフローに分かれることがあり、ルーチン作業には重すぎると感じるためです。間違って workflow がハイライトされたときは alt+w でそのターンだけ無効化できます。
src/routes/ 配下の API エンドポイントを認証チェック漏れがないか監査する workflow を実行して生成されたワークフローに納得できたら、その実行を保存して再利用できます。/workflows で対象の実行を選び s を押すと、保存先を選べます。
.claude/workflows/（プロジェクト直下）: リポジトリを clone した全員と共有されます~/.claude/workflows/（ホーム）: どのプロジェクトでも使えますが、自分だけに見えます
保存したワークフローは /<名前> というコマンドとして、次回以降のセッションで / の補完にも出てきます。同名のプロジェクト版と個人版があるときはプロジェクト版が優先されます。ブランチごとに毎回走らせるレビューのような定型処理を、毎回同じオーケストレーションで回せるのは想像以上に効きます。
動かす前に知っておきたい制約
実運用で引っかかった、あるいは引っかかりそうだと感じた制約を挙げておきます。
- 実行中にユーザー入力を挟めません。途中で承認を入れたいなら、ステージごとに別々のワークフローに分けるのが定石です
- スクリプト自体はファイルやシェルに直接触れません。読み書きやコマンド実行はエージェントが担い、スクリプトはあくまで調整役です
- 同時 16 エージェント・合計 1,000 エージェントが上限です。暴走ループの歯止めになっています
- 各エージェントはセッションのモデルを使います。コストを抑えたいステージは、スクリプト側で小さいモデルに振り分けるよう Claude に頼めます
無効化したい場合は /config のトグルか、~/.claude/settings.json の "disableWorkflows": true、あるいは環境変数 CLAUDE_CODE_DISABLE_WORKFLOWS=1 のいずれかで止められます。組織全体で止めるなら managed settings で同じキーを設定します。
まず試す一歩
もし今日 1 つだけ試すなら、/config で Dynamic workflows をオンにして、自分が実際に困っている調べものを /deep-research に投げてみてください。そのうえで「View raw script」で中身のフェーズ構成を一度読むと、スクリプトとして何が起きているかが腹に落ちます。
私自身、2014年から個人開発を続けてきた中で、この「計画をコードに固定する」という発想が、複数サイトの運用を一人で回すうえで効いてくる予感がしています。自作のワークフローをスクリプトとして書く話は、Dynamic Workflow を自作する — phase / agent / pipeline で再現可能な調査パイプラインを書くで掘り下げました。スクリプトに渡す指示の置き場所を軽くしておく観点では、SKILL.md を 200 行以内に収める設計も合わせて読むと整理しやすいはずです。
お読みいただきありがとうございました。