AIコーディングアシスタントを使っていて、一番もどかしい瞬間があります。良いモデルは高くて、安いモデルは難しい問題で止まってしまう——そのジレンマにAnthropicが真正面から取り組みました。
Claude Codeの/advisorコマンドは、実行モデル（Sonnet）が作業中に詰まると自動的に上位モデル（Opus）に助言を求める機能です。大半のトークンは安いモデルが処理し、難しい判断だけ高いモデルが介入することでコスト対効果を最大化する仕組みです。SWE-benchではSonnet単独72.1%→Sonnet+Opus Advisor 74.8%に向上し、作業あたりのコストは逆に11.9%減りました。
これは何?
/advisorは2026年4月9日にAnthropicがClaudeプラットフォームに正式リリースしたモデルペアリングパターンです。 従来は高いモデル（Opus）が上から指示し、安いモデル（Sonnet/Haiku）が下請けをこなす構造（サブエージェントパターン）が一般的でしたが、/advisorはこれをまったく逆転させました。
仕組みはこうです。Sonnet 4.6やHaiku 4.5のような速くて安価なモデルが最初から最後まで作業を主導します。ファイルの読み込み、コードの作成、テストの実行——すべて実行モデルが担います。そして自分では判断が難しい局面に差し掛かると、自動的にOpus 4.6に助言を求めます。
ポイント：Opusは会話全体のコンテキストを確認したうえで、400〜700トークン程度の短い戦略的アドバイスだけを返します。コードを直接書いたり、ファイルを編集したり、外部ツールを呼び出したりは一切できません。純粋に「考える」だけの役割です。
Claude Codeでは/advisorと入力してOpus 4.6を選択するだけで即有効になります。別途設定やパラメータ調整は不要で、1行で完結します。 APIでもツール配列にadvisor_20260301タイプを1つ追加するだけです。
最も印象的なのは、アドバイスがセッションのコンテキストに蓄積される点です。後でAdvisorが再び呼び出されると、以前のアドバイスも参照します。実行モデルがアドバイスと異なる結果を得た場合、「AdvisorはXと言いましたが、テスト結果はYでした——再度相談しますか?」と明示的に確認してきます。
何が変わるのか?
従来のマルチモデルパターンと/advisorがどう違うか、比較してみましょう。
| 従来のサブエージェントパターン | /advisorパターン | |
|---|---|---|
| 構造 | 高いモデルが上から指示、安いモデルが実行 | 安いモデルが主導、詰まった時だけ高いモデルが助言 |
| コスト構造 | オーケストレーターモデルにコストが集中 | 実行モデルの料金が主体、Advisorは少量トークンのみ |
| コンテキスト共有 | 開発者がコンテキスト渡しを手動管理 | サーバーサイドで自動送信 |
| オーケストレーション | LangGraph、AutoGenなどのフレームワークが必要 | API設定1行で完結 |
| Advisorのツールアクセス | Workerがツール使用可能 | Advisorはツールアクセス不可（推論のみ） |
| 適した作業 | すべてのターンが複雑な場合 | 大半が機械的で、時折難しい判断が必要な場合 |
実際のベンチマークは?
数字で確認してみましょう。
特にHaikuの飛躍が注目に値します。BrowseCompで19.7%→41.2%というのは単なる改善ではなく、複雑なウェブリサーチにおける根本的な能力差をAdvisorが埋めているということです。法律文書抽出サービスのEve Legalは実際にHaiku + Opus Advisorの組み合わせでフロンティアモデル水準の品質を達成しながら、コストはOpus単独比で5分の1に抑えられたとのことです。
始め方のポイント
- Claude Codeですぐに始める
ターミナルで/advisorを入力→Opus 4.6を選択→完了です。Sonnet 4.6をメインモデルとして使っているなら、今すぐ試してみてください。 - APIで連携する
Messages APIリクエストにベータヘッダーanthropic-beta: advisor-tool-2026-03-01を追加し、tools配列に{"type": "advisor_20260301", "name": "advisor", "model": "claude-opus-4-6"}を入れるだけです。 - コスト管理の設定
max_usesパラメータでリクエストあたりのAdvisor呼び出し回数を制限しましょう。コーディング作業なら2〜3回で主要な意思決定ポイントを十分にカバーできます。 - おすすめのモデルペアリングを選ぶ
コスパ最高：Sonnet + Opus Advisor。超節約：Haiku + Opus Advisor（大量処理に最適）。Opusをメインにするならサブエージェントワークフローと併用する方が良いです。 - プロンプティングのコツを活用する
「substantive workの前にadvisorに確認して」や「完了前にadvisorとダブルチェックして」といった明示的な指示をシステムプロンプトに入れると、Advisor呼び出しのタイミングがより正確になります。
実践のヒント： Advisorの呼び出しはトークン台帳に別行として記録されます。Advisorがコスト対効果を出しているかプロジェクトごとに追跡できます。また/compactで会話を圧縮してもAdvisorの過去のアドバイスは保持されるため、長いセッションで知識の蓄積レイヤーとして機能します。
さらに深掘りしたい人へ
限界も把握しておきましょう： Advisorの出力はストリーミングされないため、サブ推論中にストリームが一時的に止まります。また、メインモデルが過信するとAdvisorを呼び出さないという問題があります——プロンプトで補完することが重要です。
Advisorの真の可能性は単独機能ではなく、将来のモデル戦略におけるインフラという点にあります。もしOpusよりはるかに高価な次世代モデル（Mythosなど）が登場したとしても、それをメインで使うのはコストが高すぎます。しかしAdvisorとして設定すれば、核心的な意思決定だけに次世代モデルの知性を活用しながら、コストを管理可能な水準に保てます。
Anthropicの公式ドキュメントによれば、コーディング作業でSonnetをmedium effortに設定してOpus Advisorを付けると、default effortのSonnet単独と同等の知性をより低コストで得られます。最大限の知性が必要な場合はdefault effort + Advisorの組み合わせが最強です。
サブエージェントとAdvisor、どちらを使うべきでしょうか？SonnetがメインならAdvisorが正解です。Opusがメインならサブエージェント（独立コンテキスト）の方が良いです。実はAdvisorはトランスクリプト全体を共有するため、メインモデルが問題を誤ってフレーミングするとAdvisorも同じ罠にはまる可能性があるからです。一方、サブエージェントはクリーンなコンテキストから始まるので、新鮮な視点を提供できます。
