⚖️ マルチエージェント並列化の損益分岐点 — いつ分割し、いつ単一エージェントへ戻すか

調査日: 2026-07-17 / 対象: 決定論的な順次処理を「サブエージェントに分割するか、単一エージェントのスクリプトへ戻すか」を判断するコストモデル
視座: プロダクト機能の解説ではなく、「いつ並列化し、いつ順次へ戻すか」をコスト構造で判断する方法論として読む
代表ケース: tottoko_hamu 氏の実測（39 本の記事への一括処理を 4 フェーズに分け、エージェント 116 本・428 万トークンを消費。順次フェーズの過剰分割が主因で理想設計比 5.7 倍のコスト）

概要

このモデルが解く問題

複数ステップの作業を自動化するとき、実行方法の選択肢は主に 3 つあります。

• サブエージェントを大量起動して並列実行する
• サブエージェントを流れ作業（パイプライン）で実行する
• 単一エージェントがループ（bash スクリプト）で順番に処理する

このモデルは「どの実行方法を選ぶべきか」を、勘ではなくコスト構造で判断するための枠組みです。判断の主軸は 1 点だけです。

タスク間に順次依存があるか、独立して並列化できるか。

順次依存があるタスクでは、前の結果が出て初めて次を始められます。サブエージェントを何本起動しても、処理速度は 1 本の場合と同じです。この場合、サブエージェント分割は起動コストだけを積み増します。

なぜ「損益分岐点」が生まれるか

サブエージェント分割には固定費があります。エージェント 1 本ごとに、コンテキスト初期化・指示読込・ツール呼び出しが発生します。この固定費は、起動本数に比例して積み上がります。

一方、並列化には便益があります。wall-clock 時間の短縮と、コンテキスト分離（各タスクが独立した文脈を保つこと）です。

損益分岐点は、次の不等式で表せます。

並列化の便益 (wall-clock短縮 + context分離の価値)
  >
起動固定費 × 本数 + 調整オーバーヘッド + 再試行増幅コスト

左辺が右辺を上回るときだけ、サブエージェント分割に価値があります。順次依存タスクでは左辺（便益）がほぼゼロなので、右辺（コスト）だけが積み上がります。

代表ケースが示す実測ギャップ

tottoko_hamu 氏の実測（一次: zenn.dev/tottoko_hamu）は、このギャップを具体的な数値で示しています。

このタスクの Phase1（CTA 編集 39 本並列）は、記事間に依存がない独立ファンアウトなので、並列化の便益がコストを上回ります。一方 Phase2（はてな公開 38 本）と Phase4（Qiita 公開 37 本）の合計 75 本は、外部プラットフォームへの順次公開を 1 件ずつサブエージェントに割り当てていました。直列にしか実行できない処理です。なお Phase3（Zenn への git push）は単一エージェントで実行されています。著者の結論はこうです。

並列処理には Workflow の parallel()、順次処理には単一エージェントの bash ループを使う。この使い分けを設計段階で意識できているかどうかで、コストが数倍変わる。

Phase2・Phase4 をそれぞれ単一エージェントに統一すると、この 2 フェーズは合計 75 本から 2 本（各フェーズ 1 本）へ減ります。Phase1 の 39 本（並列）と Phase3 の 1 本、管理用を合わせ、全体は 116 本から約 43 本まで削減できます。これがコスト差 5.7 倍の内訳です。

一次データが示すコストの重み

Anthropic の「How we built our multi-agent research system」（一次）は、マルチエージェント化のトークンコストを定量化しています。

• 単一エージェントは chat の約 4 倍のトークンを消費します。
• マルチエージェントは chat の約 15 倍のトークンを消費します。
• パフォーマンスの分散は、トークン使用量・ツール呼び出し回数・モデル選択の 3 要因の合計で約 95% を説明できます。うちトークン使用量単体で約 80% を占めます（残る約 5% は 3 要因では説明されません）。

同記事は、マルチエージェント化が正当化される条件を「重い並列化を伴う価値の高いタスク・単一コンテキストウィンドウを超える情報量・多数の複雑なツールとのやり取り」と述べています。逆に「全エージェントが同じコンテキストを共有する必要がある領域」「エージェント間の依存が多い領域」は不向きだと明示しています。

依存関係が多いタスク（コーディングタスクが例示されています）は、マルチエージェント化に向きません。トークンコストの重さは、独立して並列化できるタスクにだけ支払う価値がある「入場料」です。

判断フロー

3 つの実行モードの比較

