Claude Media
Claude CodeのadvisorModelでAdvisorの既定モデルを指定する
Claude CodeTips

Claude CodeのadvisorModelでAdvisorの既定モデルを指定する

advisorModelはAdvisorが答えるモデルを保存する設定キーです。書き込むのは通常/advisorピッカーで、手動編集は検証が効かず静かに無効化されることがあります。

読了目安 約7分

advisorModelとは何か

advisorModel は、Claude Codeがサーバー側のadvisorツールを呼ぶときに、どのモデルへ相談するかを保存する設定キーです。~/.claude/settings.json などの設定ファイルに書き込まれ、キーが無い(unset)状態が既定で、その場合advisorはオフになります。

値の型は文字列です。"fable" "opus" "sonnet" のエイリアス、または "claude-opus-5" のようなフルのモデルIDを受け付けます。エイリアスはClaude Codeのリリースごとに更新される、そのモデルファミリーの既定バージョンに解決されます。設定ファイルに書く場合はキー1つだけの単純な形です。

{
  "advisorModel": "opus"
}

advisorとして機能するには、メインモデル以上の能力が要求されます。条件を満たさないモデルを指定していた場合、Claude Codeはリクエストをadvisorなしで送るだけで、エラーにはなりません。この検証はキーへの保存時ではなく、リクエスト送信時に毎回行われます。順序が入れ替わって聞こえますが、ここが手動編集の落とし穴の土台になります。

advisorModel 自体は、advisorが提供されない環境でも書き込めてしまいます。Amazon BedrockやAWS上のClaude Platformではadvisorという仕組みそのものが提供されないため、これらの環境で値を設定しても効果を持ちません。"fable" を指定する場合も、usage creditsへの同意とは別にFableアクセス権限がアカウントに必要で、権限が無ければ値は保存されていても呼び出されません。

/advisorピッカーが書き込む値

advisorModel を直接さわらずに済む方法が /advisor コマンドです。引数なしで実行すると、現在の選択・使えるadvisorの一覧・「No advisor」を並べたピッカーが開きます。

/advisor opus

選ぶと Advisor set to に続けてモデル名が表示され、Claude Codeがその値を advisorModel としてユーザー設定へ書き込みます。以降のセッションでもこの値が引き継がれます。

例外が1つあります。Remote Controlのクライアントから選んだとき、またはリモートワーカーに接続したセッションで選んだときは、選択がそのセッションだけに適用され、advisorModel の値自体は変わりません。設定ファイルを見ても選択が反映されていないように見えるのは、この仕様どおりの挙動です。

/advisor はターミナルの対話ピッカーが無い面(-p の非対話モード、Agent SDK、デスクトップアプリ、Remote Control)でも動きます。これにはClaude Code v2.1.260以降が必要です。それらの面では引数なし実行が現在値と使えるエイリアスを表示するだけの読み取り専用になり、/advisor <model> で設定、/advisor off で解除という形に整理されています。

Fableをadvisorに選ぶ場合は、プランによってusage creditsへの課金同意が別途必要です。同意前に /advisor fable を実行しても advisorModel には何も書き込まれず、/model fable の実行を促す案内が出るだけです。

settings.jsonを手動編集するとどうなるか

公式ドキュメントは「通常このキーは手で編集しない」と明記しています。理由は、ピッカーが持っている検証や状態管理を、手動編集では素通りしてしまうからです。

  • 綴りが違っても保存はできます。Claude Codeが認識しないモデルIDを書いても、ファイルの保存自体はそのまま成立します。実際に無効化されるのはリクエスト送信のタイミングで、advisorが黙って紐付かないだけです。エラーメッセージも警告も出ません
  • メインモデルが対応していないadvisorも保存できます。この確認もリクエスト送信時にしか働かないため、advisorに対応しないメインモデルのまま opus と書いても、ファイル上は正常に見えます。これは手動編集に限った挙動ではなく、/advisor ピッカーで選んでも同じです。Claude Codeは現在のメインモデルが対応していないadvisorもそのまま保存し、対応するメインモデルへ /model で切り替えたあとに有効になります
  • 組織の許可リストとの整合は保存時に見ません。管理者が availableModels で許可していないモデルを書いても保存できますが、Claude Codeはそのadvisorを呼び出しません。設定はそのまま残り、組織の許可リストに含まれるモデルを /advisor で選び直すまで、そのadvisorは呼び出されません
  • Fable同意前でも手書きなら保存はできてしまいます。/advisor fable は同意前だと保存自体を拒否して /model fable の実行を促しますが、settings.json に直接 "advisorModel": "fable" と書けば保存はそのまま通ります。ただし実際のリクエストは同意を済ませるまでadvisorなしで送られ続けるため、設定は入っているのに一向に呼ばれない状態になります
  • advisorModel は特定のファイル専用のキーではなく、管理者設定・プロジェクト設定(共有・ローカル)・ユーザー設定のどこにでも書けます。優先順位はmanaged-settings.json(管理者設定)が最も強く、次に .claude/settings.local.json(プロジェクトローカル)、.claude/settings.json(共有プロジェクト)、最後に ~/.claude/settings.json(ユーザー設定)という順です。/advisor ピッカーが書き込むのは一番弱いユーザー設定だけなので、共有プロジェクト設定やローカル設定に別の値が手動で書かれていると、ピッカーで選び直しても見た目上は反映されません

