Claude Code の Dynamic Workflows を解説：ultracode、/workflows、1,000 エージェント上限（2026年）

- 本記事の数値とバージョンのしきい値はすべて、執筆時点（2026年8月）で公式ドキュメント（code.claude.com/docs/en/workflows）と照合しています。この機能はほぼ毎リリースで変わるため、依存する前に必ず最新のドキュメントで確認してください。

これは上級者向けの内容です。すでに Claude Code をサブエージェントやスキルと組み合わせて使っている読者を想定しており、基礎から説明し直すことはしません。サブエージェントが何かよく分からない場合は、まず Claude Code のサブエージェントの仕組み や Claude Code のスキルとは何か を読んでください。

dynamic workflow とは実際に何なのか

dynamic workflow は独立した UI 機能ではなく、1 つの仕組みです。いったん起動すると、Claude は計画（何を最初に実行し、何を並行して実行し、何が前のステップの結果を待つか）を記述した JavaScript のスクリプトを書きます。そのスクリプトが作業を多数のバックグラウンドのサブエージェントへ振り分け、Claude はメインセッションのコンテキストに最終結果だけを残します。各サブエージェントの推論の全過程は残しません。

これを通常のターンと比べてみましょう。Claude にサブエージェントへの委譲を頼んだ場合でも、メインセッションは次に何をするかを判断するために各サブエージェントの出力を自分のコンテキストに保持しなければならず、タスクの途中でセッションを閉じると、進行中の推論は失われます。dynamic workflow は「次に何をするか」という判断を会話から完全に切り離してスクリプトの中へ移します。これが、メインセッションのコンテキストウィンドウを破綻させずに 1,000 エージェント規模の実行を可能にしている要因です。

仕組みを具体的にするための例です（実測データではなく、あくまでロジックの説明）。src/ ディレクトリ全体をセキュリティ問題について監査するよう Claude に頼むとします。書かれるスクリプトはたとえば「各サブディレクトリをそれぞれ専用のエージェントに渡してスキャンさせ、問題を見つけたエージェントは証拠付きで報告し、最後に 1 つのエージェントがすべてを表にまとめる」といった形になります。この分岐・待機・集約のロジック全体がスクリプトファイルの中に置かれ、手作業でサブエージェントをオーケストレーションするときのように Claude の作業メモリの中には置かれません。

必要要件は Claude Code v2.1.154 以降 （バージョンのしきい値です。依存する前に自分のバージョンを確認してください）で、すべての有料プランに加えて API/Bedrock/Vertex/Microsoft Foundry で利用できます。Pro では デフォルトで有効になっていません。/config の「Dynamic workflows」の行から手動でオンにします。これを auto-mode（2026-08-14 以降デフォルトで有効）と混同しないでください。両方がほぼ同じ時期のリリースで登場したとはいえ、auto-mode はまったく別の機能で、dynamic workflows とは無関係です。

Claude Code v2.1.154 以降が必要です（まず実際のバージョンを確認してください）。すべての有料プランに加えて API/Bedrock/Vertex/Microsoft Foundry で動作します。Pro ユーザーは /config から手動で有効化する必要があり、デフォルトではオンになっていません。

起動する 2 つの方法

dynamic workflow を呼び出す方法は 2 つあり、1 つのタスクに使いたいのか、セッション全体に使いたいのかで選びます。

多くの解説が省く歴史的な細部があります。入力するキーワードは v2.1.160 より前は workflow でしたが、v2.1.160 で ultracode に改名されました。ただし自然言語での言い回し（「これはワークフローで処理して」）は どちらの時代でも常に機能してきました。正確なキーワードに依存したことは一度もありません。古いドキュメントや投稿で「workflow と入力する」と書かれていたら、それは v2.1.160 より前の名称です。

覚えておくべき落とし穴があります。このキーワードは 人間が入力したテキスト からのみ発火します。-p フラグ経由、Agent SDK の非人間入力経由、スケジュールされたタスク経由、webhook や PR コメントの中継経由では発火しません。これらのいずれかのチャネル経由で Claude Code をスクリプト実行している場合、どこかに「ultracode」と書いても、それだけでは dynamic workflow は起動しません。

