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種類を複数コピー呼び出すこともできます。

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

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

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

BrowseCompの易しい部分(単独モデルが安定して解く10問)での測定です。実行回数は委譲が50回、単独が70回です。Fable 5をコーディネーター、Sonnet 5をワーカー1本にした構成は、Fable 5単独の平均のおよそ半分の費用でした。90パーセンタイルでは約3分の1で、$12対$33です。単独の最も高い実行は$84で、しかも誤答でした。

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

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

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

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

Fable 5.1のリードにSonnet 5のワーカー25本を付けた構成は、費用が47〜55%低く済みました。精度は単独より10〜12ポイント低く、所要時間は約2.3時間です。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で、すでに要求水準を満たしている

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

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

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

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

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

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間のばらつきの端にある差でした。

advisorの仕組みと設定はManaged Agentsのadvisor、出力を抑える具体策はClaude API advisorのmax_tokensに別記事があります。Managed Agentsのadvisorはrosterに {"type": "advisor", "model": "..."} を1件加える形で、最大1件です。主スレッドだけが相談でき、同時スレッド数の上限にも数えられません。

どちらを選ぶか

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

1. 現在のモデルで、effortを下げた場合を測る。最も安い実験で、多くの仕事はここで終わる
2. 差が出たら、強いモデルを低effortで単独実行した費用を測る。advisor構成が超えるべき基準になる

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

判断の早見表

コストの上限管理は戦略と別の層でも打てます。セッション単位の予算はManaged Agentsのセッション予算で扱っています。Managed Agents自体の位置づけはManaged Agentsの使い分けにまとまっています。

まとめ

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

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