Claude Code Advisorとは？仕組みや使い方、コスト効果を解説

Claude Code Advisorは、Sonnetを実行役・Opusを助言役として1つのAPIリクエスト内で組み合わせるマルチモデル戦略機能です。
2026年4月にAnthropicがAPI向けに発表し、その後Claude CodeにCLIコマンド「/advisor」として統合されました。

「Sonnetは軽くて安いが判断が難しい場面で頼りない、Opusは強いが常時運用は高い」というジレンマに対し、実行の大半はSonnetに任せ、方針決定・エラー再発・完了直前など「判断が難しい瞬間」だけOpusに相談する構造で応えています。

本記事では、Advisorの仕組み・使えるモデル組み合わせ・有効化方法・課金構造・opusplanやsub-agentsとの使い分け・制約と導入時の判断ポイントまでを、Claude Code実務目線で整理します。

Claude Code Advisorとは？Opusを助言役として使うマルチモデル戦略

Claude Code Advisorとは、実行モデル（Sonnet／Haiku）とは別に、より高性能なモデル（Opus／Fable）を「助言役」として1つのリクエスト内でペア運用する仕組みです。

Anthropicが2026年4月9日に「The advisor strategy」としてAPIで発表し、その後Claude Codeに「/advisor」コマンドとしてCLI側にも統合されました。

2026年現在、Claude Codeで長時間のリファクタや繰り返しエラーのデバッグを回すと、「Sonnetは十分に速いが要所で外す」「Opusで通すと料金が跳ねる」というトレードオフに突き当たります。

Advisorはこの構造そのものに介入する仕組みで、普段は軽い実行モデルに走らせ、方針決定・エラー再発・完了直前など「判断が難しい瞬間」だけOpusに相談させるという設計です。

Advisorが破る「品質とコストのトレードオフ」

ここまで見たAdvisorのペア運用は、抽象論としてはシンプルですが、Anthropicが外部公開ベンチマーク（SWE-bench Multilingual・BrowseComp・Terminal-Bench 2.0）を用いて行った評価では、「品質を上げるためにコストが上がる」という常識を数字で突破する結果が公表されています。

本セクションでは公式blog（The advisor strategy）とClaude Platform公式docsが公表している3種類の測定結果を整理します。

SWE-bench Multilingualで+2.7pt／コスト-11.9%

コーディングエージェントの業界標準ベンチマークであるSWE-bench Multilingualでは、Sonnet 4.6単独に対してSonnet 4.6+Opus 4.6 advisorが以下の結果を出しています。

以下の表で、SWE-benchでの実測差を整理しました。

通常、AIエージェントの品質を上げようとすると上位モデルへの切り替えが必要になり、コストは同じ方向に増えます。Advisorはこのトレードオフを破っており、「安くなって、しかも良くなる」という組み合わせが成立するのが特徴です。

BrowseCompでHaikuが2倍以上に化ける

Web閲覧タスク向けのBrowseCompベンチマークでは、より小さいモデルへの効果が顕著です。以下の表で結果を整理しました。

Haiku単独では2割弱しか取れなかった問題を、Advisor付きで4割超まで押し上げています。Sonnet単独と比べるとまだ下回りますが、その差は「タスクあたりコスト-85%」と引き換えです。

つまり「Sonnet相当の精度は不要だがコストを徹底的に下げたい大量処理」向けに、Haiku+Advisor構成が新たな選択肢として立ち上がりました。

Terminal-Bench 2.0でも同傾向

ターミナル操作のTerminal-Bench 2.0（89タスク、5試行平均）でも、Sonnet+Opus advisorはSonnet単独よりスコアが向上しています。

加えて前述のBolt・Genspark・Eve Legalなど早期採用企業からも、複雑タスクでの設計判断改善・エージェント運用の改善・フロンティアモデル並の精度を維持したまま5倍のコスト削減という評価が寄せられており、単一ベンチマークの偏りではなく複数タスクで再現しています。