どちらの方法を選ぶかは、何をしているかによります。通常のセッションの中で 1 つの大きなタスクを扱う場合（たとえば「ultracode: api/ ディレクトリのエラー処理をすべて監査して」）は、そのターンだけキーワードを入力すれば十分です。セッションの残りはいつもどおり動き、小さな作業に余計な推論のオーバーヘッドはかかりません。セッション全体が重い作業になると最初から分かっている場合（移行や監査のために丸一日を確保しているとき）は、/effort ultracode を使えば毎ターンキーワードを打ち直さずに済みます。ただしトレードオフとして、そのセッション内の実質的なタスクはすべて xhigh の推論に押し上げられ、ワークフローとして実行するつもりのなかったものまで含まれてしまいます。

まずは組み込みの /deep-research ワークフローを試す

セットアップ不要で dynamic workflow の実際の動きを最も手早く確認できるのが、組み込みの /deep-research ワークフローです。

1. /deep-research <your question> を実行します。
2. 実行前に Claude が提案する計画を承認します。
3. /workflows で進捗を確認します。
4. 最終レポートを読みます。出典付きです。

興味深いのは、相互チェックに通らなかった主張は 除外され、検証できなかった主張は頭ごなしに否定されるのではなく 未検証と印を付けられる という点です。これは Claude が自信満々に 1 つの答えをでっち上げるのとは別の失敗モードです。このワークフローには WebSearch ツールを有効にしておく必要があります。サブエージェントが何かまだあいまいなら、次のセクションに進む前に Claude Code のサブエージェントの仕組み を読んでください。

最初に試す価値がある理由は、オーケストレーションのプロンプトを自分で書かなくてよい唯一のワークフローだからです。Anthropic がすでに「情報源を探す → 相互チェックする → 弱い主張を除外する → 出典付きレポートを書く」というロジックを中にパッケージしています。具体的な技術的な質問（たとえば「Next.js 16 と Remix がストリーミング SSR をどう扱うか比較して」）で一度実行してみれば、どの dynamic workflow にも共通する大まかな形が見えてきます。最初に承認される計画、逐一お守りをしなくても並行して動く複数のエージェント、そして 1 つの未検証の答えではなく、すでにフィルタリングされた最終結果です。

実行を監視・管理する — /workflows

/workflows と入力すると、ライブ追跡ビューが開きます。現在のフェーズ、実行中のエージェント数、消費した合計トークン、経過時間が、すべてライブ更新される 1 画面に表示されます。

このビューは見た目以上に重要です。実行が週の予算を食い尽くす前に、どれだけ「食べて」いるかを知る唯一の手段だからです（コストについては後述します）。ダッシュボードなしで CI パイプラインを走らせるようなものだと考えてください。放っておいても問題なく終わることはありますが、大きな実行は最初の数回は目を配る価値があります。少なくとも、自分がふだん渡す種類のタスクでどれくらいトークンを消費するか感覚がつかめるまでは。

有効にする前に知っておくべき数値

この機能を大きな対象に向ける前に、じっくり読む価値があるセクションです。これらの数値はどれも、自分で探しにいくまで UI からは分かりません。

ハードな上限：1 回の実行あたり最大 1,000 エージェント（暴走ループが永遠に走り続けるのを防ぎます）、および同時実行は最大 16 エージェント（CPU に制約のあるマシンやコンテナではより少なくなります）。1,000 という数字は実行全体の天井であって目標ではありません。ほとんどの実際のタスクははるかに少ないエージェントで終わります。この上限は、停止条件が一度も発火しない場合に、スコープの甘いスクリプトが際限なくエージェントを生成するのを止めるために設けられています。

サイズガイドラインは 推奨であって、ハードな上限ではありません（v2.1.202 以降が必要 - バージョンのしきい値です。依存する前に確認してください）。エージェント数をデフォルトより低く抑えるよう Claude に強制したい場合に設定できます。

大規模ワークフローの警告：実行が 25 エージェント または 150 万の予測トークン を超えると発火します（独自のサイズガイドラインを設定している場合、25 という数字は変わります）。これは あくまで注意喚起 で、実行を一時停止はしません。すでに /effort ultracode で動いているセッションではこの警告は表示されません。そのモードを選んだ時点で、最初から大規模な実行を受け入れていることになるからです。

