Claude Advisor Strategyとは？Sonnet+Opusで性能UP＆コスト11.9%削減する仕組みを解説

2026/04/10

コードを書かないAIエンジニア@もるふぉです。

ソフトウェアエンジニアとして10年以上開発をしてきましたが、今はClaude Codeを使って「コードを書かない開発」を実践しています。

この記事では、2026年4月に登場したClaude Advisor Strategy（アドバイザー戦略）を解説します。

あなたも、こんな葛藤ありませんか？

「Opusは確かに賢い。でも全部Opusにすると月の請求額が怖くなる。Sonnetにすると複雑なアーキテクチャ判断でたまにこける。かといって両方使い分けるのも面倒くさい」——エージェント開発をやっていると、この「知能とコスト」のジレンマ、地味にしんどいんですよね。

2026年4月9日、Anthropicがそのジレンマをそのまま解決する機能を出してきました。

Claude PlatformへのAdvisor Strategy（アドバイザー戦略）の追加です。

一言でまとめると、Opusの頭脳をSonnetやHaikuのコストで使えるようにする仕組みです。

「そんな都合のいい話が？」と思いますよね。でも数値がはっきり出ているんです。

SWE-bench Multilingualでは、Sonnet+Opusアドバイザーの組み合わせが単独Sonnetより2.7パーセントポイント高いスコアを出しつつ、コストは11.9%削減という結果が出ています。

性能が上がってコストが下がる。普通は相反する2つの指標が同時に改善しているんです。

この記事では、Advisor Toolの仕組みからAPI実装、コスト制御、使いどころの判断基準まで、エンジニアが知りたいポイントを一通り解説していきます。

Claude Advisor Strategyとは？発表の背景

Opusの知能をもっと安く使いたいという課題

エージェントワークロードを触っている方なら肌感としてわかると思うんですが、実際にOpus級の判断が必要な場面ってタスク全体の中の一部なんですよね。

大半の処理は「Sonnetで十分」です。

でも現実は——Sonnet単体だと複雑なアーキテクチャ判断やエッジケースの処理で品質が落ちる場面がある。かといって全部Opusにすると予算が厳しい。

この「知能とコストのジレンマ」を解消するのがAdvisor Strategyです。

つまり、「Sonnetを走らせながら、本当に難しい判断ポイントだけOpusに聞く」という構造です。

学術的背景 -- Dimakisらの「Advisor Models」論文

面白いのは、これに学術的な背景があるところなんですよ。

How to Train Your Advisor: Steering Black-Box LLMs with Advisor Models

Frontier language models are deployed as black-box services, where model weights cannot be modified and customization is limited to prompting. We introduce Advisor Models, a method to train small open-weight models to generate dynamic, per-instance natural language advice that improves the capabilities of black-box frontier models. Advisor Models improve GPT-5's performance on RuleArena (Taxes) by 71%, reduce Gemini 3 Pro's steps taken in SWE agent tasks by 24.6%, and outperform static prompt optimizers in personalizing GPT-5 to user preferences (85-100% vs. 40-60%). We also find that advisors are transferable: an advisor trained with a low-cost student model still transfers improvements to a frontier model. Moreover, Advisor Models are robust: we observe no degradation on other benchmarks than the pipeline is trained on. Our method shows how to perform parametric optimization for black-box frontier models in a practical and cost-effective way.

arxiv.org

この論文では、小さなオープンウェイトモデルを「アドバイザー」として使い、プロプライエタリなフロンティアモデルに自然言語ガイダンスを与える手法が提案されています。

この論文では、GPT-5のRuleArenaスコアが71%向上、Gemini 3 ProのSWEエージェントタスクのステップが24.6%削減されたと報告されています。

AnthropicのAdvisor Strategyはこの概念を逆方向に応用しています。

より大きなモデル（Opus）をアドバイザーにして、より小さなモデル（Sonnet/Haiku）の判断を引き上げるというアプローチです。

研究ベースで裏付けがある機能なのは、個人的には信頼感がありますね。

では次からいよいよ具体的な仕組みに入ります。

Advisor Toolの仕組み -- ExecutorとAdvisorの役割分担

エグゼキューターが判断に迷ったとき何が起きるか

構造としては非常にシンプルで、いわばシニアエンジニアと若手エンジニアのペアプログラミングのような関係です。

エグゼキューター（Sonnet/Haiku）: 実際にタスクを実行するモデル
アドバイザー（Opus）: 難しい判断に直面したときに相談されるモデル