ここまでの数字が示しているのは、Advisorが「オーケストレーターで巨大モデルが小さいモデルを指揮する」従来のマルチエージェント構造とは逆で、小さい実行モデルが自律的に走り、必要なときだけ強いモデルにエスカレーションするという新しい役割分担が現実的に機能する、という事実です。

Advisorの内部動作——ExecutorとAdvisorの役割分担

Advisorが「実行モデルの脇に強いモデルを常時待機させる」以上、内部でどう動くかを押さえておかないとコスト設計もデバッグもできません。

本セクションではAnthropic公式docs（Advisor tool - Claude Platform Docs）に沿って、AdvisorとExecutorの役割・呼び出し経路・完結範囲を整理します。

Executor（実行役）とAdvisor（助言役）の分担

Advisor Strategyは、1つのAPIリクエスト内で2つのモデルが役割を分担して動きます。

• Executor（実行役）
  Sonnet／Haikuなど軽い実行モデル。ツール呼び出し・ファイル編集・コード実行など、ユーザーに返す成果物を作る側。会話全体をエンドツーエンドで進める。
  
  

• Advisor（助言役）
  Opus／Fableなど高性能モデル。ツールを呼ばず、ユーザーにも直接返答しない。Executorから相談を受けたときだけ「計画・軌道修正・停止シグナル」を数百トークンで返す参謀ポジション。

Advisorはあくまで「助言専業」で、Executorの成果物に直接手を入れないのが構造上のポイントです。

人間チームで例えるなら、ジュニアエンジニアが実装を回し、シニアが設計レビュー・障害切り分けだけ担当するイメージに近い分担になります。

いつAdvisorが呼ばれるか——モデル判断ベース

Advisorはユーザーが手動で呼び出すのではなく、Executor自身が「この場面で相談すべきか」を判断します。Anthropic公式docsによれば、以下のような場面でExecutorがAdvisorを呼ぶ傾向があります。

• 方針を決める直前（どのアプローチで進めるか迷ったとき）
• 同じエラーが繰り返し出て詰まったとき
• タスク完了を宣言する直前のセルフレビュー

逆に、単純な反復処理や情報取得のような場面ではAdvisorは呼ばれません。Anthropicは「呼び出し回数はモデル判断」と明示しており、ユーザーが強制的に呼ばせたい場合はプロンプトで「advisorに相談してから進めて」と依頼する形になります。

単一APIリクエスト内で完結する設計

もう1つの重要な特徴は、ExecutorとAdvisorのやり取りが単一の「/v1/messages」リクエスト内で完結する点です。

従来、複数モデルを協調させるにはクライアント側でリクエストを分けて、モデル間のコンテキスト受け渡しを実装する必要がありました。Advisorではこれをすべてサーバー側で処理します。

• Executorが判断を要する場面に到達
• サーバー側でAdvisorに会話全文を渡し助言を取得
• Advisorの助言をExecutorが受け取り、実装を継続
• 完了までクライアントには通常のレスポンスが返る

クライアント視点では「1リクエスト送って1レスポンス受け取る」という構造は変わらないため、既存エージェント基盤への組み込みハードルが極端に低くなっています。

追加のオーケストレーション層・キューイング・状態管理を実装せずに、モデル階層化の恩恵だけ受けられる形です。

Advisorに使えるモデル組み合わせマトリックス

Advisorは「どんなモデルにも自由に助言をつけられる」わけではなく、アドバイザーはメインモデル以上の性能でないと受理されないという制約があります。

Anthropic公式docs（Claude Code /advisor）が定めるペアリング条件と、実務でよく使う組み合わせを整理します。

受理されるメイン×アドバイザーの対応表

以下の表で、メインモデルごとに受理されるアドバイザーを整理しました。

この対応表から読み取れるのは、Advisorは「上位モデルから下位モデルへの助言」だけを許可する片方向の制約になっているという点です。