3 つの実行モードは、Claude Code dynamic workflows（公式）が提供する agent() / pipeline() と、それに対置される「単一エージェントの bash ループ」です。なお公式ドキュメントに実行例が載るのは agent() と単一ステージの pipeline() のみです。parallel() の存在・バリア意味論・複数ステージ pipeline() の挙動は、非公式の解説（claude-world.com / alexop.dev）で補足された記述に基づきます。

ユースケース別の推奨

特徴

• コスト因子を分解して判断できる。 起動固定費（コンテキスト初期化・指示読込）、tool 呼び出し数、モデル選択、調整/統合オーバーヘッド、再試行増幅、成果物衝突による再実行の 6 因子に分けて評価します。
• 役割名でなく依存関係と並列化可能性で設計する。 「レビュー担当エージェント」のような役割ラベルではなく、「このタスクは前段の結果を必要とするか」「複数タスクは互いに独立か」で実行モードを決めます。
• 順次依存タスクへのサブエージェント分割は便益ゼロ。 tottoko_hamu の実測では、直列必須の Phase2・Phase4（合計 75 本）がコスト超過の主因でした。直列なら 1 本のループに統一するのが正着です。
• マルチエージェント化のトークンコストは軽くない。 Anthropic の実測で、マルチエージェントは chat の約 15 倍、単一エージェントでも約 4 倍のトークンを消費します。この重さに見合う便益（並列化・大量情報の集約）があるかを先に確認します。
• 性能分散の大半はトークン使用量で説明される。 分散はトークン使用量・tool 呼び出し回数・モデル選択の 3 要因合計で約 95%、うちトークン使用量単体で約 80% を説明できます。エージェント本数を増やす前に、トークン消費の見積もりが判断材料になります。
• pipeline() は parallel() の idle gap を解消する。 parallel() は全 thunk 完了を待つバリア同期のため、遅い 1 本に全体が律速されます。pipeline() はステージ間バリアがなく、アイテム N+1 は前アイテムが stage1 を終えた時点で開始できます。
• 実行系にはガードレールがある。 Claude Code dynamic workflows は同時実行エージェント数の上限 16 本、1 run あたり総数上限 1000 本を設けています。25 本超過または見積もりトークン総量が 150 万を超えると「Large workflow」警告が表示されます。
• 損益分岐の判定基準は「タスク価値・方向性の独立性・トークン量に見合う答えか」。 Anthropic は、マルチエージェント化が正当化される条件を「重い並列化・単一コンテキストを超える情報量・多数の複雑なツールとのやり取り」と述べる一方、「全エージェントが同じコンテキストを共有する必要がある領域」「エージェント間の依存が多い領域」は不向きとしています。

構造

本セクションは、損益分岐点モデルとオーケストレーション実行系の論理構造を C4 の 3 階層（システムコンテキスト / コンテナ / コンポーネント）で示します。対象はモデルという方法論そのものです。特定プロダクトの機能カタログではありません。なお C4 のコンテナは本来デプロイ可能な実行単位を表しますが、本図の「コスト因子」コンテナは実行プロセスではなく計算対象のデータ分類として、C4 記法を便宜的に流用しています。

システムコンテキスト図

損益分岐点モデルを中心に、それを使うアクターと外部システムの関係を示します。

アクター

損益分岐点モデル本体

外部システム

コンテナ図

損益分岐点モデルとオーケストレーション実行系の主要構成要素を示します。

判断エンジン

コスト因子

実行モード群

コンポーネント図

各コンテナの内部をドリルダウンします。実行モード群のみ、Claude Code workflow のプリミティブを具体例として使います。

判断エンジンのコンポーネント図

コスト因子のコンポーネント図

実行モード群のコンポーネント図

Claude Code workflow の agent() parallel() pipeline() プリミティブと、単一エージェント順次モードの bash for ループを具体例とします。図中の parallel()・バリア・複数ステージの意味論は公式ページに記載がなく、非公式解説（claude-world.com / alexop.dev）に基づく点に注意してください。

データ

このセクションでは、損益分岐点モデルが扱う概念エンティティを定義します。対象は「損益分岐の判定に必要な最小の概念集合」です。

概念モデル

以下の 10 エンティティで構成します。

• Task、DependencyEdge、WorkBatch は「何を、どういう順序でやるか」を表します。
• AgentInvocation、Retry、Artifact、Conflict は「実行の結果として何が起きるか」を表します。
• CostFactor、Breakeven、ExecutionMode は「損益分岐をどう判定し、どの方式を選ぶか」を表します。

