Advisor Strategyとは何か
Advisor Strategyはエンスロピックが公式に発表した構造だ。実行はSonnetやHaikuのような低コストモデルが担い、そのモデル自身が判断に行き詰まったと感じた瞬間だけ、API呼び出しでOpusを呼んで助言を受ける。Opusは常に待機しているのではなく、オンデマンドでのみ登場する。
組織にたとえるとわかりやすい。実務はインターンが処理し、本当に行き詰まったときだけ上司に尋ねる。上司はずっと席にいるのではなく、呼ばれたときだけ状況を把握して助言する。
構造上、実行モデルとアドバイザーは同じ共有コンテキスト——会話履歴とツール履歴——を見ている。アドバイザーが出した助言は再びその共有コンテキストに記録され、実行モデルはそれを見て次の行動につなげる。一回のAPI呼び出しの中で全体が処理されるため管理がシンプルで、アドバイザーが使ったトークンは別途レポートされ、コストも分けて追跡できる。
なぜ今回の発表が重要なのか
コスト差は実在する。Opusは出力トークン100万個あたり25ドル、Haikuは5ドルで、五倍の差がある。一日に数千件を処理するサービスをすべてOpusで運用すれば、コスト負担は大きい。
かといって安いモデルだけを使えば性能は落ちる。コストを下げながら性能を維持する、あるいは両方を同時に改善する地点を見つけることが、この戦略の存在理由だ。
ベンチマークは何を示しているか
これはエンスロピック自身が2026年4月9日、公式ブログ記事「The advisor strategy: Give Sonnet an intelligence boost with Opus」で公開した実測結果だ。この発表では、実行モデルはSonnet 4.6とHaiku 4.5、アドバイザーはOpus 4.6だった。
SWE-bench Multilingualベンチマークでは、SonnetにOpusアドバイザーを付けると、Sonnet単独に比べて性能が2.7パーセントポイント上がり、タスクあたりのコストは11.9パーセント下がった。性能は上がり、コストは下がったのだ。
BrowseCompベンチマークでは、Haiku単独で19.7パーセントだった性能が、Opusアドバイザーを付けると41.2パーセントへと二倍以上に跳ね上がった。ただしこの組み合わせはSonnet単独より29パーセントポイント低いスコアだが、タスクあたりのコストは85パーセント安い。以下はエンスロピックが公開した数値をまとめたものだ。
| ベンチマーク | 構成 | 性能の変化 | コストの変化 |
|---|---|---|---|
| SWE-bench Multilingual | Sonnet単独 → Sonnet+Opusアドバイザー | +2.7pt | -11.9% |
| BrowseComp | Haiku単独 → Haiku+Opusアドバイザー | 19.7% → 41.2% | - |
| BrowseComp | Haiku+アドバイザー vs Sonnet単独 | -29pt | -85% |
四つの戦略を並べて比較すると
実務で選べる選択肢は大きく四つに分かれる。最初から最後までOpusを使う方法、先ほど説明したAdvisor Strategy、Claude Code CLIのopusplan、そして低コストの実行モデルをアドバイザーなしで単独に置く方法だ。
この四つを分ける本当の基準は、モデルの等級ではなく、判断の主導権がどこにあるか、そして実行中に再検証が入るかどうかだ。
| 戦略 | 判断の主導 | 上位モデルの介入 | 実行中の再検証 | 適した状況 |
|---|---|---|---|---|
| Opus単独 | Opus | 常に | 不要(常に最上位) | 曖昧で複雑な一回限りの判断 |
| Advisor Strategy | 実行モデル | 行き詰まったときだけオンデマンド | あり(呼び出すたび) | 積み重なる反復作業、コストと性能を同時に改善 |
| opusplan(CLI) | 計画=Opus / 実行=Sonnet | 計画段階で一回 | なし | 計画さえ精密であればよい作業 |
| 実行モデル単独 | 実行モデル | なし | なし | 単純な作業。複雑になると試行錯誤が急増するリスク |
opusplanはAdvisor Strategyとどう違うのか
Claude Code CLIで同じ発想を使う方法が/model opusplanだ。計画モードではOpusが設計を担い、実行モードに切り替わると自動的にSonnetが引き継ぐ。
ただし決定的に異なる点がある。Advisor Strategyは実行中でも行き詰まればいつでも再びOpusを呼べて、呼ぶたびにアドバイザーが実行モデルの作業を改めて検討する。opusplanは計画段階で一度介入すると、実行が終わるまでOpusは二度と見返さない。再検証ループが構造的に欠けているのだ。
だからopusplanは、計画がすでに緻密で実行中に逸脱するリスクが低い作業には十分だが、実行途中で判断が揺れ続ける作業では、その空白がそのままリスクとして残る。
実務ではどう選べばよいか
判断基準は二つだ。その作業が低コストモデルで対応できる難易度かどうか、そして一回限りの作業か、複数ステップが積み重なる長期の作業かどうか。
曖昧で複雑な判断が続くならOpusが最後まで握る方が安全だ。定型的な労働が大量に積み重なる長期作業ならAdvisor Strategyでコストを大きく減らせる。計画さえ一度精密に立てればよい作業ならopusplanで十分だ。
ただし、低コストの実行モデルをアドバイザーなしで複雑な作業に単独で置くのは避けるべきだ。自分でいつ止まるべきか判断できず試行錯誤が急増し、結果として総コストがOpus単独より高くなるという逆説が起こりうる。
AXの観点からこれが意味すること
この構造は実は新しい技術ではなく、見慣れた組織設計だ。実務者が行き詰まったときに上司に尋ね、上司は常に待機せず呼ばれたときだけ介入する。組織が長く使ってきた委任構造を、そのままAIパイプラインに移したものだ。
違うのは、この委任の境界と呼び出しのルールをコードとして明示できることだ。何回まで呼べるか、どんな条件で呼ぶか、その呼び出しのコストをどう追跡するかを、すべて設定値として制御できる。
AI導入を検討する組織であれば、問いを「どのモデルを使うか」から「この判断をどこに配置するか」へと変えるべきだ。モデル選びより役割設計こそが、コストと品質を同時に決める時代になっている。