同格モデル同士のペア（Opus 4.7同士など）は、意図的なダブルチェック運用として認められています。

実務でよく使う組み合わせ

以下の表で、実務で選ばれやすい組み合わせと使いどころを整理しました。

実務で最初に試すべき組み合わせは Sonnet main + Opus advisor です。ベンチマーク実測が最も安定しており、Sonnet単独からの移行コストがほぼゼロで済みます。

Haiku main + Opus advisorは「品質より速度・コスト最優先」の運用に振った選択肢で、Sonnet相当の精度が必要な場面には使い分けが必要になります。

Claude Codeでの有効化と3つの設定方法

Advisorを実際にClaude Codeで動かすには、3通りの設定方法があります。以下の表で3方法を整理しました。

それぞれ使いどころが違うため、日常運用と一時検証で使い分けるのが実務的です。

「/advisor」 コマンドでセッション中に切り替える

セッション実行中に「そろそろOpusの目で見てほしい」と思ったら、以下のコマンドで即時切り替えます。

/advisor opus

引数なしで 「/advisor」 を打つとモデルの選択ピッカーが開き、Opus／Sonnet／Fableから選べます。選択内容はユーザー設定の 「advisorModel」 に保存されるため、次回起動以降も同じアドバイザーが継続適用されます。

セッションのメインモデルがアドバイザーに対応していない場合でも設定は保存され、対応するメインモデルに切り替えた時点で自動で発動します。

組織側で 「availableModels」 の許可リストが設定されているケースでは、リストにないアドバイザー選択は保存されるものの発動しない挙動になります。

settings.json で永続的に固定する

チームや個人で「常にOpusをアドバイザーに置きたい」場合は、settings.jsonに書いておくのが確実です。

{
  "advisorModel": "opus"
}

この記述をユーザー設定・プロジェクト設定のどちらに書くかで適用範囲が変わります。個人のClaude Code全体で有効にしたければユーザー設定に、特定プロジェクトだけで有効にしたければプロジェクトルートの 「.claude/settings.json」 に書きます。

「--advisor」 フラグで一時的に検証する

「今回のセッションだけAdvisorを試したい」「他のプロジェクトの設定は変えたくない」という一時検証には、起動時フラグが便利です。

claude --advisor opus

このフラグは 「advisorModel」 設定より優先され、そのセッションが終了すると効果は消えます。組織のモデル許可リストや、メインモデルとのペアリング条件を満たさない場合は起動時にエラー終了する点は覚えておくと良いです。

Advisorを完全に無効化する

Advisor機能そのものを止めたい場合は、環境変数で無効化できます。

export CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1

この環境変数がセットされているとき、「/advisor」 コマンドは利用不可になり、保存された 「advisorModel」 の設定も無視されます。「--advisor」 フラグはエラーにはならず、単に効果なしで受理される仕様のため、既存のCI／自動化スクリプトを書き換えずに機能停止だけ行えます。

Advisorの課金構造と実務コスト設計

Advisorは「Opusを常時走らせるより安い」という言い方をされますが、内部ではExecutorとAdvisorの両方が別々にトークンを消費します。実務でコスト設計を狂わせないために、課金構造の骨格を押さえておく必要があります。

2モデル分の課金が別立てで発生する

Advisorが呼ばれるたびに、その時点までの会話全文がアドバイザーモデルに渡されます。つまり課金は以下の2軸で発生します。

• Executor分: Sonnet／Haikuなど実行モデルのinput／outputレート
• Advisor分: Opus／Fableなど助言モデルのinput／outputレート（呼ばれた回数だけ）

API課金ならそれぞれのモデル単価が加算され、Max／Proなどサブスクリプションプランではプランの利用制限枠に両方が計上されます。

Advisor分は「/usage」コマンドで確認できるセッション合計にも含まれます。

なぜ「常時Opus」より安く済むのか

前述のとおりAdvisorは全ターン呼ばれるわけではなく、方針決定・エラー再発・完了直前など判断が難しい瞬間だけ呼ばれます。

