Claude Advisor Tool解説｜Opus相談員でAPI費用を最大85%下げる逆転パターン

開発者のあいだで2026年4月以降ひそかに広がっているのが、Claude APIのadvisor_20260301というベータツールだ。Svelteアプリのリファクタを試した開発者は、Sonnet実行＋Opus相談役という構成で、グローバルなdocument.querySelectorAll()をスコープ限定のnode.querySelectorAll()に置き換えるべきこと、挿入したDOM要素を破棄時に追跡する必要があること、$paraglideエイリアスがTypeScriptで解決できない可能性があること、という3点をOpus側が指摘した過程をブログで報告している（出典：azukiazusa.dev『Using Claude’s Advisor Strategy to Optimize the Balance Between Performance and Cost』、2026年4月）。Sonnet単体では拾い切れなかった3つのリスクを、Opusに「相談だけ」させる構成で押さえた事例だ。

これが「Claude Advisor Tool」の素地にあるアイデアになっている。AnthropicがClaude Messages APIに加えた新しいベータ機能で、ベータヘッダーはanthropic-beta: advisor-tool-2026-03-01、ツール型はadvisor_20260301だ（出典：Advisor tool - Claude API Docs、2026年5月8日アクセス）。最初に押さえてほしい中核は2つだけだ。実行モデル（executor）と、相談役モデル（advisor）。この2語だけ覚えれば、本記事の残りは全部読める。

Advisor Toolはツール定義の追加で動くため、Messages APIの基本が分かっていれば導入は数行で済む。逆に「そもそも有料Claudeをどう選ぶか」から悩んでいる人は、料金とプランの全体像を先に押さえてほしい。Claude Pro有料サブの元取り条件とClaude Opus 4.7完全ガイドを読むと、本記事の費用比較が立体的に理解できる。

サブエージェントパターンの反転｜なぜ今この設計が出てきたか

Claude APIで本格的にエージェントを書いた経験があるエンジニアなら、「Opusで全部回すと早晩課金が崩壊する」という壁にぶつかっているはずだ。Opusは$15/M入力・$75/M出力（税抜・USD建て、出典：Claude API Pricing）と高い。長時間走るエージェントワークフローでは、数十回の中継ぎツール呼び出しすべてに最高峰モデルの料金がかかる。

従来の対策は「Opusをオーケストレーターに据え、ワーカーをSonnet/Haikuに分担させる」サブエージェント設計だった。だがこの構造でも、メインループのトークンはOpus課金で動く。並列処理は速くなっても、コストの天井は変わらない。

Advisor Toolはこの構造をまるごと反転させる。MediumにアップされたAlireza Rezvani氏のレビューによれば、「The cheap model drives. The expensive model consults（安いモデルが運転、高いモデルが相談に乗る）」という図式に変わる、と整理されている（出典：Alireza Rezvani『Claude’s Advisor Tool: The Sub-Agent Pattern, Inverted』Medium、2026年4月）。Sonnet/Haikuがエージェントの主役として最初から最後まで走り、Opusは要所だけ呼ばれる相談役になる。

ポイントは、advisor呼び出しが1回の/v1/messagesリクエスト内で完結することだ（出典：Advisor tool - Claude API Docs、2026年5月8日アクセス）。クライアント側で別のAPI呼び出しを発行する必要はなく、コンテキストの引き継ぎも自動だ。実行モデルがadvisorをツールとして呼び、Anthropic側のサブ推論でOpusが応答し、結果がツール結果ブロックとして実行モデルに戻る。

Advisor Toolの動作｜内部で何が起きているか

公式ドキュメントの記述を表に整理した。

ステップ	担当	動作
1	実行モデル（Sonnet/Haiku）	タスクを開始。コンテキストを構築
2	実行モデル	判断が必要だと感じた時点でserver_tool_useブロックを発行（name: "advisor"、inputは空）
3	Anthropicサーバー	実行モデルの全トランスクリプトをadvisorモデルに渡してサブ推論を実行
4	advisorモデル（Opus 4.7）	計画・修正案・次のステップを通常400〜700テキストトークンで返す
5	実行モデル	advisor_tool_resultブロックを受け取り、続きの作業を進める

Anthropic公式の解説によれば、advisor自身はツールやコンテキスト管理機能を持たずに動き、その思考ブロックは結果返却時にドロップされる（出典：同公式ドキュメント、2026年5月8日アクセス）。実行モデルが受け取るのは、最終的なアドバイス本文だけだ。