若手（Sonnet）が通常の作業はテキパキ進めて、「これちょっと設計の判断が難しいな」という場面でシニア（Opus）にさっと相談する。シニアは全体のコンテキストを把握した上でアドバイスを出し、若手が方針に沿って作業を続ける。そういう動きです。

エグゼキューターは通常通り処理を進め、複雑な判断が必要な場面に遭遇すると自動的にアドバイザーに相談します。

アドバイザーは会話の全コンテキストを把握した上で計画やガイダンスを返し、エグゼキューターがその方針に沿って続行します。

単一APIリクエスト内で完結する設計

「複数モデルの連携というと、クライアント側でAPIコールを何回も管理しないといけないのでは？」と思いますよね。

ここが嬉しいところなんですよ。この一連のやり取りが単一の /v1/messages リクエスト内で完結するんです。

クライアント側で複数のAPIコールをオーケストレーションする必要がありません。

動作フローは4ステップです。

エグゼキューターが server_tool_use ブロックを発行（name: "advisor", input: {}）
サーバー側でアドバイザーモデルの推論を実行（会話の全トランスクリプトを渡す）
アドバイザーの応答が advisor_tool_result ブロックとしてエグゼキューターに返る
エグゼキューターがアドバイスに基づいて生成を継続

外から見ると1回のAPIコールです。

既存のクライアントコードへの組み込みがシンプルで済むのは、実運用面でかなり助かりますね。

モデルの組み合わせ

現時点で対応している組み合わせは以下の通りです。

Executor

Advisor

Haiku 4.5

Opus 4.6

Sonnet 4.6

Opus 4.6

アドバイザーは現在Opus 4.6のみです。

Opus同士の組み合わせも可能で、セルフレビュー的な使い方ができます。

数値でどう変わるか、次のベンチマーク結果が面白いんですよ。

ベンチマーク結果 -- コスト削減と性能向上の実数値

SWE-bench Multilingual：Sonnet+Opus vs 単独Sonnet

「実際の数値を見せてくれ」ということで、Anthropicが公開したベンチマーク結果を見てみます。

SWE-bench Multilingualでの結果がもっとも印象的です。

Sonnet + Opusアドバイザー: 単独Sonnetより2.7パーセントポイント高いスコア
コスト: 単独Sonnetより11.9%少ないコスト

正直、最初に見たとき「え？」ってなりました。

性能が上がるのにコストは下がる——通常はトレードオフになる2つの指標が同時に改善しているんです。

これが実現するのは、アドバイザーの出力が非常にコンパクトだからです。

アドバイザーの出力は通常400〜700テキストトークン程度（thinking含めて1,400〜1,800トークン）に収まります。

想像してみてください。エグゼキューターが方向性を見失って試行錯誤しながら余計なトークンを大量消費するより、早い段階でOpusに「こっちの方向で行け」と一言もらった方が、全体のトークン消費が少なく済む。そういう仕組みなんですよ。

コストシミュレーション：3パターン比較表

実際の利用シナリオを想定して、3パターンのコスト感を整理してみます。

パターン

推論の質

コスト感

適したユースケース

Opus 4.6 単体

最高

最も高い

毎ターンOpus級の判断が必要な場合

Sonnet 4.6 単体

高い

標準

大半の処理がSonnetで十分な場合

Sonnet 4.6 + Opus 4.6 アドバイザー

Opus並み

Sonnet以下（11.9%削減）

エージェントワークロード全般

Haiku 4.5 + Opus 4.6 アドバイザー

Sonnet級

Sonnet以下

コスト最優先で品質を底上げしたい場合

特にエージェントワークロード（数十ターン以上の処理）では、Sonnet+Opusアドバイザーが「コスパ最強」のポジションになる可能性が高いです。

数値で確認できたところで、実際に動かしてみましょう。

API実装 -- advisor toolの使い方

ここからは実装の話です。

Advisor Toolは現在ベータ版で、betaヘッダー advisor-tool-2026-03-01 を付与して利用します。

最低限の実装（curlコマンド）

まずは最小構成で動作確認してみましょう。curlコマンド1発で試せます。

curl https://api.anthropic.com/v1/messages \
    --header "x-api-key: $ANTHROPIC_API_KEY" \
    --header "anthropic-version: 2023-06-01" \
    --header "anthropic-beta: advisor-tool-2026-03-01" \
    --header "content-type: application/json" \
    --data '{
        "model": "claude-sonnet-4-6",
        "max_tokens": 4096,
        "tools": [
            {
                "type": "advisor_20260301",
                "name": "advisor",
                "model": "claude-opus-4-6"
            }
        ],
        "messages": [{
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown."
        }]
    }'

