注目 workflow orchestration multi-agent claude-code agents

Workflow とは何か？Claude Code のマルチエージェントオーケストレーション徹底解説

Claude Code の Workflow とは？サブエージェントを統率する決定論的な JavaScript スクリプト——マルチエージェントオーケストレーションを実例付きで解説。

2026年7月8日 • 11 分で読む • 著者：Claude World

2026 年の Claude Code が大きなタスクに取り組む様子を見ていると、「12 エージェントで workflow を起動します」といったアナウンスに出会うことがあります。そして /workflows コマンドを叩けば、何十ものサブエージェントが一斉に展開し、互いに検証し合い、1 つの答えに収束していくライブ進捗が表示されます。新しいユーザーが必ず口にする疑問は 2 つ。Workflow（ワークフロー）とは何か？ そして「オーケストレーション」とは実際のところ何を意味するのか？

本記事はこの両方に、ゼロから答えます。マルチエージェントの予備知識は不要です。

短い答え

Workflow とは、Claude Code が書き、ハーネスが実行する小さな JavaScript プログラムです。スクリプトの仕事は*調整（コーディネーション）*です。サブエージェントを生成し、その出力を互いに受け渡し、処理を並列に走らせ、次に何が起こるかを決める——モデルの即興ではなく、ごく普通のループと条件分岐を使って。

オーケストレーションは文字どおりの意味です。1 つの楽譜と、大勢の演奏者。

  • 楽譜は workflow スクリプトです。決定論的（deterministic）——同じスクリプトは毎回同じ動きをします。誰がいつ演奏するかを決めるのは楽譜です。どのエージェントを、どの順番で、どの入力に対して走らせるか。
  • 演奏者はサブエージェントです。それぞれが独自のコンテキストウィンドウとツールを持つ、完全な Claude エージェントです。コードを読み、証拠を吟味し、分析を書く——楽譜が割り当てたパートの中で、判断力を発揮します。

この分業こそがすべてであり、暗記する価値があります。

制御フローはコードに。判断はモデルに。

タスクの途中でモデルが「もう 1 人レビュアーを生成すべきか？」と決めるのは即興です——柔軟ではあるものの、再現不能でコストの見積もりも困難です。それをスクリプトが決めるなら——for ループと if 文で——それがオーケストレーションです。

1 人のエージェントからオーケストラへ

Workflow は突然現れたわけではありません。Claude Code の歴史をたどれる進化の、4 段階目にあたります。

Stage 1: Solo agent
  ┌─────────┐
  │ Claude  │  one context window does everything:
  └─────────┘  read, plan, edit, test

Stage 2: Subagent fan-out (Agent tool)
  ┌─────────┐
  │ Claude  │──→ agent: "search the codebase"
  │ (main)  │──→ agent: "read these 40 files"
  └─────────┘    results return to the parent only

Stage 3: Agent teams
  ┌─────────┐    ┌─────────┐
  │ agent A │←──→│ agent B │  named agents that persist,
  └─────────┘    └─────────┘  continued via SendMessage

Stage 4: Scripted workflows
  ┌────────────────────────────┐
  │  JavaScript orchestration  │
  │  loops · phases · fan-out  │
  └──┬──────┬──────┬──────┬────┘
   agent  agent  agent  agent   (deterministic score,
                                 judging musicians)

Stage 1 は誰もが最初に立つ場所です。1 つのエージェント、1 つのコンテキストウィンドウ。単一のコンテキストに収まる規模のタスクなら、これで十分に機能します。

Stage 2 で Agent tool が加わりました。メインエージェントは複数ファイルの読み取りや検索をサブエージェントに委譲し、自分のコンテキストにはファイルの中身の山ではなく結論だけを残します。サブエージェントはデフォルトでバックグラウンド実行され、その最終メッセージは呼び出し元にのみ返されます。（詳しくは Session 4: サブエージェントとコンテキスト分離で扱っています。）

Stage 3 はエージェントを継続的な協働者にしました。サブエージェントに name を与えれば、親はあとから SendMessage を通じてメールボックス方式で——コンテキストを保ったまま——続きを依頼できます。毎回ゼロから始め直す必要はありません。（Session 9: エージェントチームとコミュニケーションを参照。）

Stage 4 —— Fable 5 時代の Workflow tool —— が変えたのは、構造を誰が決めるかです。Stage 2 と 3 では、メインエージェントがターンごとに委譲を即興で組み立てます。Workflow では、構造は一度だけコードとして書き下ろされ、そのとおり正確に実行されます。ハーネスはスクリプトをバックグラウンドで実行してタスク ID を返し、完了時に通知します。その間ずっと、/workflows でライブ進捗を確認できます。