server_tool_use.inputフィールドが常に空である点も重要だ。これは設計上の意思表示で、advisorは実行モデルから渡された雑な要約ではなく、Anthropicサーバーが自動構築したフルトランスクリプトを直接読む。実行モデル側が「Opusに何を見せるか」を選ぶ余地はない。これが助言の質を担保するアーキテクチャになっている。

対応モデルと組み合わせ

実行モデルとadvisorモデルの組み合わせには制約がある。advisorは実行モデル以上の能力を持つ必要がある、というルールだ（出典：同公式ドキュメント、2026年5月8日アクセス）。

実行モデル	advisorモデル
Claude Haiku 4.5（claude-haiku-4-5-20251001）	Claude Opus 4.7（claude-opus-4-7）
Claude Sonnet 4.6（claude-sonnet-4-6）	Claude Opus 4.7（claude-opus-4-7）
Claude Opus 4.6（claude-opus-4-6）	Claude Opus 4.7（claude-opus-4-7）
Claude Opus 4.7（claude-opus-4-7）	Claude Opus 4.7（claude-opus-4-7）

無効な組み合わせ（HaikuにSonnetを相談役にするなど）を指定すると、APIは400 invalid_request_errorを返して具体的な理由を伝える。現時点でadvisor側に指定できるモデルはOpus 4.7だけだ。Sonnet 4.6を実行に使う場合のadvisorはOpus 4.7が事実上の唯一解になる。

実装の最短コース｜PythonとcURL

公式ドキュメントから抜粋した最小コードがこれだ（出典：同公式ドキュメント、2026年5月8日アクセス、表記簡略化のため一部整形）。

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-7",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

print(response)

cURLなら以下になる。

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-7"
            }
        ],
        "messages": [{
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown."
        }]
    }'

このリクエストを投げると、レスポンスのcontent配列にtext・server_tool_use・advisor_tool_result・続きのtext、という4種類のブロックが順番に並んで返ってくる。続くターンでは、レスポンスを丸ごとmessagesに含める運用が必要だ。advisor_tool_resultブロックを抜いて投げると、APIは400 invalid_request_errorを返す（出典：同公式ドキュメント、2026年5月8日アクセス）。

usageフィールドの返却形式は次のようになる（公式ドキュメントの記述例を抜粋・整形）。

{
  "usage": {
    "input_tokens": 412,
    "output_tokens": 531,
    "iterations": [
      { "type": "message", "input_tokens": 412, "output_tokens": 89 },
      { "type": "advisor_message", "model": "claude-opus-4-7",
        "input_tokens": 823, "output_tokens": 1612 },
      { "type": "message", "input_tokens": 1348,
        "cache_read_input_tokens": 412, "output_tokens": 442 }
    ]
  }
}

トップレベルのinput_tokens・output_tokensは実行モデル分しか含まない。iterations配列のtype: "advisor_message"がadvisorのサブ推論の課金内訳だ。コスト追跡を実装するなら、必ずiterations配列を読んでmodel別に集計する処理を入れる。後付けで足すと、月末の請求書を見て驚く人が出る。

ベンチマーク｜どれだけ効くか

Anthropicは2つのベンチマーク数値を公開している。あくまで自社環境での計測値で、読者の用途で同じ結果が出るとは限らない点を最初に断っておく。

Sonnet 4.6 + Opus 4.7 advisorの構成では、SWE-bench Multilingual（多言語のソフトウェアエンジニアリング・ベンチマーク）でSonnet単体比+2.7ポイントの上振れが報告されている（出典：The advisor strategy: Give Sonnet an intelligence boost with Opus | Claude、2026年4月）。同時に、Sonnet単体運用と比較した場合の1タスク当たりコストは11.9%下がった。Sonnetだけで回すより、Sonnetが主に動いてOpusに相談する構成のほうが、品質を伸ばしつつ安い、という結果だ。

Haiku 4.5 + Opus 4.7 advisorの伸びはさらに大きい。BrowseCompベンチマークでHaiku単体19.7%だったスコアが、advisorを足すだけで41.2%まで2倍以上伸びた（出典：同上）。Sonnet単体のスコアからは29ポイント下回るが、1タスク当たり費用はSonnet単体運用比で85%安いと報告されている。「Sonnet並みの精度は要らないが、Haiku単体ではしんどい」という用途には強烈に効く構成だ。