図の読み方を補足します。

• WorkBatch は Task と DependencyEdge を所有します（subgraph の入れ子）。
• それ以外の矢印はすべて利用・呼び出し・データ供給の関係です。
• Breakeven → ExecutionMode → WorkBatch →（次サイクルの Task/DependencyEdge）というループが、判定結果が次の実行方式に反映される構造を表します。

情報モデル

主要属性のみを示します。メソッドは扱いません。

属性の根拠を、実測ケースに基づく値・公式仕様に基づく値・モデルとしての定義に分けて示します。

tottoko_hamu 実測から抽出した属性

Claude Code workflows 公式仕様から抽出した属性

モデルとして定義した属性（実装・記事に個別の記載なし）

構築方法

損益分岐点モデルをどう組み立てるかを示します。実行方法を選ぶ前に、3 つの準備が要ります。依存グラフの抽出、コスト因子の見積もり、損益分岐の判定式への当てはめです。

依存グラフの抽出手順

• タスクを列挙し、各タスクの入力と出力を書き出します。
• あるタスクの入力が、別タスクの出力に依存するかを確認します。依存があれば有向エッジを引きます。
• エッジがゼロのタスク集合は「独立探索」に分類します。
• エッジが直列に連なるタスク集合（前工程の完了が次工程の開始条件）は「決定論的順次」に分類します。
• 「独立だが各アイテムが複数ステージを通る」パターン（例: 収集→変換→検証）は、ステージ単位で見ると順次ですが、アイテム単位で見ると並列余地があります。このパターンは pipeline() の対象です。

コスト因子の見積もり

並列化を検討する前に、次の 6 因子を数値化します。単位は円換算（トークン単価 × 消費トークン）またはドル換算に揃えます。

Anthropic の一次データ（https://www.anthropic.com/engineering/multi-agent-research-system）は、単一エージェントが chat の約 4 倍、マルチエージェントが約 15 倍のトークンを消費するとしています。この 4 倍・15 倍という比率が、消費トークン量を見積もる際の参照値になります。なお同記事の「token 使用量が性能分散の約 80% を説明する」は、同社の評価ベンチマークにおける成果の分散の話であり、コスト構成比そのものではありません。混同せずに使います。

粗い単価分解の例を示します。tottoko_hamu 実測は 116 本で約 $25.70 なので、1 本あたり平均コストは約 $0.22 です。理想設計は約 43 本なので、43 × $0.22 ≈ $9.5 に近づくと見込めますが、実測の理想値はさらに低い $4.47 です。この差は、順次フェーズを bash ループへ統合するとエージェント起動そのものが消え、平均単価も下がるためです。実際の見積もりでは、この平均単価をフェーズごとの起動本数へ掛け、順次フェーズの本数をゼロに置き換えて理想値を出します。

損益分岐の判定式

並列化の便益 (wall-clock短縮の価値 + context分離の価値)
  >
起動固定費 × 本数 + 調整オーバーヘッド + 再試行増幅コスト + 衝突コスト

• 左辺が右辺を上回るときだけ、サブエージェント分割に価値があります。
• 決定論的順次タスクは、便益（wall-clock 短縮）がほぼゼロです。前工程の結果が出るまで次工程を始められないため、本数を増やしても時間は縮みません。この場合は右辺だけが積み上がるので、判定式は常に不成立になります。
• tottoko_hamu 実測（Phase2・Phase4、計 75 本を順次実行）はこのケースに該当します。単一エージェントの bash ループに統一すると、起動固定費の項がほぼゼロになり、理想設計コストは実測 $25.70 から $4.47 まで下がります。

利用方法

判定式を当てはめたら、3 モードのいずれかを選びます。まず使い分け表で選定基準を確認します。

1. parallel() 独立ファンアウト（依存なしの探索）

parallel(thunks) は「配列を並行実行し、全 thunk 完了を待つバリア」として動作します。以下は独立ファンアウトの実装例です。ただし公式ドキュメントには parallel() の関数名・シグネチャ・バリア動作の記載がありません。この関数の存在・意味論・呼び出し構文は、いずれも Claude Code Workflow 解説ブログ（alexop.dev、claude-world.com）の記述に基づく補完です。

export const meta = {
  name: 'audit-independent-articles',
  description: 'Audit N articles for missing CTA independently, no cross-article dependency',
}

const found = await agent('List every article file under content/articles/.', {
  schema: {
    type: 'object',
    required: ['files'],
    properties: { files: { type: 'array', items: { type: 'string' } } },
  },
})

