Advisor Strategyとは｜Opus AdvisorでSonnet・Haikuを底上げするClaude API構成と実装

Advisor Strategyは、Anthropicが2026年4月9日に公開したClaude APIの構成パターンです。安価なExecutorモデル（Sonnet 5やHaiku 4.5）がタスク全体を駆動し、判断に迷った局面でだけ上位のAdvisorモデル（Opus 4.8／4.7）へ相談させることで、Opus級の推論をSonnet級のコストで引き出します。従来のマルチエージェント構成が大型モデルにタスク分解を委ねる「トップダウン型」だったのに対し、Advisor Strategyは小型モデルが主導権を持つ「ボトムアップ型」です。この記事では、仕組みと従来型との違い、ベンチマークの実測値、advisor_20260301ツールの実装、有効なモデルペア（2026年時点の最新）、そして導入が裏目に出るケースまでを、実装判断に使える粒度で整理します。

まとめ：Advisor Strategyの要点と導入判断

• 正体：Executor（実行役）とAdvisor（助言役）を分離し、Executorが必要なときだけAdvisorへ相談するClaude API標準のツール（advisor_20260301、ベータ）。追加のオーケストレーション実装は不要で、tools配列に1エントリ足すだけで動く。
• 現在のモデルペア（2026年時点）：AdvisorはOpus 4.8（またはOpus 4.7）、ExecutorはHaiku 4.5・Sonnet 4.6・Sonnet 5・Opus 4.6／4.7から選ぶ。AdvisorはExecutor以上の能力を持つモデルでなければならず、Executorに Opus 4.8 を使う場合はAdvisorも Opus 4.8 に限定される。発表時（2026年4月）はOpus 4.6がAdvisorだったが、上位モデルの登場に合わせてペアは更新されている。
• 効果（Anthropic発表値・発表時モデルで計測）：SWE-bench MultilingualでSonnetのスコアが72.1%→74.8%（+2.7ポイント）、同時にタスク単価が11.9%低下。BrowseCompではHaikuが19.7%→41.2%へ倍増し、Sonnet単体比で約85%安く処理できた。
• 向く場面：コーディング・マルチステップ調査・Computer Use・高頻度バッチなど、長く続くエージェントタスクで判断ポイントが点在するワークロード。
• 向かない場面：単発のQ&Aやシンプルな生成、全ターンでOpus級推論が要るタスク、ユーザーがモデルを選ぶパススルー型プロダクト。
• コストの注意点：AdvisorトークンはAdvisorモデル（Opus単価）で課金される。max_usesで相談回数の上限を決めないと、Advisorの呼び過ぎでOpus単体と大差ない費用になり得る。
• 提供範囲：Claude APIとClaude Platform on AWSでベータ提供。Amazon Bedrock・Google Vertex AI・Microsoft Foundryでは利用できない。

Advisor Strategyの仕組みと従来サブエージェント構成との違い

Advisor Strategyの核心は、タスク実行を担うExecutorと戦略的助言を与えるAdvisorの役割分離にあります。従来型のマルチエージェント構成との違いは、どちらのモデルが主導権を握るかという点に集約されます。ここでは2層構造の設計、単一リクエストで完結するサーバーサイド処理、そしてトップダウン型との構造的な差を順に見ていきます。

Executor＋Advisorの2層構造が役割を分ける仕組み

Executorには処理速度が速く単価の低いSonnetまたはHaikuを配置し、ツール呼び出し・結果処理・出力生成という一連の作業を一貫して担当させます。Advisorには推論能力の高いOpusを据え、Executorが自力では解決困難と判断した局面だけ介入させます。フロンティアレベルの推論が必要な箇所にだけOpusのコストが発生するため、大半のターンはSonnetまたはHaikuの料金で処理されます。

