顧問モデルと実行モデルはどう分業するか

顧問モードはチームが独自に編み出した我流のやり方ではなく、Anthropic APIに正式に実装されたbeta機能、advisor toolである。実行モデルClaude Sonnet 5はタスクを受け取ると自力で進め、判断に迷う局面に差し掛かったときだけ顧問モデルClaude Fable 5に一度相談し、判断を得てからタスクを完了させる。

これは自前のコードで手動で2回リクエストを叩いてつなぎ合わせるものではない。toolsの中にadvisor_20260301タイプのツールを1つ宣言し、顧問に使うモデルを指定すれば、あとはすべてAnthropicのサーバー側で処理される。実行モデルは通常のツール呼び出しと同じ感覚でいつ相談するかを自分で決め、サーバー側で顧問モデルの推論がもう一度走る。顧問が目にするのは、実行モデルがそこまでに積み上げた対話の全文（システムプロンプト、ツール結果、書きかけの内容を含む）で、判断を返すとそのまま実行モデルの対話に差し戻され、実行モデルはそのアドバイスを踏まえて続きを書く。すべて同一のAPIリクエスト内で完結する：

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[{"role": "user", "content": "Build a concurrent worker pool in Go with graceful shutdown."}],
)

モデルの組み合わせには厳格なルールがある：顧問は少なくとも実行モデルと同等以上の能力を持たなければならず、逆はできない。ドキュメントが挙げる典型的な組み方は2つ。すでにSonnetで複雑なタスクをこなしているなら、Fable 5/Opusを顧問にして品質を底上げする。すでにHaikuを使っていてもう少し賢くしたいなら、Opusを顧問にすることで、実行モデル自体を大型モデルに直接置き換えるよりコストを抑えられる。

元投稿の添付画像：Sonnet 5実行＋Fable 5顧問がSWE-bench Proで示した成績とコストの比較。出典：X / @ClaudeDevs

なぜ安く済むのか：顧問の出力は通常400〜700テキストトークン程度（思考過程を含めても1400〜1800トークン）しかなく、重要な一言のアドバイスを返すだけで、最終的な答えを最初から最後まで書く責任を負わない。会計上、顧問の呼び出しは顧問モデルの単価でusage.iterations[]に個別に計上され、実行モデルの合計には含まれない。元投稿の「Fable 5は各タスクにつきごくまれにしか呼ばれない（約1回）」という記述は、まさにこの節約ロジックが実際に効いていることを示している。

公式が示すベストプラクティスは、書き始める前に顧問を呼ぶべきで、書き終わってから振り返って質問するのではない、というものだ。Haiku実行モデルが「聞くべきときに聞かない」問題に対しては、Anthropicはシステムプロンプトのテンプレート（ファイルを書くとき、判断を下すとき、行き詰まったときに顧問へ相談するようモデルに促す）を用意しており、内部のコーディングベンチマークでHaikuの通過率を約7.5ポイント引き上げた。これは実測に裏付けられた具体的な数値であり、漠然とした助言ではない。

もう一つの分業：相談せず、直接タスクを割り振る

顧問モードではFable 5は一切作業に触れず、聞かれたときだけ一言答える。オーケストレーションモードは違う。Fable 5が最初から「オーケストレーター」として、タスクをいくつかに分割し、複数のSonnet 5「ワーカー」サブエージェントに割り振って並行して作業させる。自分自身は計画と結果の取りまとめだけを担当し、手を動かさない。

元投稿の添付画像：Fable 5オーケストレーター＋Sonnet 5ワーカーサブエージェントの分業模式図。出典：X / @ClaudeDevs

このオーケストレーション機能にも正式な公式サポートがある。Claude Managed Agentsのマルチエージェントセッション機能だ。「オーケストレーター」エージェントを定義する際、multiagentフィールドで調整可能なメンバー名簿（最大20エージェント、下方向に1階層のみ、入れ子は不可）を宣言する：

coordinator = client.beta.agents.create(
    name="coordinator",
    model="claude-opus-4-8",
    tools=[{"type": "agent_toolset_20260401"}],
    multiagent={
        "type": "coordinator",
        "agents": [{"type": "agent", "id": research_agent.id}],
    },
)
session = client.beta.sessions.create(agent=coordinator.id, environment_id=environment.id)

各ワーカーサブエージェントはそれぞれ独立した「セッションスレッド」上で動き、独自のモデル・システムプロンプト・ツール構成を持ち、互いに干渉しない（最大25の並行スレッドをサポート）。公式ドキュメントは、タスクを割り振るのに適した3つのシナリオをまとめている：並行分解（複数の情報源を同時に調べる、複数のファイルを分析するなど、オーケストレーターが最後に取りまとめる）、専門分野別の割り振り（セキュリティレビューやドキュメント作成といった作業を、1つのエージェントに何でもやらせるのではなく対応する専門エージェントに任せる）、能力の格上げ（特に難しい一部のサブタスクだけを一時的により強力なエージェントに格上げして処理させる）。

Anthropic公式のcookbookには具体的に動かせる例が1つある。「コーディネーターパターン」と呼ばれるもので（CMA_plan_big_execute_small.ipynb）、タスクは国立公園10箇所・合計20件の事実が公式情報源と一致するかを照合するというものだ。トップクラスのモデルが単独ですべてのウェブページを読んで照合する場合と、トップクラスのモデルには問題を分解する仕事だけをさせ、ウェブページを読む地道な作業を複数の安価なワーカーサブエージェントに並行して割り振る場合とで、効果を比較している：

公式が実測した結果：分業チームは単独作業に比べ約2.5倍安く、約3倍速かった。ただしnotebookは、いずれも実測から得られた4つの落とし穴の経験を正直に記しており、建前だけの話ではない：

notebookはこのやり方を使うべきでないケースについても示している：問題自体の情報量が小さく、調べることがあまりなければ、無理にオーケストレーター＋ワーカーに分割しても、オーケストレーターの往復コストを1回余分に払うだけになる。オーケストレーターが結局タスクを委任せず自分の記憶だけで答えを出したなら、トップクラスモデルの料金を1回無駄にしたことになる。タスクがトップクラスモデル自身に原文の微妙なニュアンスを読み取らせる必要がある場合(単純な事実照合ではない場合)、安価なワーカーサブエージェントは要約の際に重要な情報を取りこぼしかねない。

元投稿の添付画像：Fable 5オーケストレーター＋Sonnet 5ワーカーがBrowseCompで示した成績とコストの比較。出典：X / @ClaudeDevs

なぜ繰り返しの呼び出しで毎回全額払わずに済むのか

元投稿にある「各サブエージェントはそれぞれ自分のキャッシュを保持する」という一文の背後には、2層の具体的な仕組みがある。顧問モードとオーケストレーションモードでそれぞれ別のセットになっている。

オーケストレーションモード側：各ワーカーサブエージェントは独立したセッションスレッド上で動いており、スレッド自体は永続的だ。オーケストレーターがしばらくしてから同じワーカーに再び質問しに戻っても、そのワーカーは以前に何をしたか、何を話したかを覚えているので、会話を続けるために履歴全体を喂い直す必要はない。

顧問モード側にはより具体的なスイッチがある：advisorツールは独立したprompt cachingをサポートしている。顧問が同じ会話の中で何度も相談を受ける場合、見えている会話ログの先頭部分は安定している（N回目の相談＝N-1回目の内容の後ろに一段追加されたもの）ためだ。キャッシュを有効にすると、重複する部分だけがキャッシュヒット価格で課金される。公式が示す経験則は、1つの会話の中で顧問が呼ばれるのが2回未満ならキャッシュを有効にしてもむしろ損（キャッシュの書き込みコストが節約分を上回る）、だいたい3回目の呼び出しから元が取れ始めるというもの。長い会話、複数回の相談が発生する場面でこそ有効にする価値がある。

顧問モードとオーケストレーションモード、どの条件で選ぶか

両モードとも「より強力なモデルの作業量を減らし、体力仕事を安価なモデルに任せる」という点では同じだが、違いは強力なモデルが「そもそも作業そのものに触れるかどうか」にある。

試してみたいなら、どこから始めるか

両モードとも最小実装はわずか3ステップで済む。自分のシーンに合う方を先に試すとよい。

@ClaudeDevsはClaudeの開発元Anthropicが開発者向けに運用する公式アカウントで、2026年7月7日に方法を1つ示した：高いモデルはアドバイスを出すべき局面でだけ動き、安いClaude Sonnet 5が大量のコンテンツを書き出す作業を担う。

公式は具体的な組み方を2つ示している。違いは高いモデルがそもそも作業そのものに触れるかどうかにある。1枚の図でわかる。

どちらの組み方も高いモデルの作業量を減らす。顧問モード：安いモデルが自力で進め、重要な判断に差し掛かったときだけ高いモデルに一言相談する。オーケストレーションモード：高いモデルが最初に作業をいくつかに分割し、複数の安いモデルに同時に割り振り、自分は問題の分解と取りまとめだけを担当する。

公式は2つの公開テストで実際に金額を測定した。「一貫して最強モデルだけを使う」場合の費用を100元とし、分業後にそれぞれいくらかかり、成績がどれだけ下がるかを見てみる：

以上の数値はすべてAnthropic公式の自己測定によるもので、独立した第三者による再現はない。