一番賢いモデルを一番深い思考で回し続ければいい——とはならない。枠がもたない。
Claude Codeでは、Opus・Sonnet・Haikuというモデルの格に加えて、思考の深さを指すeffortという設定がある。個人開発でClaude Codeを日常的に酷使している身として、この2つの組み合わせ方を実体験ベースでまとめる。比較記事ではない。実際に使い分けている側の判断基準を書く。
結論：モデルの格とeffortの2軸で落とす。「最重量×最深思考」を常用しない
先に結論を書く。Claude Codeのモデル選びは、Opus/Sonnet/Haikuというモデルの格だけの話ではない。もう一つ、effort（思考の深さ）という軸があり、この2つを掛け合わせて考える必要がある。
- モデルの格 — タスクの複雑度に応じてHaiku/Sonnet/Opusを選ぶ
- effort — 同じモデルでも、どれだけ深く思考させるかを選ぶ
「モデルの格」だけを気にして「effort」を見落としている人が多い印象がある。だが自分の実感では、effortもモデルの格と同じくらい、枠の消費に効いてくる。とくにOpusのような最上位モデルをeffort最大で常時回し続けると、5時間のレート制限に手前で当たりやすくなる（これは以前レート制限の記事でも触れた実感だ）。「一番重いモデル×一番深い思考」を常用しない。これが個人運用でいちばん効いている判断基準になっている。
タスク別の実際の割り当て — Haiku=探索、Sonnet=標準実装、Opus=設計判断
モデルの格の使い分けは、タスクの複雑度で決めている。
- Haiku — 探索・要約・下書き。ファイルを横断してどこに何があるか調べる、ログの内容を要約する、たたき台のコードを書いてもらう、といった軽い作業
- Sonnet — 標準的な実装。普段の機能追加やバグ修正、テストの追加など、日常のコーディング作業の大部分
- Opus — 設計判断・難しいデバッグ。アーキテクチャの選択、複数の実装案のトレードオフ検討、原因がすぐ見えないバグの深掘りなど、重い判断が要る場面だけに絞る
すべてを最上位モデルに固定するのは過剰だ。探索や下書きまでOpusに投げると消費が早くなり、逆に設計判断をSonnetやHaikuで済ませようとすると判断の質が落ちる。タスクの重さに応じて格を上下させる、という単純な原則に沿っている。実際の月ごとの使用モデルはHaiku 4.5・Sonnet 4.6・Opus 4.7・Opus 4.8にまたがり、この配分の結果が実際の料金の記事で公開した実測の中身になる。
effortの落とし方 — 見落とされがちな第2の軸
ここが今回いちばん書きたい部分だ。モデルの格の使い分けはたどり着きやすい発想だが、effort（思考の深さ）まで含めて使い分けている人は体感として多くない。以前レート制限の記事で確認した実感は、こうだった。
Opus 4.8だけをeffort最大で回し続けると、5時間ウィンドウを待たずに手前で枠に当たる。逆に下位モデルに落としたり思考のeffortを下げたりすると、5時間の制限にはそもそも当たらずに済むことが多い。
つまり「Opus 4.8×effort最大」という組み合わせが、枠を最も速く食う殺し屋だ。モデルの格を落とすだけでも効くが、effortという別の軸を下げるだけでも同じように効く。この2軸は独立していて、片方だけ気にしているともう片方で枠を食い潰していることに気づきにくい。実際の運用としては、ルーチンワーク（決まった手順の実装・軽微な修正・定型的な調査）はeffortを下げ、重い設計判断や原因がすぐ見えないデバッグのときだけ上げる。effortの調整は、拡張思考のオン/オフ、思考トークンの上限設定、そしてモデル自体の切り替え（/model）といったClaude Code側の手段で行える。キー割り当てや設定項目の名前は版・環境で変わるので最新は公式の設定で確認するのが安全だが、考え方は「ルーチンは思考を軽く、重い判断だけ深く」で一貫している。
fallbackModelで過負荷時に自動降格
もう一つ、手動でのモデル選択とは別に設定しているのがfallbackModelだ。主モデルが過負荷で応答しないときに自動で別モデルへ降格し、過負荷起因の中断や無駄な再実行を減らす。手動の使い分け（タスクの重さでモデルとeffortを選ぶ）とは目的が違う「保険」として併用している。具体的な設定値はコスト削減3設定の記事を参照してほしい。
この使い分けが効いている証拠
モデルとeffortの使い分けは、抽象的な心がけではなく、実際の数字に跳ね返っている。コスト面では、2026年6月の実測でAPI従量換算約3,800ドル相当の作業量を、Max 5xサブスクの月100ドルの定額枠でこなせている（約38倍の比率、内訳は実際の料金の記事）。すべてを最上位モデル×effort最大で固定していたら、この比率はもっと小さくなっていたはずだ。レート制限回避面では、モデルの格とeffortを一段落とすことが、5時間のレート制限に当たる頻度を下げるのにいちばん効いた対処だった（詳細はレート制限の記事）。コストを下げる話とレート制限を避ける話は、根っこでは同じ「重さのコントロール」につながっている。
料金プランやモデルのラインナップは改定が速いため、ここでは数字を断定しない。最新情報は料金プラン比較記事を参照してほしい。
【関連】モデルの使い分けはコスト効率の話でもある。2026年6月のCopilot従量課金化・Cursor2プール制で課金方式の選択肢が分かれた — 料金地殻変動の整理記事で比較している。
まとめ — 格とeffort、2軸で考えると枠が持つ
モデルの格を選ぶ発想だけでは片手落ちだった。Haikuは探索・要約・下書き、Sonnetは標準実装、Opusは設計判断・難しいデバッグという振り分けに、effortの上げ下げ（ルーチンは下げ、重い判断だけ上げる）を重ね、fallbackModelを過負荷時の保険として併用する。「最重量×最深思考」を常用しないこの2軸が、月100ドルのサブスクで約3,800ドル相当をこなせたという実測と、レート制限に当たりにくくなったという体感の両方につながっている。
よくある質問
Opusを使わなければレート制限に当たりませんか？
モデルの格だけの話ではありません。同じOpusでもeffortを下げれば消費は緩やかになり、逆にSonnetでもeffortを上げれば重くなります。格とeffortの両方を見て判断する必要があります。
effortはどこで設定しますか？
拡張思考のオン/オフや思考トークンの上限設定、モデル切り替え（/model）で調整できます。キー割り当てや設定項目の名前は版・環境によって変わるため、最新は公式の設定で確認してください。考え方としては、ルーチンは思考を軽く、重い判断のときだけ深くする、で一貫させています。
すべての作業をHaikuにすればコストは最小になりますか？
コストだけならそうなりますが、設計判断や難しいデバッグまでHaikuに任せると判断の質が落ちます。軽い作業はHaiku、重い判断はOpusという住み分けを保つほうが、結果的にやり直しが減り総コストも安定します。
fallbackModelがあれば手動でモデルを使い分ける必要はありませんか？
別の仕組みです。fallbackModelは過負荷時の自動保険、手動の使い分けはタスクの重さに応じた日常の判断です。両方を併用しています。
あわせて読みたい：Claude CodeのfallbackModelで過負荷時に止まらないようにする
コメント