これまでは安いか賢いか、二択しかなかった

多段階を要するagentタスク（コード作成、コンピュータ操作、複数ステップの調査）では、大半のターンは実は機械的な作業で、本当にトップレベルの知性を必要とするのはごく少数の重要なノードだけだ。だがこれまでモデルを呼び出す方法は2通りしかなく、どちらも帯に短し襷に長しだった。

協働モードは品質とコストの中間地帯を踏んでいる。大多数のトークンは安価な実行モデルが低料金で生成し、本当に頭を使う必要のある重要なノードでだけ、数百トークンをかけてトップモデルにアイデアを求める。

作業を半分進めたところで、顧問に電話をかける

顧問ツールは普通のツールと同じくtools配列にぶら下がっており、いつ呼び出すかは実行モデル自身が判断する。1回の完全な呼び出しは次の4ステップで進む。

最初のステップで実行モデルが吐き出すのはserver_tool_useブロックで、名前はadvisor、中のinputは常に空だ。実行モデルは「今問うべきタイミングだ」と判断するだけで、顧問に与える具体的なコンテキストはサーバー側が自動で補完する。2つ目のステップでは、サーバーが自分の側で顧問モデルを単独で1回実行する。顧問はAnthropicが用意した専用のシステムプロンプトを使い、実行モデルの完全な会話記録を見る。あなたのシステムプロンプト、ツール定義、これまでの全ターンとツール結果、そして実行モデルがこのターンでこれまでに書き出した文章も含まれる。

もし顧問がまだ答え終わっていなければ：中断からの再開（pause_turn）

時には顧問の呼び出しがまだ懸かったままこのリクエストが先に終わることがある。レスポンスにはstop_reason: "pause_turn"が付き、呼び出しを発行したserver_tool_useブロックだけがあって、対応する結果はまだない。この場合、このassistantメッセージをそのままmessagesに追記して（server_tool_useブロックは保持したまま）、同じ顧問ツールとbeta headerを付けて再度リクエストを送ればよい。新しいユーザーメッセージを加える必要はなく、tool_resultブロックを補う必要もない。

誰が誰の顧問になれるかには決まりがある

トップレベルのmodelフィールドが実行モデル、ツール定義の中のmodelフィールドが顧問モデルで、両者は正当な組み合わせを成立させなければならない。ルールは1つの明確な線だけだ。顧問はClaude Sonnet 4.6以上でなければならず、かつ能力は少なくとも実行モデルと同等でなければならない。組み合わせを間違えるとAPIは即座に400エラーを返し、この組み合わせは対応していないと名指しされる。

点線枠＝能力が同格で互いに顧問になれる（Opus 4.7とOpus 4.8など）。ハイライト行のSonnet 5は分かりやすい例で、Opus 4.7かOpus 4.8にしか組めず、Opus 4.6すら対象外だ。

この「顧問の能力は実行モデル以上」という厳格なルールの背景にある理屈はとてもシンプルだ。顧問が実行モデルより弱ければ、本当に価値のあるアドバイスを出せず、その呼び出しは無駄になってしまう。だから公式はペアリング関係を1枚の互換表で固定し、弱い顧問を強い実行モデルに組み合わせる構成はそもそも提出できないようにしている。

積極的に顧問を頼らないモデルもいる、公式は専用の「リマインド」を用意した

実行モデルの中には最初のターンで自発的に顧問を尋ねないものがあり、特にClaude Haiku 4.5のような軽量モデルに顕著だ。公式のやり方はこうだ。もし1ターン目に顧問を呼び出さなければ、2ターン目の前に別のユーザーメッセージを立てて短いリマインド（nudge）を差し込む。ただし、このリマインドを挿入するタイミングの早い遅いは、結果を大きく左右する。

公式が示す使い方は具体的だ。まず自分の実行モデルがリマインドなしで通常何ターン目に初めて顧問を呼び出すか（これをNターン目とする）を測定し、NUDGE_TURNをNより大きく設定する。ワークロードにシンプルなタスクと複雑なタスクの両方が混在する場合は、NUDGE_TURNを3に引き上げて、2ターンで完了するようなシンプルなタスクを先に終わらせ、必要のない相談にリマインドで無理に押し込まれないようにできる。

