Claude Codeの「opusplan」── Opusで考えて、Sonnetで書く、2段階モデル運用

Claude Code には opusplan というモデルエイリアスがある。プランニング段階は Opus 4.6、実行段階は自動的に Sonnet 4.6 に切り替わる設定だ。「Opus の判断力で設計して、Sonnet のスピードで実装する」という2段階の分業をワンコマンドで実現する。

なぜこの分け方が効くのか

Claude Code のセッションで使われるトークンの内訳を見ると、プランニングフェーズが消費するのは全体の 10〜15% 程度。大半は実際のコード生成とファイル編集に使われる。

Opus は Sonnet の約5倍のコストがかかる。つまり「全部 Opus」で回すと、コストの大半を占める実装フェーズに割高なモデルを使い続けることになる。逆に「全部 Sonnet」では、タスク分解や実装順序の判断など、品質を決める上流工程の精度が落ちる。

opusplan はその中間を取る。品質に直結するプランニングだけ Opus を使い、あとは Sonnet に任せる。

仕組み

Claude Code の Plan Mode（shift+tab で切り替わる）がアクティブな間は Opus 4.6 が動く。プランを確定して実行フェーズに移ると Sonnet 4.6 に自動で切り替わる。ユーザーがモデルを意識して切り替える必要はない。

公式ドキュメントには次のように書かれている。

opusplan: Special mode that uses opus during plan mode, then switches to sonnet for execution

設定方法

1
2
3
4
5
6
7
8
# セッション開始時に指定
claude --model opusplan

# セッション中に切り替え
/model opusplan

# 環境変数で固定
export ANTHROPIC_MODEL=opusplan

settings.json に書いておくと常時適用される。

1
2
3
{
  "model": "opusplan"
}

Sonnet だけとの差がどこに出るか

Sonnet はコーディング性能で Opus の約 98% を出す（ClaudeLog の比較記事による）。単発のファイル編集や関数追加なら差は出にくい。

差が出やすいのは「何から手をつけるか」という判断を伴うタスクだ。複数ファイルにまたがるリファクタリング、テスト設計、依存関係の整理など、実装前の構造化が品質に直結する作業では Opus の推論が生きる。

逆に、やることが決まっている単純な実装タスクでは sonnet で十分で、opusplan を使うコストメリットは薄い。

Max・Team Premium ユーザーの注意点

Max プランおよび Team Premium では、デフォルトモデルがすでに Opus 4.6 になっている。この場合 opusplan に切り替えると、実行フェーズが Sonnet に落ちる。Opus のクォータ消費は抑えられるが、実装フェーズの精度が若干落ちる可能性がある。コスト節約より品質を優先するなら opus のままで使う方が合っている。

Pro プランや Team Standard では、デフォルトが Sonnet 4.6 なので opusplan は素直にコスト最適化の手段になる。

1M コンテキストとの組み合わせ

opusplan は [1m] サフィックスで拡張できる。

1
2
3
/model opusplan
# → 環境変数で 1M を指定する場合
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-6[1m]'

大きなコードベースを扱うセッションでは、プランニング段階でコンテキストが埋まりやすい。Opus で広く読んでプランを立て、Sonnet で実装する流れと 1M コンテキストは相性がいい。

「Opus でプランして Sonnet で実行」は考え方としては単純だが、opusplan はそれを設定一発で実現する。使い分けを手動でやろうとすると面倒なことが、エイリアス一つで完結する。Pro プランや Team Standard で Claude Code を日常的に使っていて、コストを抑えながらプランニング品質を上げたいなら、まず試す価値がある設定だ。