ピッカーを使う一番の理由はここにあります。選べるのは実在するモデルだけなので、綴り違いのモデルIDをそのまま書き込む心配がありません。書き込み先もユーザー設定に固定されているため、共有プロジェクト設定やローカル設定に別の値が残っていても、優先順位のどこに何が書かれているかを見失いにくくなります。

優先順位 — 環境変数・フラグ・設定キー・ピッカー

advisorを制御する仕組みは4段構えで、上にあるものほど下を上書きします。

設定方法効果範囲関係
CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1効果範囲advisor機能そのもの関係最優先。立っているとadvisorModelを書いても効果がない
--advisor <model> フラグ効果範囲起動したそのセッションのみ関係advisorModelより優先。ファイルには保存しない
advisorModel(settings.json)効果範囲以降の全セッションの既定値関係/advisorピッカーが通常書き込む先
/advisorピッカー効果範囲advisorModelへの書き込み手段関係Remote Control等では書き込まずセッション限定になる

CLAUDE_CODE_DISABLE_ADVISOR_TOOL を設定すると、/advisor コマンド自体が使えなくなり、設定済みの advisorModel は無視されます。--advisor フラグは受け付けられますが効果を持ちません。advisorを完全に止めたいときはこちらが確実です。

表3行目の「advisorModel(settings.json)」は単一のファイルを指すのではなく、前節の4ファイルのうち最も優先度が高いものの値を意味します。トラブルシューティングで「どの設定が効いているか分からない」となったら、--advisor フラグや環境変数がまず立っていないかを確認し、次にどのファイルに advisorModel を書いたかを一覧で洗い出す、という順で切り分けます。加えて /status を実行すると、そのセッションで読み込まれた設定ファイルの一覧が Setting sources として表示されるので、どの階層まで設定が読み込まれているかの手がかりになります。ただし /status が示すのはファイルの読み込み有無だけで、advisorModel の値を最終的にどのファイルが供給しているかまでは表示しません。読み込まれたファイルを実際に1つずつ開いて、値を比較する必要があります。

advisorModelを設定しても動かないときに確認すること

値を書いた(あるいはピッカーで選んだ)のにadvisorが呼ばれない場合、切り分けは次の順で行います。

  1. feature flagが取得できているか — advisorはAnthropicから取得するfeature flagで有効化される仕組みです。flag取得を止める環境変数(DISABLE_TELEMETRYなど)が立っているセッションでは、advisorModel を正しく設定していてもadvisorは動きません
  2. Anthropic API経由の接続か — advisorはサーバー側で実行されるツールで、Amazon Bedrock・Claude Platform on AWS・Google CloudのAgent Platform・Microsoft Foundryでは使えません。ANTHROPIC_BASE_URL でLLMゲートウェイを挟んでいる場合は、そのゲートウェイがリクエストをAnthropic APIへそのまま転送しているかに左右されます
  3. メインモデルが対応しているか — advisorに対応するのはFable、Opus 4.6以降、Sonnet 4.6以降、Haiku 4.5です。これより前のモデルをメインにしていると、advisorModel の値にかかわらずadvisorは付きません
  4. ペアリングとして受け付けられる組み合わせか — メインモデルより弱いadvisorは紐付かず、その旨は /advisor の出力や通知に表示されます

Sub-agentsは親セッションの advisorModel をそのまま引き継ぎ、Sub-agent自身のモデルに対して同じペアリング判定を受けます。親では条件を満たしていても、委譲先のSub-agentのモデルが弱ければ、そのSub-agentだけadvisorが外れることがあります。

強いモデルを要所だけ差し込みたい場合、advisor以外にfallbackModel(過負荷時の切り替え)やopusplan(plan modeだけOpusにする設定)もあります。どれも settings.json のキー1つで完結する点は共通ですが、advisorModelが制御するのは「会話の要所でもう1つのモデルに意見を求めるか」であり、他の2つとは効くタイミングが違います。

まとめ

advisorModel はAdvisorが答えるモデルを持つ設定キーで、通常は /advisor ピッカーが書き込みます。手動で編集すること自体は禁止されていませんが、保存時には綴りもペアリングの可否も検証されないため、「ファイルには書けたのに動かない」状態を自分で作り込みやすくなります。値を変えたいときはピッカーか --advisor フラグを使い、settings.json を直接開くのは現在の値を確認するときにとどめるのが安全です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →