Claude Codeに /advisor コマンドがベータ導入されました（2026年3月〜、ツール型識別子 advisor_20260301 より）。設定するだけで、コーディング中にClaudeが自分で「上位モデルに相談」してくれる仕組みです。
サブエージェントと組み合わせると、相談→実装→レビューのワークフローが回せます。この記事では、それぞれの仕組みと使い分け、Maxプランでの最適な構成を公式ドキュメントベースでまとめます。
アドバイザーとは何か
アドバイザーは、実行モデル（Executor）が作業中に「自分より賢いモデル」へ自動で相談する仕組みです。
例えばSonnet 4.6がコードを書いている最中に複雑な設計判断にぶつかると、Opus 4.6に自動でアドバイスを求めます。相談は1回の /v1/messages リクエスト内で完結し、サーバー側で別の推論パスが走って結果が返ってきます。ユーザーが何かする必要はありません。
いつ発動するのか
Anthropicの公式システムプロンプトはこう指示しています（原文意訳）。
実質的な作業の前にadvisorを呼べ。書く前、解釈を確定する前、仮定の上に積み上げる前に。ファイルを探す・資料を取ってくるといった「方向付け（orientation）」は実質的な作業ではない。書く・編集する・答えを宣言することが実質的な作業だ。
つまり発動タイミングは次のとおりです。
- 実装に取りかかる前 ── 探索が終わった段階で最初の相談
- タスク完了を宣言する前 ── 成果物をファイル保存・コミット済みにしてから最終相談
- スタックした時 ── 同じエラーが繰り返し出る・収束しない時
- 方針転換を検討する時 ── 今のアプローチを続けるべきか迷った時
「数ステップ以上のタスクでは、アプローチを決める前に1回、完了宣言前にもう1回」が公式推奨の最小構成です。
設定方法
Claude Code CLIで以下を実行するだけです。
/advisor
アドバイザーモデルの選択肢が表示されるので選びます。プロンプトのカスタマイズや追加設定は不要です。
内部的には anthropic-beta: advisor-tool-2026-03-01 ヘッダを付けて、次のようなツール定義をリクエストに注入しています。
{
"type": "advisor_20260301",
"name": "advisor",
"model": "claude-opus-4-6"
}
実行モデル/アドバイザーの有効な組み合わせ
公式の制約として、アドバイザーは実行モデル以上の知能でなければなりません。有効なペアは次の3つだけです。
| Executor | Advisor |
|---|---|
| Claude Haiku 4.5 | Claude Opus 4.6 |
| Claude Sonnet 4.6 | Claude Opus 4.6 |
| Claude Opus 4.6 | Claude Opus 4.6 |
無効なペア（例：Sonnetをadvisorに指定）をリクエストすると 400 invalid_request_error が返ります。
ベンチマーク（公式の数値）
Anthropicが公表している数値です。
- SWE-bench Multilingual：Sonnet + Opus advisor は Sonnet単独比で +2.7ポイント、タスクあたりコスト -11.9%
- BrowseComp：Haiku + Opus advisor は 41.2%（Haiku単独 19.7% の約2倍）
- アドバイザー出力は通常 400〜700テキストトークン（thinking込みで1,400〜1,800）
重要なのは「より賢くなる」だけではなく「Sonnet単独より安い」という点です。アドバイザーが不要なツール呼び出しや会話の冗長化を減らすため、全体コストが下がります。
サブエージェントとは何か
サブエージェントは、メインのエージェントとは別のコンテキストウィンドウで動く独立したClaudeインスタンスです。
Claude Codeには組み込みのサブエージェントが3種類あります。
| 名前 | モデル | 役割 |
|---|---|---|
| Explore | Haiku | 読み取り専用、コードベース探索 |
| Plan | 親から継承 | 読み取り専用、plan modeの調査 |
| general-purpose | 親から継承 | 全ツール使用可、複雑な多段作業 |
/agents コマンドで独自のサブエージェントを作成でき、~/.claude/agents/*.md または .claude/agents/*.md にYAML frontmatter付きMarkdownで定義します。
---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---
You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.
アドバイザーとの決定的な違い
| アドバイザー | サブエージェント | |
|---|---|---|
| コンテキスト | 会話の全履歴を見る | 必要な情報だけ渡される |
| 実行単位 | 同一リクエスト内の sub-inference | 独立したエージェント呼び出し |
| ネスト | ─ | サブエージェントは別サブエージェントをspawn不可 |
| 強み | 文脈を踏まえた的確な助言 | バイアスに引きずられない新鮮な視点 |
| 弱み | 会話のバイアスを引き継ぐ | 全体の文脈を知らない |
なぜ「新鮮な視点」が重要か
同じOpus 4.6でも、コンテキストが違えば結論が変わります。
会話の流れで誤った前提が積み上がっていると、アドバイザーはその前提を引き継いで相談相手になってしまいます。一方、サブエージェントは要件だけ渡されたフレッシュな状態なので、そもそも「前提がおかしい」と再定義できる可能性が高いです。
これがサブエージェントの固有価値で、Opus実行時に特に効いてきます。
両方を組み合わせたワークフロー
アドバイザーとサブエージェントは排他ではなく、組み合わせて使うのが最も効果的です。
1. 相談 → アドバイザー（Opus）に方針を確認
2. 実装 → Sonnetがコード変更
3. 検証 → サブエージェントが実装結果をレビュー
4. 修正 → レビュー指摘があれば対応
5. 報告 → 変更内容と検証結果をユーザーに報告
この流れをCLAUDE.mdに書いておけば、毎回自動で回すことができます。
CLAUDE.mdに追加するプロンプト例
## Advisor活用ルール
- 実装に着手する前に、まずアドバイザーに方針・設計を相談すること
- 複数ファイルにまたがる変更の前には必ずアドバイザーに確認する
- 同じエラーを2回繰り返したら、自力で試行を続けずアドバイザーに相談する
## Sub-agent レビュールール
- コード変更の実装が完了したら、必ずサブエージェントを起動して以下を確認すること：
1. 変更内容が元の要件を満たしているか
2. 既存機能への副作用がないか
3. エッジケースの考慮漏れがないか
4. セキュリティ上の問題がないか
- レビューで問題が見つかった場合は修正してから報告すること
## ワークフロー（この順序を守ること）
1. アドバイザーに方針を確認
2. コード変更を実装
3. サブエージェントでレビュー＋テスト実行
4. レビュー指摘があれば修正
5. 変更内容と検証結果をユーザーに報告
Maxプランならどう構成すべきか
API従量課金ではアドバイザーのOpusトークンはOpusレート課金ですが、Maxプランは定額制なのでレート制限内であれば積極的に使った方がお得です。
推奨構成：Sonnet 4.6実行 + Opus 4.6アドバイザー
これが日常コーディングのスイートスポットです。Sonnetの速度とOpusの知性を両取りできます。
公式のコスト最適化テクニック2つも覚えておくと便利です。
- Sonnetをmedium effortで動かす と、Opus advisorとの組み合わせでデフォルトeffortのSonnet単独と同等の知能が出る（Anthropic内部テスト）
-
システムプロンプトに
The advisor should respond in under 100 words and use enumerated steps, not explanations.を追加 すると、アドバイザー出力トークンが35-45%削減される（呼び出し頻度は変わらず）
Opus枠にも余裕がある場合
実行モデル自体をOpusにする選択肢もありますが、その場合はアドバイザーよりもサブエージェントの方が付加価値が大きいです。
理由はシンプルで、Opus + Opusアドバイザーは「同じ知能レベルの自分に会話バイアスごと相談する」ようなものなので、知能ブーストが薄いからです。一方、サブエージェントなら新鮮なコンテキストで並列推論できるため、Opus同士でも意味があります。
| 状況 | 推奨構成 |
|---|---|
| Maxプラン（通常利用） | Sonnet実行 + Opusアドバイザー |
| Opus枠に余裕あり | Opus実行 + サブエージェント活用 |
| 重要なタスク | Sonnet実行 + Opusアドバイザー + サブエージェント全部盛り |
opusplanとの違い
Claude Codeには以前から /model opusplan というモードがあります。Opusで計画、Sonnetで実装の二段階方式です。
/advisor との違いはタイミングです。
- opusplan → 最初に計画、あとは実行。途中で再相談できない
- advisor → 実装中いつでも相談できる。必要な時だけ発動
opusplanは「設計書を書いてから作る」感じ。advisorは「作りながら先輩に聞ける」感じです。作業中に想定外の問題が出た時に対応できるのはadvisorの方です。
注意点・既知の制限
公式ドキュメントに明記されているもの
- ベータ版（2026年4月時点）
-
ストリームが一時停止する。アドバイザー実行中は
server_tool_useブロックが閉じてから結果が届くまでSSEが停止し、約30秒ごとに keepalive ping が飛ぶ（短い相談だとpingも出ないことあり） - Vertex AI・AWS Bedrockでは利用不可（Anthropic直接APIのみ）
-
max_tokensはexecutor出力のみに適用。アドバイザートークンには効かない -
会話レベルの呼び出し上限なし。
max_usesはリクエスト単位。会話全体で制限したい場合はクライアント側でカウントする必要がある - Priority Tier は executor と advisor で別々に契約が必要
-
Context editing の
clear_tool_usesは advisor tool ブロックと互換性未完成（follow-up release予定）
コミュニティで報告されているもの
-
LiteLLM経由は互換性問題（Issue #25516）。プロキシがベータヘッダと
server_tool_use/advisor_tool_resultブロックを正しく扱えない時期がありました - Haiku 4.5をexecutorにした場合のCLI側バグが報告されています（API自体は公式にサポート済み）
コスト管理のためのTips
-
max_usesを設定してアドバイザー呼び出し数に上限を付ける（コーディングタスクでは2-3が典型） - 会話内で3回以上アドバイザーを呼ぶ見込みなら
caching: {type: "ephemeral", ttl: "5m"}を有効化すると損益分岐を超える - 短いタスクではcachingをオフにしておく
まとめ
Claude Codeの /advisor とサブエージェントは、単なる便利機能ではなくモデルの賢さをコストと切り離して組み立てる仕組みです。
- アドバイザー = 作業中に賢いモデルへ自動相談（同一リクエスト内、会話文脈を共有）
- サブエージェント = 新鮮な視点で独立レビュー（別コンテキスト、別インスタンス）
- 両方をCLAUDE.mdに書いて自動化
Maxプランなら定額なので、レート制限内で積極的に使えます。まずは /advisor を設定して、CLAUDE.mdにレビュールールを追加するところから試してみるのがよさそうです。
公式ベンチではSonnet+Opus advisorはSonnet単独比で精度が少し上がり、コストもやや下がる結果が出ています。タスク依存なので、自分のワークロードで評価するのが確実です。