Advisorが1回の相談で返すのは、Anthropicによれば通常400〜700テキストトークン程度の短い計画や方針です。具体的な実装計画、現在のアプローチへの修正指示、あるいはタスク中断を促すストップシグナルの3種類に大別され、いずれもExecutorがそのまま実行に移せる粒度で記述されます。たとえばコーディングタスクなら「チャネルベースの協調パターンを使い、シャットダウン時はまず入力チャネルを閉じてからWaitGroupで待機する」といった実装方針が返り、Executorの試行錯誤を減らします。重要な制約として、Advisorはツールを呼び出せず、ユーザーへ直接出力も返しません。役割を「Executorへの助言」に限定することで、予期しない副作用やAdvisorの応答がエンドユーザーに露出する事態を構造的に防いでいます。

単一リクエストで完結するサーバーサイド処理とラウンドトリップゼロ設計

Advisor Strategyの技術的な特徴は、Executorからの相談とAdvisorからの応答がすべて単一の/v1/messagesリクエスト内で完結する点です。開発者側で追加のAPIコールやコンテキスト管理を行う必要はありません。Executorが相談を決めると、サーバーサイドで自動的にAdvisorへルーティングされ、応答がExecutorに返された上で生成が継続されます。

従来のマルチモデル構成では、モデル間のコンテキスト受け渡しや応答の統合をアプリケーション側で実装する必要がありました。Advisor Strategyではこの複雑なオーケストレーションが不要になり、ラウンドトリップが増えないためレイテンシの増大も最小限に抑えられます。相談時には、システムプロンプト・全ツール定義・過去の全ターン・全ツール結果を含むフルトランスクリプトがAdvisorへ自動提供されるため、開発者がコンテキストの選別や圧縮を行う必要もなく、情報の欠落リスクもありません。

トップダウン型オーケストレーションとの構造的な差

従来のマルチエージェント構成の多くは、最も高性能な大型モデルがオーケストレーターとしてタスクを複数のサブタスクに分解し、小型のワーカーモデルへ委任するトップダウン型でした。この方式ではオーケストレーターが全工程で常時稼働するため高単価モデルのトークン消費が続き、さらにタスク分解の粒度設計・コンテキスト受け渡し・結果の整合性チェック・エラーハンドリングといったロジックの実装保守工数が膨らみます。

Advisor Strategyはこの構造を逆転させ、SonnetやHaikuが制御権を保持したまま、自力で対処できない判断に直面したときだけOpusへエスカレーションします。人間の組織で担当者が基本業務を遂行し、重要な意思決定だけ上長に相談する形に近い設計です。利点のうち最も大きいのはコストの予測性です。大型モデルのトークン消費が相談時のみに限定されるため費用の見積もりが立てやすく、加えてタスク分解というプロセス自体が不要になりオーケストレーション層の開発工数がゼロに近づきます。さらにExecutorが一貫してタスクを実行するため、文脈の断絶やワーカー間の整合性問題も構造的に排除されます。マルチエージェントの設計パターンを俯瞰した上で選定したい場合は、Anthropic公式のマルチエージェント協調5パターンと比較すると、Advisor型がどの位置づけにあるかを把握しやすくなります。

移行時によくある失敗は、既存のオーケストレーションロジックをそのまま残したままAdvisorを追加してしまうケースです。分解・委任の仕組みが不要になるにもかかわらず従来のタスク分解層を残すと、構成が無駄に複雑化してコスト削減効果も薄れます。もう一つの典型は、Executorが自力で処理できるターンでも毎回Advisorを呼び出す設定にしてしまうことで、この場合はOpusのトークンコストが積み重なりOpus単体と大差ない費用になります。

SWE-bench・BrowseCompで示された性能とコストの実測値

Advisor Strategyの効果は、Anthropicが公開した複数のベンチマークで具体的な数値として示されています。以下の数値はいずれも発表時（2026年4月）のモデル構成、すなわちSonnet 4.6またはHaiku 4.5をExecutor、Opus 4.6をAdvisorとした場合の計測値である点に注意してください。