数値を総合すると、数十ファイル程度のディレクトリを対象にした監査を、デフォルトの medium サイズガイドライン（15 エージェント未満）で行う場合、25 エージェントの警告しきい値にはまず到達しません。しかしリポジトリ全体で 200 以上のファイルにまたがる移行なら、25 エージェントと 150 万トークンの両方を軽く超えることがあります。その場合は、実行の途中で驚かされるよりも、あえてサイズガイドラインを large に設定する（あるいは警告を受け入れる）ほうが賢明です。言い換えれば、1,000／16／25 という数字は機能から遠ざけるためのものではなく、Enter を押す前に「これから渡そうとしているものはどれくらい大きいか」を見積もれるようにするためのものです。

ワークフロー vs サブエージェント vs スキル vs エージェントチーム — 誰が計画を持つか

すでにサブエージェントとスキルを使っているなら、これが最も重要な問いです。この 4 つの違いは 誰がオーケストレーションの計画を持つか にあり、どれが「強い」かにあるのではありません。

平たく言えば、サブエージェントとスキル は各ステップを Claude 自身に決めさせ、そのセッションのコンテキストウィンドウに制約されます。エージェントチーム（実験的機能 — マルチセッション協働のためのエージェントチーム を参照）は、共有タスクリストを通じてピアエージェントを監督するリードエージェントで、長い協働セッションに向いています。dynamic workflow が異なるのは、計画が Claude のコンテキストではなく スクリプト の中に置かれる点です。そのため、メインコンテキストはプロセス全体ではなく最終的な答えだけを保持すればよくなります。

手早い選び方：日常的な委譲 → サブエージェント／スキル。継続的な監督が必要な長い協働セッション → エージェントチーム。1 つのコンテキストウィンドウより大きいタスク、または敵対的な相互チェック（複数のエージェントが互いの結果を検証する）が必要なタスク → dynamic workflow。自分専用の再利用可能なサブエージェントを定義したいですか？ サブエージェントガイド を参照してください。先にスキルの基礎が必要なら、Claude Code のスキルとは何か を参照してください。

この 4 つで最も起こりやすい混同があります。サブエージェントとスキルはどちらも メインセッションの Claude に判断させるもので、違いは、スキルがコンテキストによって読み込まれる指示のまとまりであるのに対し、サブエージェントが 1 つの仕事をこなして結果を返すために呼び出される別個の「ペルソナ」である、という点だけです。どちらもそのセッションのコンテキストウィンドウとともに生き死にします。途中でセッションを中断すれば進捗は消えます。エージェントチームと dynamic workflows はどちらもこの制約から逃れますが、その方法は異なります。エージェントチームは、単一エージェントのコンテキストより長く存続する共有タスクリストを通じて複数のセッションを協働させることで逃れます。dynamic workflows は、計画をコンテキストから完全に切り出し、保存でき、git でバージョン管理でき、いつでも同じように再実行できるオブジェクトに変えることで逃れます。これこそが、探索的な会話よりも大規模で反復可能な作業に向いている理由です。

気に入ったワークフローを再利用可能なコマンドとして保存する

気に入った実行はありますか？ 次回 Claude にスクリプトを一から書き直させずに済むよう、保存しておきましょう。

1. /workflows を開き、残したい実行を選びます。
2. s を押して保存します。
3. 保存先を選びます。.claude/workflows/（共有、プロジェクト単位）または ~/.claude/workflows/（個人用）。
4. 保存したワークフローは /<name> コマンドになり、args パラメータを通じて入力を受け取れます。

チームで作業しているなら、ワークフローをプラグイン（workflows/ ディレクトリ）の中に同梱し、名前空間付きの /plugin-name:workflow-name で呼び出すこともできます。コマンドをコピー＆ペーストする代わりに、オーケストレーションスクリプトをチーム全体で共有するのに便利です。