ただし注意点がある。AnthropicのMindWired AI誌のまとめによると、これらの数値は特定タスクでの結果で、全タスクで同じ伸びが出るとは限らない（出典：MindWired AI『Anthropic’s Advisor Strategy: Cut Claude API Costs by Up to 85%』、2026年4月）。シンプルなテキスト要約ではOpus advisorを呼ぶ判断自体が起きにくく、効果はほぼゼロに近い。一方で長時間動く計画系・コーディング系・ブラウジング系のエージェントでは、節目の判断品質がアウトプット全体の品質を支配しやすいため、advisor投入の効きが大きく出る。

advisor 1回当たりのコスト感｜円換算で押さえる

ベンチマーク数値だけでは現場感がつかみづらいので、advisor 1呼び出し当たりの実費を概算しておく。Opus 4.7のレートは$15/M入力・$75/M出力（税抜・USD建て）。advisorの典型的な使用量は入力1,500〜3,000トークン（実行モデルのトランスクリプト全文を渡すため可変）、出力400〜700テキストトークン、思考込みで1,400〜1,800トークンとされる（出典：公式ドキュメント、2026年5月8日アクセス）。

控えめに入力2,000トークン・出力1,600トークン（思考込み）で計算するとこうなる。

• 入力料金：2,000トークン × $15/M = $0.03（約4.5円、150円/USD換算）
• 出力料金：1,600トークン × $75/M = $0.12（約18円）
• advisor 1回当たり：合計 約$0.15（約22.5円）

長時間動くコーディング・エージェントでadvisorが3〜5回呼ばれる場合、advisor分だけでセッション当たり約70〜110円が乗る計算になる。月100セッション動くワークフローなら7,000〜11,000円。これを「Opusで全部回す」場合と比べて高いか安いかは、実行モデルがSonnetかHaikuか・トータルセッション長で変わる。為替・税の扱いはAnthropicの規約に従うため、ここでの円換算は概算として読んでほしい。

「100語以内・列挙形式」の指示をシステムプロンプトに足せばadvisor出力が35〜45%下がるので、上記の22.5円が13〜15円程度まで圧縮できる。長尺タスクで効くテクニックだ。

実体験｜Svelteリファクタで「単体では拾えなかった」リスクの3点

冒頭で触れた、Svelteコンポーネントのリファクタ事例を掘り下げる。Card.svelteという、責務が混ざっていたコンポーネントを整理する作業で、開発者はOpus advisor付きSonnetに以下のような形でタスクを渡している（出典：azukiazusa.dev『Using Claude’s Advisor Strategy to Optimize the Balance Between Performance and Cost』、2026年4月）。

Sonnet実行モデルは作業の冒頭でadvisorを呼び、続きで実装を進めた。途中の判断と完了直前にもadvisorを呼んでいる。Opus側が拾った3つの技術リスクはこれだ。

• スコープの誤り：Sonnetの初稿はdocument.querySelectorAll()をグローバルに使っていた。Opusは「node.querySelectorAll()にスコープすべき」と指摘。これがリファクタの本質、とOpus自身が要約していた
• DOMクリーンアップ漏れ：挿入した要素を配列で追跡し、コンポーネント破棄時に確実に削除する設計を提案
• インポート解決：$paraglideエイリアスがTypeScriptで通る前提を疑い、明示的なパラメータ化を勧めた

著者は「Opusに直接書かせるのではなく、Sonnetの実装をOpusがレビューする形にすると、Opus単体ではかえって過剰設計になりがちなところを、Sonnetの素朴な実装が抑え、要所のリスクだけOpusが整えてくれる」というトレードオフ感覚を述べていた。これは個人体験の範囲だが、「Sonnet単体＋Opus単体」の単純合計とは違う、Advisor Toolならではの性質を捉えた観察だ。

注意点と限界

導入前に把握しておきたい論点を5つに整理する。

1. ストリーミングが途中で止まる。advisorのサブ推論はストリームしない（出典：公式ドキュメント、2026年5月8日アクセス）。実行モデルがadvisorを呼んだ時点で、content_block_stopイベントの後にストリームが沈黙する。30秒ごとにSSE pingが流れる以外は無音だ。終わるとadvisor_tool_resultが一括で届く。チャットUIを作っているなら、advisor呼び出し中の表示を「Opusと相談中…」のような状態に切り替える設計が要る。