SWE-benchで72.1%→74.8%（+2.7pt）とコスト11.9%削減の内実

SWE-bench Multilingualは多言語環境でのソフトウェアエンジニアリングタスクを評価するベンチマークです。Sonnet単体のスコアが72.1%だったのに対し、Opusをアドバイザーとして併用した構成では74.8%を記録し、2.7パーセントポイントの改善が確認されました。SWE-benchの上位帯では1ポイントの改善にも大きな技術的困難が伴うことを踏まえると、意味のある向上です。注目すべきは、この改善がコスト増ではなくタスク単価11.9%の低下と同時に達成された点です。

ただしAnthropicの脚注によれば、Sonnet単体はadaptive thinking有効、Advisor併用構成はthinking無効という異なるテスト条件で測定されており、純粋な構成差による改善幅とは断定できません。自社での導入検討時は、この条件差を織り込んだ上で参考値として扱うのが安全です。

BrowseCompで19.7%→41.2%へ倍増したHaiku構成の理由

BrowseCompはウェブブラウジングタスクの性能を評価するベンチマークで、ここでのHaikuの改善幅が最も大きくなりました。Anthropicが公表しているHaikuのスコアとコストは以下のとおりです（Sonnet単体のBrowseCompスコアは非公表のため表には載せていません）。

ブラウジングでは「どのリンクをたどるか」「いつ情報収集を打ち切るか」といった戦略的判断が頻繁に求められ、これはHaiku単体が苦手とする領域です。Advisorがこれらの判断ポイントで的確な方針を示すことでHaikuの実行能力が引き出され、単体の約2倍のスコアに達しました。しかもAnthropicの発表ではこの構成のタスク単価はSonnet単体の約15%（約85%減）で、大量のブラウジングタスクを低コストで処理したいケースでHaiku＋Opusが有力な選択肢になります。

ベンチマーク値を自社環境で再現するための前提条件

ベンチマーク結果をそのまま本番環境に当てはめるのは避けるべきです。効果の再現には少なくとも3つの前提が必要です。第一に、タスクの性質がベンチマークと類似していること。SWE-benchはコーディング、BrowseCompはブラウジングに特化しており、異なる性質のタスクでは同じ改善率は得られません。第二に、Executorが適切なタイミングでAdvisorへエスカレーションできるプロンプト設計が整っていること。第三に、max_usesの設定がワークロードの複雑度に合致していること。相談回数を変えれば妥当な値も変わります。導入前は、Sonnet単体構成とAdvisor併用構成を同一タスクセットで並行実行し、タスク完了率・出力品質・合計トークン数・合計コスト・レイテンシを比較するA/Bテストで検証するのが確実です。Sonnet 4.6単体の詳細なベンチマークはClaude Sonnet 4.6の性能・料金解説が参考になります。

advisor_20260301ツールの実装とmax_uses制御

Advisor Strategyの導入は技術的にはシンプルです。既存のMessages APIリクエストにツール定義を1つ追加し、ベータヘッダーを付与するだけで動作します。ここでは最小構成から、有効なモデルペア、コスト制御、レスポンス解析までを解説します。

最小構成コードとベータヘッダー

Advisorツールの必須パラメータは、typeにadvisor_20260301、nameにadvisor、modelにAdvisorモデル名を指定する3項目です。加えてリクエストにベータフラグadvisor-tool-2026-03-01を含めます。ExecutorモデルはトップレベルのモデルIDで指定し、Advisorはtools配列に置きます。既存のWeb検索・コード実行ツールと同列に並べて共存させることもできます。

client.beta.messages.create(
    model="claude-sonnet-5",          # Executor
    max_tokens=16000,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {"type": "advisor_20260301", "name": "advisor", "model": "claude-opus-4-8"},
    ],
    messages=[...],
)

ツール定義の順序は動作に影響しないため、配列内の位置を気にする必要はありません。既存のツール設定を変更せず追加できるため、稼働中のエージェントへの導入も低リスクで実施できます。

