Claude Codeで使えるモデル（Opus・Sonnet・Haiku）の使い分けガイド

Claude Codeを導入して最初にぶつかる壁が「どのモデルを使えばいいのか」という判断です。Anthropicが提供するOpus・Sonnet・Haikuはそれぞれ性格が大きく異なり、タスクとの相性を間違えると「高いコストを払ったのに品質が微妙」「安く済ませたら手戻りが発生した」という事態になります。

本記事では、3つのモデルを日常的に切り替えながら使ってきた経験をもとに、タスク別の最適モデル・コストと品質のリアルなトレードオフ・運用上のモデル切り替えフローを具体例とともに整理します。

結論 — 「Sonnetで始めて、壁にぶつかったらOpusに上げる」が最適解

モデル選択の大原則を先にまとめます。

モデル	一言で言うと	推奨シーン
Opus	最高精度・深い推論	設計判断、複雑なリファクタリング、マルチファイル変更
Sonnet	バランス型の主力	日常的な実装・テスト・バグ修正の大部分
Haiku	高速・低コスト	コミットメッセージ生成、フォーマット変換、定型処理

日常の開発フローでは実行回数の7〜8割がSonnetになります。Opusは「Sonnetで上手くいかなかったとき」の切り替え先として待機させておくイメージです。Haikuは「考える必要がないタスク」専用と割り切ると、コスト効率が劇的に改善します。

Claude Codeの全体像をまだ把握していない方は、先にClaude Code完全ガイドを読んでおくと、本記事の内容がより理解しやすくなります。

各モデルの実力差 — 同じタスクで比較するとわかること

カタログスペックだけでは実務での差は掴めません。ここでは、同じタスクを各モデルに投げた際の差を具体的に示します。

Opusが真価を発揮する場面

Opusはコードベース全体の構造を俯瞰したうえでの判断が求められるタスクで圧倒的な差を出します。

たとえば、あるNext.jsプロジェクトでServer ActionsからRoute Handlersへのリファクタリングを依頼した際、Opusは以下のように処理しました。

• 影響を受ける全ファイル（15ファイル以上）を正確に特定
• エラーハンドリングの方式をServer Actions用からHTTPレスポンス用に一貫して変換
• 既存のテストコードを新しいAPI呼び出しパターンに合わせて修正
• TypeScriptの型定義を新しいレスポンス形式に合わせて更新

同じタスクをSonnetに投げた場合、ルートの変換自体はできたものの、テストコードの更新が不完全で、一部のエラーハンドリングで元のServer Actions用のパターンが残るという結果でした。修正に追加で2〜3ターンのやり取りが必要になり、結果としてOpusで一発で通した方が速かったケースです。

もうひとつ、Opusが効く典型的なシーンが設計相談です。「このリポジトリでGraphQLからtRPCに移行するとしたら、どういう手順が現実的か」のような問いに対して、Opusはコードベースの依存関係を踏まえた段階的な移行プランを返してきます。Sonnetは一般論としては正しい回答をしますが、「このリポジトリ固有の事情」を踏まえた具体性では差が出ます。

Sonnet — 日常の8割を担う主力

Sonnetの強みは速度・品質・コストの三拍子が揃っていることです。以下のタスクではSonnetで十分な品質が得られます。

• 新しいコンポーネントの実装（1ファイル完結のもの）
• ユニットテスト・統合テストの作成
• 既存関数のバグ修正（エラーの場所が特定できている場合）
• APIクライアントの追加・修正
• 型定義の追加・修正

Sonnetが苦手なのは「ファイルを跨いだ依存関係の全体像を把握したうえでの判断」です。5ファイル以上にまたがる変更をSonnetに投げると、変更漏れが出やすくなります。この兆候が見えたらOpusに切り替える、というのが実務的なフローです。

逆に、Sonnetの方がOpusより良い結果を出すケースもあります。シンプルなタスクにOpusを使うと、過剰に複雑な回答を返すことがあるのです。「このユーティリティ関数にnullチェックを追加してください」のような指示に対して、Opusがエラーハンドリング全体を再設計しようとする、というパターンは実際に遭遇します。タスクのスコープが明確なときはSonnetの方が素直に応答します。

Haiku — 「考えなくていいタスク」に限定する

Haikuを有効に使うコツは用途を極端に絞ることです。以下のようなタスクではHaikuで十分です。