2. max_tokensが実行モデルにしか効かない。トップレベルのmax_tokensはexecutorのアウトプット上限で、advisorのサブ推論には適用されない。advisorは典型的に400〜700テキストトークン（思考込みで1,400〜1,800）を出力するので、その分の課金が別枠で発生する。max_usesパラメータで1リクエスト中のadvisor呼び出し回数だけは縛れる。

3. conversation単位の上限がない。1リクエスト内でmax_usesは効くが、複数ターンに渡る対話のなかでadvisorが何回呼ばれるかは、開発者がクライアント側でカウントする必要がある。上限に達したらadvisorツールをtools配列から外し、かつ過去のadvisor_tool_resultブロックも履歴から消す。残っていると400 invalid_request_errorになる。

4. キャッシュは3回以上で損益分岐。advisor自身のtranscript caching（caching: {"type": "ephemeral", "ttl": "5m"}）は、advisorが2回以下しか呼ばれない会話では書き込みコストが読み出しの節約を上回る。3回呼ばれて損益分岐、それ以上で効いてくる（出典：公式ドキュメント、2026年5月8日アクセス）。短命なタスクでは無効のままが安い。

5. clear_thinking設定との相性。コンテキスト編集機能でclear_thinkingにkeep値を"all"以外で指定すると、advisor側のtranscriptが毎ターン揺れてキャッシュミスを引き起こす。advice品質には影響しないが、コストが想定外に上がる。Opus 4.5以降・Sonnet 4.6以降のデフォルトはkeep: "all"相当の挙動なので問題は起きにくいが、明示的に変更している場合は注意が要る。

ベストプラクティス｜公式が示した実装パターン

Anthropic公式は、Advisor Toolを上手く動かすためのシステムプロンプト断片まで公開している（出典：公式ドキュメント、2026年5月8日アクセス、Anthropic公式の英文を翻訳・抜粋）。要旨はこうだ。

• オリエンテーション後・実装前にadvisorを呼ぶ：ファイル探索やソースの確認のような「準備」はsubstantive workではない。書き込み・編集・結論宣言の前にadvisorを呼ぶ
• 完了宣言前にもう1度呼ぶ：ただし宣言前に成果物を「永続化」しておく。advisorコールには時間がかかるので、途中で切れたときに保存済みのほうが残る
• 詰まったときに呼ぶ：エラーが繰り返す、アプローチが収束しない、結果が合わない、というシグナル時
• アプローチ変更を検討するときに呼ぶ

公式は加えて「The advisor should respond in under 100 words and use enumerated steps, not explanations.（advisorは100語以内で、説明ではなく列挙形式で返答すること）」という1行をシステムプロンプトに追加すると、advisor出力の総トークンが35〜45%下がったと内部テスト結果として報告している。コスト最適化を本気でやるならこれは外せない。

矛盾発生時の挙動も明示されている。実行モデルが既に取得した情報とadvisorの助言が食い違ったら、黙って切り替えるのではなく、もう1度advisorに「自分はXを確認した、あなたはYを示した、どの制約で決着するか」と問い合わせる。advisorは執行者の証拠を見ているが、過小評価していることがある、という前提で再相談を促す設計だ。

PMとしての判断｜自分ならこう使う

PMの目線で言うと、Advisor Toolは「すぐ全部に適用」すべきではない。一部の用途で劇的に効き、別の用途では遅延と運用負荷だけが増える、と性格がはっきり分かれている機能だ。自分（電脳狐影）が新規プロジェクトで導入するなら、優先度はこう並べる。

1. 長時間動くコーディング・エージェントから入れる：SWE-benchの伸びが示す通り、多段の判断が連鎖する作業に効く。アーキテクチャ判断・リファクタ・コードレビュー領域のエージェントが最有力
2. Haikuベースのリサーチ系エージェント：BrowseCompの2倍超えはここでの導入インセンティブが強い。情報収集を大量に走らせるが、Sonnet全量はオーバースペックなパイプラインに最適
3. 創造性・ブランド表現の判定は後回し：advisor自身もLLMで、独立コンテキストとはいえ別種のバイアスは残る。客観基準で運用パターンを掴んでから主観領域に手を出す

運用に入れる前に決めておきたいガードレールも3つある。

