Claude APIに「途中でOpusに相談する」モードが来た — Sonnetで回しながら判断だけ格上げする仕組み

Claude APIに変わった形のツールが1つ増えた。名前は「advisor tool」。ざっくり言うと、安いモデルで本文を書きつつ、要所だけ上位モデルに相談できる機能だ。2026年4月9日にpublic betaでリリースされ、ベータヘッダー advisor-tool-2026-03-01 を付けると使える。

最初に公式ドキュメントを読んだときの率直な感想を言うと、「ああ、これは人間がチームで仕事するときの構造をAPIに持ち込んだやつだな」と思った。実務で言えば、駆け出しのエンジニアが9割の作業を進めつつ、詰まった瞬間だけシニアに相談する、あの流れ。それを1回のAPIリクエストの中で閉じ込めてしまう発想が、やけに実直で好ましい。

何が新しいのか

従来、Claude APIでエージェント的な処理を組もうとすると、モデル選びは二択だった。Sonnetで安く回すか、Opusで賢く回すか。Haikuまで含めれば三択だが、いずれにせよ「1つのタスクを1つのモデルに任せる」のが大前提だった。

advisor toolはこの前提を崩す。

• Executor（実行役）: ユーザーの会話に直接応えるモデル。例えばSonnet 4.6。ここで最終出力を生成する。
• Advisor（相談役）: Executorが必要と判断したタイミングで呼び出す上位モデル。通常はOpus 4.6。会話全体を読んだ上で、400〜700トークン程度のプランや軌道修正を返してくる。

この構造のキモは、Advisorが出すのは最終出力ではなくアドバイスだけという点だ。Executorはそれを受け取って、自分の言葉で続きを書き進める。結果として、生成トークンの大半はSonnet料金のまま、判断の質だけがOpus相当に引き上がる。

動きを追ってみる

コードで見るとむしろシンプルだ。ツール定義に advisor_20260301 を1つ追加するだけでいい。

import anthropic

client = anthropic.Anthropic()

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-6",
        }
    ],
    messages=[
        {"role": "user", "content": "Goで並列ワーカープールを書いて。graceful shutdown込みで。"}
    ],
)

ExecutorがAdvisorを呼ぶ判断をすると、レスポンスには server_tool_use ブロック（呼び出しのマーカー）と、続けて advisor_tool_result ブロック（返ってきたアドバイス）が並ぶ。ここで面白いのは、Advisorに何を渡すかを開発者側が指定する必要がないことだ。サーバー側が自動的に会話全体を転送する。システムプロンプト、過去のツール呼び出し、すべての結果が勝手にAdvisorに渡される。

Advisor側は逆に、ツール呼び出しもcontext管理もしない。純粋に「読んで、助言を返す」だけ。thinking blockは破棄され、テキスト本体だけがExecutorに届く。

料金の読み解き方

課金はわりと正直な設計になっている。AdvisorのトークンはExecutorのトークンとは別枠で、Advisorのモデル（通常Opus）のレートで請求される。トップレベルの usage にはExecutor分しか乗らず、全体を把握したければ usage.iterations を舐めることになる。

重要なのは、出力トークンの圧倒的多数はExecutorが吐くという点だ。Advisorは1回の呼び出しで400〜700テキストトークン、thinking込みで1,400〜1,800トークン程度。一方で最終出力（関数の実装、リファクタのdiff、長文レポートなど）は全部Executorが書く。この非対称性こそが「Opus級の判断 × Sonnet級のコスト」という合成を成立させている。

公式のガイドにも直接書かれているが、ちゃんとしたコストメリットが出るのは長いエージェントループだ。短いQ&Aや、1往復で終わる用途にはほぼ意味がない。相談する内容が存在しないからだ。

どのExecutorとペアにできるか

モデルの組み合わせには制約がある。Advisorは「少なくともExecutor以上に賢い」ペアでなければ受け付けてくれない。

Executor	Advisor
Claude Haiku 4.5	Claude Opus 4.6
Claude Sonnet 4.6	Claude Opus 4.6
Claude Opus 4.6	Claude Opus 4.6

いまのところAdvisor側は実質Opus 4.6一択だ。無効な組み合わせを投げると 400 invalid_request_error が返る。

個人的にはHaiku × Opusの組み合わせが一番面白いと思っている。これまでHaikuは「安いけど判断は頼れない」ポジションで、本番のエージェント制御に置きづらかった。Advisorで補強できるなら、UIの裏側で軽く動かすHaikuエージェントの射程がぐっと広がる。

向いている使い所

Anthropicが想定しているのは、いわゆるlong-horizon agentic workloadだ。具体的には:

• コーディングエージェント — 最初に方針を決めて、後はファイルを読み書きしながら進める種類の作業。最初のファイル探索が終わった後の「どう攻めるか」の1手目と、「完成したつもりの瞬間」の確認、この2回にAdvisorを呼ぶのが公式の推奨パターン。
• Computer use — 画面を見ながら何度もクリックする自動化で、方針がブレやすい瞬間だけOpusに聞きにいく。
• マルチステップのリサーチパイプライン — 情報を集めてから統合する工程で、集めた情報の読み解きだけ上位モデルに委ねる。

