Claude Codeで「軽作業はHaiku 4.5、通常はSonnet 5、難しい場面だけOpus 5、最難関はFable 5」と使い分けたい場合、見るべきなのは作業時間の長さではなく、不確実性・変更範囲・失敗時の影響・自律的な判断の量です。
結論からいうと、まずSonnet 5で着手し、作業が止まる理由を観察して上位モデルへ切り替える方法が実用的です。
最初から最高性能のモデルを選ぶのではなく、「何が難しいのか」を4項目で判定すると、コストと速度を無駄にしにくくなります。
まず覚えたい：難易度は「コード量」だけでは決まらない
短い修正でも、認証・決済・データ削除・本番障害に関わるなら難易度は高くなります。反対に、数十ファイルにまたがっていても、変更ルールが明確で自動テストが十分なら、比較的軽い作業として進められることがあります。
モデル選択では、次の4つを確認してください。
- 要件の明確さ：完成条件が具体的か、それとも調査や仕様判断が必要か
- 影響範囲：変更が1ファイル内で収まるか、複数サービス・DB・外部APIへ広がるか
- 検証の容易さ：テスト、型検査、再現手順で正否をすぐ確認できるか
- 失敗コスト：誤りが見た目の崩れで済むか、障害・漏えい・データ破損につながるか
モデル別の判断基準
| モデル | 向いている難易度 | 使う目安 | 具体例 |
|---|---|---|---|
| Haiku 4.5 | 低 | 答えや修正箇所がほぼ決まっており、確認も簡単 | 変数名の変更、コメント追加、定型的なテスト作成、単純な表示文言修正、既知パターンに沿った小修正 |
| Sonnet 5 | 中 | 通常の実装・調査・デバッグ。複数ステップはあるが、目的と検証方法を説明できる | 機能追加、一般的なバグ修正、既存コードの理解、API連携、複数ファイルのリファクタリング |
| Opus 5 | 高 | 設計上のトレードオフや原因調査が必要で、複数の仮説を比較する必要がある | 原因が不明な本番不具合、複雑な並行処理、段階的な移行、性能劣化の分析、巨大な既存コードベースの設計変更 |
| Fable 5 | 最難関 | 長時間にわたる探索・設計・実装・検証を一貫して進める必要があり、失敗の切り分けも難しい | 大規模アーキテクチャ刷新、複数リポジトリをまたぐ移行、難解な技術調査を伴う開発、長期的な自律実行が必要な課題 |
Anthropicの案内では、Haiku 4.5は速度とコスト効率を重視する用途、Sonnet 5は計画・ツール利用・自律的な実行を伴う日常的な開発、Opus 5は高度なコーディングや知識作業、Fable 5は長く複雑なタスクほど優位性が大きいモデルとして位置付けられています。
迷ったときの4段階チェックリスト
1. Haiku 4.5でよいケース
- 変更内容を1文で明確に指示できる
- 触る場所が事前に分かっている
- 似た実装がリポジトリ内にある
- テストや画面確認で結果をすぐ判定できる
- 失敗しても戻しやすい
たとえば「この関数の戻り値を文字列から数値へ変え、既存テストを更新する」のように、方針が決まっている作業です。Haiku 4.5は、速く小さな反復を回したいときに向いています。
2. Sonnet 5を標準にするケース
- 要件は分かるが、実装手順はコードを読んで決める必要がある
- 数ファイルから数十ファイルをまたぐ変更になる
- 既存の規約、テスト、依存関係を確認する必要がある
- 調査、実装、テスト修正をまとめて依頼したい
普段の機能開発やバグ修正は、まずSonnet 5で十分かを確認するのがおすすめです。Sonnet 5が計画を立て、関連箇所を調べ、テストまで一通り進められるなら、上位モデルへの切り替えは不要です。
3. Opus 5へ上げるべきサイン
次のどれかが出たら、単にプロンプトを長くするよりOpus 5へ切り替える価値があります。
- Sonnet 5が原因候補を挙げるものの、再現と切り分けを何度も繰り返している
- 複数の設計案に明確な正解がなく、保守性・性能・互換性を比較する必要がある
- 非同期処理、競合状態、キャッシュ、分散システムなど、再現しにくい問題を扱う
- 既存仕様が曖昧で、コード・履歴・テストから意図を推定しなければならない
- 失敗時の影響が大きく、実装前に慎重なレビュー観点が必要になる
ポイントは、作業が大きいからOpus 5ではなく、推論の分岐が多く、誤った仮説で進むリスクが高いからOpus 5という考え方です。
4. Fable 5を検討するサイン
- 問題の全体像を把握するだけで、複数のコードベース・設計資料・実行ログを横断する必要がある
- 調査、設計、実装、テスト、失敗時の再計画までを長い作業単位で任せたい
- 途中で見つかった事実によって、当初の計画を大きく組み替える可能性が高い
- 通常の上位モデルでも、文脈の維持や複数仮説の統合がボトルネックになっている
ただし、Fable 5は「とにかく難しいコードを書くためだけ」のモデルではありません。Anthropicは、Fable 5に高度な能力と追加の安全対策を組み合わせていると説明しています。特にサイバーセキュリティ、バイオ・化学、モデル能力の複製などに関わる依頼では、安全対策により応答や処理が制限される場合があります。通常のアプリ開発では、まずSonnet 5、次にOpus 5を試し、それでも長期的・横断的な問題解決が必要なときにFable 5を選ぶとよいでしょう。
実務で使える「昇格ルール」
モデル選択を毎回考え込まないために、チームや個人の作業ルールとして次のように決めると運用しやすくなります。
- 最初はSonnet 5：通常の開発依頼は、目的・制約・完了条件・実行したいテストを添えて依頼する
- 単純で反復的ならHaiku 4.5：調査済みの小修正、定型作業、並列に処理したい小タスクへ使う
- 30分程度で仮説が収束しない、または設計判断が残るならOpus 5：原因分析、設計比較、難しいデバッグを引き継がせる
- 複数領域の統合と長い自律実行が必要ならFable 5：依頼を小さく分けられない最難関に限定する
ここでの「30分」は厳密な時間ではありません。重要なのは、Sonnet 5が失敗した回数ではなく、追加情報を与えても問題の構造が単純化しないかです。単なる情報不足なら、上位モデルに変える前にログ、再現手順、期待値、失敗した試行を渡すほうが効果的です。
難易度を下げる依頼の出し方
上位モデルへの切り替えを減らすには、依頼を具体化して問題そのものの難易度を下げるのが有効です。Claude Codeには、次の順で伝えます。
- 目的：何を実現・修正したいか
- 制約：変更してはいけない箇所、対応すべき環境、互換性の条件
- 完了条件：通すべきテスト、期待する挙動、確認コマンド
- 現状：エラー、ログ、再現手順、試したこと
- 作業範囲：調査だけか、実装とテストまで行うか
例えば「ログインが壊れている。直して」ではなく、「特定の条件でログイン後に画面遷移せず、コンソールにこのエラーが出る。認証基盤の仕様は変更せず、再現テストを追加して修正し、既存の認証テスト一式を実行してほしい」と伝えると、Sonnet 5でも安定しやすくなります。
Claude Codeでの切り替え方法
Claude Codeでは、セッション中に/modelを実行してモデルを選べます。1回だけ変更したい場合は、起動時に--modelを指定する方法もあります。利用可能なモデルや契約プランは変わり得るため、実際に選択できるモデルはClaude Codeの画面または公式ドキュメントで確認してください。
まとめ：難易度ではなく「不確実性」で選ぶ
- Haiku 4.5：答えが見えている、小さくて検証しやすい作業
- Sonnet 5：日常的な実装、調査、デバッグの標準モデル
- Opus 5：原因が不明、設計判断が重い、失敗コストが高い作業
- Fable 5：長期・横断・高不確実性で、探索から再計画まで必要な最難関
最初の一手はSonnet 5にし、単純ならHaiku 4.5へ下げる、推論の分岐が増えたらOpus 5へ上げる、そして長期的かつ横断的な最難関だけFable 5にする。この順番なら、Claude Codeの速度・コスト・品質をバランスよく使い分けやすくなります。
参考資料
- Claude Code model configuration：Claude Codeで選択できるモデルと切り替え方法
- Introducing Claude Sonnet 5：Sonnet 5のエージェント的な開発・ツール利用に関する説明
- Introducing Claude Haiku 4.5：Haiku 4.5の速度・コスト効率・軽量な開発作業での位置付け
- Anthropic’s Transparency Hub：Opus 5とFable 5の能力・提供形態・安全対策の概要
