opusplanとは — Claude CodeのPlan modeだけOpusを使う設定

opusplanとは何か

opusplanは、plan modeの間だけOpus、承認して実行に移るとSonnetへ自動で切り替わる、Claude Codeの特殊なエイリアスです。有効にするには、セッション中に/model opusplan、起動時にclaude --model opusplan、恒常的にはsettings.jsonに"model": "opusplan"を書きます。opus planのように空白を入れず、opusplanと1語で指定します。

上位モデルの推論力を計画づくりだけに充て、実装は単価の低いモデルに任せる構成が、手動で切り替えずに成立します。

default・sonnet・opus・haikuといった他のエイリアスは、どの局面でも同じモデルを指します。opusplanだけは権限モード(permission mode)によって指す先が変わるという点で毛色が異なります。opusplanが指す実体はプロバイダーごとに異なり、詳細は次の表のとおりです。

表の値は、公式のモデル設定ページにあるopus・sonnetエイリアスの解決先と同じです。Opus 5.5にはv2.1.280以降、Sonnet 5.5にはv2.1.284以降が必要で、これより古いバージョンは別のモデルに解決されます。手元のv2.1.286でclaude --helpを見ると、--modelの説明は次のとおりでした。「最新モデルのエイリアス(例: 'fable'、'opus'、'sonnet')か、モデルのフルネーム」です。opusplanは例に出ませんが、前述の特殊エイリアスとして受け付けられます。

opusplanはどう設定するか

セッション中に切り替えるだけなら/modelコマンドで指定します。選択は新しいセッションの既定値としても保存されます。ただし、Claude Desktopの「Code」タブでは/model opusplanが「Unsupported model」で失敗する不具合が報告されています。症状と回避策はopusplanが「Unsupported model」で失敗するClaude Desktopの不具合にまとめています。

/model opusplan

起動時から使いたい場合は--modelフラグを渡します。この場合は今回の起動限りの指定です。

claude --model opusplan

恒常的な既定値にするなら、settings.jsonにmodelキーとして書きます。

{
  "model": "opusplan"
}

「plan modeから始めてopusplanで運用する」構成にしたい場合は、起動時のモードも指定します。1回だけなら次のとおり、2つのフラグを並べます。v2.1.286のclaude --helpでは、--permission-modeの選択肢は6つでした。acceptEdits・auto・bypassPermissions・manual・dontAsk・planです。

claude --permission-mode plan --model opusplan

プロジェクトの既定にするなら、.claude/settings.jsonのpermissions.defaultModeにplanを書きます。キーはpermissionsの中にある点に注意してください。トップレベルにdefaultModeを置いても、公式の設定リファレンスにそのキーはありません。

{
  "model": "opusplan",
  "permissions": {
    "defaultMode": "plan"
  }
}

VS Code拡張が開始する会話は、プロジェクト設定の起動モードを読みません。その場合はVS Codeのユーザー設定でclaudeCode.initialPermissionModeをplanにします。plan modeの入り方・抜け方の基本操作はPlan Modeの使いどころ完全ガイドにまとめています。

Plan modeと実行フェーズでいつ切り替わるか

opusplanの切り替え条件は、計画の承認ではなく、plan modeに入っているかどうかです。Shift+Tabでモードを循環させるか、プロンプトの先頭に/planを付けると、その間はOpusが応答します。

計画フェーズでOpusが働くあいだも、Claudeはシェルコマンドを走らせて調べものをします。auto modeが使え、useAutoModeDuringPlanが有効(既定でオン)なら、組み込みの読み取り専用コマンド以外はclassifierが審査して、承認されたものが実行されます。auto modeが使えないか設定がオフなら、そうしたコマンドは承認を求める画面になります。計画の途中で承認待ちが出るのは、opusplanの仕様ではなくplan modeの権限規則によるものです。

plan modeを使わないセッションでは、最初から最後までSonnetです。opusplanを設定しただけでOpusが呼ばれることはなく、通常のSonnet運用と変わりません。

この切り替えは、実質的にモデルの切り替えそのものです。Claude Codeのキャッシュはモデルごとに別で、モデルを替えると同じ内容でもリクエスト全体が再計算されます。plan modeに出入りするたびにモデルが替わり、新しいキャッシュから始まります。plan modeを何度も往復して方針を練り直すタスクでは、このコストが積み上がります。詳しい仕組みはClaude Codeのトークン節約術で扱っています。

切り替えまわりの不具合も1件ありました。v2.1.286以前では、opusplanでOpus 5.5とSonnet 5.5が切り替わるときに、それまでのextended thinkingが失われることがありました。v2.1.287で修正されています。

コンテキストウィンドウはどう扱われるか

opusplanのコンテキストウィンドウは、計画フェーズがopus、実行フェーズがsonnetの設定と同じ大きさです。専用の枠があるわけではありません。

