Claude Codeのモデル使い分け｜Opus・Sonnet・Haikuとeffort設定の選び方【2026年5月版】

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

さらに2026年のClaude Codeでは、どのモデルを使うかに加えて**どれだけ深く考えさせるか（effort）**という第2の軸が加わりました。Opus 4.7 のデフォルトが xhigh になり、/effort でセッション中に推論深度を切り替えられるようになったいま、「モデル×effort」の2軸で考えるのがコスト最適化の前提になっています。

本記事では、3つのモデルを日常的に切り替えながら使ってきた経験をもとに、最新モデルID・effortとの組み合わせ・タスク別の推奨設定・コストと品質のリアルなトレードオフ・運用上の切り替えフローを具体例とともに整理します。情報は2026年5月時点の一次情報に基づきます。

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

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

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

ポイントは、速度優先の場面では同じモデルのまま --effort medium に下げるだけでも体感速度とコストが大きく変わること。「Opusに上げる」と「effortを上げる」は別レバーであり、両方を意識的に使い分けるのが2026年版の運用です。effortの5段階の挙動は後半の「effort × モデルの2軸設計」で詳しく扱います。

Claude Codeの全体像をまだ把握していない方は、先にClaude Code完全ガイドを読んでおくと、本記事の内容がより理解しやすくなります。Opus 4.7 とeffortの仕様を一次情報で深掘りしたい方は、ピラー記事のClaude Opus 4.7 × Claude Code 完全活用ガイドもあわせてどうぞ。

2026年5月時点の最新モデルラインナップと料金

まず現行モデルの正確な情報を押さえておきます。記事や設定ファイルでモデルIDが旧世代（claude-opus-4-20250514 のような形式）のまま残っているケースが多いため、ここで最新版に揃えておくと混乱を防げます。

OpusとHaikuでは出力トークンの単価に5倍の差があります。後述するように、ここに新tokenizerによる消費増とeffortの深さが掛け算で効いてくるため、実効コストの差はさらに開きます。

Opus 4.7 で何が変わったか

2026 年 4 月 16 日に一般提供開始された Claude Opus 4.7 で、Claude Code の運用は一段階変化しました。

注目すべきは、料金カードは据え置きでも実効コストは tokenizer の +35% でじわじわ上がる点です。「Opus 4.6 と同じ感覚で使っていたら請求が増えていた」という事態を避けるには、後述のeffortとTask Budgetsでの相殺が前提になります。

xhigh effort level のデフォルト化

Opus 4.7 に合わせて、Opus 4.7 の Claude Code 上のデフォルト推論深度（effort level）が xhigh になりました。これまで手動で深い推論を指示していた場合はコマンドを簡略化でき、逆に速度優先なら --effort medium を明示的に下げるのが基本になります。effortの5段階それぞれの挙動は次のセクションで詳説します。

Task Budgets（beta）と Auto mode

• Task Budgets（beta）: タスクごとのトークン消費上限を .claude/settings.json で制御できる新機能。xhigh デフォルト化とセットで運用することで、「深く考えすぎて予算を食い潰す」事故を予防できます。
• Auto mode（Max プラン限定）: 難易度に応じて Opus 4.7 と Sonnet 4.6 を自動で切り替えるモード。「設計判断は Opus、整形は Sonnet」という本記事のコスト戦略を、Auto mode が自動化してくれる形です。手動の使い分けに自信がつくまでの“補助輪”としても有効です。

Opus 4.7 のベンチマークの出典・1M context・effortの仕様を一次情報ベースで深掘りした解説は、ピラー記事のClaude Opus 4.7 × 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に回すべきです。

effort × モデルの2軸設計 — 「どのモデルで、どれだけ考えさせるか」

2026年のClaude Codeでモデル選択を語るうえで外せないのが effort（推論深度） です。従来は「Opusか、Sonnetか」というモデルの1軸だけで考えていましたが、いまは同じモデルでもどれだけ深く推論させるかを別レバーで調整できます。この2軸を理解すると、コストと品質のコントロール精度が一段上がります。

effort の5段階

effort は、Claudeが「適応的推論（adaptive reasoning）」にどれだけリソースを割くかを制御するパラメータです。利用できるレベルは5段階あります。

Opus 4.7 は常に適応的推論を使い、デフォルトが xhigh です。つまり Opus を呼んだ時点で、手を加えなくても最も深く考える設定で動いています。一方でAPI経由のデフォルトは high である点に注意してください。

effort の優先順位と設定方法

どのeffortが適用されるかは、次の優先順位で決まります。

1. 環境変数 CLAUDE_CODE_EFFORT_LEVEL（最優先）
2. settings.json の effortLevel
3. モデルごとのデフォルト

セッション中に切り替えるなら /effort コマンドが手軽です。チーム全体に効かせたいなら settings.json、一時的に全体へ効かせたいなら環境変数、という使い分けになります。

// ~/.claude/settings.json — チーム標準のeffortを固定する例
{
  "model": "claude-sonnet-4-6",
  "effortLevel": "high"
}