この一手間で増えるお金は、請求書上どう計算されるか

顧問の呼び出しは独立したサブ推論として、顧問モデル自身の料金で決済され、実行モデルのusage総数に組み込まれることはない。どの部分にいくらかかったかを分解して見たいなら、usage.iterationsという配列を見る必要がある。

顧問は毎回典型的には400〜700個のテキストトークンしか出力しない。破棄される前に使った思考分を合わせても、合計は約1400〜1800トークンだ。コスト削減の鍵はまさにここにある。顧問はあなたの最終的な大量の出力を生成する役ではなく、その部分はより低い料金の実行モデルが担当する。

他にも実行モデルにのみ適用され、顧問に自動的に及ばない細部がいくつかある。トップレベルのmax_tokensは実行の出力だけを制約し、顧問のサブ推論には及ばない（単独で制限したい場合はツール定義の中で別途max_tokensを設定する必要がある）。顧問のトークンは実行モデル側のtask budgetを消費しない。Priority Tier（優先度コミット）もそれぞれ別々に計算され、自分の組織が顧問モデル側にもコミットを持っていない限り、顧問の呼び出しは優先度ルートを通らない。

もう一段節約できる：顧問側でもキャッシュを開ける

キャッシュには2層あり、それぞれ独立している。実行側のadvisor_tool_resultブロックは普通のコンテンツブロックと同様にキャッシュ可能で、この層は特に気にする必要はない。本当に工夫が要るのは顧問側自身のキャッシュだ。

顧問モデルが毎回見る会話記録は、前回の内容に新しい部分を1段追加しただけのものなので、プレフィックスは安定している。ツール定義でcaching（{"type":"ephemeral","ttl":"5m"}のような形）を有効にすると、呼び出しのたびに1つキャッシュを書き込み、次回はその地点まで読み込んで新規追加分だけの料金を払う。2回目以降のadvisor_messageイテレーションでcache_read_input_tokensが非ゼロになるのが見て取れる。

公式はさらに2つの一貫性の落とし穴を注意喚起している。1つ目はcachingのスイッチは1度設定したら全過程通して維持すべきで、途中で切り替えるとキャッシュが直接無効になってしまうこと。2つ目はclear_thinkingの設定が不適切（keep値が"all"でない）だと、顧問が毎ターン見る引用記録に位置ずれが起き、同様に顧問側キャッシュが中断してしまうこと。ただしこれはコストが悪化するだけで、アドバイスの質には影響しない。

どんな作業に向いていて、どんな作業では手を出さないべきか

公式は「When to use it」で境界線をはっきり引いている。この協働方式は「大半のターンは節約でき、少数のターンだけは強くなければならない」混合ワークロードでのみ割に合う。

公式もあらかじめ念を押している。結果はタスクによって異なるため、自分のワークロードで評価してほしい、と。現時点でこのツールはClaude APIとAWS上のClaude Platformでbeta版が提供されており、Amazon Bedrock、Google Cloud、Microsoft Foundryには当面対応せず、ゼロデータ保持（ZDR）の条件を満たしている。

Advisorツールは「作業する」と「アイデアを出す」を切り分けた。実行モデルが終始答えを書き、重要な決断にぶつかった時だけ、一時的により強力な顧問モデルに数百字のアイデアを求め、受け取ったら戻って続きを書く。コードに落とすと、トップレベルを安いモデルに替え、顧問をもう1つぶら下げるだけだ。

ではこの「一時的に一言尋ねる」は具体的にどう起きるのか?

具体的なシーンで見てみよう。小互が安い実行モデルに並行処理コードを書かせていて、「プログラム終了時にどう優雅にシャットダウンするか」という重要な決断で詰まった。無理押しはせず、途中で顧問を1回呼んだ。ことの全体が同一リクエスト内で4ステップを歩む。

誰が誰の顧問になれるかには厳格なルールがある。顧問は実行モデルと同等かそれ以上でなければならず、より弱いものを組み合わせるとAPIは即座に拒否する。弱い顧問は本当に価値のあるアドバイスを出せないからだ。

こうした協働で、どこがどれだけお得になるのか?公式は2つの実測値を示している。