Anthropic APIでは、Sonnet 5以降とOpus 4.7以降が、Proを含むすべてのプランで100万トークンのウィンドウで動きます。[1m]を付ける必要も、使用量クレジットを有効にする必要もありません。Opus 5.5とSonnet 5.5はこの条件に入るので、opusplanは追加設定なしで両フェーズが100万トークンです。プランによって計画フェーズだけが100万トークンになる、という区別は現行の公式記述にありません。

Opus 4.6とSonnet 4.6は、[1m]を付けた場合にだけ100万トークンに届きます。Opus 4.6の100万トークンは、Max・Team・Enterpriseでは契約に含まれます。ProではOpus 4.6もSonnet 4.6も使用量クレジットが必要です。Microsoft Foundryのopusplanは計画フェーズがOpus 4.6なので、[1m]を付けない限り計画フェーズは20万トークンです。プランや使用量クレジットの条件が検査されるのは、Anthropic APIに直接つなぐ場合だけです。

100万トークンが標準でない環境で、両フェーズに適用したいときはopusplan[1m]と書きます。

/model opusplan[1m]

/modelでこの書式を指定できるのはv2.1.265以降です。それより古いバージョンでは、--modelフラグかmodel設定を使います。対応モデルと料金はClaude 1Mコンテキストの実務活用にまとめています。

ANTHROPIC_DEFAULT_OPUS_MODELでバージョンを固定している場合は、モデルIDの末尾に[1m]を付けます。[1m]は環境変数ごとに別々に読まれます。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryでは、ANTHROPIC_DEFAULT_OPUS_MODELとANTHROPIC_DEFAULT_SONNET_MODELの両方に付けないと、付け忘れたほうは20万トークンのままです。Sonnet 5はこれらのプロバイダーでも常に100万トークンで動くため、付ける必要がありません。

100万トークンを抑えたいときは、CLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定します。Sonnet 5のようにネイティブで100万トークンのモデルも、200Kのウィンドウとして扱われます。

availableModelsでOpusが制限されている場合の挙動

組織がavailableModelsで最新のOpusを許可リストから外し、古いバージョンだけ許可している場合(例: ["sonnet", "claude-opus-4-6"])があります。この場合opusplanは、許可されている中で最も新しいOpusを計画フェーズに使います。Sonnetに落ちるのは、許可リストにOpusが1つも残っていないときだけです。同じ規則は、plan mode中にSonnetへ格上げされるHaikuセッションにも及びます。許可されたSonnetが1つも無いときだけ、Haikuのまま計画を進めます。

この「古い許可バージョンへの格下げ」が働くのは、Anthropic APIとClaude Platform on AWSに限られます。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・Mantleは、モデルidがプロバイダー固有です。これらの環境では、アップグレード先のモデルが許可リストから外れていても、plan modeはセッションのモデルのまま据え置かれます。古いバージョンへの自動格下げは起きません。Claude Code v2.1.205より前のバージョンには、この格下げの仕組み自体がありませんでした。最新バージョンが許可リスト外なら、古いバージョンが許可されていてもセッションのモデルのまま据え置かれていました。

opusplanが指す2つのモデル名を明示的に固定したい場合は、環境変数を使います。ANTHROPIC_DEFAULT_OPUS_MODELはplan modeが有効なときのopusplanの実体を制御します。ANTHROPIC_DEFAULT_SONNET_MODELはplan mode以外のときの実体を制御します。組織で許可バージョンを厳密に固定運用したい場合、この2変数をsettings.jsonのenvか管理設定に書いておく方法が確実です。

opusplanが効くタスクと効かないタスク

opusplanは万能のコスト削減策ではありません。複雑な計画が長引けば、単価の高いOpusの呼び出し時間もそのぶん伸びます。実際のコストは、タスクの性質と会話の長さで決まります。利用形態別に見ると、向き不向きがはっきりします。

「メインは軽く保ったまま要所だけ強いモデルの目を入れたい」場合は、Claude Code advisorという別の仕組みもあります。advisorはタスク中の判断ポイントごとにClaude自身が呼び出しを判断します。opusplanはplan modeという明確な境界でだけ切り替わる点が違います。切り替えの主導権を自動判断に委ねたいか、モードという明示的な境界で管理したいか。どちらを選ぶかはこの違いで決まります。

常時Opus固定とopusplanは何が違うか

どちらも計画にはOpusを使います。違いは、計画を終えたあとの実装フェーズです。

まとめ

opusplanは、計画の質を上げたいが実装まで高い単価を払いたくないタスクに向く設定です。逆に、実装中にも難しい判断が続く作業や、plan modeを何度も出入りする作業では、/model opusで固定する選択肢があります。組織で許可リストを運用している管理者は、2つの環境変数で両フェーズのモデルを明示しておくと、プロバイダーごとの差に左右されません。全体像はClaude Code完全ガイドにあります。