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

opusplanとは何か

opusplanは、Claude Codeのmodel設定に指定できる特殊なエイリアスです。plan modeの間はOpusで計画を練り、承認して実行フェーズに移るとSonnetへ自動的に切り替わります。上位モデルの推論力を計画づくりだけに充て、実装は単価の低いモデルに任せる構成が、手動でモデルを切り替えずに成立します。

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

opusplanはどう設定するか

セッション中に切り替えるだけなら/modelコマンドで指定します。選択は新しいセッションの既定値としても保存されます。

/model opusplan

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

claude --model opusplan

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

{
  "model": "opusplan"
}

プロジェクト単位で「plan modeから始めてopusplanで運用する」構成にしたい場合は、defaultMode: "plan"をあわせて設定します。セッション起動時から自動でplan modeに入り、そのままOpusでの計画が始まります。plan modeの入り方・抜け方の基本操作はPlan Modeの使いどころ完全ガイドにまとめています。

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

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

plan modeを抜ける経路は2つあります。1つは提示された計画を承認する経路で、承認すると選んだ実行モードに切り替わり、Claudeが編集を始めます。もう1つは、計画をまとめないままShift+Tabをもう一度押して手動で抜ける経路です。どちらの経路でも、plan modeを離れた時点でopusplanはSonnetに切り替わります。逆に、実行フェーズの途中でもう一度Shift+Tabかplan modeに入ればOpusに戻り、往復のたびに同じ切り替えが繰り返されます。

この切り替えは実質的にモデルの切り替えそのものです。プロンプトキャッシュはモデルをまたいで引き継がれないため、plan modeに出入りするたびに直前までの会話をキャッシュなしで再処理することになります。plan modeを何度も往復して方針を練り直すタスクでは、このコストが積み上がる点に注意が必要です。詳しい仕組みはClaude Codeのトークン節約術で扱っています。

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

plan mode中のOpusフェーズは、opus単体を選んだときと同じコンテキストウィンドウを使います。Max・Team・Enterpriseプラン(Team StandardとTeam Premiumの両方の座席を含む)では、Opusが追加設定なしで100万トークンへ自動アップグレードされます。opusplanのplan modeフェーズも、このアップグレードをそのまま受け取ります。

Max・Team・Enterpriseでは100万トークンが及ぶのはplan modeのOpusフェーズだけで、実行フェーズのSonnetは通常の枠のままです。対象外プランではplan modeフェーズも自動では100万トークンになりません。計画と実行の両方を強制的に100万トークンにしたいときは、opusplan[1m]という書式を使います。

/model opusplan[1m]

[1m]サフィックスは、opusplanのplan modeフェーズを含めてopus・sonnetエイリアスの利用箇所すべてに100万トークンウィンドウを適用します。対応プランと料金は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万トークンで動作します)。

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という明確な境界でだけ切り替わる点が違います。切り替えの主導権を自動判断に委ねたいか、モードという明示的な境界で管理したいか。どちらを選ぶかはこの違いで決まります。

よくある質問

plan modeに一度も入らなければopusplanはどう動きますか

実行フェーズのモデルであるSonnetのまま動きます。opusplanは「plan modeに入ったときだけOpusに切り替わる」設定なので、plan modeを使わないセッションでは通常のSonnet運用と変わりません。

常時Opus固定(/model opus)との違いは何ですか

常時Opus固定は、plan modeを抜けて実装フェーズに入ってもOpusのままです。opusplanは実装フェーズだけSonnetに切り替わるため、実装量が多いタスクほど単価差が効いてきます。設計の質を落とさずコストだけ抑えたい場合はopusplanが基本の選択肢です。

HaikuセッションでもOpusと同じような格上げは起きますか

起きます。Haikuセッションがplan mode中にSonnetへ格上げされる場面でも、許可リストのルールは同じです。許可されたSonnetが1つも無いときだけ、Haikuのまま計画が進みます。

Bedrock・Foundry等のプロバイダーでも同じように格下げされますか

されません。これらのプロバイダーはモデルidがプロバイダー固有で、許可リストの照合方法自体が異なります。特定バージョンへ固定したい場合は、ANTHROPIC_DEFAULT_OPUS_MODELにプロバイダー側の識別子を直接指定する運用になります。

opusplan[1m]はどんなときに必要ですか

Max・Team・Enterprise以外のプランで、plan modeの計画フェーズだけでなく実行フェーズのSonnetにも100万トークンウィンドウを強制したいときに使います。自動アップグレードの対象プランでは、opusplan単体でもplan modeフェーズは既に100万トークンを受け取っています。

まとめ

opusplanは、plan mode中はOpus、実行フェーズはSonnetに自動で切り替わるClaude Codeのモデル設定です。/model opusplan・--model opusplan・settings.jsonのmodelキーのいずれかで設定できます。切り替えの境界はplan modeへの出入りそのものです。1Mコンテキストは対応プランならplan modeフェーズに自動で及び、そうでなければopusplan[1m]で両フェーズに強制できます。availableModelsで最新のOpusが制限されている場合、Anthropic APIとClaude Platform on AWSでは、許可された中で最も新しいバージョンへ自動的に降格します。組織の許可リスト運用と衝突しにくい設計です。plan modeを何度も往復するとキャッシュ再処理のコストが乗る点だけ踏まえておけば、設計と実装でモデルを使い分けたい場面の既定の選択肢になります。