Claude Codeワークフローとは？本当に必要な場面を解説
Claude Code v2.1.154にアップデートすると、/configにDynamic workflowsという新しい項目が表示されます。これをオンにすると、ClaudeがJavaScriptスクリプトを作成し、最大16個のエージェントを同時に実行できるようになります。これが今、誰もがひそかに話題にしている機能です。公式ドキュメントには機能の説明が書かれていますが、本当に知りたいことは書かれていません。それは「自分にこれが必要なのか、それとも既存のサブエージェントで十分なのか」ということです。
ここがギャップです。Claude Codeワークフローはリサーチプレビューとして提供されましたが、ドキュメントはあくまでリファレンスであり、アドバイスではありません。そこで私たちは、バンドルされている唯一のワークフロー/deep-researchを自社のコンテンツパイプラインで実際に実行し、リアルな数値を記録して、正直な結論を書き出しました。短く言えば、エージェントを手動で管理できているうちは、ワークフローはまだ必要ありません。ただし、本当に必要な人もいます。自分がどちらのグループに属するか、見極めましょう。
主なポイント：
- Claude Codeワークフローとは、Claudeが作成するJavaScriptスクリプトで、サブエージェントを大規模にオーケストレーションします（リサーチプレビュー、v2.1.154以上、全有料プランで利用可能）。
- 必要になるのは、1つの会話では調整しきれない数のエージェントが必要なタスクだけです。それ以外はサブエージェントで十分です。
- 現在提供されているワークフローは1つだけ：
/deep-research。バックグラウンドで実行されるため、セッションはそのまま使えます。 - ワークフローはトークンを大量に消費します。推奨する前に実際の実行を計測しました（数値は後述）。
Claude Codeワークフローとは？
Claude Codeワークフローとは、サブエージェントを大規模にオーケストレーションするJavaScriptスクリプトです。タスクを説明すると、Claudeがスクリプトを作成し、ランタイムがバックグラウンドで実行します。チャットセッションはそのまま使えます。Claude Codeのリサーチプレビュー機能で、Claude Code v2.1.154以上が必要であり、全有料プラン（Pro、Max、Team、Enterprise、さらにAPIとBedrock/Vertex/Foundry）で利用できます。
日常的な例で説明しましょう。キッチンのカウンターに立って、作りたい料理を説明すると想像してください。シェフがレシピを書き、それを裏の厨房にいる大勢の調理人に渡します。調理人たちは作業を始め、あなたはその間もカウンターで会話を続けます。一人ひとりの調理人を細かく管理する必要はありません。レシピが管理してくれます。このレシピがワークフロー、調理人がサブエージェント、裏で動いている厨房がランタイムです。
ワークフローは別のエージェントではありません。エージェントに何を、どの順番で、結果をどう処理するかを指示するスクリプトです。この区別は本記事で最も重要であり、次のセクションで具体的に説明します。
ひとつ混同しやすい点を整理しておきます。「claude code workflows」で検索すると、GitHubのリポジトリやプラグイン、Ruflo、claude-flow、
wshobson/agentsなどのコミュニティ製スワームツールが並ぶmarketplaceが見つかります。これらはサードパーティのオーケストレーターです。Anthropic公式のDynamic workflowsは別の組み込み機能です。v2.1.154以上の/configに表示されなければ、公式のものではありません。
これは、最近のfast modeリサーチプレビューなど、Anthropicの他のリサーチプレビューと同様の位置づけです。早期に提供され、トグルの背後にあり、まだ粗削りです。プレビューとして扱ってください。実際そうだからです。完全な仕様は公式ワークフロードキュメントにあります。
ワークフロー vs サブエージェント vs スキル：誰がプランを保持するか？
この3つを最も明確に区別する方法は、ひとつの質問をすることです。「誰がプランを保持しているか？」スキルは、Claudeが必要に応じて読み込む、パッケージ化された指示と知識です。サブエージェントは、委譲された1つのジョブを実行する独立したコンテキストです。ワークフローは、サブエージェントを大規模に調整するオーケストレーションスクリプトで、最大16個を同時に実行できます。同じツールボックスですが、3つの異なる役割です。
公式ドキュメントが暗に示しながらも並べて示していない比較がこちらです：
| スキル | サブエージェント | ワークフロー | |
|---|---|---|---|
| 誰がプランを保持するか？ | メインコンテキストのあなた/Claude | 委譲された独立コンテキスト | ワークフロースクリプト（ランタイム） |
| 何か？ | 必要に応じて読み込まれるパッケージ化された指示/知識 | 独自のコンテキストで実行される1つの分離されたジョブ | サブエージェントをオーケストレーションするJavaScriptスクリプト（同時実行≤16） |
| スケール | 該当なし | 数個、会話で調整 | 最大16同時実行 / 1実行あたり1,000 |
| コードとして再実行可能？ | いいえ | いいえ | はい（/commandとして保存） |
| 最適な用途 | 再利用可能な知識/指示 | 1つの委譲タスク | 1つの会話では追跡しきれない数のエージェント |
1つのClaude会話でプラン全体を把握できるなら、必要なのはワークフローではなくサブエージェントです。人間であるあなたが「誰が何をどの順番でやっているか」を追跡できる数を超えてエージェントを起動した瞬間、プランは会話のキャパシティを超えています。ワークフローが越えるのは、まさにその境界線です。
最初の要素について詳しく知りたい方は、スキルチュートリアルで、Claudeが必要に応じて読み込む知識のパッケージ化について解説しています。また、ネイティブなオーケストレーションではなく、フルのエージェントフレームワークを選ぶべきか検討中なら、その比較も参考になります。私たちの正直な見解：ネイティブプリミティブは、フレームワークが必要になるまで、想像以上に遠くまで行けます。
Claude Codeワークフローが本当に必要なのはどんなとき？
Claude Codeワークフローが必要になるのは、(a) タスクが1つの会話で調整できる数を超えるエージェントを必要とする場合、(b) オーケストレーションを一度きりのプロンプトではなく再実行可能なコードとして保存したい場合、または (c) 複数のエージェントが互いの作業を検証する敵対的レビューやクロスチェックが必要な場合です。いずれにも当てはまらなければ、サブエージェントで十分です。ここは自分に正直になりましょう。
これはドキュメントが声に出して言わない部分なので、私たちが言います：おそらく、まだワークフローは必要ありません。 数個のサブエージェントを通常の会話で調整すれば、日常の作業はこなせます。ワークフローは卒業してアップグレードするものではありません。1つの特定の形の問題のためのツールです。つまり、1つの脳では追跡しきれない数のエージェントが必要な場合です。
このチェックリストを試してみてください。以下のうち少なくとも1つに「はい」と答えたら、おそらくワークフローが必要です：
- タスクが1つの会話で追跡できる数を超えるエージェントを必要とする。
- オーケストレーションを、再入力する一度きりのプロンプトではなく、再実行可能なコードとして欲しい。
- 敵対的レビューやクロスチェックが必要（複数のエージェントが互いを検証）。
- 定期的なコードベース監査や500ファイルの移行など、同じマルチエージェントジョブを繰り返し実行する。
4つすべてに「いいえ」と答えましたか？サブエージェントのままにしましょう。トークンを節約し、デバッグしやすい状態を保ち、何も失いません。仕様駆動の開発に慣れている方は、優れたCLAUDE.mdベストプラクティスからこのパターンを認識するでしょう。プランを一度書き留め、再実行可能にし、再入力をやめる。ワークフローは、プラン自体に実行するためのランタイムが必要になるまで、そのアイデアを推し進めたものです。
すでに手元にある唯一のワークフロー：/deep-research
/deep-researchは、プレビューにバンドルされている唯一のワークフローです。質問を指定して呼び出すと、サブエージェントを展開してトピックを並列で調査し、調査結果を互いにクロスチェックして、統合された1つの回答をコンテキストに返します。すべてバックグラウンドで実行されるため、セッションはそのまま使えます。
/deep-research What are the real token costs of running multi-agent research in Claude Code?これがインターフェースのすべてです。内部的にはいくつかのフェーズを経て進みます。質問をリサーチスレッドに分解し、それぞれを追うエージェントを起動し、クロスチェックまたはレビュー段階を実行してエージェントが互いの弱い主張を捉え、最終回答を統合してチャットに返します。実行中に指示を出すことはできません。質問し、作業し、報告が返ってきます。
これは、10個のタブを開いて午後を無駄にしてしまうような、厄介なリサーチの質問に本当に役立ちます。すでにリサーチツールを構築している方は、おすすめMCPサーバーのまとめが、この種の並列リサーチと相性抜群です。ただし「役立つ」と「トークン代に見合う」は同じではありません。まさにそれを計測するために、私たちは実行しました。
自社パイプラインでワークフローを実行した結果
私たちの/deep-research実行では、4フェーズにわたって9個のサブエージェントが起動し、100万トークン強を消費し、実時間で約8分で完了しました。見合った価値はあったか？簡単な質問なら、到底見合いません。半ダースのエージェントを手動で調整するリサーチタスクなら、元は取れます。正直な内訳を以下に示します。
私たちのパイプラインでは、今読んでいるこの記事自体がマルチエージェントシステムで制作されています。リサーチ、ブリーフ、執筆、検証、翻訳、公開がそれぞれ独立したサブエージェントとして実行されています。つまり、上記チェックリストの「1つの会話ではエージェントが多すぎる」世界に、私たちはすでに住んでいます。だからこそ、私たちは適切なテストケースであり、無理やり作ったものではありません。
すでにリサーチ中だった実際のキーワードで/deep-researchを実行し、全実行を記録しました：
| 指標 | 私たちの/deep-research実行 |
|---|---|
| 起動したサブエージェント数 | 9 |
| フェーズ数 | 4（分解 → 展開 → クロスチェック → 統合） |
| 総トークン数 | 約105万 |
| 実時間 | 約8分 |
| 価値の判定 | 一度きりの質問には過剰。本格的なマルチソースリサーチには見合う |
最も驚いたのはクロスチェックフェーズです。あるエージェントが出した初期の主張が、別のエージェントの指摘を受けて静かに修正されました。これは単一の会話では見逃されがちなことです。この敵対的ステップこそが、生の並列処理以上の、本当の価値です。ただしトークンコストは高く、これらのエージェントはOpusティアのモデルで実行されます（なぜそれが請求額に関わるかはOpus 4.8の新機能を参照）。2つのプロンプトで答えられる質問に100万トークンは悪い取引です。本当に6つのソースを突き合わせる必要がある質問なら、あなたの時間に対する格安の投資です。
これはTechsyがクライアント向けに構築している種類のオーケストレーションであり、どこで元が取れ、どこで予算を燃やすだけか、強い事前見解を持っていました。私たちの見解：難しい質問に実行し、簡単な質問はスキップする。
独自のワークフローを作成・保存する方法
独自のワークフローを作成するには、workflowキーワードを使ってタスクを平易な言葉でClaudeに説明し、生成されたスクリプトを確認・承認して、そのスクリプトを再利用可能な/commandとして保存します。より高い労力をかけるには、/effort ultracodeを設定すると、Claudeが自らワークフローを計画します。JavaScriptを書く必要はありません。Claudeがスクリプトを書き、あなたが承認します。
以下が全ループです。実際に試す場合の手順としても使えます：
-
Dynamic workflowsを有効にする。 Proでは、
/configを開き、Dynamic workflowsの行をオンにします。（v2.1.154以上ですよね？）bash/config # then enable the "Dynamic workflows" row -
workflowキーワードでタスクを説明する。 プロンプトのどこかにworkflowという言葉を含めます。例：「このリポジトリのすべてのルートファイルをworkflowで監査し、認証チェックの漏れを見つけて。」 Claude Codeはその言葉をハイライトし、ターンごとに作業する代わりにスクリプトを作成します。Claude自身に判断させたい場合は、/effort ultracodeを設定します。これはxhighの推論と自動ワークフローオーケストレーションを組み合わせたもので、かなりのタスクごとに適用されます（トークン消費も増えるので、通常の作業は/effort highに戻しましょう）。 -
生成されたスクリプトを確認・承認する。 Claudeは何も実行する前に、JavaScriptのオーケストレーションを表示します。読んでください。展開が広すぎる場合に気づくチャンスです。
-
再利用のために
/commandとして保存する。 うまく動いたら、ワークフローをカスタムスラッシュコマンドとして保存します。来四半期の監査がワンキーで実行できます。
再利用性が静かな勝利です。一度きりの/deep-researchは便利ですが、「全ルートの認証を監査する」や「このディレクトリを新APIに移行する」といった保存済みワークフローは、数時間かかる調整作業を1つの繰り返し可能なコマンドに変えます。トークンコストが一度きりの痛みではなく、実行ごとに償却され始めるのは、まさにこのときです。
制限、コスト、ワークフローのオフ方法
ワークフローは最大16個の同時エージェント、1実行あたり1,000エージェントのハードキャップで実行され、実行中の入力は受け付けず、同一セッション内でのみ再開可能です。すべてのエージェントがコンテキストを消費するため、設計上トークンを大量に消費します。設定のdisableWorkflowsまたはCLAUDE_CODE_DISABLE_WORKFLOWS環境変数で、機能を完全に無効にできます。
各制限はタスクにとって意味があります。実行中の入力不可は、開始後に軌道修正できないことを意味し、曖昧なプロンプトは1回分まるごとのトークンを無駄にします。同一セッション内でのみ再開可能は、ターミナルを閉じると実行が消えることを意味します。1実行あたり1,000エージェントは膨大に聞こえますが、Opusティアのレートで広く展開すれば実際のお金がかかります。16同時実行のデフォルトは、押し上げるべき上限ではなく、機能として扱ってください。
オフにするには：
export CLAUDE_CODE_DISABLE_WORKFLOWS=1
# or set "disableWorkflows": true in your configバージョンの落とし穴につまずく人がいます。/configにDynamic workflowsの行が表示されない場合、v2.1.154未満です。まずアップデートしてください。そして、こうしたエージェントパイプラインを実際の業務で構築し、本当に元を取れるようにしたいなら、私たちはB2Bチーム向けにエージェントパイプラインを構築しています。オーケストレーションがボトルネックになりつつあるなら、無料相談はこちら →
まとめ
本記事全体を5行で。Claude Codeワークフローとは、Claudeが作成するJavaScriptスクリプトで、サブエージェントを大規模にオーケストレーションし、v2.1.154でリサーチプレビューとして提供されました。現在存在するのは/deep-researchだけです。ワークフローが必要になるのは、タスクが1つの会話で調整できる範囲を超えたとき、再実行可能なオーケストレーションが欲しいとき、またはエージェントに互いをクロスチェックさせたいときだけです。実際の実行では、9エージェントで約100万トークン、8分かかりました。簡単な質問には過剰で、難しいリサーチには見合います。おそらくまだ必要ありません。それで大丈夫です。
著者について
Mert Batur GurbuzはTechsy.ioの共同創業者であり、チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。バーミンガム大学で学び、Techsyチームが実際に本番環境で使用しているLLMツールスタックについて執筆しています。
共同創業者、Techsy.io、バーミンガム大学 · LinkedIn
よくある質問
Claude Codeワークフローとは何ですか？
Claude Codeワークフローとは、サブエージェントを大規模にオーケストレーションするJavaScriptスクリプトです。タスクを説明すると、Claudeがスクリプトを作成し、ランタイムがバックグラウンドで実行します。セッションはそのまま使えます。Claude Code v2.1.154以上のリサーチプレビュー機能で、全有料プランで利用できます。
ワークフローとサブエージェントの違いは何ですか？
サブエージェントは、独自の独立したコンテキストで実行される単一の委譲ジョブで、会話の中であなたが調整します。ワークフローは、サブエージェントを同時に最大16個調整するオーケストレーションスクリプトです。1つの会話でプラン全体を把握できるなら、サブエージェントを使いましょう。プランにエージェントを追跡するランタイムが必要なら、ワークフローを使いましょう。
Claude Codeワークフローのトークンコストはどれくらいですか？
私たちが計測した/deep-researchの実行では、4フェーズにわたる9個のサブエージェントが、約8分で約105万トークンを消費しました。ワークフローはすべてのエージェントが独自のコンテキストを消費するため、設計上トークンを大量に消費し、これらのエージェントはOpusティアのモデルで実行されます。簡単な質問には無駄ですが、本格的なマルチソースリサーチにはコストに見合います。
Claude Codeワークフローを使うには有料プランが必要ですか？
はい。Dynamic workflowsは全有料Claudeプラン（Pro、Max、Team、Enterprise）とAPI、Bedrock/Vertex/Foundryで実行できます。無料プランでのアクセスはありません。Proでは、Claude Code v2.1.154以降にアップデートした後、/configのDynamic workflowsの行をオンにして機能を有効にします。
Claude Codeの/deep-researchとは何ですか？
/deep-researchは、リサーチプレビューにバンドルされている唯一のワークフローです。質問を指定すると、サブエージェントを展開してトピックを並列で調査し、エージェントが互いの調査結果を検証するクロスチェック段階を実行し、1つの回答を統合してコンテキストに返します。すべてバックグラウンドで実行されます。
ワークフローをスラッシュコマンドとして保存するには？
workflowキーワードを使ってタスクをClaudeに説明し、生成されたJavaScriptスクリプトを確認・承認して、その承認済みスクリプトをカスタム/commandとして保存します。その後、マルチエージェントジョブ全体がワンキーで実行でき、ワークフローのトークンコストが繰り返し実行で償却され始めます。
ワークフローは同時にいくつのエージェントを実行できますか？
ワークフローは最大16個の同時エージェントを実行でき、1実行あたり1,000エージェントのハードキャップがあります。16同時実行のデフォルトには正当な理由があります。Opusティアのレートで広く展開すると、すぐに高額になります。制限は目標ではなくガードレールとして扱い、タスクが許す限り展開を狭く保ちましょう。
Dynamic workflowsをオフにするには？
設定でdisableWorkflowsをtrueにするか、Claude Codeを起動する前にCLAUDE_CODE_DISABLE_WORKFLOWS=1環境変数をエクスポートします。いずれも機能を完全に無効にします。/configにDynamic workflowsの行が表示されないだけなら、必要なv2.1.154未満の可能性が高く、まずアップデートが必要です。
Claude Codeワークフローは本当に必要ですか、それともサブエージェントで十分ですか？
タスクが1つの会話を超えるまで、サブエージェントで十分です。通常の会話で調整する数個のサブエージェントで、トークンコストなしに日常の作業をこなせます。ワークフローが本当に必要になるのは、タスクが1つの会話で追跡できる数を超えるエージェントを起動するとき、再実行可能なオーケストレーションをコードとして欲しいとき、またはエージェントに敵対的にクロスチェックさせたいときだけです。