なぜスクリプトなのか？ 決定論が重要な理由

調整レイヤーを決定論的にする、と聞くと些末な技術的こだわりに思えるかもしれません。実際には、価値の大半はここから生まれます。

1. 再現性。 スクリプトは非決定性を全面的に禁止しています。Date.now()、Math.random()、引数なしの new Date() は、workflow スクリプト内ではすべて例外を投げます。同じスクリプトなら、同じ挙動。「前回はうまくいったのに」は存在しません——楽譜は公演のたびに変わったりしないのです。

2. キャッシュからの再開（resume）。 すべての workflow 実行はスクリプトを永続化し、journal.jsonl が各エージェントの実際の戻り値を記録します。resumeFromRunId を付けて再起動すると、ハーネスは agent() 呼び出しのうち変更されていない最長のプレフィックスをキャッシュからそのまま再生し、編集された呼び出しと新規の呼び出しだけを実際に実行します。50 エージェント規模の実行でステージ 3 のプロンプトを直したら、支払い直すのはステージ 3 の分だけ——ステージ 1 と 2 は再課金されません。これが成り立つのは、制御フローが決定論的だからこそです。非決定的な組み込み関数が禁止されている理由もここにあります。

3. 混乱なき並列性。 コードによるファンアウト（並列展開）は、安全なファンアウトです。Workflow は最大 min(16, CPU コア数 − 2) のエージェントを同時実行し、超過分はキューに入れ、暴走ループへの歯止めとして 1 回の実行を合計 1,000 エージェントに制限します。単一のファンアウト呼び出しに 4,096 件を超えるアイテムを渡すと、明示的にエラーになります（黙って切り捨てることは決してありません）。

4. 予算の強制。 プロンプトに「+500k」と書けば、そのターンにトークン目標が設定され、スクリプト内では budget オブジェクトとして参照できます。budget.total、budget.spent()、budget.remaining() です。このプールはメインループとそのターンのすべての workflow で共有され、しかもハードシーリング（絶対上限）です。消費が総額に達すると、以降の agent() 呼び出しは例外を投げます。スクリプトは budget.remaining() を確認して穏やかに手仕舞いできますが、即興するモデルにこれに相当するブレーキはありません。

やさしいツアー：agent()、parallel()、pipeline()

概念をつかむのに API の全貌は必要ありません（深掘りは Session 27: Workflow ツールで）。ほとんどの workflow は 3 つのプリミティブで動いています。

  • agent(prompt, opts?) —— サブエージェントを生成し、その最終テキストを受け取ります。opts.schema で JSON Schema を渡せば、代わりに検証済みオブジェクトが返ります。サブエージェントは構造化出力ツールを強制的に通され、形が一致しなければ自動でリトライされます。エージェントごとの model と effort オプションにより、機械的な作業には安価なモデルを、判断には最上位モデルを割り当てられます。
  • parallel(thunks) —— 複数の処理を同時に走らせ、すべての完了を待ちます（バリア）。例外を投げた thunk は実行をクラッシュさせる代わりに null に解決されるので、.filter(Boolean) でフィルタします。
  • pipeline(items, stage1, stage2, ...) —— 各アイテムがすべてのステージを独立に流れ、ステージ間にバリアはありません。アイテム B がまだステージ 1 にいる間に、アイテム A はステージ 3 に進めます。総所要時間は、最も遅い 1 アイテムのチェーンの長さだけです。

以下は完全でシンプルな workflow の例です——変更されたファイルのリストを並列にレビューし、その結果をマージします。

export const meta = {
  name: 'review-changes',
  description: 'Review changed files in parallel, then merge findings',
  phases: [{ title: 'Review' }, { title: 'Merge' }],
};

phase('Review');
const files = args.files; // passed in when the workflow is invoked

// Fan out: one reviewer per file, all running concurrently.
const reports = (await parallel(
  files.map((file) => () =>
    agent(`Read ${file} and report any correctness bugs you find.`, {
      label: `review ${file}`,
      phase: 'Review',
      model: 'haiku',   // cheap tier for mechanical per-file reading
      effort: 'low',
    })
  )
)).filter(Boolean); // a failed reviewer becomes null — drop it

phase('Merge');
log(`Collected ${reports.length} per-file reports.`);

// One high-effort agent merges and ranks everything.
await agent(
  `Merge these review reports. Deduplicate and rank by severity:\n\n` +
  reports.join('\n---\n'),
  { phase: 'Merge', effort: 'high' }
);

