「全部Opusで」はもったいない——タスク別モデル選択戦略

「とりあえずOpus」で全作業を回している人は、毎月かなりの金額を捨てている。

Claude Code を使い始めた頃、多くの人が「せっかくだから最上位モデルを使おう」と考える。気持ちはわかる。でも日常的なコーディング作業の9割は、Sonnetで十分に解決できる。問題は、Opusしか使っていないと、その「十分性」に気づく機会がないことだ。

この記事では、Claude Codeを中心に、Cursor・Windsurfも含めたモデル選択戦略をまとめる。どのタスクにどのモデルを使うか。いつOpusに切り替えるか。その判断基準を実用的な観点で整理する。

---

コスト差を正しく理解する

まず数字を見る。Anthropicの公式APIドキュメント（2026年3月時点）によると、現行モデルの価格は以下の通りだ。

SonnetはOpusと比べて、入力・出力ともに60%のコスト、つまり40%安い。Haikuはさらに安く、Opusの5分の1だ。

// ❌ 全部Opusで動かした場合の概算（API従量課金）
1日の入力: 1M tokens @ $5/MTok → $5/日
1日の出力: 200K tokens @ $25/MTok → $5/日
合計 $10/日 × 30日 = $300/月

// ✅ Sonnetファースト + Opus 10%のハイブリッド構成
Sonnet: 900K tokens入力 @ $3/MTok → $2.70
Sonnet: 180K tokens出力 @ $15/MTok → $2.70
Opus: 100K tokens入力 @ $5/MTok → $0.50
Opus: 20K tokens出力 @ $25/MTok → $0.50
合計 $6.40/日 × 30日 ≈ $192/月（36%削減）

この試算はあくまでイメージだが、方向性はシンプルだ。Opusを使う割合を下げるほど、コストが下がる。

---

各モデルの「向き・不向き」

価格だけがモデル選択の基準ではない。各モデルには実用上の得意・不得意がある。

Claude Opus 4.6——深い推論が必要な局面

複雑な多段推論、アーキテクチャの意思決定、曖昧な要件から設計を組み立てるタスクが得意だ。「何を作るべきか」を考えさせるフェーズ向き。

実用的な使いどころ：

• 複数のサービスやコンポーネントにまたがる大規模リファクタリングの計画
• 新機能の設計（データモデル、APIインターフェース、状態管理の構造）
• デバッグが難航していて、原因を推論させる必要がある場面
• セキュリティ観点でコードレビューを依頼するとき

Claude Sonnet 4.6——日常作業のメインエンジン

コーディング速度と精度のバランスが優れており、Anthropicは「日常的なコーディングタスク向け」と位置づけている。

実用的な使いどころ：

• CRUD処理のAPIエンドポイント実装
• フロントエンドコンポーネントの生成・修正
• テストコードの生成
• ドキュメントの生成・整理
• CI/CDスクリプトの作成
• 既存機能へのバグ修正

上記のようなタスクが全体の8〜9割を占めるなら、Sonnetだけで問題ない。

Claude Haiku 4.5——繰り返しの定型作業

最も安くて速い。単純な変換・整形・検索系のタスクに使う。

実用的な使いどころ：

• コードのフォーマット整理
• 変数名・関数名の変換（camelCase → snake_case など）
• ファイル内の特定パターン検索・置換
• 単純なコメント追加

Claude Codeでは、バックグラウンド処理（ファイル操作の補助、コンテキスト管理など）に内部的にHaikuが使われている場面もある。

---

Claude Codeのモデル設定：4つの方法

Claude Codeの公式ドキュメントによると、モデルの設定方法は4段階の優先度で整理されている。

# 1. セッション中（最高優先度）
/model sonnet
/model opus
/model haiku

# 2. 起動時
claude --model sonnet
claude --model opus

# 3. 環境変数
export ANTHROPIC_MODEL=sonnet

# 4. 設定ファイル（最低優先度・永続設定）
# ~/.claude/settings.json に記述

設定ファイルでデフォルトをSonnetに固定するのが基本戦略だ。

// ❌ 設定なし（MaxプランはOpus 4.6がデフォルト）
// → 全作業がOpusで動く

// ✅ settings.jsonでSonnetをデフォルトに設定
{
  "model": "sonnet"
}

このファイルに1行書くだけで、Claude Code起動時のデフォルトがSonnetになる。重い作業のときだけ /model opus で切り替える。タスクが終わったら /model sonnet で戻す。この運用を習慣にするだけで、コストと速度のバランスが改善する。

---

opusplan——設計はOpus、実装はSonnet

公式ドキュメントで紹介されているモデルエイリアスの中に、実用度が高いものがある。opusplan だ。

# opusplanで起動する
claude --model opusplan

このモードでは：

• Plan Mode（設計フェーズ）: Opus 4.6を使用
• Execution Mode（実装フェーズ）: 自動的にSonnet 4.6に切り替わる

「何を作るか」を考えるのはOpusの仕事。「どう書くか」を実行するのはSonnetの仕事。この分担が自動で行われる。