逆に、単発Q&A、モデル選択をユーザー側に委ねているプロダクト（pass-through）、そして毎ターンAdvisorの全能力が必要な重い仕事には向かない。最後のやつは素直にExecutorをOpusにした方が早い。

試すときに引っかかりそうな点

触る前に知っておくと楽な落とし穴がいくつかある。

1つめ。ストリーミングはAdvisor呼び出し中だけ止まる。ExecutorのストリームはAdvisorが考えている間は無言になる（SSEのpingだけ流れる）。ユーザー体験を設計するときは、この「沈黙時間」の演出を考えておいた方がいい。

2つめ。会話レベルの呼び出し上限は自前で管理する必要がある。リクエスト単位の max_uses はあるが、「1つの会話で合計○回まで」というキャップはAPI側にない。上限を設けたいならクライアント側でカウントして、届いたら tools からadvisor toolを外し、さらに過去メッセージ内の advisor_tool_result ブロックも全部剥がしてからリクエストを送らないと400が返る。ここは地味にハマりポイント。

3つめ。Advisor側のpromptキャッシュは3回目の呼び出しから黒字化する。ツール定義に caching: {"type": "ephemeral", "ttl": "5m"} を付けるとAdvisorのトランスクリプトがキャッシュされるが、最初の2回は書き込みコストの方が高い。短いタスクで雑にオンにすると逆にコストが上がるので、長いエージェントループ以外は切っておくのが安全だ。

4つめ。公式ドキュメントに明記されているが、clear_thinking のデフォルト挙動がAdvisorキャッシュを壊す。extended thinkingを使っていて特に設定していないと、keep: {type: "thinking_turns", value: 1} が効いてしまい、Advisor側のキャッシュミスが頻発する。キャッシュ恩恵を狙うなら keep: "all" を明示する必要がある。

何が実現できそうか

この機能を触ると、いくつか「それもできるのか」と思わせる応用がすぐ浮かぶ。

ローカルCLIエージェントの知能底上げ。 Claude CodeやOpenCodeのようなターミナルベースのエージェントは、デフォルトのコストと応答速度のバランスでSonnetを回していることが多い。そこにadvisor toolを組み込めば、「探索フェーズ → Advisor相談 → 実装フェーズ → 最終確認Advisor相談 → PR作成」という流れを1コマンド内で閉じられる。ユーザーから見れば「なぜかSonnetのままなのに意思決定が賢くなった」という体験になる。

Haikuで組むユーザー向けエージェントのバックボーン強化。 たとえばサポートbotやフォーム入力支援のような、リアルタイム性が要る軽量エージェント。普段はHaikuでサクサク返すが、ユーザーの質問がこじれ始めた瞬間だけAdvisorにOpusを呼んで戦略転換する、みたいな構造が現実的に組める。応答の9割は今と同じ速さで、1割だけ「あ、急に賢くなった」というUXになり得る。

コードレビューの2段構え。 CIに組み込むコードレビュー bot で、Sonnetが差分を読んで指摘を並べ、要所で「この変更の本当のリスクは何か」をOpus advisorに聞く。Opusの出力そのものをユーザーに見せる必要はなく、Sonnetが咀嚼して返してくれるので、体裁は普段のレビューコメントのまま質だけ上がる。

どれも理屈としては今までもManaged Agentsやクライアント側のオーケストレーションで組める話ではあったが、1リクエスト内で完結するのが大きい。接続管理、再試行、stateの引き回しが全部Anthropic側の責任になる。開発者が書くコードが一段薄くなる。

個人的な評価

Anthropicの最近のAPI周りの機能追加は、「エージェントを組む人がいつもコードで書いている手続きを、APIの内側に吸い込む」方向で一貫している。Managed Agentsがオーケストレーションを吸い込んだのと同じ文脈で、advisor toolはプランナーとワーカーを分けるパターンを吸い込んだ、と言える。

正直に言えば、これをすでにクライアント側で自前実装している会社は多い。Sonnetで回しつつ、危なくなったらOpusに別APIで問い合わせて、その結果を次のプロンプトに差し込む、というやつ。advisor toolはそれを置き換える最短経路だ。ただし、単純に置き換えるとExecutorのストリームが止まる瞬間が発生するので、フロントエンドの見せ方は工夫が要る。

もう1つ気になるのは、Advisor側のモデル選択肢が実質Opus 4.6しかないこと。将来的に「Sonnet executor × もう少し上位のSonnet advisor」のような細かい刻みができれば、中〜小規模案件でも使いやすくなるはずだ。今のペアリングはちょっとゴツい。

いま試すべき人は、すでにSonnet/Haikuでエージェント系のパイプラインを動かしていて、肝心な一手で精度が足りないと感じている開発者だろう。ドキュメントに書かれたシステムプロンプトのテンプレ（Advisorをどう扱うかの指示、出力を100語以内に絞らせる1行など）をコピペして当てはめるだけで、体感がかなり変わるはずだ。

公式ドキュメントはplatform.claude.comで公開されている。まずはcurl 1回で済むQuick startを叩いて、usage.iterations を眺めてみるのをおすすめしたい。ExecutorとAdvisorのトークン配分を見れば、自分の用途で元が取れるかの肌感がすぐ掴める。