• コミットメッセージの生成
• インポート文の整理
• 型定義の機械的な変換（interfaceからtypeへの変換など）
• ボイラープレートコードの生成（CRUDのエンドポイント雛形など）
• JSDocコメントの追加

Haikuに「このバグの原因を調査してください」と依頼しても、表面的な回答しか返ってこないことが多いです。原因の推論が必要なタスクは最低でもSonnet、できればOpusに回すべきです。

コスト感覚 — 実際の利用データから見える現実

モデル選択のもうひとつの軸がコストです。ここでは、実務的なコスト感覚を共有します。

「全部Opus」は現実的ではない

Opusは確かに最高品質ですが、一日の開発タスクを全てOpusで処理すると、APIコストが大幅に跳ね上がります。とくにClaude Codeは1回のタスクで複数回のAPI呼び出しを行うため、モデルの価格差が累積的に効いてきます。

コスト最適化の実践パターン

最もコスト効率が高い運用パターンは以下の通りです。

1. 朝一の設計・方針決定はOpus: 一日の最初にその日のタスクの方針をOpusで固める。「このissueをどう実装するか」「どのファイルを変更すべきか」をOpusに相談し、方針が決まったらSonnetに切り替える
2. 実装作業はSonnet: 方針が決まった後の実装、テスト作成、バグ修正はSonnetで処理する
3. 定型作業はHaiku: コミットメッセージ、import整理、フォーマット変換はHaikuに任せる

この運用で、品質を維持しつつコストを半分以下に抑えられる実感があります。

失敗コストという視点

「安いモデルで失敗して手戻りが発生する」コストも計算に入れる必要があります。

たとえば、認証フローのリファクタリングをSonnetに投げて不完全な結果が返ってきた場合、その修正にさらに3〜4ターンのSonnet呼び出しが必要になります。最初からOpusで一発で通していれば、結果的にコストも時間も節約できたというケースは少なくありません。

**判断基準は「間違えた場合の修正コスト」**です。セキュリティに関わるコード、決済ロジック、認証フローなどは失敗コストが高いため、最初からOpusを使う方が合理的です。逆に、テストデータの生成やフォーマット変換のように、間違っても即座に気づいて修正できるタスクはHaikuで十分です。

料金体系の詳細については、Claude Codeの料金プランと費用感で網羅的に解説しています。

タスク別の推奨モデル — 判断に迷ったときの早見表

実務で頻出するタスクを推奨モデル別に整理します。

タスク	推奨	理由
アーキテクチャ設計の相談	Opus	複数の選択肢を比較検討する推論力が必要
5ファイル以上にまたがるリファクタリング	Opus	ファイル間の依存関係を正確に把握する必要がある
セキュリティ関連の実装	Opus	エッジケースの考慮が品質に直結する
コードレビュー（設計判断を含む）	Opus	「なぜこの設計が問題か」の説明に推論力が必要
新機能の実装（1〜3ファイル）	Sonnet	品質とコストのバランスが最適
テストコードの作成	Sonnet	パターン認識と正確性の両方が求められる
バグ修正（原因が特定済み）	Sonnet	変更範囲が限定されていればSonnetで十分
バグの原因調査（原因不明）	Opus	コードベース全体を探索する推論力が必要
APIクライアントの追加	Sonnet	パターンが決まっている作業
コミットメッセージの生成	Haiku	定型的な出力で十分
インポート文の整理	Haiku	機械的な並び替え処理
JSDocコメントの追加	Haiku	型情報から自動生成可能
ボイラープレートの生成	Haiku	テンプレート的な出力

判断に迷うケースの対処法

実務で最も悩むのは「SonnetかOpusか」の境界線です。以下の基準で判断すると、外れが少なくなります。

• 変更対象が3ファイル以下 → Sonnet
• 変更対象が5ファイル以上 → Opus
• 「これを間違えるとまずい」と感じる → Opus
• 「間違えてもすぐ直せる」と思える → Sonnet
• Sonnetで一度やって不完全だった → Opusにエスカレーション

3〜5ファイルの中間帯は、まずSonnetで試して結果を見てから判断する、というのが実務的です。

モデル切り替えの実践 — /model コマンドの使い方

Claude Codeでのモデル切り替えは、セッション内で /model コマンドを使って行います。

基本的な切り替えフロー

# セッション中にモデルを切り替え
> /model

