AI エージェントの運用コストを抑えながら性能も上げたい——開発現場で繰り返し向き合う矛盾に、Anthropic が新しい回答を出した。Messages API に追加された advisor tool は、高性能な Claude Opus を相談役として配置し、日常処理は Sonnet や Haiku に任せるハイブリッド構成を API ネイティブで提供する。SWE-bench Multilingual で +2.7 ポイント改善、コスト 11.9% 削減という実測値が一次データとして公表されている。
- Anthropic が advisor tool を発表し、Claude Opus を Sonnet/Haiku の”相談役”として使うハイブリッド構成を Messages API で提供開始
- SWE-bench で +2.7pt 改善 ＆ コスト 11.9% 削減、BrowseComp では Haiku の性能が 2 倍超に向上
- max_uses パラメータで Opus 呼び出し回数を制御でき、API コストの上限管理が実務レベルで可能に
advisor tool とは——「判断は Opus、実行は Sonnet」のハイブリッド設計
Anthropic が発表した advisor tool は、Claude API の Messages API に直接統合された新機能だ。仕組みはシンプルで、日常的なタスク処理を担当する「executor」モデル（Sonnet または Haiku）が、複雑な判断を迫られた場面でのみ上位モデルの Opus に相談する——という構成を、API 側でネイティブにサポートしたもの。
この設計を人間の組織構造に例えるとわかりやすい。ジュニアエンジニアが日々のコーディングやバグ修正を担当しつつ、アーキテクチャ判断や設計方針で迷ったときだけシニアエンジニアに相談する。その関係を AI モデル間で再現したのが advisor tool の仕組みだ。
従来、同様の仕組みを実現しようとすると、開発者自身がオーケストレーション層を構築する必要があった。「どのタイミングで上位モデルを呼ぶか」「コンテキストをどう受け渡すか」といったロジックを自前で書くのは想像以上に手間がかかる。advisor tool はこれを API レベルで吸収するため、既存のツールチェーンを壊さずに導入できる。Anthropic Messages API リファレンス によれば、tools 配列は複数の組み込みツールを並列定義でき、advisor tool もこのフレームに準じる。既存の tool_use / tool_result の往復構造を踏襲しているため、SDK のメッセージハンドラを書き換える必要はない。
具体的には、tools 配列に advisor_20250301 というツールタイプを追加し、advisor に使うモデル（現時点では Claude Opus）と max_uses（最大呼び出し回数）を指定するだけ。Anthropic Tool use overview に沿った構造のため、検索ツールやコード実行ツールなど、すでに使っている他のツールとも問題なく共存する。
既存オーケストレーション層との位置づけ
advisor tool が登場するまで、複数モデルを使い分けるハイブリッド運用は外部ライブラリやカスタムロジックに頼るのが一般的だった。代表的な構成を並べると、advisor tool の導入容易性とコスト管理の素直さが見えてくる。
| 方式 | 実装コスト | API 統合度 | コスト管理 | 運用難易度 |
|---|---|---|---|---|
| advisor tool (Messages API) | 低（tools 配列に追記） | ネイティブ | max_uses で上限制御 | 低 |
| 自前オーケストレーション | 高（判定ロジック実装） | 外部 | 呼び出しロジック内で制御 | 高 |
| LangChain / LangGraph Router | 中（フレーム導入） | 外部 | カスタムノードで制御 | 中 |
| Vercel AI SDK / OpenAI SDK ミドルウェア | 中 | 外部 | SDK レベル | 中 |
外部ライブラリ方式は柔軟性が高い反面、運用上はバージョン追従コストや障害ポイントが増える。advisor tool は Anthropic 自身が保守する API 内蔵機能のため、Messages API のリリースサイクル上でメンテナンスされる点も導入判断の材料になる。
ベンチマーク結果——コスト削減と性能向上を両立した実測データ
advisor tool の価値を語るうえで避けて通れないのが、Anthropic が公開したベンチマーク結果だ。2 つの代表的なタスク領域で具体的な数値が示されている。
コーディングタスク（SWE-bench Multilingual）の結果
SWE-bench Multilingual は、多言語のソフトウェアエンジニアリングタスクを評価するベンチマーク（SWE-bench 公式サイト）。実際の GitHub Issue とその修正パッチを大規模に集めた評価セットで、AI コーディングエージェントの実務性能を測る指標として広く採用されている。ここで Sonnet 単体の成績に対し、Sonnet + Opus advisor の構成は +2.7 ポイントの改善 を達成した。
押さえておきたいのは、この性能向上が コスト 11.9% 削減 と同時に実現されている点だ。通常、モデルの性能を上げるには大きなモデルに切り替えるしかなく、コストは跳ね上がる。advisor tool はこの常識を覆した。Opus を常時使う構成と比べて大幅に安く、Sonnet 単体よりも賢い。コストと性能の中間解を、開発者が明示的に選択できるようになった。
ブラウジングタスク（BrowseComp）の結果
より劇的な改善が見られたのが BrowseComp での結果。Web ブラウジングを伴うタスク評価において、Haiku 単体のスコアは 19.7% にとどまっていた。ここに Opus advisor を組み合わせると、スコアは 41.2% に跳ね上がった。2 倍以上の性能向上だ。
しかもこの構成は、Sonnet 単体で同じタスクを処理する場合と比べて コストを 85% 削減 できる。Haiku の低コストを活かしつつ、判断が難しい場面だけ Opus の知性を借りることで、「安いモデルでは解けないが、高いモデルを常時使うほどでもない」タスク群に対して最適な解を提供している。
| 構成 | ベンチマーク | スコア | コスト変化（基準比） |
|---|---|---|---|
| Sonnet 単体 | SWE-bench Multilingual | 基準 | 基準 |
| Sonnet + Opus advisor | SWE-bench Multilingual | +2.7pt | -11.9% |
| Haiku 単体 | BrowseComp | 19.7% | 基準 |
| Haiku + Opus advisor | BrowseComp | 41.2% | Sonnet 比 -85% |
この 85% という数字を具体的に考えると、月間 API 利用料が 100 万円のプロジェクトなら、ブラウジング系タスクだけで月 75 万円以上のコスト圧縮が見込める計算になる。エージェントの本番運用でコストがネックになっていた開発チームにとっては、検討する価値のある選択肢だ。
実装方法——Messages API での advisor tool 組み込み手順
advisor tool の導入は、既存の Claude API 利用者であれば拍子抜けするほど簡単だ。大がかりなアーキテクチャ変更は不要で、API リクエストの tools 配列に advisor の定義を追加するだけで動作する。
基本パラメータと課金の仕組み
API リクエストの構成要素を整理すると以下のようになる。
- model: executor として使うモデルを指定。claude-sonnet-4-6 や claude-haiku-4-6 が選択肢
- tools 配列: ここに advisor_20250301 タイプのツールを追加
- advisor の model: 相談先モデルとして claude-opus-4-6 を指定
- max_uses: 1 回のリクエスト内で advisor を呼び出せる上限回数
課金は executor と advisor で完全に分離されている。Sonnet が処理したトークンは Sonnet の単価で、Opus に相談した分は Opus の単価で、それぞれ別カウントされる。API レスポンスにも advisor の使用量が明示されるため、「思ったより Opus を使ってしまっていた」という事態を防ぎやすい。各モデルの単価は Anthropic 公式 Pricing ページ で都度確認できる。
| 役割 | モデル候補 | 課金単価の参照 | 備考 |
|---|---|---|---|
| executor | claude-sonnet-4-6 / claude-haiku-4-6 | 各モデルの input / output 単価 | tools 呼び出し含むレスポンス全量に課金 |
| advisor | claude-opus-4-6（現時点で固定） | Opus の input / output 単価 | 呼び出し時のコンテキスト＋応答分 |
| 合算 | — | API レスポンス usage で別カウント | ダッシュボードでも分離表示 |
max_uses によるコスト制御の考え方
実務上、最も重要なパラメータが max_uses だ。これは executor が advisor に相談できる回数の上限を指定するもので、コスト管理の要となる。たとえば max_uses を 3 に設定した場合、executor モデルは 1 回の API コール内で最大 3 回まで Opus に相談できる。4 回目以降は相談なしで自力判断を続ける。
この制御がなければ、executor が不確実さを感じるたびに Opus を呼び出し、結果として「Opus を常時使うのと変わらないコスト」になるリスクがある。最適な max_uses はタスクの複雑さによって異なるが、まず max_uses: 1 から始めて効果を測定するのが堅実なアプローチだ。1 回の相談だけでどの程度性能が改善するかを確認し、費用対効果を見ながら段階的に増やしていく。Anthropic の公開データを見る限り、少ない相談回数でも有意な性能改善が得られているため、いきなり大きな値を設定する必要はない。
prompt caching との組み合わせ
長いシステムプロンプトを抱えるエージェントでは、prompt caching の併用がコスト最適化に効く。Anthropic 公式: Prompt caching によれば、cache_control ブロックでマークされた領域は再利用時に大幅に安くなる。executor 側のシステムプロンプトをキャッシュしつつ、advisor 呼び出し時のコンテキストもセグメント単位でキャッシュ対象に含められるため、繰り返し同じ長文プロンプトを送るワークロードでは効果が大きい。
モデル選択ガイド——どの executor と Opus を組み合わせるか
advisor tool では advisor 側は Opus 固定（執筆時点）だが、executor 側は Sonnet と Haiku から選べる。タスク特性に応じた選び方を整理する。
| executor | 得意領域 | advisor 投入が効く場面 | 想定 max_uses 初期値 |
|---|---|---|---|
| Sonnet | コード生成、構造化分析、長文要約 | 多段階リファクタ、ライブラリ選定、設計判断の分岐 | 1〜2 |
| Haiku | 高頻度の分類、抽出、短文応答、ブラウジング | 意図解釈の曖昧さ、Web 構造の判別、長文要点整理 | 1 |
Sonnet は単体でも判断力が高いため、advisor 呼び出しの効果は「特定の難所だけ」に集中させる運用が効率的になりやすい。一方 Haiku は応答速度と単価が魅力だが、難易度の高い意図解釈で詰まりやすい。Haiku + Opus advisor の構成が BrowseComp で 2 倍超の改善を見せたのは、まさにこの「Haiku が苦手な場面でだけ Opus を借りる」運用がハマったケースだ。Anthropic Models overview で各モデルのコンテキスト長や得意領域を確認したうえで、ペアを決めるとよい。
セキュリティと情報ガバナンス
advisor tool の導入は技術的にはシンプルだが、本番環境で運用する際に見落としがちなポイントが情報ガバナンスだ。executor が advisor に相談する際、処理中のコンテキスト——ユーザーの入力データやツール実行の結果——が advisor モデルにも渡される。executor が顧客の個人情報や API キーを含むデータを処理していた場合、その情報が advisor 経由で別のモデルインスタンスに流れることになる。
Tool use では、モデルに渡すコンテキストを必要最小限に保ち、機密性の高いフィールドはサニタイズしてから渡すことが推奨される。エージェントが扱うデータ範囲は、ツールの設計時点で明示的に定義すべき。
Anthropic 公式: Tool use overview（要旨）
もう一つの注意点は、advisor 呼び出し回数の最適化だ。max_uses を高く設定しすぎると、executor が些細な判断でも Opus に頼るようになり、コストメリットが薄れる。逆に低すぎると、本当に Opus の判断が必要な場面で相談枠を使い切っている——という事態も起こりうる。Anthropic 公式: Rate limits によれば、レート制限は組織単位・モデル単位で適用されるため、advisor 経由で Opus を呼ぶ分も Opus のクォータを消費する点は留意したい。
現時点では advisor モデルとして Opus のみが指定可能で、Sonnet 同士や Haiku 同士の相談構成は対応していない。ただし、Anthropic が段階的に機能を拡張してきた経緯を踏まえると、将来的に advisor 側のモデル選択肢が増える展開はありえる。Sonnet を advisor にした「Haiku + Sonnet advisor」構成が登場すれば、さらに低コストなハイブリッド運用が実現する可能性がある。
FAQ
Q1. max_uses の最適値はどう決めるか
タスクの複雑さに大きく依存するため、まず max_uses: 1 で運用を開始し、性能とコストのバランスを 1〜2 週間程度モニタリングしてから増減する流れが現実的。Anthropic 公開データでも、少ない相談回数で有意な改善が出ているため、初期値を大きくする必要はない。
Q2. prompt caching と併用できるか
併用可能。executor 側の長いシステムプロンプトを cache_control でマークしておけば、繰り返し呼び出し時のコストが下がる。advisor 呼び出し時のコンテキストもセグメント単位でキャッシュ対象に含められる。詳細は Anthropic 公式: Prompt caching を参照。
Q3. streaming レスポンスでの挙動は
Messages API は streaming 配信に対応しており、tool use 系イベントもストリーム上で配信される。advisor tool の呼び出しと結果も content_block_start / content_block_delta 系イベントを通じて UI へ反映できる構造になっている。Anthropic 公式: Streaming Messages のイベントスキーマに沿って実装すればよい。
Q4. rate limit は executor と advisor で別管理か
レート制限はモデル単位で課されるため、advisor 経由で Opus を呼ぶリクエストは Opus のクォータを消費する。executor が Sonnet なら Sonnet のクォータ、advisor が Opus なら Opus のクォータ、と別カウントになる。組織全体の使用状況は Anthropic Console のダッシュボードで監視できる。
出典・参考
- The advisor strategy: Give Sonnet an intelligence boost with Opus (Anthropic 公式ブログ) — Sonnet+Opus advisor で SWE-bench Multilingual +2.7pt、 タスクあたりコスト -11.9% の一次データ。
- Advisor tool — Claude API 公式ドキュメント — 仕様、 beta header (advisor-tool-2026-03-01)、 model 互換ペア、 server_tool_use / advisor_tool_result の応答構造、 課金単位の一次仕様。
- Anthropic launches advisor tool for Claude API users (TestingCatalog) — 2026-04-09 beta 公開のタイミングと提供形態を補足する報道記事。
- SWE-bench 公式サイト — マルチリンガル評価セットの仕様。
- Anthropic Pricing — 各モデルの最新単価。
- Anthropic Models overview — Sonnet / Haiku / Opus の特性・コンテキスト長一覧。
まとめ
Anthropic の advisor tool は、「高性能モデルを常時使うか、安いモデルで妥協するか」という二択を過去のものにした。押さえておくべきポイントは 3 つ。
第一に、実測で証明されたコスト効率。 SWE-bench で +2.7pt 改善かつコスト 11.9% 削減、BrowseComp では Haiku の性能を 2 倍以上に引き上げつつ Sonnet 比 85% のコスト削減。理論値ではなく、ベンチマーク上の実測結果。
第二に、導入のハードルが極めて低い。 Messages API の tools 配列に advisor 定義を追加するだけで、既存のワークフローを壊さず導入できる。
第三に、max_uses によるコスト統制が可能。 「予算内でどこまで Opus の知性を借りるか」を数値で制御できるため、API コストが読めないという導入障壁が大幅に下がった。
まずは既存プロジェクトの一部タスクで max_uses: 1 の advisor 構成を試し、Sonnet 単体との性能差とコスト差を測定するところから始めるとよい。数値で効果が見えれば、本格導入の判断材料が揃う。
本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