呼び出し比率について公式に公表された値はありませんが、公式docsは「判断点で呼ぶ」「タイミングはモデル判断」と説明しており、「/usage」コマンドでセッションごとの実測を確認するのが安全です。

このため、以下のような単純化された比較になります。

• Sonnet main + Opus advisor: Sonnet単価 × 全ターン + Opus単価 × 助言呼出ターン
• Opus単独運用: Opus単価 × 全ターン

Opusの単価がSonnetより高く、助言呼出ターンが全体の一部で済むため、SWE-bench Multilingualでは「Sonnet単独より+2.7pt・かつコスト-11.9%」というほぼ最適化された結果に着地しています。

ただしClaude Codeでは、Advisorの呼び出し回数を強制・固定する設定は用意されていません。

極端に長いセッション・繰り返しエラーが多いセッションでは、想定以上にAdvisorが呼ばれる可能性があります。API直利用の場合は、リクエスト側で「max_uses」（呼び出し回数上限）・「max_tokens」（Advisor出力トークン上限）・advisor-side cachingを設定してコストを抑えることができます。

プロンプトキャッシュへの影響

Anthropic公式docs（Escalate hard decisions with the advisor tool）によれば、Advisorの有効化・無効化を途中で切り替えても、メインモデル側のプロンプトキャッシュは無効化されません。モデル切替や思考レベル変更と違い、「/advisor」 トグルは既存キャッシュを保持する挙動です。

一方で、Claude Codeの「/advisor」ではAdvisorモデル自身の読み込みはキャッシュされません。

Advisorが呼び出されるたびに会話全文が新規で処理されるため、長時間セッションでは1回あたりの助言呼び出しコストが徐々に重くなります（API直利用でcachingを設定すればAdvisor側にもprompt cachingを効かせられます）。

長時間タスクを想定するなら、Advisorの呼び出しコストが会話長に比例して増える前提でコスト予測を立てるのが安全です。

他の「強いモデルを絡ませる仕組み」との使い分け

Claude Codeには、Advisor以外にもモデルの強弱を組み合わせる機能が複数存在します。以下の表で、代表的な4手段を整理しました。

この表が示すとおり、Advisorは「判断が難しい瞬間だけ強いモデルを呼ぶ」という最も細かい粒度のマルチモデル運用手段です。

opusplanとの違い——プラン時か実行中か

opusplanは「プランモード中はOpus、実行はSonnet」という設計文書型の使い分けで、Claude Codeで長い実装タスクに入る前の設計段階に強いモデルを充てたい場合に有効です。

Advisorとの違いは「Opusが動くフェーズ」です。opusplanは計画段階に完結し、実行フェーズに入るとOpusは出番なし。Advisorは実行フェーズの最中にも判断点でOpusに相談が飛ぶ、という粒度の差になります。

長い実装タスクをOpus品質で最初から設計しつつ、実行中の分岐にも保険をかけたいなら、opusplan＋Advisorの併用も設計として成立します。

Sub-agentsとの違い——独立コンテキストか同一コンテキストか

Sub-agentsは独立したコンテキスト・システムプロンプト・ツール許可リストを持つワーカー会話を切り出す機能で、モデルもサブエージェントごとに指定できます。特定領域（テスト・レビュー・調査など）を専門のエージェントに委譲するのに向いています。

Advisorは同一会話コンテキスト内での助言取得なので、「1つのタスクを進める中で強いモデルの目を借りたい」場面向け。

Sub-agentsは「別コンテキストとして専門タスクを丸ごと委譲したい」場面向け、と役割分担できます。なおSub-agentsは、そのサブエージェント自身のペアリング条件を満たせば設定済みAdvisorを継承する仕様です。

AI総研としてのケース別推奨

支援現場での使い分けの傾向を整理すると、以下のような判断軸に落ち着きます。

• 既存プロジェクトへの後付け・低コストで試したい → Advisor 一択
  記述はsettings.jsonへの1行追加だけで済み、他機能への影響がない
  
  

