サブエージェント並列実行のコスト経済学 2026 — ファンアウトの損益分岐点

「並列＝安い」という誤解

エージェントアーキテクチャの定番テクニックに「ファンアウト」がある。1つのオーケストレーターが複数のサブエージェントを並列に起動し、それぞれに独立したサブタスクを割り当てる。リサーチ、マルチサービスのデータ収集、横断検索——並列化で壁時計時間(wall-clock time)が劇的に縮むのは事実だ。

だが、ここで多くのチームが踏む落とし穴がある。「並列にすれば速くなる」を「並列にすれば安くなる」と取り違えることだ。トークン課金は実行時間ではなく、入力・出力トークン量で決まる。10件を逐次で叩いても並列で叩いても、API呼び出しの実トークンが同じなら課金は変わらない——ように見える。実際には、並列化は3つの隠れコストを生む。

コスト①: コンテキスト複製税

サブエージェントは、それぞれが独立したコンテキストを持つ。システムプロンプト、ツール定義(MCPツールスキーマ)、タスク指示、共有状態のスナップショット——これらがサブエージェントの数だけ複製される。オーケストレーターが5つのサブエージェントをファンアウトすれば、共通のシステムプロンプトとツール定義は5回入力トークンとして課金される。

MCPツール定義は特に重い。ツール定義がコンテキストの相当部分を占めることは既知の問題で、これがサブエージェント数だけ掛け算される。逐次実行なら1つのコンテキストを使い回せる場面でも、並列では各エージェントがフルセットを抱える。これが「コンテキスト複製税」だ。

コスト②: 最遅サービスによる律速

並列バッチは通常、全サブエージェントの完了を待ってから次に進む。つまりバッチの所要時間は、最も遅いサービスのレイテンシで決まる。KanseiLinkの実測データを見ると、サービス間のレイテンシ差は無視できない。

ここが肝心だ。Backlog(128ms)とSlack(163ms)を並列で叩くだけなら、バッチは約163msで終わる。だが同じバッチにSalesforce(474ms)を1つ混ぜた瞬間、バッチ全体は474ms待ちになる。速いサービスのサブエージェントは、最遅サービスの完了を待つ間アイドルする。並列度を上げても、律速段階が遅ければ壁時計の短縮効果は頭打ちになる——これがアムダールの法則のエージェント版だ。

コスト③: 低成功率サービスのリトライ掛け算

3つ目が最も見落とされやすい。失敗はリトライを生み、リトライはコンテキストを再消費する追加実行を生む。並列幅を広げるほど、低成功率サービスでは失敗の絶対数が増える。

成功率39%のSmartHRに10件の並列呼び出しを投げる場合を考えよう。期待成功は約4件、残り約6件はリトライ対象になる。各リトライはサブエージェントのコンテキスト(複製税込み)を再度消費する。一方、成功率90%超のverified層(freee・Slack・Backlog)に同じ10件を投げれば、失敗は約1件で済む。同じ並列幅でも、成功率帯によってリトライコストは6倍違う。

つまり、低成功率サービスへのファンアウトは「速く失敗する」だけでなく「複製税込みで失敗を量産する」。リトライ税の経済学が、並列化によって増幅される構図だ。

損益分岐点 — いつ並列にすべきか

では、ファンアウトはいつ正当化されるのか。並列が有利になる条件は、突き詰めると次の3つに集約される。

具体例で言えば、10サービスから独立にデータを収集する高レイテンシのリサーチタスクは並列の典型的な勝ちパターンだ。待ち時間が支配的で、依存がなく、収集先が高成功率なら、複製税を払ってでも壁時計を縮める価値がある。

逆に、verified層を2〜3件だけ叩く軽量タスクは逐次のほうが安いことが多い。Backlog 128ms × 3件を逐次で叩いても400ms程度で、コンテキストは1つで済む。ここで3並列にすれば速度はわずかに上がるが、入力トークンは3倍になる。「速くなるが、割に合わない」典型例だ。

実践プレイブック

• 独立タスクだけ並列化する — 依存関係のあるタスクを無理に並列化すると、結局待ち合わせが発生し、複製税だけが残る。
• バッチを成功率帯で揃える — verified層と低成功率サービスを同一バッチに混ぜない。混在は最遅・最低成功率に律速され、最も非効率な組み合わせになる。
• 遅いサービスを隔離する — Salesforce(474ms)やSmartHR(337ms)は律速段階。別バッチに分離し、速いサービスのスロットを待たせない。
• 共通コンテキストはプロンプトキャッシュで再利用 — システムプロンプト・ツール定義をキャッシュすれば、複製税の大部分を回収できる。プロンプトキャッシュのコスト削減はファンアウトと特に相性が良い。
• ファンアウト幅を成功率に応じて調整 — 低成功率サービスは並列幅を絞り、リトライの絶対数を抑える。事前に get_insights でレイテンシ・成功率を確認してバッチ設計に反映する。

FAQ

サブエージェントの並列実行はコストを増やしますか？

多くの場合増やします。並列(ファンアウト)は壁時計時間を縮めますがトークンコストは下げず、(1)各サブエージェントのコンテキスト複製、(2)最遅サービスによる律速、(3)低成功率サービスへのリトライ掛け算、という3つの隠れコストを生みます。「速い」は「安い」を意味しません。

ファンアウトの損益分岐点はどこですか？

壁時計短縮の価値が複製トークンのコスト増を上回るときです。(1)タスクが独立、(2)対象サービスが高レイテンシ、(3)対象サービスが高成功率、の3条件が揃うほど並列が有利。逆に安く速く高成功率のverifiedを少数叩くだけなら逐次が効率的です。

なぜ最も遅いサービスがバッチ全体を律速するのですか？

並列バッチは全サブエージェントの完了を待つためです。verified層は128〜216msですが、Salesforceは474ms、SmartHRは337ms。Salesforceを1つ混ぜると他が128msでも全体は474ms待ちになり、遅いサービスが律速段階になります。

低成功率サービスを並列で叩くとなぜコストが膨らむのですか？

失敗がリトライを生み、リトライが複製税込みの追加実行を生むからです。成功率39%のSmartHRに10件並列を投げると期待失敗は約6件、verified層(90%+)なら約1件。同じ並列幅でも成功率帯でリトライコストは6倍違います。

並列実行のコストを抑えるベストプラクティスは？

(1)独立タスクだけ並列化、(2)バッチを成功率帯で揃える、(3)遅いサービスを別バッチに隔離、(4)共通コンテキストをプロンプトキャッシュで再利用、(5)ファンアウト幅を成功率に応じて調整。get_insights で事前にレイテンシ・成功率を確認してバッチ設計に反映できます。