本文の最終更新: 2026年4月
検証: AIツール図鑑編集部(AI自動化・ツール実運用 / 料金・規約は公式資料で確認)
AI エージェントの運用コストを抑えながら性能も上げたい。開発現場で繰り返し向き合う矛盾に、Anthropic が新しい回答を出した。Messages API に追加された advisor tool は、高性能な Claude Opus を相談役として配置し、日常処理は Sonnet や Haiku に任せるハイブリッド構成を API ネイティブで提供する。SWE-bench Multilingual で +2.7 ポイント改善、コスト 11.9% 削減という実測値が一次データとして公表されている（Anthropic公式評価条件下の結果。効果はワークロード依存のため自社評価が前提）。
- Anthropic が advisor tool を発表し、Claude Opus を Sonnet/Haiku の”相談役”として使うハイブリッド構成を Messages API で提供開始
- Anthropic公式評価でSWE-bench +2.7pt改善・コスト11.9%削減、BrowseCompではHaikuの性能が2倍超に向上(いずれも公式評価条件下の結果。効果はワークロード依存)
- max_uses パラメータで1リクエストあたりのOpus呼び出し回数を制御可能(既定は無制限。会話全体の上限はクライアント側で別途管理する必要がある)
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 もこのフレームに準じる。advisor は server_tool_use / advisor_tool_result という専用のブロック種別で返るため、既存の content block 処理がこの未知ブロックを保持・パススルーできるか確認が必要。multi-turn では advisor 関連ブロックをそのまま履歴に含めて送り返し、advisor tool 自体も毎回継続して指定する(tools 配列から外すと 400 エラーになりうる)。
具体的には、tools 配列に advisor_20260301 というツールタイプを追加し、advisor に使うモデル（executor 以上のモデル。例：Claude Opus）と max_uses（最大呼び出し回数）を指定するだけ。ただし2026年7月時点ではベータ機能のため、APIリクエストに anthropic-beta: advisor-tool-2026-03-01 ベータヘッダー（SDK利用時は betas パラメータ）を含める必要がある。また現状 Claude API と Claude Platform on AWS でのみ利用可能で、Amazon Bedrock・Google Cloud・Microsoft Foundry では未提供。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 ポイントの改善 を達成した（数値は Anthropic 公式: The advisor strategy による実測値。Sonnet 4.6 単体と Sonnet 4.6 + Opus 4.6 advisor の比較、300問・9言語・5試行平均という条件下）。
押さえておきたいのは、この性能向上が コスト 11.9% 削減 と同時に実現されている点だ。通常、モデルの性能を上げるには大きなモデルに切り替えるしかなく、コストは跳ね上がる。advisor tool はこの常識を覆した。Opus を常時使う構成と比べて大幅に安く、Sonnet 単体よりも賢い。コストと性能の中間解を、開発者が明示的に選択できるようになった。
ブラウジングタスク（BrowseComp）の結果
より劇的な改善が見られたのが BrowseComp での結果。Web ブラウジングを伴うタスク評価において、Haiku 単体のスコアは 19.7% にとどまっていた。ここに Opus advisor を組み合わせると、スコアは 41.2% に跳ね上がった。2 倍以上の性能向上だ。
しかもこの構成は、Sonnet 単体で同じタスクを処理する場合と比べて コストを 85% 削減 できる。ただし公式評価では BrowseComp のスコア自体は Sonnet 単体より約 29% 低く、あくまで「Sonnet 単体ほどの精度は要らないが Haiku 単体では物足りない」中間レンジ向けの選択肢である点には注意したい。この数値も Anthropic 公式評価の条件下のもので、1266問・1問1試行・thinking off・web search/web fetch ツール使用、Opus 4.6 advisor という設定で測定されている。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% という数字を具体的に考えると、Sonnet 単体でブラウジング系タスクに月100万円かかっていた場合、公式評価の85%削減をそのまま当てはめると月額は約15万円、削減額は約85万円という計算になる。ただし Haiku 単体よりは advisor 分のコストが上乗せされるため、Haiku 単体運用からの切り替えでは削減ではなくコスト増になりうる点に注意したい。実際の削減幅は自社のログで再計算するのが確実だ。
実装方法：Messages API での advisor tool 組み込み手順
advisor tool の導入は、既存の Claude API 利用者であれば拍子抜けするほど簡単だ。大がかりなアーキテクチャ変更は不要で、API リクエストの tools 配列に advisor の定義を追加するだけで動作する。
基本パラメータと課金の仕組み
API リクエストの構成要素を整理すると以下のようになる。
- model: executor として使うモデルを指定。claude-sonnet-5（旧世代の claude-sonnet-4-6 も継続利用可）や claude-haiku-4-5 が選択肢
- tools 配列: ここに advisor_20260301 タイプのツールを追加
- advisor の model: 相談先モデルとして claude-opus-4-8 を指定
- max_uses: 1 回のリクエスト内で advisor を呼び出せる上限回数
課金は executor と advisor で完全に分離されている。Sonnet が処理したトークンは Sonnet の単価で、Opus に相談した分は Opus の単価で、それぞれ別カウントされる。API レスポンスの usage.iterations[] 配列に advisor 呼び出し分が type: "advisor_message" として個別計上されるため、「思ったより Opus を使ってしまっていた」という事態を把握しやすい(top-level の usage は executor 分のみを反映し、advisor 分は合算されない点に注意)。各モデルの単価は Anthropic 公式 Pricing ページ で都度確認できる。
| 役割 | モデル候補 | 課金単価の参照 | 備考 |
|---|---|---|---|
| executor | claude-sonnet-5 / claude-haiku-4-5 | 各モデルの input / output 単価 | tools 呼び出し含むレスポンス全量に課金 |
| advisor | claude-opus-4-8 など（executor 以上のモデル。最低ラインは claude-sonnet-4-6） | Opus の input / output 単価 | 呼び出し時のコンテキスト＋応答分 |
| 合算 | — | usage.iterations[] で advisor_message として別カウント | top-level の usage は executor分のみ反映 |
max_uses によるコスト制御の考え方
実務上、最も重要なパラメータが max_uses だ。これは executor が advisor に相談できる回数の上限を指定するもので、コスト管理の要となる。たとえば max_uses を 3 に設定した場合、executor モデルは 1 回の API コール内で最大 3 回まで Opus に相談できる。4 回目以降は相談なしで自力判断を続ける。
max_uses は1回の API リクエスト内での上限であり、既定値は無制限(unlimited)。会話全体を通じた呼び出し回数を抑えたい場合は、クライアント側で advisor 呼び出し数をカウントし、上限到達後は tools 配列から advisor tool 自体を外す実装が必要になる(その際、履歴内の advisor_tool_result ブロックも併せて取り除かないと 400 エラーになりうる)。また、top-level の max_tokens は executor の出力だけを制限し advisor のサブ推論には適用されないため、advisor の出力量を抑えたい場合は tool 定義側に別途 max_tokens を設定する必要がある。この制御がなければ、executor が不確実さを感じるたびに Opus を呼び出し、結果として「Opus を常時使うのと変わらないコスト」になるリスクがある。最適な max_uses はタスクの複雑さによって異なるが、まず max_uses: 1 から始めて効果を測定するのが堅実なアプローチだ。1 回の相談だけでどの程度性能が改善するかを確認し、費用対効果を見ながら段階的に増やしていく。Anthropic の公開データを見る限り、少ない相談回数でも有意な性能改善が得られているため、いきなり大きな値を設定する必要はない。
prompt caching との組み合わせ
長いシステムプロンプトを抱えるエージェントでは、prompt caching の併用がコスト最適化に効く。executor 側は通常どおり cache_control ブレークポイントでシステムプロンプト等をキャッシュできる。advisor 側は仕組みが異なり、tool 定義に caching: {"type": "ephemeral", "ttl": "5m"} のようにオン/オフを指定する形でキャッシュを有効化し、キャッシュ境界はサーバー側が自動的に決める。会話内で advisor を3回以上呼び出すワークロードで効果が出やすく、2回以下では書き込みコストが上回る場合がある。
モデル選択ガイド：どの executor と Opus を組み合わせるか
advisor 側は Opus 固定ではなく、最低ラインの Claude Sonnet 4.6 以上から選べる。executor 側はコスト削減が主目的なら Sonnet（2026年6月30日公開の Sonnet 5 を含む）と Haiku が中心になるが、公式の互換表では Opus 同士の組み合わせ（例: Opus 4.7 executor × Opus 4.8 advisor）も対応している。ここでは主用途であるコスト削減構成を中心に整理する。
| 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 の会話全体(システムプロンプト・ツール定義・それまでの全ターン・ツール実行結果・そのターンで executor がすでに生成済みのテキストまで)を引用コンテキストとして受け取る。executor が顧客の個人情報や API キーを含むデータを処理していた場合、その情報が advisor 経由で別のモデルインスタンスに流れることになる。なお Zero Data Retention(ZDR)契約を結んでいる組織では、advisor 経由で送信されたデータは API レスポンス返却後に保存されない。
Anthropic公式のTool use overviewの趣旨を要約すると次のとおり: モデルに渡すコンテキストを必要最小限に保ち、機密性の高いフィールドはサニタイズしてから渡すことが推奨される。エージェントが扱うデータ範囲は、ツールの設計時点で明示的に定義すべき。
Anthropic 公式: Tool use overview（要約）
もう一つの注意点は、advisor 呼び出し回数の最適化だ。max_uses を高く設定しすぎると、executor が些細な判断でも Opus に頼るようになり、コストメリットが薄れる。逆に低すぎると、本当に Opus の判断が必要な場面で相談枠を使い切っているという事態も起こりうる。Anthropic 公式: Rate limits によれば、レート制限は組織単位・モデル単位で適用されるため、advisor 経由で Opus を呼ぶ分も Opus のクォータを消費する点は留意したい。
advisor モデルは Opus 固定ではなく、executor 以上の能力を持つモデル（最低ラインは Claude Sonnet 4.6）を指定できる。たとえば Haiku を executor にして Sonnet 4.6 を advisor にする低コスト構成も現時点で利用でき、Opus 4.6/4.7/4.8 を advisor にすればより高い知性を借りられる。ただし2026年6月30日公開の Sonnet 5 を executor にする場合、対応する advisor は Opus 4.7 以上に限られ、Sonnet 4.6 や Opus 4.6 は組み合わせ対象外になる点に注意したい(公式の互換表で executor ごとに有効なペアが定義されている。互換表は今後も更新され得るため、導入時は都度公式ドキュメントで確認するのが安全)。executor と advisor は「advisor が executor 以上の能力を持つ」という制約を満たす有効なペアである必要がある。また Sonnet 4.6 から Sonnet 5 へ executor を切り替える場合は、新トークナイザによる token 数の変化・adaptive thinking が既定になる点・対応する sampling parameter の違いなど、移行時の挙動差を公式の移行ガイドで確認したうえで token counting や max_tokens を見直すとよい。
FAQ
Q1. max_uses の最適値はどう決めるか
タスクの複雑さに大きく依存するため、まず max_uses: 1 で運用を開始し、性能とコストのバランスを 1〜2 週間程度モニタリングしてから増減する流れが現実的。Anthropic 公開データでも、少ない相談回数で有意な改善が出ているため、初期値を大きくする必要はない。
Q2. prompt caching と併用できるか
併用可能。executor 側の長いシステムプロンプトを cache_control でマークしておけば、繰り返し呼び出し時のコストが下がる。advisor 側は tool 定義の caching パラメータ(オン/オフ切り替え、境界はサーバー側が決定)で別途有効化する仕組みで、3回以上の advisor 呼び出しがあるワークロードで効果が出やすい。
Q3. streaming レスポンスでの挙動は
Messages API は streaming 配信に対応しているが、advisor のサブ推論自体はストリーミングされない。advisor 呼び出し中は executor 側のストリームが一時停止し、完了すると advisor_tool_result が単一の content_block_start イベントとして一括で届く(delta配信はない)。UI 側はこの「一時停止 → 一括結果」を前提に実装する必要がある。
Q4. rate limit は executor と advisor で別管理か
レート制限はモデル単位で課されるため、advisor 経由で Opus を呼ぶリクエストは Opus のクォータを消費する。executor が Sonnet なら Sonnet のクォータ、advisor が Opus なら Opus のクォータ、と別カウントになる。組織全体の使用状況は Anthropic Console のダッシュボードで監視できる。
まとめ
Anthropic の advisor tool は、「高性能モデルを常時使うか、安いモデルで妥協するか」という二択を過去のものにした。押さえておくべきポイントは 3 つ。
第一に、Anthropic公式評価条件下で示されたコスト効率。 SWE-bench で +2.7pt 改善かつコスト 11.9% 削減、BrowseComp では Haiku のスコアを 2 倍以上(19.7%→41.2%)に引き上げつつ Sonnet 比 85% のコスト削減。ただし BrowseComp のスコア自体は Sonnet 単体より約29%低い中間レンジ向けの構成であり、効果はワークロード依存のため自社評価での確認が前提になる。理論値ではなく、公式の特定評価条件下での実測結果。
第二に、導入のハードルが極めて低い。 Messages API の tools 配列に advisor 定義を追加するだけで、既存のワークフローを壊さず導入できる。
第三に、max_uses による1リクエスト単位のコスト統制が可能。 「1回のAPIコール内でどこまでOpusの知性を借りるか」を数値で制御できる(既定は無制限。会話全体の上限はクライアント側で別途カウントする設計が必要)ため、API コストが読めないという導入障壁が大幅に下がった。
まずは既存プロジェクトの一部タスクで max_uses: 1 の advisor 構成を試し、Sonnet 単体との性能差とコスト差を測定するところから始めるとよい。数値で効果が見えれば、本格導入の判断材料が揃う。
本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