• 長時間のリファクタや大規模設計変更 → opusplan＋Advisor併用
  計画段階はopusplanで、実行中の分岐はAdvisorで拾う二段構え
  
  

• テスト・レビュー・調査を専門エージェント化したい → Sub-agents単体
  Advisor付けても本題のExecutorが動かないため、そもそもSub-agentsに寄せる
  
  

• ダブルチェックが監査要件になっている業務 → Opus main + Opus advisor
  同格ペアで独立レビュー体制を作る。金融・法務などのユースケース

「安く済ませたい」からAdvisor、「品質を絶対落としたくない」だけならopusplanかOpus main切替、「役割ごとに人格を分けたい」ならSub-agents、というのが実装現場のざっくりした住み分けです。

Advisorの制約と、導入前に押さえたい3つのこと

Advisorはコスト×品質のトレードオフを破る強力な仕組みですが、環境制約と設計判断の両方で気をつけるべきポイントがあります。本セクションでは、導入前に必ず確認したい制約と、実務で判断に迷いやすい3つの観点を整理します。

環境制約——Claude Codeの/advisorとAPI版で切り分ける

Advisorは提供経路によって対応環境が異なります。Claude Codeの「/advisor」コマンドを使う場合と、API版のadvisor tool（「advisor_20260301」）を直接叩く場合とで、利用できるクラウド経路が変わる点は特に注意が必要です。

以下の表で対応環境を整理しました。

Claude Code経由でAdvisorを使うにはAnthropic API直の接続が必須で、Bedrock・Vertex・Foundry経由では動作しません。API版のadvisor toolはClaude APIに加えてClaude Platform on AWS経由でもbeta提供されますが、Bedrock・Vertex・Foundryは依然として未対応です。

企業ですでにBedrock／Vertex／Foundry経由でClaudeを利用している組織は、AdvisorのためにClaude API直またはClaude Platform on AWSへの経路確保が導入前提になります。

LLMゲートウェイ経由の場合も、ゲートウェイがAnthropic APIへリクエストを素通しする構成なら動作しますが、独自ロジックを差し込むゲートウェイでは動かないことがあります。

いつ有効化すべきか

Advisorは「あらゆる場面で有効」ではありません。判断点が少ない短いタスクではAdvisorが呼ばれず、単に環境変数が1つ増えるだけの状態になります。

有効化に向いているのは以下のような場面です。

• 大規模リファクタリング（複数ファイルの一貫した書き換え）
• 繰り返しエラーが出るデバッグセッション
• 完了判定を独立レビューしたい重要タスク
• 長時間のマルチステップ実装

逆に、単純な1〜2ファイル修正・情報検索のみ・短いプロトタイピングでは、Advisorのメリットが薄くなります。

「常時オン」で運用したい気持ちは分かりますが、短時間タスクに対しては呼び出しがゼロで実質無関係、という状態が続くだけです。

どのモデル組み合わせを選ぶか

前述のマトリックスで組み合わせ候補は絞れますが、実務ではさらに以下の3軸で判断します。

• 現在のメインモデル: すでにSonnet運用なら、Sonnet main + Opus advisorで即試せる
• 求める品質水準: Sonnet相当以上が必須ならSonnet main、Sonnet未満でも許容ならHaiku main
• 月あたりの想定タスク量: 少量ならOpus単独運用も検討余地あり、大量ならAdvisorに寄せる

「Sonnet単独でも回るがOpusの目が欲しい局面が10%以上ある」というプロジェクトがAdvisor導入の判断ライン、とAI総研の支援現場では捉えています。

既存プロジェクトへの後付け適用のリスク

既存の実装フローにAdvisorを後付けする際に見落としがちなのが、プロジェクト側の「.claude/settings.json」と個人設定の優先順位です。

プロジェクト設定が存在する場合、個人の「advisorModel」はプロジェクト設定に上書きされます。