// 記事間に依存がないため parallel() でファンアウトする
const results = await parallel(
  found.files.map((file) => () =>
    agent(`Audit ${file} for missing CTA block.`, {
      label: file,
      phase: 'Audit',
      schema: {
        type: 'object',
        required: ['file', 'hasCta'],
        properties: { file: { type: 'string' }, hasCta: { type: 'boolean' } },
      },
    }),
  ),
)

return results.filter((r) => r && !r.hasCta)

• parallel() は全 thunk の完了を待つバリアです。次工程（集計・レポート化）を始める前に全件揃える必要がある場合に使います。
• 同時実行数はランタイム上限 16 本です（CPU コアが少ない環境ではさらに減ります）。thunk 数が上限を超えた場合の待機挙動は公式に明記されていません。

2. pipeline() ステージ流し（段階依存あり、バリア不要）

公式ドキュメントの唯一の完全な実行例は単一ステージの pipeline() です。以下がその原文（https://code.claude.com/docs/en/workflows より、meta 名も含めそのまま引用）です。

export const meta = {
  name: 'audit-routes',
  description: 'Audit every route handler for missing auth checks',
}

const found = await agent('List every .ts file under src/routes/.', {
  schema: {
    type: 'object',
    required: ['files'],
    properties: { files: { type: 'array', items: { type: 'string' } } },
  },
})

const audits = await pipeline(found.files, (file) =>
  agent(`Audit ${file} for missing authentication checks.`, { label: file }),
)

return audits.filter(Boolean)

複数ステージ（例: レビュー→検証）を通す場合は、pipeline(items, ...stages) に複数のステージ関数を渡します。以下はレビュー→反証の 2 段パイプライン例です。ただし公式ドキュメントの記載は「pipeline() はリスト内の item ごとに 1 つ実行する」までで、複数ステージやステージ間バリアなしの説明はありません。「pipeline は item を複数ステージにストリームし、item N+1 は item N が stage1 を終えた時点で開始する」という意味論と具体構文は、いずれも claude-world.com の解説に基づく補完です。

const reviews = await pipeline(
  changes.files,
  (file) =>
    agent(`Review ${file} for correctness bugs introduced on this branch.`, {
      label: `review:${file}`,
      phase: 'Review',
      model: 'sonnet',
    }),
  (review) =>
    review &&
    agent('Try to REFUTE each finding by reading the actual code.', {
      label: 'verify',
      phase: 'Review',
    }),
)

• item N がステージ 1（レビュー）を終えた時点で、item N+1 のステージ 1 がすぐ始まります。ステージ 2（反証）の開始を待つ必要はありません。
• これが「既定は pipeline() 推奨」の理由です。parallel() のバリアが生む idle gap を排除できます。

3. 単一エージェント bashループ（決定論的順次）

並列化の余地がないタスクは、Workflow のサブエージェントを本数分起動しません。ここで避けたいのは「アイテムごとに新しいエージェントプロセスを立ち上げ直す」ことです。ループの各回で claude -p を呼ぶと、呼び出しごとに非対話セッションが起動し、起動固定費が本数分積み上がります。これでは削減の原理を実装できません。

削減の要点は 2 つに分かれます。

第 1 に、LLM の判断が不要な決定論的変換は、そもそもエージェントを使いません。同一文字列の追記のような機械的処理は sed などの通常スクリプトで一括処理します。

#!/usr/bin/env bash
set -euo pipefail

# 同一の CTA ブロックを全ファイルへ機械的に追記する。LLM 判断は不要なので、
# エージェントを一切起動せず sed だけで一括処理する。起動固定費はゼロ。
CTA='<!-- CTA: 次の問い予告 -->'
while IFS= read -r file; do
  grep -qF "$CTA" "$file" || printf '\n%s\n' "$CTA" >> "$file"
done < files.txt

第 2 に、各アイテムに LLM 判断が要るものの外部制約（レート制限など）で直列化するタスクは、1 つのエージェントプロセス内でループさせます。プロセス起動を 1 回に抑え、内部で retry-with-backoff しながら順に処理します。tottoko_hamu 氏の Phase2・Phase4（合計 75 本を順次サブエージェント起動していた箇所）は、この単一プロセス化でコスト差 5.7 倍のほとんどを解消しました。

• 起動固定費は、アイテム数ではなくプロセス起動回数に比例します。単一プロセス化で固定費は 1 回に収まります。
• 著者の結論のとおり「どうせ直列なら、エージェントを何本も起動する意味がない」場合に適用します。
• 判定式に当てはめると、このモードは右辺の「起動固定費 × 本数」の項を最小化する選択です。左辺（並列化の便益）が最初からゼロに近いタスクでは、この項を下げることが最適解になります。

運用

マルチエージェント並列化の損益分岐点は、一度設計して終わりではありません。実行のたびに実測し、モデルの前提とズレていないか監視し続ける対象です。

監視すべき指標

Anthropic 公式は「3 要因（token usage・ツール呼び出し回数・モデル選択）合計で性能分散の約 95%、うち token usage 単体で約 80% を説明できる」と述べています。これは同社の評価ベンチマークでの成果の分散に関する知見です。加えてトークン量はコストに直結するため、運用で最優先すべき指標を token 使用量に定めます。

wall-clock 時間とコストは別軸として扱う点が重要です。並列化は wall-clock を縮める一方、トークン消費は縮めません。両者を同じダッシュボードで並べて見ないと、「速いが高い」判断を見落とします。

収集するログの最小スキーマ

エージェント単位でログを残すと、後から「どのフェーズが委任税を払いすぎたか」を特定できます。以下は監視のために自分で設計する正規化スキーマの例です。CLI や API が返す生 JSON ではありません。

{
  "run_id": "string",
  "phase": "string",
  "agent_id": "string",
  "mode": "agent | parallel | pipeline | bash_loop",
  "tokens_in": 0,
  "tokens_out": 0,
  "tool_calls": 0,
  "wall_clock_ms": 0,
  "retry_count": 0,
  "conflict_flag": false,
  "status": "success | failed_retriable | failed_final"
}

このスキーマは agent-loop 系の運用パターン（agent_outcomes → dbt mart → Grafana）と同型です。生ログを landing し、run 単位・フェーズ単位に集計するマートを作ると、後述のコスト回帰レビューがそのままクエリになります。

ダッシュボード化の実装例

Claude Code の /workflows ビューは、この最小スキーマに相当する情報をフェーズ単位で標準表示します。

さらに以下のしきい値超過を自動検知します。

• 1 run が 25 エージェントを超えて計画された場合
• 1 run の見積もりトークン総量が 150 万トークンを超えた場合

このしきい値超過は「Large workflow」警告として表示されますが、実行を止めるものではなく参考情報です。自前のダッシュボードを組む場合も、同様の閾値アラートを一次防波堤として設けると、暴走ファンアウト（後述のアンチパターン）を早期発見できます。汎用の LLM Observability 基盤（Datadog、Langfuse、Grafana、OpenObserve 等）を使う場合は、per-agent / per-tool の呼び出し頻度・エラー率・p95 レイテンシをトレースできる構成にすると、Claude Code 外の自作オーケストレーションでも同水準の可視性を確保できます。

コスト回帰のレビュー運用

損益分岐点モデルの核は次の回帰式です。

総トークン ≈ 起動本数(N) × 固定費(C_fixed) + 調整費(C_coord) + 再実行分(rework)

• C_fixed: エージェント起動ごとの context 初期化・指示読込コスト。tottoko_hamu 氏は、同著者が別記事で提唱した「サブエージェント委任税」という表現でこれを説明しています。
• C_coord: 統合パス・citation pass など、複数エージェントの結果を合流させるためのコスト。起動本数に対して非線形に増える傾向があります。
• rework: 再試行と成果物衝突による再実行分。

運用レビューでは、run のたびにこの回帰式へ実測値を当てはめ、想定と乖離していないかを確認します。

このレビューは、本番実行の前に小規模スライス（1 ディレクトリ、狭い質問など）で試走してからスケールする運用と組み合わせると効果的です。小規模スライスでの実測トークン単価を外挿し、想定コストを事前に見積もってから本実行に進みます。

本番運用化に向けた工夫（Anthropic の知見）

Anthropic は研究システムを本番運用する過程で、以下の工夫を積み重ねたと報告しています。

• フルプロダクショントレーシング: エージェントの意思決定パターンと相互作用構造を追跡し、失敗原因の診断に使う。ユーザープライバシーは維持したまま構造だけを追跡する。
• rainbow deployments: 実行中のエージェントを壊さずに新旧バージョンを段階的に切り替える。
• チェックポイント運用: エージェントは stateful でエラーが複合するため、失敗時の再起動コストが高い。「途中から再開する」チェックポイントを実装し、全体の再実行を避ける。
• 評価のスケーリング: 小サンプルから LLM-as-judge 評価を始め、事実正確性・引用精度・網羅性などの基準で継続評価する。LLM 評価だけでは見落とすエッジケースは、人間評価で補う。

ベストプラクティス

独立探索だけ並列化し、決定論的反復はスクリプトへ戻す

判断はデータ依存を最初のゲートに、外部制約と LLM 判断の要否を重ねて決めます。役割の多さやフェーズの多さでは決めません。3 つの軸を分けて評価します。

• データ依存: 前段の出力が次段の入力に直結するか。直結するなら並列化できません。
• 外部制約: レート制限など、データ依存はなくても直列実行を強いる制約があるか。あるなら 1 プロセス内でループします（エージェントを本数分は起動しません）。
• LLM 判断の要否: 各アイテムに推論が要るか。要らない決定論的変換は、エージェントを使わず sed などのスクリプトで処理します。

なお「決定論的である」ことは「逐次依存である」ことを意味しません。同一文字列の追記のような決定論的処理は、多くの場合は互いに独立で並列化できます。それでも順次にするのは、外部公開のレート制限など別の制約があるときです。

tottoko_hamu の理想設計は、この表をそのまま適用したものです。Phase 1（CTA 編集、各記事が独立）は parallel() のまま 39 エージェントを維持し、Phase 2/4（プラットフォームへの順次公開）を単一エージェント + bash ループに置き換えることで、116 本を約 43 本まで削減しています。

役割名でエージェントを増やさない。依存グラフと並列化可能性で設計する

「編集係」「校正係」「公開係」のように役割を切ってエージェント数を決める設計は、依存関係を無視しがちです。設計の入口は常に「このタスクとこのタスクは依存しているか」であるべきです。フェーズを立てるたびに「並列か順次か」を問い、順次なら役割が何個あっても 1 エージェントに畳み込みます。

multi-agent が正当化される条件を事前判定する

Anthropic は multi-agent が正当化される条件を「タスク価値が高く、方向が独立し、答えが大量トークンに値する」場合と定義しています。実行前チェックリストとして運用できます。

3 条件（高価値・独立方向・大トークン）を全て満たし、かつ共有 context が不要な場合のみ multi-agent 化を検討します。

誤解 → 反証 → 推奨

本モデルの適用限界

このモデルは、次の前提の上で使います。

• 代表ケースの tottoko_hamu 実測は単一事例です。コスト概算値（$25.70 / $4.47）は公開情報に基づく著者の推定であり、課金明細レベルの生ログは検証していません。
• 数値の一般化には注意が要ります。起動固定費の絶対額・調整費の増え方は、タスク種別・使用モデル・オーケストレーション基盤で変わります。本モデルは「順次依存タスクへのサブエージェント分割は便益ゼロ」という定性判断が中核で、5.7 倍という倍率そのものは他タスクへ横展開できません。
• 各コスト因子の実測値を自環境で計測し、判定式へ当てはめ直すことを前提とします。

トラブルシューティング

順次分割・過剰ファンアウト・成果物衝突など、損益分岐点を踏み外したときの典型的な症状と対処を示します。

まとめ

マルチエージェント並列化の損益分岐点は、データ依存を最初のゲートに、外部制約と LLM 判断の要否を重ねて決まります。データ依存や外部制約で直列にしかできないタスクにサブエージェントを本数分割り当てても、並列化の便益はゼロのまま起動固定費だけが積み上がり、代表ケースでは同一タスクでコストが 5.7 倍に膨らみました。独立探索だけを並列化し、直列タスクは 1 プロセスへ畳み込み、LLM 判断が不要な決定論的処理はスクリプトへ戻すことが、コスト構造から導ける設計原則です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • Orchestrate subagents at scale with dynamic workflows（Claude Code 公式）
  • How we built our multi-agent research system（Anthropic Engineering）
• 記事
  • 順次タスクを Claude Code Workflow で並列化したら、コストが 5.7 倍に膨れ上がった話（tottoko_hamu, Zenn）
  • Multi-Agent AI Systems: Why They Fail and How to Fix Coordination Issues（Augment Code）
  • Multi-Agent Orchestration Economics: When Single Agents Win（Iterathon）
  • Claude Code Workflows: Deterministic Multi-Agent Orchestration（alexop.dev）
  • The Workflow Tool: Scripted Multi-Agent Orchestration（claude-world.com）
  • AI agent orchestration for production systems（Redis Blog）
  • 15 AI Agent Observability Tools in 2026（aimultiple）