Anthropic が Advisor ツールを発表：安いモデルが行き詰まったら、もっと賢いモデルにワンタップで電話相談

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

多段階を要する agent タスク（コーディング、PC操作、複数ステップの調査）では、大部分のターンは実は機械的な操作で、本当に最高レベルの知性が必要なのはごく一部の重要な局面だけだ。しかし従来モデルを呼ぶ方法は2通りしかなく、どちらも帯に短し襷に長しだった。

協業モードは品質とコストの中間地点を突いている：ほとんどのトークンは安い実行モデルが低料率で生成し、本当に頭を使う必要のある数回の重要な局面だけ、数百トークンをかけて最高峰モデルに知恵を借りる。

作業を途中まで進めたら、アドバイザーに電話をかける

アドバイザーツールは普通のツールと同じく tools 配列に掛かっており、いつ呼び出すかは実行モデル自身が判断する。一連の完全な呼び出しは次の4ステップで進む。

1ステップ目では、実行モデルが吐き出すのは 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 フィールドがアドバイザーモデルで、両者は正当な組み合わせを構成しなければならない。ルールはたった一つの明確な線だけだ：アドバイザーは 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 という配列を見る必要がある。

アドバイザーは1回あたり典型的に 400 から 700 個のテキストトークンを出力し、破棄される前に消費した思考分を含めると合計で約 1400 から 1800 トークンになる。コスト削減の鍵はここにある。アドバイザーは最終的な出力の大部分を生成する役割を担わず、その部分は実行モデルがより低い料率で完成させる。

さらに、実行モデルにのみ作用し、アドバイザーには自動的に及ばない細部がいくつかある。トップレベルの max_tokens は実行の出力のみを制約し、アドバイザーのサブ推論には及ばない（単独で制限したい場合はツール定義の中で別途 max_tokens を設定する必要がある）。アドバイザーのトークンは実行モデル側の task budget も消費しない。Priority Tier（優先度契約）もそれぞれ独立して計算され、あなたの組織がアドバイザーモデルにも契約を結んでいない限り、アドバイザーの呼び出しは優先処理を通らない。

もう一手節約できる：アドバイザー側でもキャッシュを開ける

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

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

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

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

公式は「When to use it」の中で境界線をはっきり引いている。この協業方式が割に合うのは「大部分のターンは節約できるが、少数のターンはどうしても強さが必要」という混合ワークロードだけだ。

公式も先に釘を刺している。結果はタスクによって異なるので、自分のワークロードで評価してほしいとのことだ。現時点でこのツールは Claude API と AWS 上の Claude Platform で beta 版として提供されており、Amazon Bedrock、Google Cloud、Microsoft Foundry にはまだ対応しておらず、ゼロデータ保持（ZDR）の条件に適合している。