ポイントは tools 配列にアドバイザーの定義を追加するだけという手軽さです。

既存のコードに type: "advisor_20260301" と model: "claude-opus-4-6" の定義を1ブロック足すだけ。つまり、既存のエージェント実装に後付けで組み込めます。

type にベータ版の型名 advisor_20260301、model にアドバイザーとして使うモデルを指定します。

Pythonでのマルチターン会話実装

実際のアプリケーションではマルチターン会話になることが多いですよね。

まずは単発リクエストの基本形です。

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": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

マルチターンに拡張する場合は、advisor_tool_result ブロックを含むレスポンス全体を次のターンにそのまま渡します。

tools = [
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-opus-4-6",
    }
]

messages = [
    {"role": "user", "content": "Build a concurrent worker pool in Go with graceful shutdown."}
]

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=tools,
    messages=messages,
)

# advisor_tool_resultブロックを含む全レスポンスを次のターンに渡す
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content": "Now add a max-in-flight limit of 10."})

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=tools,
    messages=messages,
)

response.content をそのまま assistant ロールに入れるだけです。

アドバイザーの応答ブロックも含まれた状態で次のターンに渡されるので、特別な加工は不要です。

max_usesとcachingでコストを制御する

本番環境ではコスト制御が重要ですよね。

max_uses で1リクエストあたりのアドバイザー呼び出し回数に上限を設定できます。

tools = [
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-opus-4-6",
        "max_uses": 3,  # 1リクエストあたり最大3回
        "caching": {"type": "ephemeral", "ttl": "5m"},  # 3回以上呼ぶなら有効
    }
]

caching オプションはエフェメラルキャッシュで、同一セッション内で3回以上アドバイザーを呼ぶ場合にコスト効率が良くなります。

TTLは "5m"（5分）または "1h"（1時間）から選択します。

「使いたい場面だけOpusを呼んで、あとは制限をかける」という細かいチューニングができるのは、実際の運用で助かるポイントです。

他ツール（web_search等）との組み合わせ

Advisor Toolは他のツールと並列で定義できます。

tools = [
    {"type": "web_search_20250305", "name": "web_search", "max_uses": 5},
    {"type": "advisor_20260301", "name": "advisor", "model": "claude-opus-4-6"},
    {"name": "run_bash", "description": "Run a bash command", "input_schema": {"type": "object", "properties": {"command": {"type": "string"}}}},
]

エグゼキューターはWeb検索やBash実行を行いながら、必要に応じてアドバイザーに相談する複合エージェントを構成できます。

これが1回のAPIコールで完結するのは非常に強力です。

コストの把握という観点で、もう一点抑えておきたい話があります。

課金の仕組み -- iterations配列の読み方

コストを正確に把握するには、レスポンスの usage フィールドの構造を理解しておく必要があります。

ここ、ちょっと注意が必要なので確認しておきましょう。

トップレベルの usage はエグゼキューターのトークンのみを反映します。

アドバイザーのトークン消費は usage.iterations[] 配列の中に type: "advisor_message" として記録されています。

usage.iterations = [
  { type: "message", ... },           // エグゼキューターのトークン
  { type: "advisor_message", ... },   // アドバイザーのトークン
]

「なんかコストが想定より多い気がする」となったとき、トップレベルの usage しか見ていないと実態を見誤ります。

iterations[] の中身まで追いかけることで、どのタイミングでアドバイザーが何トークン消費したかを正確に把握できます。

もう一点。max_tokens もエグゼキューター出力にのみ適用されます。

アドバイザーの出力トークンには別の上限が適用されるため、max_tokens を小さく設定してもアドバイザーの応答は制限されません。

課金の構造を把握できたところで、実際に「どこで使うか」の判断基準を整理します。

いつ使うべきか・使わないべきか

効果が高い場面

Advisor Toolが真価を発揮するのは以下のようなケースです。

長期的なエージェントワークロード: コーディングエージェント、コンピューター操作、マルチステップリサーチなど。数十ターンにわたる処理で、途中の判断品質が最終結果に大きく影響するケース
Sonnetを複雑タスクに使っている場合: Opusアドバイザーを付けることで品質が向上し、コストは同等以下に抑えられる
Haikuで知能をステップアップしたい場合: コストはHaiku単体より上がりますが、Sonnet単体よりは安くSonnet級の品質を実現できる