モデル × effort の組み合わせ早見表

実務での代表的な組み合わせを整理します。「モデルを上げる」前に「effortを上げる」だけで解決する場面が意外と多いのがポイントです。

エスカレーションの順序は「Sonnet×medium → Sonnet×high → Opus×xhigh」が基本です。いきなりOpus×maxに飛ばすと、tokenizerの+35%と相まってコストが跳ね上がります。effortという中間ギアを挟むことで、Opusに上げる回数そのものを減らせます。

effortごとのトークン消費の傾向や業務別（コード生成・デバッグ・設計・レビュー・テスト・ドキュメント）の詳細マトリクスは、ピラー記事のClaude Opus 4.7 × Claude Code 完全活用ガイドで網羅しています。

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

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

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

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

さらに2026年は新tokenizerによって同一テキストでも最大+35%のトークンを消費し、Opus 4.7はデフォルトが xhigh で深く推論する分だけトークンを使います。「Opus×xhighを多用する」は、出力単価5倍 × tokenizer +35% × 深い推論、という三重の乗算でコストが効いてくる構図です。

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

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

1. 朝一の設計・方針決定は Opus × xhigh: 一日の最初にその日のタスクの方針をOpusで固める。「このissueをどう実装するか」「どのファイルを変更すべきか」をOpusに相談し、方針が決まったらSonnetに切り替える
2. 実装作業は Sonnet × high（急ぐ場面は medium）: 方針が決まった後の実装、テスト作成、バグ修正はSonnetで処理する。速度を優先したい局面では /effort medium に下げるだけでも体感とコストが改善する
3. 定型作業は Haiku × low/medium: コミットメッセージ、import整理、フォーマット変換はHaikuに任せる
4. 予算上限は Task Budgets で固定: 「深く考えすぎて予算を食い潰す」事故を防ぐため、.claude/settings.json のTask Budgetsでタスクごとの消費上限を設定しておく

この運用で、品質を維持しつつコストを半分以下に抑えられる実感があります。モデルとeffortの両方を絞ることで、効果は乗算的に効いてきます。

失敗コストという視点

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

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

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

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

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

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

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

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

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

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

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

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

基本的な切り替えフロー

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

# 表示されるモデル一覧から選択（2026年5月時点）
# claude-sonnet-4-6 (default)
# claude-opus-4-7
# claude-haiku-4-5-20251001

# 推論深度（effort）を切り替え
> /effort
# low / medium / high / xhigh / max から選択

デフォルトモデルとeffortの設定

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

// ~/.claude/settings.json
{
  "model": "claude-sonnet-4-6",
  "effortLevel": "high"
}

環境変数で一時的に上書きすることもできます（settings.json より優先）。

# このセッションだけ深く考えさせる
export CLAUDE_CODE_EFFORT_LEVEL=xhigh

大半のタスクはSonnetで処理するため、デフォルトをSonnetにしておき、必要なときだけ /model でOpusに、/effort で推論深度を上げるのが効率的です。なお ANTHROPIC_MODEL 環境変数でデフォルトモデルを指定する方法もあります。

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

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

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

## モデル × effort の基準
- デフォルト: Sonnet（claude-sonnet-4-6） / effort high
- 急ぎ・反復作業: Sonnet のまま effort medium に下げる
- 設計相談・レビュー・5ファイル以上の変更: Opus（claude-opus-4-7） / effort xhigh
- コミットメッセージ・フォーマット変換: Haiku（claude-haiku-4-5）/ effort low
- セキュリティ関連のコード: 必ず Opus / xhigh を使用

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

Maxプランでのモデル利用と Auto mode

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

Maxプランでは Auto mode が利用でき、難易度に応じて Opus 4.7 と Sonnet 4.6 を自動で切り替えてくれます。「自分で /model を切り替えるのを忘れて、簡単なタスクにOpusを使い続けてしまう」というありがちな無駄を防げるため、使い分けの判断に自信がつくまでの間はAuto modeに任せるのも有効です。慣れてきたら手動に戻し、effortまで含めて細かく制御する、という移行が現実的です。

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」ではなく「モデル×effortの適材適所」

モデル選択の本質は、タスクの性質に合わせて最適なリソースを配分することです。2026年版では、モデルとeffortの2軸で考えるのが前提になりました。

• Sonnet × high をデフォルトにして、日常タスクの大部分を処理する（急ぐ場面は medium に下げる）
• **Opus × xhigh は「Sonnetで壁にぶつかったとき」と「失敗コストが高いタスク」**に限定する
• **Haiku × low は「考える必要がないタスク」**に絞り込む
• 「Opusに上げる」前に、まず /effort で推論深度を上げる中間ギアを挟む
• タスクの性質が変わったら、セッション中に /model と /effort で柔軟に切り替える
• 判断に自信がつくまでは Auto mode（Max限定） に任せ、慣れたら手動＋effort制御へ移行する

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