AIエージェントの運用コストを抑えながら、性能も上げたい。開発者なら誰もが抱えるこの矛盾に、Anthropicが一つの回答を出した。新機能「advisor tool」は、高性能なClaude Opusを”相談役”として配置し、日常の処理はSonnetやHaikuに任せるハイブリッド構成を可能にする。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レベルで吸収してくれるため、既存のツールチェーンを壊さずに導入できる点が大きい。
具体的には、tools配列にadvisor_20250301というツールタイプを追加し、advisorに使うモデル（現時点ではClaude Opus）とmax_uses（最大呼び出し回数）を指定するだけ。検索ツールやコード実行ツールなど、すでに使っている他のツールとも問題なく共存する。
ベンチマーク結果——コスト削減と性能向上を両立した実測データ
advisor toolの価値を語るうえで避けて通れないのが、Anthropicが公開したベンチマーク結果だ。2つの代表的なタスク領域で、具体的な数値が示されている。
コーディングタスク（SWE-bench Multilingual）の結果
SWE-bench Multilingualは、多言語のソフトウェアエンジニアリングタスクを評価するベンチマーク。ここでSonnet単体の成績に対し、Sonnet + Opus advisoryの構成は+2.7ポイントの改善を達成した。
注目すべきは、この性能向上がコスト11.9%削減と同時に実現されている点だ。通常、モデルの性能を上げるにはより大きなモデルに切り替えるしかなく、コストは跳ね上がる。advisor toolはこの常識を覆した。Opusを常時使う構成と比べて大幅に安く、Sonnet単体よりも賢い。いわば「コストと性能の中間解」を、開発者が明示的に選択できるようになったわけだ。
ブラウジングタスク（BrowseComp）の結果
より劇的な改善が見られたのがBrowseCompでの結果。Webブラウジングを伴うタスク評価において、Haiku単体のスコアは19.7%にとどまっていた。ここにOpus advisoryを組み合わせると、スコアは41.2%に跳ね上がった。2倍以上の性能向上だ。
しかもこの構成は、Sonnet単体で同じタスクを処理する場合と比べてコストを85%削減できる。Haikuの低コストを活かしつつ、判断が難しい場面だけOpusの知性を借りることで、「安いモデルでは解けないが、高いモデルを常時使うほどでもない」タスク群に対して最適な解を提供している。
この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を使ってしまっていた」という事態を防ぎやすい。
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の公開データを見る限り、少ない相談回数でも有意な性能改善が得られているため、いきなり大きな値を設定する必要はない。
エージェント運用で押さえておくべき注意点
advisor toolの導入は技術的にはシンプルだが、本番環境で運用する際にはいくつか見落としがちなポイントがある。
まず意識しておきたいのが、モデル間でのコンテキスト共有に伴う情報管理の問題だ。executorモデルがadvisorに相談する際、処理中のコンテキスト——つまりユーザーの入力データやツール実行の結果——がadvisorモデルにも渡される。executorが顧客の個人情報やAPIキーを含むデータを処理していた場合、その情報がadvisor経由で別のモデルインスタンスに流れることになる。
もう一つの注意点は、advisor呼び出し回数の最適化だ。max_usesを高く設定しすぎると、executorが些細な判断でもOpusに頼るようになり、コストメリットが薄れる。逆に低すぎると、本当にOpusの判断が必要な場面で相談枠を使い切っている——という事態も起こりうる。
現時点ではadvisorモデルとしてOpusのみが指定可能で、Sonnet同士やHaiku同士の相談構成は対応していない。ただし、Anthropicが段階的に機能を拡張してきた過去の経緯を踏まえると、将来的にadvisor側のモデル選択肢が増える展開は十分にありえる。Sonnetをadvisorにした「Haiku + Sonnet advisory」構成が登場すれば、さらに低コストなハイブリッド運用が実現するだろう。
まとめ
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単体との性能差とコスト差を測定するところから始めてみてほしい。数値で効果が見えれば、本格導入の判断材料が揃う。
コメント