• iterations単位の課金監視を最初に組む：Advisor Toolはトップレベルusageに出ない隠れコストがusage.iterations[]に積まれる。ロギング基盤に最初からiterations配列をパースする処理を入れておく。後付けで足すと、月末に課金額を見て驚くことになる
• max_usesを必ず指定する：1リクエスト内のadvisor呼び出し回数を縛る。デフォルトは無制限だ。本番投入では3〜5を初期値にして、不足するならログを見て上げる流れが安全
• キャッシュは長尺タスクだけ：3回以下の対話でcaching有効化はコスト増になる。短命APIエンドポイントでは切る、長時間動くバッチでは入れる、と用途で分岐する

逆に避けたいのは、Advisor Toolを「Opusの安価版」と勘違いすることだ。advisor呼び出しは追加の遅延と複雑性を持ち込む。単発のチャットや短い問い合わせなら、最初からSonnet単体やOpus単体で動かしたほうがシンプルで安い。Advisor Toolが効くのは、トータルセッションが長く、判断の節目が複数あるエージェント設計のときだけ、と理解しておきたい。

なお、ここで前提にしているOpus 4.7の特性とSonnet 4.6の特性は、それぞれClaude Opus 4.7完全ガイドとClaude Sonnet 4.6レビューで詳しく扱っている。Advisor Toolの「相性」がいい用途を見極めるには、両モデルの性能特性を先に押さえておくと失敗が減る。

関連発表との位置づけ

Advisor Toolは2026年4月9日のベータ公開からCode w/ Claude 2026（5月6日）の発表群につながっていく。同じ周辺で発表されたのが、Claude Managed Agents「Outcomes」による評価ループ、Dreamingによるメモリ整理、Multiagent Orchestrationによる並列実行、そしてCompaction APIや拡張されたClaude API機能群だ。

整理するとこうなる。

• Advisor Tool：1リクエスト内で「実行モデル＋相談役」を構成するパターン
• Multiagent Orchestration：1セッション内で「リード＋複数サブエージェント」を構成するパターン
• Outcomes：1タスク内で「実行＋採点」を分離するパターン

似ているが目的が違う。Advisor Toolは「節目の判断品質」を上げる、Multiagent Orchestrationは「並列・分担」を実現する、Outcomesは「品質基準への準拠」を縛る。本番運用では、Multiagent Orchestrationの各サブエージェントの中でAdvisor Toolを使い、出力をOutcomesで縛る、という重ね方ができる。Anthropicの設計としては、これら4つを組み合わせて使うことが想定されている。

まとめ

Claude Advisor Toolは派手さはないが、長時間動くエージェント運用の経済性を根本から書き換える機能だ。「Opusで全部回すか、Sonnet/Haikuで割り切るか」という二択しかなかった世界に、「安いモデルが運転、高いモデルが要所だけ相談」という第3の選択肢を持ち込んだ。

導入のしやすさは、対象ワークフローの「長さ」と「判断の節目の多さ」で決まる。短いリクエストには遅延と複雑性だけが乗るので入れる意味が薄い。長く動くコーディングやリサーチのエージェントには、コストを下げつつ品質を上げる組み合わせが見つかりやすい。フリーランス・個人開発者にとっては、Opus単体運用で月額が膨らんでいるなら、まずanthropic-beta: advisor-tool-2026-03-01を1行足してSonnet実行＋Opus advisorに切り替えてみる、というのが最短の検証ルートだ。

関連する内部リンク

• Claude Sonnet 4.6レビュー｜Sonnet実行モデルの最有力候補
• Claude Opus 4.7完全ガイド｜advisorとして指定する唯一の選択肢
• Claude Managed Agents完全ガイド｜エージェント本番運用の全体像
• Claude Outcomes解説｜rubric graderで品質を縛る評価ループ
• Anthropic完全ガイド｜Claudeを支える企業の全貌

---

免責事項：本記事は2026年5月8日時点の公開情報をもとに構成している。料金・機能仕様・ベータヘッダー名・対応モデルはAnthropicの判断で変更される可能性がある。商用導入の前にAdvisor tool公式ドキュメントで最新版を必ず確認すること。本記事に記載のベンチマーク数値はAnthropicが自社環境で計測・公表したものであり、第三者検証や読者環境での再現を保証するものではない。Advisor Tool導入によって生じうる課金・運用結果の責任は導入企業・個人に帰属する。USD表記の料金は為替・税の扱いがAnthropicの規約に従う。本記事は技術解説を目的としたものであり、特定企業のサービス選定を推奨するものではない。