Managed Agentsのオーケストレーターでコストが下がる2条件 — advisorとの選び分け

Managed Agentsで高性能モデルをコーディネーターに置き、安価なモデルをワーカーに並べると、安くなりそうに見えます。実測では、そうなったのは2つの状況だけでした。並列に走らせる最大の効果は時間の短縮で、費用の削減ではありません。

もう一つの選択肢が、安価なモデルが主役で、詰まったときだけ上位モデルに相談するadvisor戦略です。どちらを選ぶかは、仕事が独立した部品に割れるか、依存した一本の鎖かで決まります。

オーケストレーター戦略の役割と、コストが動く仕組み

オーケストレーター戦略では、フロンティアモデルが主ループを持ちます。仕事を分解し、安価なワーカーモデルへ小さな作業を配り、結果を統合します。ワーカーが重い探索を引き受けるので、コーディネーター自身の履歴は短く保たれます。トークンの大半はワーカーの単価で課金され、計画と統合だけが上位モデルの仕事になります。

Managed Agentsでは、コーディネーターのエージェントに multiagent を設定し、委譲先のroster(名簿)を並べて構成します。rosterの各エージェントは自分のモデルを持てます。次の例は、コーディネーターにOpus 5.5、委譲先に別エージェントを置く公式ドキュメントの構成です。

{
  "name": "Engineering Lead",
  "model": "claude-opus-5-5",
  "multiagent": {
    "type": "coordinator",
    "agents": [
      {"type": "agent", "id": "<REVIEWER_AGENT_ID>"},
      {"type": "agent", "id": "<TEST_WRITER_AGENT_ID>"}
    ]
  }
}

構成手順とスレッドの設計はManaged Agentsでマルチエージェントを編成する方法に詳しくあります。この記事が扱うのは、その構成が財布にとって得かどうかの判断です。

並列の効果は時間、コストではない

並列化が確実に効くのは所要時間です。コーパス系ベンチマークでは、コーディネーターが25本のワーカーを同時に走らせたとき、1エピソードは約2.3時間でした。単独モデルは15〜20時間かかっています。25本はプラットフォームが文書化している同時スレッド数の上限で、rosterに載せられる固有のエージェントは最大20種類です。1種類を複数コピー呼び出すこともできます。

時間が縮んでも、費用が下がるとは限りません。DRACOというベンチマークでは、同じモデルのエージェントをチームにすると、単独エージェントの4.0倍の費用がかかりました。所要時間はほぼ同じです(95%区間で12%短い〜13%長い)。並列の分だけ仕事量が増えるので、素のままのチームは高くつきます。

コスト面で得をした状況は、実測では2つだけです。しかも、単一モデルで足りる仕事では、同じモデルのeffortを下げた構成が毎回より安く済みました。

節約になった状況1: 易しい仕事に潜む高コストの裾

フロンティアモデルを単独で走らせると、普段なら解ける易しい問題で、たまに迷走します。どの実行が迷走するかは事前に分かりません。数回の迷走が請求額を支配します。易しい仕事をワーカーに渡すコーディネーターは、迷走が起きても安いワーカー単価で済むので、この裾を切り落とせます。

BrowseCompの易しい部分(単独モデルが安定して解く10問)での測定です。実行回数は委譲が50回、単独が70回で、Fable 5をコーディネーター、Sonnet 5をワーカー1本にした構成を比べています。

「ワーカーは難しい問題向け」という直感とは逆です。委譲が効いたのは、普段なら解ける定型寄りの仕事です。同じBrowseCompでも、難しい完全版では経済性が逆転しました。

節約になった状況2: 1つのコンテキストウィンドウに入らない仕事

単独モデルは、コンテキストウィンドウ1枚分ずつ順番に読み進めます。パスのたびに自分の状態を読み直す費用も払います。ワーカーは自分の担当分だけを、並列に、ワーカー単価で読みます。

どのウィンドウにも収まらない入力が用意されました。14個の公開Pythonパッケージ、2,160万トークンのコーパスに、130個の欠陥を仕込んだものです。この規模では、effortを下げても単独モデルは安くなりません。費用の大半がコーパスを読む分だからです。

Fable 5.1のリードにSonnet 5のワーカー25本を付けた構成は、Sonnet 5単独のベースラインを上回りました。Fable 5.1の high は最高精度を保ち、費用はこのコーディネーター構成の約2.2倍です。委譲は精度の大半を買い、すべては買いません。

読む量は逆に増えています。コーディネーター構成が読んだキャッシュ済みトークンは1エピソードで約5.6億で、単独モデルの約3.65億の1.5倍です。そのほとんどをSonnet 5のキャッシュ読み取り単価で処理するため、総額は半分で収まりました。

単一のコンテキストに収まる読み込み中心の仕事は、委譲ではなくモデル選択の問題です。読む費用だけで見れば、オーケストレーターが有利になるのは、どのコンテキストにも仕事が収まらないときだけです。

委譲が得にならない仕事

依存した一本の鎖の仕事や、1つのコンテキストに収まる仕事では、オーケストレーターは計画・引き継ぎ・統合の費用を余計に払います。単一モデルなら、それらは要りません。測定された該当ケースでは、いずれもコーディネーターのモデル単独の低effortが上回りました。

境界を決めるのは、ベンチマークではなく問題の難しさです。難しい完全版のBrowseCompでは、Fable 5単独がコーディネーター構成と同じ精度に、22〜30%低い費用で到達しています。外部の独立した報告も同じ傾向を示しています。

判断基準をまとめると、次のようになります。

• 仕事が一本の鎖で、依存関係が強い
• 1つのコンテキストに収まり、費用の裾が長くない
• 単一モデルの低effortで、すでに要求水準を満たしている