# 表示されるモデル一覧から選択
# claude-sonnet-4-20250514 (default)
# claude-opus-4-20250514
# claude-haiku-3-5-20250805

デフォルトモデルの設定

毎回のセッションで使うデフォルトモデルは、設定ファイルで指定できます。

// ~/.claude/settings.json
{
  "model": "claude-sonnet-4-20250514"
}

大半のタスクはSonnetで処理するため、デフォルトをSonnetにしておき、必要なときだけ /model でOpusに切り替えるのが効率的です。

チームで運用する場合のガイドライン

チーム開発では、モデル選択を個人の判断に任せると属人化します。以下のようなガイドラインを設けておくと、コスト管理と品質担保の両面で効果があります。

# CLAUDE.md に記載するモデル選択ガイドライン

## モデル選択の基準
- デフォルト: Sonnet
- 設計相談・レビュー・5ファイル以上の変更: Opus に切り替え
- コミットメッセージ・フォーマット変換: Haiku に切り替え
- セキュリティ関連のコード: 必ず Opus を使用

CLAUDE.md にモデル選択の方針を記載しておくと、チームメンバー全員が同じ基準で判断できます。CLAUDE.mdの書き方の詳細はCLAUDE.md作成ガイドを参照してください。

Maxプランでのモデル利用

MaxプランはAnthropicのサブスクリプションベースのプランで、利用可能なモデルや使用量の上限がプランごとに異なります。Maxプランを利用している場合、Opusの利用にはより高いプランへの加入が必要になる場合があります。最新の対応状況は公式の料金ページで確認してください。

API利用の場合はモデルの選択に制約はなく、従量課金で全モデルを利用できます。

よくある失敗パターンと対処法

失敗1:「とりあえずOpus」で全部処理する

コスト面の問題だけでなく、品質面でもデメリットがあるパターンです。前述の通り、シンプルなタスクにOpusを使うと過剰に複雑な回答を返すことがあります。「nullチェックを追加してください」と依頼しただけなのに、エラーハンドリングの設計全体を提案してくる、というケースです。

対処法: デフォルトをSonnetにして、必要なときだけOpusに切り替える習慣をつける。

失敗2:「コスト節約」でHaikuを多用する

Haikuの出力が不正確で手戻りが発生し、トータルのコストと時間がかえって増えるパターンです。特にテストコードの生成をHaikuに任せると、エッジケースの考慮が不十分なテストが生成されやすく、後からテストの修正が必要になることがあります。

対処法: Haikuの用途を「考える必要がないタスク」に限定する。テスト生成は最低でもSonnetを使う。

失敗3: モデルを固定して切り替えない

セッション中にタスクの性質が変わっても同じモデルを使い続けるパターンです。「実装はSonnetでOKだったが、途中でデバッグが必要になったのにSonnetのまま続行した」というケースでは、Opusに切り替えた方が早期に解決できることが多いです。

対処法: タスクの性質が変わったら /model で切り替える。特に「Sonnetで2回以上同じ問題に失敗した」場合はOpusへの切り替えサインです。

モデルバージョンの更新に備える

Anthropicは継続的にモデルを改善・更新しています。重要なのは、現時点でのモデル間の性能差は、将来変わる可能性があるということです。

実務的な備え方

• モデルIDをハードコードせず、設定ファイルで管理する
• 新しいモデルバージョンがリリースされたら、自社の代表的なタスクで比較評価する
• チームのCLAUDE.mdに記載したモデル選択ガイドラインも、新バージョンに合わせて見直す

Sonnetの新バージョンがリリースされたタイミングで、従来Opusでしか安定しなかったタスクがSonnetで処理可能になる、というケースは過去にもありました。定期的な再評価が、コスト最適化の鍵です。

まとめ — モデル選択は「全部Opus」ではなく「適材適所」

モデル選択の本質は、タスクの性質に合わせて最適なリソースを配分することです。

• Sonnetをデフォルトにして、日常タスクの大部分を処理する
• **Opusは「Sonnetで壁にぶつかったとき」と「失敗コストが高いタスク」**に限定する
• **Haikuは「考える必要がないタスク」**に絞り込む
• タスクの性質が変わったら、セッション中に /model で柔軟に切り替える

この使い分けができると、品質を維持しつつコストを大幅に最適化できます。最初は「迷ったらSonnet」から始めて、Opusに切り替えるべきタイミングの感覚を徐々に掴んでいくのが実践的です。