注目してほしいポイントがいくつかあります。

  • スクリプトは export const meta = ... で始まります。変数も関数呼び出しも含まない純粋なリテラルで、名前・説明・フェーズを宣言します。各 phase() 呼び出しはそこで宣言されたタイトルと対応しており、これがライブ進捗表示を支えています。
  • args は workflow がパラメータ化された入力を受け取る手段です。log() は実行中に読めるナレーション行を書き出します。
  • スクリプト自体にはファイルシステムアクセスも Node.js API もありません。ツールを持つのはエージェントです——楽譜が楽器に触れることはありません。
  • マージステップが parallel のバリアを使っているのは意図的です。全レポートを横断して重複排除するには、すべてのレポートが揃っている必要があるからです。これが経験則です——バリアが正当化されるのは、次のステージが前のステージ全体からのアイテム横断コンテキストを必要とする場合だけ。アイテム間の比較を必要としないアイテム単位のチェーンは、何も待たない pipeline に置くべきです。

手元に残しておきたい workflow は .claude/workflows/ に置いておけば、あとから名前で呼び出せます。1 つの workflow が workflow() で別の workflow を呼ぶことも可能です（ネストは 1 段まで）。

ファンアウトの先へ：品質パターン

ファンアウトは基本中の基本にすぎません。オーケストレーションの面白い部分は、構造を使って答えをより真実に近づけることにあります。

  • 敵対的検証（adversarial verify） —— 各発見事項に対して、それを反証するよう明示的にプロンプトされた独立の懐疑エージェントたちを生成します。過半数が反証に成功したら、その発見は棄却。もっともらしいが誤っている結果を、あなたの目に届く前にふるい落とします。
  • 審査員パネル（judge panel） —— 同じ問題に異なる角度から独立に複数回挑み、並列の審査員がスコアを付け、勝者に次点勢の最良のアイデアを合成して最終回答を作ります。
  • 枯れるまでループ（loop-until-dry） —— 規模が未知の「X をすべて見つけよ」型のタスクでは、数ラウンド連続で新しい発見がなくなるまで探索エージェントを生成し続けます。

これらは独立したセッションに値するテーマです——Session 28: オーケストレーション品質パターンがコード付きで 1 つずつ解説しています。いま持ち帰るべき要点はこれです。回答の品質は、モデルの性質だけでなく、オーケストレーションの仕方という構造的性質になった、ということです。

ソロか、サブエージェントか、Workflow か？

機構が増えれば常に良くなる、というものではありません。正直な判断表がこちらです。

状況選ぶべき手段理由
単一の事実確認、ファイルの場所も分かっているソロ（委譲なし）委譲のオーバーヘッドに見合わない——そのまま読めばいい
複数ファイルの読み取り、検索、探索サブエージェント（Agent tool）メインコンテキストに残るのはファイルの山ではなく結論
過去の作業を覚えている必要がある協働者名前付きエージェント + SendMessage再起動ではなく、コンテキストを保ったまま続行
多数のアイテムに対する多段プロセスで、検証や再開が必要Workflow決定論的な制御フロー、並列性、予算、キャッシュからの再開

オプトインの方法

Workflow はオプトインです。1 つの workflow が何十ものエージェントを生成し、相当なトークン量を消費し得るため、ハーネスはその規模を明示的に求めることを要求します。オプトインしなければ、Claude Code は個別のサブエージェントを使うか、ソロで作業します。入り口は 3 つあります。

  1. 言葉で伝える：単発なら、プロンプトに「use a workflow」と含めます。
  2. Ultracode：プロンプトにキーワード「ultracode」を含めるか、/effort でセッション全体に対して有効化します。Ultracode = xhigh の推論 effort + すべての実質的なタスクでの常設マルチエージェント workflow オーケストレーション。（完全ガイド：Ultracode と Effort レベル。）
  3. スキル経由：スキルの指示から、そのタスクを workflow でオーケストレーションするよう Claude Code に指定できます。

オプトインの際に「+500k」のようなトークン指示を添えれば、オーケストラ全体がハードな予算の内側で演奏します。

要点

Workflow は楽譜であって、ソリストではありません。Claude Code は決定論的な JavaScript を書いて何を、いつ、どの順序で走らせるかを決め、判断を要するすべての行為は、判断が得意なサブエージェントに委ねます。手に入るのは、コードの信頼性（再現性、再開、並列性、予算）にモデルの知能を掛け合わせたもの——どちらか一方を選ばされることは、もうありません。

次にタスクが 1 つのコンテキストウィンドウには大きすぎると感じたら、より大きなエージェントを求めるのではなく、オーケストラを求めてください。