有効なExecutor-Advisorペア（2026年時点の最新）

ExecutorとAdvisorの組み合わせには制約があり、AdvisorはExecutor以上の能力を持つモデルでなければなりません。無効なペアを指定すると、APIは400ステータスのinvalid_request_errorを返します。2026年時点で有効な組み合わせは次のとおりです。

発表当初（2026年4月）はOpus 4.6がAdvisorの標準で、ExecutorはSonnet 4.6かHaiku 4.5でした。その後Opus 4.7・4.8やSonnet 5が登場し、Advisorはより上位のOpus 4.8／4.7に、ExecutorにはSonnet 5も選べるように更新されています。無効ペアで拒否されやすいのはモデルのバージョン指定を誤るケースなので、実装時は最新のモデル文字列を確認し、送信前にペアの整合性をチェックする仕組みを組み込むと安全です。Sonnet 5とOpus 4.8の料金差や使い分けはClaude Sonnet 5とOpus 4.8の違い・料金の解説、Advisorに使うOpus 4.7の詳細はClaude Opus 4.7の性能・料金で確認できます。

max_usesによるリクエスト単位のコスト制御

max_usesは、1回のAPIリクエスト内でAdvisorを何回まで呼び出せるかを制限するコスト制御機構です。デフォルトでは制限されないため、コストを予測可能にしたい場合は明示的な指定が推奨されます。たとえばmax_usesを3に設定すれば相談は最大3回に制限され、上限到達後はExecutorが自力で判断を継続します。

実務上は少ない値から始めて段階的に調整するのが定石です。コーディングタスクではアーキテクチャ決定・エラー解決・最終確認の3回程度で足りることが多く、3が妥当な出発点になります。複数ツールを連続利用するリサーチ系では中間評価や方針転換のタイミングが増えるため、5〜7回程度が適切な場合もあります。設定値が低すぎると品質が落ち、高すぎるとコスト削減効果が薄れるため、自社タスクでのテスト結果を見ながら値を決めます。

レスポンス構造とトークンの分離計測

Advisor Strategyを利用したAPIレスポンスには、通常のテキストブロックに加えてserver_tool_useとadvisor_tool_resultの2種類の特殊ブロックが追加されます。server_tool_useはExecutorがAdvisorを呼び出したタイミングを示し（inputは通常空）、advisor_tool_resultのcontentフィールドにAdvisorの応答が格納されます。既存のレスポンスパーサーがtypeフィールドで処理を分岐している場合は、この2つの新しいtypeへの対応を追加してください。マルチターンで会話を続ける際は、advisor_tool_resultブロックを含むresponse.content全体を次のリクエストへ戻す必要があります。

コスト管理では、AdvisorトークンとExecutorトークンの分離計測が重要です。レスポンスのusage.iterations[]配列には各推論パスのトークン消費が個別に記録され、トップレベルのusageにはExecutorトークンのみが集計されます。このデータを蓄積し、Advisor呼び出し1回あたりの平均トークン消費・1リクエストあたりの呼び出し回数・Advisor利用率を追跡すれば、コストと品質のバランスを継続的に調整できます。1回あたりの消費が想定の400〜700トークンを大幅に超える場合は、プロンプト設計やエスカレーション判断に問題がある可能性を示唆します。

ユースケース別の推奨構成（コーディング・調査・バッチ処理）

Advisor Strategyは汎用的なパターンですが、Advisorの介入タイミングやmax_usesの値、Executorの選択はタスクの複雑度・長さ・必要な推論レベルで変わります。代表的な3つのユースケースについて、推奨構成とその根拠を示します。

コーディングエージェント：Sonnet Executor＋max_uses 3〜5