個人開発では動いていたAdvisorが、チームリポジトリで作業した瞬間に効かなくなる、という現象がここで起きます。導入時は以下を確認するのが安全です。

• チームリポジトリの「.claude/settings.json」にadvisorModelが記述されているか
• 個人設定とチーム設定が矛盾していないか
• 組織の「availableModels」許可リストにアドバイザーモデルが含まれているか

これはClaude Code設定ガイドで解説している設定継承ルールと同じ挙動なので、あわせて確認しておくと事故が減ります。

Claude Code運用と並行して、社内業務プロセスもAgent化するなら

Claude Code Advisorは、Claude Codeを"モデルを切り替える"から"モデルを組み合わせる"へ進化させる仕組みで、Sonnet main + Opus advisorでSWE-bench +2.7pt / コスト-11.9%を同時達成できるようになりました。

ただしAdvisor・Sub-agents・opusplanといった機能は開発ワークフロー側の最適化に閉じた話で、経費精算・請求書処理・稟議書レビュー・仕様書ドラフト・保全帳票入力といった開発以外の社内業務プロセスは、Claude Code運用とは別レイヤーの実行基盤を持つほうが、認証・課金経路・ガバナンスを分けて設計できます。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。
AI総合研究所のAI Agent Hubは、AI-OCR Agent・自動入力Agent・フロー判定Agentなど9種類の業務特化Agentを、SAP Concur・freee会計・Dynamics 365・Salesforce・勘定奉行クラウドといった基幹システムと繋げ、Microsoft Teamsから呼び出せる形でパッケージ化しています。

開発側のClaude Code最適化と、業務側のAgent実行基盤を別レイヤーで並行運用することで、開発生産性と業務自動化を両輪で伸ばせます。

AI総合研究所の専任チームが、開発ワークフローと業務プロセスの両面でAI組み込み設計から運用まで伴走支援します。AI Agent HubのLPで、Claude Codeが担う開発領域とは別レイヤーの、社内業務プロセスへのAIエージェント組み込みの全体像をご確認ください。

開発と業務、両輪でAIエージェント運用

Claude Code運用と別レイヤーで業務Agent化

Claude Code AdvisorやSub-agentsは開発ワークフロー側の最適化に閉じた話で、経費精算・請求書処理・稟議書レビュー・保全帳票入力といった開発以外の社内業務プロセスは別レイヤーで基盤化するのが現実的です。AI Agent HubのLPで、Claude Code運用と並行運用できる業務プロセスAgent実行基盤の全体像をご確認ください。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

Claude Code Advisorは、実行モデルと助言モデルを1リクエスト内でペア運用することで、これまで両立が難しかった「品質向上」と「コスト削減」を同時に成立させる仕組みです。

• Sonnet main + Opus advisorはSWE-bench Multilingualで+2.7pt・コスト-11.9%を実現する現実的な第一候補
• Claude Codeでは「/advisor」コマンド・settings.json・「--advisor」フラグの3経路で有効化できる
• アドバイザーはメインモデル以上の性能が必須。Claude Codeの「/advisor」はAnthropic API必須、API版はClaude Platform on AWSでもbeta提供、Bedrock／Vertex／Foundry経由は未対応
• opusplanは計画時のみ、Sub-agentsは独立コンテキスト、Advisorは判断点だけ、と粒度で使い分ける
• 導入判断は「判断点が10%以上あるタスクか」「プロジェクト設定と個人設定が矛盾していないか」を軸に整理する

2026年に入ってOpus 4.8・Sonnet 5・Fable 5と上位モデルの選択肢が広がる中、モデルを「切り替える」から「組み合わせる」への移行が実務で加速しています。Advisorはその第一歩として、既存のClaude Code運用に最小の変更で組み込める仕組みです。

まずは「/advisor opus」を1セッション試し、「/usage」で実際のトークン消費を測ってから、settings.jsonへの永続化を判断するのが現実的な導入手順になります。