ワークフローをファイルとして保存する利点は、.claude/workflows/ の下に単なるテキストファイルとして存在するため、リポジトリ内の他のものと同じように git にコミットできることです。ブランチを pull したチームメンバーは、同じワークフローを自動的に手にします。Claude は、あなたがすでに調整した監査や移行のやり方を「学び直す」必要がありません。これはサブエージェントやスキルとの最も明確な違いでもあります。気に入って使っているサブエージェントが、そのままチームメンバーも同じように呼び出せるものになるわけではありませんが、保存した dynamic workflow はそうなります。

トークンコストの現実

率直に言うと、公式ドキュメントは dynamic workflows について 固定の金額を一切示していません。このセクションを完結させたいためだけに、私が数字をでっち上げることもしません。「月額 200 ドルの Max プランが 1 日で週の上限の 20% を消費した」といった話が出回っていますが、確認したところ、それは一次情報でも独立して検証できる情報源でもなく、ソーシャルメディアの報告をまとめたブログ記事にたどり着きました。そのため、ここでその数字を繰り返すことはしません。

ドキュメントが はっきり 述べているのはこうです。2 つのハードな上限（1,000 エージェント／同時 16）は、まさに暴走するコストを抑えるために存在します。各サブエージェントはメインセッションのモデルを使います。ただし、スクリプトまたは CLAUDE_CODE_SUBAGENT_MODEL 変数が別のモデルへ振り分ける場合を除きます。

実践的で、ドキュメントに裏付けられたアドバイスです。

• 本番の実行の前に、まず小さな一部（リポジトリ全体ではなく 1 ディレクトリ）で試します。
• 実行中は /workflows でエージェントごとの合計トークンをライブで確認します。
• デフォルトより少ないエージェント数に抑えたい場合は、サイズガイドラインを small に下げます。

私が独自の見積もりをでっち上げない理由は、実際のコストが一度に多くの変数に左右されるからです。各サブタスクがどれだけ長く動くか、セッションにどのモデルが設定されているか、スクリプト自身が分岐ごとにいくつのエージェントを生成すると判断するか。したがって、単一の「平均」値はどれも、役立つより誤解を招くほうが大きくなります。はるかに安全なのは、自分のワークロードを実際に測ることです。小さくひと通り実行し、/workflows でトークン数を読み取り、実際に実行しようとしている規模へおおよそ線形にスケールさせる。誰かがソーシャルメディアで拾ってきた数字を信じるよりも、ずっと確実です。

AgentKit でこれが手に入るのか？（正直な答え）

すでに AgentKit を使っているなら、問う価値のある質問があります。AgentKit には独自の「ワークフロー」なるものがあって、それはこれと同じなのか？ 端的な答えは ノー です。Dynamic Workflows は Claude Code のネイティブなエンジンで、この記事が説明しているまさにその JavaScript スクリプトによるエージェントの振り分けの仕組みです。AgentKit はそのエンジンを同梱しておらず、ak 側に相当するものもありません。

docs.agentkit.best/en/beta/reference/cli を直接確認しました（2026年8月）。AgentKit のサイトにある「workflow」という語は、そのスキルバンドルを指す一般的なマーケティング文言であり、ak orchestrate コマンドはまったく別の機能です。外部 CLI ツール向けのジョブグラフで、macOS 専用、Claude Code の dynamic workflows とは無関係です。

では AgentKit は実際に何を与えてくれるのか？ 厳選され、ライセンスされたスキルとサブエージェントのペルソナのセット（/ak:cook などのコマンドから呼び出します）です。スクリプトを自分で書くにせよ Claude に書かせるにせよ、dynamic workflow をこれに向けて、他のサブエージェントと同じように個々のエージェントタスクとして使えます。要するに、作り込まれたスキル／ペルソナのレイヤーが欲しいなら AgentKit を買い、大規模なオーケストレーションのレイヤーには Dynamic Workflows（無料・ネイティブ）を使う、ということです。両者は 競合せず、積み重なります。詳しくは AgentKit の完全レビュー をお読みください。

2 つのレイヤーがどう噛み合うかの例です（実測の結果ではなく、あくまで使い方のパターン）。5 つのマイクロサービスにまたがってセキュリティを監査する dynamic workflow は、各サービスを AgentKit の ak-security スキルを動かすエージェントに渡し、最後に 1 つのエージェントが 5 つすべての結果を集約する、といった形にできます。オーケストレーションのスクリプト（何を並行して実行し、何が何を待つか）は Dynamic Workflows のものであり、各エージェントの中にあるドメインの知見は、あなたが買ったスキルのものです。AgentKit を外してもワークフローは動きます。各エージェントが、その仕事のために作られたスキルの代わりに、Claude の一般的な知識にフォールバックするだけです。