コーディングはAdvisor Strategyが最も効果を発揮する領域の一つです。コード記述や軽微なバグ修正はSonnetで十分こなせる一方、設計パターンの選択やモジュール間の依存関係の整理には高度な推論が要ります。推奨はSonnet 5をExecutor、Opus 4.8をAdvisor、max_usesを3〜5とする構成です。Executorが個々のファイル修正やテスト実行を自律的に進め、新しいモジュールの設計方針やリファクタリング戦略を決める場面でAdvisorに相談します。SWE-benchで示された2.7ポイントの改善が、この構成の安定した品質向上を裏づけます。従来のサブエージェント方式でコーディングを分担していた場合の設計は、Codexサブエージェントの使い方と比較すると差分が明確になります。

マルチステップ調査：中間結果を評価するmax_uses 5〜7

Web検索やドキュメント取得を繰り返すリサーチ型パイプラインでは、「次に何を探すか」「収集した情報は十分か」という戦略的判断が全体の効率を左右します。Executorが検索・取得・要約を高速に処理し、調査方針の決定や中間成果の品質評価をAdvisorが担う構成が効果的です。max_usesは5〜7回が目安で、初期の方針設定、中間結果の評価と方向修正、最終成果物の構成確認という各フェーズでAdvisorが介入します。Computer Use（画面操作の自動化）でも同様に、定型操作はExecutorが高速に進め、予期しないダイアログや複数の操作経路が現れた非定型の判断でのみAdvisorへエスカレーションする構成が有効です。

高頻度バッチ処理：Haiku×Opusで約85%削減とドメイン特化

1日に数百〜数千件を処理する高ボリューム環境では、Haiku 4.5をExecutorとする構成が最もコスト効率に優れます。Haikuの単価はSonnetより大幅に低く、処理量が増えるほどコスト差が拡大します。BrowseCompの実測どおり、Haiku単体では性能不足な領域でもOpus Advisorの支援で実用水準まで引き上げられ、Sonnet単体比で約85%のコスト削減が可能です。バッチではmax_usesを1〜2回に絞り、タスク冒頭で方針をAdvisorに確認し以降はHaikuが自力で完了する構成にすると、Advisorコストを全体の微小な割合に抑えられます。

金融リサーチやポリシー文書生成のようなドメイン特化型では、情報収集・整形・下書きはExecutorが担い、分析の方向性や結論の妥当性判断をAdvisorが確認する構成が実用的です。この種のタスクではAdvisorの介入が最終出力の正確性に直結するため、max_usesをやや多め（5〜8回）に設定して品質を優先する判断が妥当です。タスクの複雑度にばらつきがある場合は、難易度を分類してHaiku ExecutorとSonnet Executorへ振り分けるハイブリッド構成も検討に値します。

Advisor Strategyが不向きなケースとコスト計算の落とし穴

Advisor Strategyは万能ではありません。特定の条件下ではAdvisorの追加がオーバーヘッドとなり、性能向上よりコスト増が上回ります。導入判断を誤らないために、不向きなパターンとコスト計算の盲点を押さえておきます。

単発Q&A・全ターンOpus級・パススルー型は不向き

Advisor Strategyは長期的なエージェントタスクで真価を発揮する設計であり、単発の質問応答やブログ下書き・メール文面のようなシンプルな生成には向きません。Executorが最初から最後まで自律的に完了できるため、Advisorが呼ばれることはほとんどなく、tools配列が肥大化する分だけリクエストのトークンがわずかに増えるだけになります。

タスクの全ステップで高度な推論が求められるワークロード、たとえば高度な数学的推論や複雑な法律文書の解釈では、Executorがほぼ毎ターンAdvisorに相談する状況になり、Opusのトークンコストが頻発してExecutorの低コスト処理という利点が失われます。この場合はOpus単体で処理したほうがコスト・品質・レイテンシのすべてで有利です。また、エンドユーザーが使用モデルを自分で選ぶパススルー型プロダクトでは、バックエンドが勝手にAdvisorを追加するとユーザーの意図しないコスト増やユーザー体験の一貫性の崩れを招くため、導入するならAdvisor併用を明示してオプトイン方式にするのが適切です。