設計が難しいタスク（新機能の設計、複雑なリファクタリング計画）では opusplan を使い、日常的な実装タスクでは sonnet を使う。この使い分けが基本になる。

---

Effort Level——Opusの推論深度を制御する

公式ドキュメントによると、Opus 4.6には「Effort Level」という設定があり、推論の深さを3段階で制御できる。

# 環境変数でEffort Levelを設定
export CLAUDE_CODE_EFFORT_LEVEL=medium

# low：素早い回答が欲しいとき
export CLAUDE_CODE_EFFORT_LEVEL=low

# high：複雑な問題を深く考えさせたいとき
export CLAUDE_CODE_EFFORT_LEVEL=high

Opusを使う局面でも、タスクの性質に応じてEffort Levelを下げると、速度とコストのバランスが取れる。毎回highで動かす必要はない。

---

タスク別モデルルーティング：判断基準

どのタスクにどのモデルを使うか。判断の基準を整理する。

シンプルなルールで言うと：

• 「どう作るか」が明確なら Sonnet
• 「何を作るか、どう設計するか」が曖昧なら Opus
• 単純な変換・整形なら Haiku

詰まったとき（Sonnetで答えが出なかったとき）にOpusへエスカレーションするのが実用的だ。最初からOpusで試す必要はほとんどない。

---

CursorとWindsurfの場合

Claude Codeに限った話ではない。他のツールでもモデル選択の戦略は同じ考え方が使える。

Cursor——マルチプロバイダーの柔軟性

Cursorは会話単位でモデルを切り替えられる。sitepoint.comの比較記事でも確認されているように、Claude Sonnet 4.5、Opus 4.6、各社のモデルを一つの環境で使い分けられる。

基本はSonnet中心で、複雑な設計タスクのときだけOpusに切り替える。ツールが変わっても、原則は変わらない。

Windsurf——SWE-1.5という選択肢

WindsurfはSWE-1.5という独自モデルを持っている。2025年12月のWave 13で発表されたこのモデルは、Cognition（Devin AIの開発元）が開発したものだ。

公式ブログによると、Cerebrasハードウェアで最大950 tok/sの速度を実現しており、これはHaiku 4.5の約6倍、Sonnet 4.5の約13倍に相当する。WindsurfのArena Modeのリーダーボードでは、SWE-1.5が重量級モデルを速度で上回るケースが観測されている。

WindsurfのArena Modeについては、別記事で詳しく解説している。

WindsurfのArena Mode——「どのAIモデルが自分のコードに最強か」をIDEの中で実証するベンチマーク数値ではなく、自分のコードベースで複数AIを対決させて評価する新機能。40,000票のデータが示した意外な結果と、実務での使い方を解説する。shipcoding.org

---

モデル切り替えのデメリット：コンテキスト断絶に注意

モデルを切り替える際の注意点が一つある。セッション中に /model コマンドでモデルを変えると、会話は継続するが、新しいモデルが持つシステムプロンプトや動作特性が変わる。

より大きな問題は、別のツールやAPIを使ってモデルを変える場合だ。その場合は会話コンテキストが完全にリセットされる。タスクの途中で別環境に切り替えると、それまでの文脈（コードベースの構造、変数名のルール、進行中の実装方針など）を改めて共有し直す必要が出てくる。

実用的な対策はシンプルだ。タスクの切り替えポイント（機能単位、ファイル単位）でモデルを切り替える。長いセッションの途中で突然変えない。CLAUDE.mdに基本的なコンテキストを書いておき、どのモデルでもすぐに状況を把握できるようにする。

// ✅ CLAUDE.mdに最低限のコンテキストを書く
# プロジェクト概要
Next.js 16 + TypeScript strict。bun でパッケージ管理。
テスト: bun test。Lint: bun run lint。

# 命名規則
コンポーネント: PascalCase
ユーティリティ: camelCase
定数: SCREAMING_SNAKE_CASE

CLAUDE.mdはセッション開始時に自動で読み込まれる。モデルを切り替えても、このファイルの内容はコンテキストに含まれる。

---

運用の基本：「Sonnetから始めて、詰まったらOpus」

まとめると、以下の運用が実用的だ。

1. ~/.claude/settings.json に "model": "sonnet" を設定してデフォルトをSonnetにする
2. 日常のコーディングはSonnetで進める
3. 「設計が必要」「Sonnetで解決できなかった」タスクには /model opus か opusplan を使う
4. タスクが終わったら /model sonnet に戻す
5. 単純な整形・変換タスクには /model haiku を試す

Opusを使うべきタイミングは具体的だ。複数のファイルやサービスをまたぐ設計、Sonnetで2〜3回試みても解決しないバグ、新機能のアーキテクチャ決定——そういう場面だけでいい。

工事現場に例えるなら、全員にクレーンを使わせる必要はない。図面を引くのは設計士の仕事で、穴を掘るのは掘削機でいい。クレーンが必要な場面はある。でも毎回クレーンを持ち込むのはコストの無駄だ。

AIモデルも同じ構造だ。Opusは必要な場面で使う。それ以外はSonnetで十分に仕事が進む。