いずれかに当てはまるなら、オーケストレーターは作らない方向です。

Managed Agentsの仕様面でも、委譲の入れ子には制限があります。コーディネーターが委譲できるのは1段までで、自分のrosterを持つエージェントを参照すると、作成や更新のリクエストが検証エラーで失敗します。ワーカーがさらに下請けを呼んで安くする構成は取れません。

時間指示と経過時間の時計は、ワーカーに届かない

並列実行では、時間の指示と経過時間の時計で、実行時間を縮められる場合があります。DRACOでは、同じモデルのエージェントのチームに時間の指示と時計を渡すと、所要時間が33%減り、タスクあたりの費用が54%下がりました。スコアは1.5ポイント下がっています。ただし、チームの全員が指示と時計を持った実験です。

Managed Agentsでは、時計はコーディネーターにしか届きません。ワーカーは時計を見られません。コーディネーターだけが時計を持つチームは、測定されていません。低コストのワーカーに時計を持たせた場合も未測定です。コーディネーターの時計が最新になるのも、自分が受け取ったツール結果やメッセージの直後のターンだけです。

同じ節約がManaged Agentsで再現するとは言えないため、この数字を根拠に構成を決める材料にはなりません。

読み方にも癖があります。HLEと物理問題集では、リードが起動したヘルパーの中央値は0でした。少なくとも半数の実行はリードだけで動いており、この2つの結果は並列ヘルパーの効果というより、リード自身の振る舞いを映しています。並列ヘルパーが実際に動いたのはDRACOです。

単独エージェントなら、効果は別に測られています。物理問題集では時間も費用も34%減り、HLEでは時間が54%、費用が48%減りました(スコアは1.1ポイント低下)。各ターンの前に経過時間を送る手順があるのは、自分でループを回すMessages APIのエージェントです。

advisor戦略との選び分け

もう一つの戦略、advisorは制御の持ち方が逆です。安価なexecutorがループを回し、判断が要る場面だけ上位モデルに相談します。主ループを持つモデルと、費用が増える要因が違います。

問いは1つです。仕事が独立した部品に割れるか、それとも依存したステップの連なりで一つの答えに至るか。前者はorchestrator、後者はadvisorです。

advisorの節約が崩れる条件

advisorの節約は、相談の頻度に左右されます。executorがほとんど相談しなくなると、単独のexecutorを下回ることがあります。逆に、ほぼ毎回相談すると、上位モデル単独より高くつきます。

Chartographyでは、Opus 5.5(low)のexecutorにFable 5.1のadvisorを付けたところ、300問中1問しか相談しませんでした。スコアはOpus 5.5単独より7ポイント低い61.7で、費用はほぼ同じでした。コーディング系の内部ベンチマークでは、Opus 5.5の high にFable 5.1のadvisorを付けて90.1%、1試行$2.92です。Opus 5.5単独の high より1.7ポイント高いものの、費用は約2.1倍で、run間のばらつきの端にある差でした。

費用の中身も測られています。Opus 5をexecutorにしたコーディング系の構成では、助言で探索の行き止まりが減り、executorの費用がOpus 5単独(既定設定)より1試行あたり$1.26下がりました。相談そのものは$2.47かかるので、助言の費用の約半分を取り戻した計算です。Opus 5.5がexecutorだと、助言が節約したexecutor費用はほとんどありません。単独の high が$1.38なのに対し、executorは$1.36、相談は$1.55でした。同じ内部ベンチマークでOpus 5.5を xhigh で単独実行すると、91.1%で1試行$4.11です。advisorの上積みは、effortを上げた場合と同じ線上にあります。

ほぼ毎回相談する例も測られています。Chartographyで、Opus 5をexecutorにした別の構成は、ほぼすべての問題で相談しました。Fable 5.1単独の medium とスコアは誤差の範囲で並び(65.0対67.5)、1問あたりの費用は約1.8倍でした。

advisorの仕組みと設定はManaged Agentsのadvisor、出力を抑える具体策はClaude API advisorのmax_tokensに別記事があります。Managed Agentsのadvisorはrosterに {"type": "advisor", "model": "..."} を1件加える形で、最大1件です。主スレッドだけが相談でき、同時スレッド数の上限にも数えられません。相談は、advisorに指定したモデルの単価で課金されます。advisorに指定できるのは、agent自身のモデルより能力が同じか高いモデルで、条件を外れた組み合わせは保存時に400で拒否されます。

どちらを選ぶか

入口として勧められているのは、何も作る前にeffortを振ることです。

測定された複数モデルの構成は、同じモデルの低effortと、一つ下のモデルの単独実行に対して判定されています。あなたの仕事でも、同じ比較をしてから構成を決める順序です。

判断の早見表

コストの上限管理は戦略と別の層でも打てます。セッション単位の予算はManaged Agentsのセッション予算で扱っています。予算はセッション内の全スレッドで共有する1つの上限で、各スレッドの費用はそのスレッドが使ったモデルの単価で計算されます。ワーカーを安いモデルにした分は、予算の減り方にも反映されます。Managed Agents自体の位置づけはManaged Agentsの使い分けにまとまっています。

まとめ

オーケストレーターは時間を買う仕組みで、コストが下がるのは、易しい仕事の高コストの裾を切るときと、1ウィンドウに収まらない仕事を分けるときの2状況でした。単一モデルで足りる仕事は、同じモデルの低effortが、測定した範囲では毎回より安く済みました。

構成に進む前の順序は決まっています。effortを振り、強いモデルの低effortを基準に置き、独立に割れるならorchestrator、割れないならadvisorを試します。どちらも実測に沿って選ぶ戦略です。