Advisorトークンの課金体系を誤解した想定外コスト

よくある誤解の一つは「Advisorのトークンもexecutorの単価で課金される」という思い込みです。実際にはAdvisorのトークンはAdvisorモデル（Opus単価）で課金されるため、Advisorが多く呼ばれるほどOpus単価のトークンが積み上がります。もう一つは「Advisorは400〜700トークンしか生成しないからコストは無視できる」という過小評価です。1回あたりのトークン数は限定的でも、max_usesを高めに設定した状態で1日に数千リクエストを処理すればAdvisorトークンの累積は無視できない金額になります。たとえば1リクエストあたりAdvisorが5回・各700トークンを消費すると3,500トークン分のOpus料金が上乗せされ、これが1日1,000リクエストで350万トークン分のOpus課金になります。導入前にusage.iterations[]のデータでコストをシミュレートし、予算内に収まる設定を確認してから本番投入することが不可欠です。

よくある質問

Advisor Strategyとは何ですか？

Anthropicが2026年4月9日に公開したClaude APIの構成パターンで、安価なExecutorモデルがタスクを駆動し、判断に迷ったときだけ上位のAdvisorモデルへ相談させる仕組みです。advisor_20260301ツールとして提供され、tools配列にAdvisorの定義を追加しベータフラグadvisor-tool-2026-03-01を付けるだけで動作します。Opus級の推論をSonnetやHaikuのコストで得ることを狙った設計です。

opus advisorには現在どのモデルを使いますか？

2026年時点では、AdvisorにOpus 4.8またはOpus 4.7を指定します。発表当初はOpus 4.6が標準でしたが、上位モデルの登場に合わせて更新されています。AdvisorはExecutor以上の能力を持つ必要があるため、ExecutorにOpus 4.8を使う場合はAdvisorもOpus 4.8に限定されます。

Sonnet 5でもAdvisor Strategyは使えますか？

使えます。Sonnet 5はExecutorとして有効で、Advisorには上位のOpus 4.8またはOpus 4.7を組み合わせます。Haiku 4.5・Sonnet 4.6・Opus 4.6／4.7もExecutorに指定できます。無効なペア（AdvisorがExecutorより低能力）を指定すると400エラーになります。

Advisor Strategyでコストはどのくらい下がりますか？

Anthropicの発表値では、SWE-bench MultilingualでSonnet併用構成がタスク単価11.9%低下、BrowseCompではHaiku＋Opus構成がSonnet単体比で約85%安く処理できました。ただしこれは発表時のモデルとテスト条件での値で、実際の削減率はタスクの性質・Advisorの呼び出し頻度・max_usesの設定に依存します。

max_usesは何回に設定すべきですか？

ワークロードによります。コーディングは3〜5回、マルチステップ調査は5〜7回、高頻度バッチは1〜2回が目安です。低すぎると品質が落ち、高すぎるとOpusトークンが積み上がってコスト削減効果が薄れるため、少ない値から始めて自社タスクで実測しながら調整するのが確実です。

Amazon BedrockやVertex AIでも使えますか？

2026年時点では、Advisor StrategyはClaude APIとClaude Platform on AWSでベータ提供されており、Amazon Bedrock・Google Vertex AI・Microsoft Foundryでは利用できません。これらのプラットフォームで同等の効果を得たい場合は、アプリケーション側で明示的にモデルを切り替えるマルチモデル構成を検討します。

関連記事

• Anthropic公式が示すマルチエージェント協調5パターンの全体像と選定意義
• Claude Sonnet 5とは？料金・Opus 4.8との違いと移行の判断基準
• Claude Opus 4.7とは？性能・料金・上位モデル4.8との違いと使い方
• Claude Sonnet 4.6とは？性能・料金・ベンチマークと後継Sonnet 5との違い
• Codexサブエージェントとカスタムエージェントの使い方