今日これを有効にすべきか

ここに万能の答えはありません。これは、はっきりしたイエス／ノーよりも正直で役に立つ結論です。正しい判断は、機能が新しくて刺激的かどうかではなく、次のタスクが実際にどれくらい大きく、どれくらい反復可能かによって決まります。手短な結論は、セッション全体に /effort ultracode を設定すると決める前に、まず 1 つの実在する、範囲の限られたタスク（リポジトリ全体の移行ではなく、単一ディレクトリの監査）で ultracode キーワードを試す、ということです。向いているのは、大規模な移行、コードベース全体の監査、複数の情報源にまたがる相互チェックが必要なリサーチ。避けたほうがよいのは、日常的な小さな編集や、余裕のないコスト重視の Pro プランを使っている場合です。

Enter を押す前の手早いチェックリストです。(1) そのタスクは、独立した分岐に分けられるほど本当に大きいのか、それとも手作業のほうが速い逐次的な連なりにすぎないのか。(2) /workflows を開いたまま実際に見張るつもりなのか、それとも席を離れる予定なのか。(3) この実行が途中で失敗した場合、すでに消費したトークンを許容できるか。3 つすべてが「はい」なら、有効にして進めてかまいません。(1) が「いいえ」なら、ふつうは素のサブエージェントのほうが速くて安上がりです。

FAQ

Claude Code の ultracode とは何ですか？

ultracode は dynamic workflow を起動するキーワード（および effort 設定）です。Claude が JS スクリプトを書き、1 つのタスクを最大 1,000 個のバックグラウンドのサブエージェントへ振り分けます。「ultracode」と入力しても、「これはワークフローで処理して」のように自然に言い表しても、どちらでも起動します。

1 つの dynamic workflow はいくつのエージェントを実行できますか？

1 回の実行あたり最大 1,000 エージェントで、同時実行は最大 16（CPU に制約のあるマシンやコンテナではより少なくなります）。これらは推奨値ではなく、ハードな上限です。

大規模ワークフローの警告は何をきっかけに出ますか？

実行が 25 エージェントまたは 150 万の予測トークンを超えたときです（25 という数字は自分のサイズガイドラインに応じて変わります）。あくまで注意喚起で、実行を一時停止はしません。

dynamic workflow はエージェントチームと同じものですか？

いいえ。エージェントチームは、共有タスクリストを通じてピアエージェントを監督するリードエージェントで、長い協働セッションに向いた（実験的な）機能です。dynamic workflow の計画は Claude のコンテキストではなく、あらかじめ書かれたスクリプトの中に置かれ、保存して同じように再実行できます。エージェントチームは、一般に同じ形で二度と再現することはできません。

有料プランは必要ですか？

はい。すべての有料プランに加えて API/Bedrock/Vertex/Microsoft Foundry で動作します。Pro ユーザーは /config の「Dynamic workflows」の行から手動で有効化する必要があります。デフォルトではオンになっていません。

AgentKit に Claude Code の dynamic workflows は含まれますか？

いいえ。Dynamic Workflows は Claude Code のネイティブで無料のエンジンです。AgentKit は別個の有料のスキルとサブエージェントのペルソナのセットで、dynamic workflow の中で個々のエージェントタスクとして使えます。両者は補い合う関係で、同じものではありません。

まとめ

dynamic workflows はパワーユーザー向けの機能です。実在する上限（1,000 エージェント／同時 16）、25 エージェント／150 万トークンでの注意喚起の警告があり、AgentKit のスキルレイヤーを置き換えるのではなく組み合わせて使うものです。セッション全体で有効にする前に何か小さなもので試し、/workflows を開いたままにして、何にどれだけ使っているかを常に把握してください。バージョンのゲートは速く動くので、この記事のしきい値はどれも絶対の真理ではなく出発点として扱い、重要な対象に実際にこれを切り替える当日に、最新のドキュメントで確認し直してください。