Claudeモデル比較 — Fable / Opus / Sonnet / Haikuの使い分けと組み合わせ方

ClaudeのモデルはFable 5 / Opus 5 / Sonnet 5 / Haiku 4.5の4系統です。2026年7月24日にOpus 5が加わり、Opusクラスの中身が入れ替わりました。単価の開きは10倍、扱えるコンテキストは200Kトークンから1Mトークンまで幅があります。スペックと料金、用途ごとの向き不向き、そして複数のモデルを1つのワークフローに混ぜる設計をまとめます。

現行4系統の結論 — どれをいつ使うか

モデル選びは「どれが一番賢いか」ではなく、4系統それぞれに守備範囲を割り当てる作業です。迷ったときの起点はSonnet 5になります。

割り当ての原則は4つに畳めます。

1. 既定はSonnet 5。大半の作業は品質・速度・コストのバランスで足ります
2. 結果の質が意思決定に直結するならOpus 5。採点、設計、レビューのように、判断の深さがそのまま成果へ響く場面です
3. 判定基準が明確で呼び出し回数が多いならHaiku 4.5。単価差が累計で効いてきます
4. 長く曖昧な自律タスクだけFable 5。単価はOpus 5の2倍なので、対象を絞って投入します

Opus 5の登場で動いたのは、2番目と4番目の境界です。Opus 5はCursorBench 3.2の最大effortでFable 5のピークまで0.5ポイント差に迫り、それを半額で出しています。Fable 5にしか任せられない領域は以前より狭くなりました。1Mトークンのコンテキストと128Kトークンの最大出力はOpus 5も備えるため、残る差は知性のピークと、長く曖昧な作業での粘りに絞られます。

Fable 5の側にも譲れない条件があります。全トラフィックで30日のデータ保持が必須で、ゼロデータ保持(ZDR)の契約下では選べません。攻撃的セキュリティや生物研究のような領域では安全分類器の発動が想定挙動なので、最初からOpusクラスを選ぶほうが運用は単純になります。仕様の細部はClaude Fable 5の解説にまとめてあります。

スペックと料金 — 4系統の数字を並べる

数字で見ると、4系統は「コンテキストと出力の壁」と「単価の階段」という2つの軸で分かれます。前者はHaiku 4.5だけが一段低く、後者は$1から$10まで4段です。

スペック比較

思考の制御方式が、実装に最も直結する差です。Fable 5・Opus 5・Sonnet 5は、モデル自身が思考の要否と深さを決めるadaptive thinkingに一本化されており、深さは effort パラメータ(low / medium / high / xhigh / max)で調整します。Haiku 4.5だけが thinking の budget_tokens を受け取る従来方式です。旧世代向けに budget_tokens を送る実装が残っていると、Sonnet 5では400エラーになります。

コンテキストの壁も判断を左右します。Haiku 4.5の200Kトークンは、リポジトリ横断の調査や長大なログの一括解析には届きません。裏返せば、その2種類の作業を抱えていないならHaiku 4.5が候補から外れる理由はなくなります。1Mトークンのコンテキストに長文の追加プレミアム料金はなく、900Kトークンのリクエストも9Kトークンと同じ単価で課金されます。

提供条件と対応バージョン

高速モード(fast mode)は、Opus 5を通常の約2.5倍速で動かす代わりに基本料金の2倍を払う仕組みです。入力$10 / 出力$50に相当します。Claude Codeでは /fast の対象がOpus 5とOpus 4.8に絞られており、v2.1.219でOpus 4.7が外れました。同じv2.1.219で /model ピッカーのOpus行が「Opus (1M context)」表示になっています。バージョンごとの変更点はClaude Code v2.1.219のリリースノートにまとめてあります。

料金比較

Sonnet 5には2026年8月31日までの導入価格(入力$2 / 出力$10)が設定されており、9月1日以降は上表の標準価格に移行します。Batch APIを使えば全モデルで入力・出力とも50%引きです。即時性の不要なバルク処理なら、実質単価は半分になります。Opus 5の単価はOpus 4.8から据え置きなので、Opus 4.8を主軸に組んでいたワークロードは料金の再試算なしで乗り換えられます。詳しい発表内容はOpus 5の登場を伝えた記事で扱っています。

額面の単価だけで比べると見落とす要素が1つあります。Fable 5はOpus 4.7世代のトークナイザーを使うため、同じテキストでも旧世代モデルよりトークン数がおよそ30%多くカウントされます。Opus 4.6以前の世代から移行する場合、単価2倍にこの増分が重なり、入力側の実コストは約2.6倍に相当する計算です。これは机上の概算で、実際の差はプロンプトの構成とキャッシュヒット率で変わります。

用途別の使い分け

コーディング

コーディングの起点はOpus 5とSonnet 5の2択になります。Opus 5はFrontier-Bench v0.1でOpus 4.8の性能を2倍以上に押し上げ、タスクあたりのコストはむしろ下がったと報告されています。体感で分かりやすいのは、テスト実行やブラウザーでの確認まで自分で進めてから完了扱いにする挙動です。複数ファイルにまたがるリファクタリングや、判断を挟みながら長時間走らせる作業ほど差が出ます。

一方、日常の機能追加やバグ修正はSonnet 5で十分に届きます。Sonnet 5は計画を立ててターミナルを操作し、無指示でも再現テストを書いて修正を確認しに行く水準まで上がりました。数か月前なら上位モデルが必要だった作業が、Sonnetクラスの単価で回るようになっています。境界の目安は、出力をそのまま使うならSonnet 5、出力を根拠に何かを決める(マージ可否、設計採否、公開判断)ならOpus 5です。

長文分析と大規模コードベース

コンテキストが1MトークンあるFable 5・Opus 5・Sonnet 5は、分割せずに投げられる範囲が広い系統です。128Kトークンの最大出力も効いてきます。大規模なリファクタリング差分やドキュメント一式を一度に受け取れる水準なので、出力を分割して「続きを書かせる」制御を自前で組んでいるなら、その層を畳める可能性があります。

曖昧さの残る調査ではFable 5が候補に入ります。長く複雑なタスクほど他モデルとの差が広がるとされ、5,000万行規模のRubyコードベース移行が見積もり2か月から1日に短縮された事例が挙げられています。ただし単価は2倍です。従来構成で時間がかかっている作業、途中で迷走しがちな作業だけを振り替えて、完了率と所要時間を比べる入り方が現実的なところです。

日常利用

claude.aiでの日常利用は、Free / Proの既定であるSonnet 5がそのまま最適解になります。ProプランではOpus 5も選べるので、日常はSonnet 5、要所でOpus 5という切り替えが組みやすい形です。MaxプランはOpus 5が既定になったため、モデルを明示的に選ばずに使っている場合は自然にOpus 5が走り始めます。プランごとの枠の仕組みはClaude料金プラン比較で扱っています。

コスト重視の大量処理

判定基準を言語化できる処理は、Haiku 4.5に降ろすほど累計コストが効いてきます。構造化データの抽出、明示パターンの分類、ログ要約、URL一覧の取り出し。この種の作業では、上位モデルとの品質差がほとんど出ません。逆に「文章品質の評価」「編集方針の判断」のように基準を書き切れない作業をHaiku 4.5に任せると、精度が安定しません。基準を言葉にできないと気づいた時点でSonnet 5以上に切り替えるほうが、結局は安くつきます。

作業別の早見表

複数のモデルを1つのワークフローに混ぜる

ここまでは「1つの作業に1つのモデル」を前提にしてきました。実運用でコストと品質の両方を取りに行くなら、視点をもう一段上げて「1つのワークフローに複数のモデル」を配置する設計になります。重い判断は上位モデル、量産は下位モデルへ。この振り分けは、その都度の手動切り替えに頼らず設定として固定できます。

メインとサブエージェントで階層を分ける

Claude Codeのサブエージェントは、定義ファイルのYAML frontmatterで使うモデルを指定できます。.claude/agents/*.md に置いた定義に model を書けば、メインセッションとは別のモデルで走ります。指定できる値は sonnet / opus / haiku / fable のエイリアスと、claude-opus-5 のようなフルmodel ID、そしてメインセッションに追従する inherit です。

---
name: log-classifier
description: 実行ログを読み、種別と重大度をJSONで返す
model: haiku
---

この1行があるだけで、メインセッションをOpus 5で回しながら、呼び出し回数の多い分類処理だけHaiku 4.5に降ろせます。同じfrontmatterには effort も書けるため、モデルと思考の深さをサブエージェント単位で決められます。判断の重いレビュー系はOpusとxhigh、量産系はHaikuと既定値、という組み方です。

割り当ての考え方は、作業の性質を2つに分けるところから始まります。線を引く場所は基準を言葉にできるかです。抽出、字数カウント、パターン一致の検出は言葉にできる側で、下位モデルに降ろせます。品質の採点、独自視点の評価、設計の採否は言葉にできない側で、上位モデルに残します。この線でサブエージェントを切ると、上位モデルの呼び出し回数が自然に減ります。

計画と実装で自動的に切り替える

エイリアス opusplan を指定すると、計画モード中はOpus、実行フェーズに移るとSonnetへ自動で切り替わります。設計の質はOpusで取り、コード生成はSonnetで流す使い分けが、手動の切り替えなしで成立します。

/model opusplan

計画と実装でモデルを分ける発想は、コストの配分としても筋が通ります。計画フェーズは出力トークンが少なく入力の理解が重い工程で、実装フェーズはその逆です。単価の高いモデルを、出力量の少ない工程に集中させる形になります。

モデルを変えずに思考の深さだけ動かす

モデルの切り替えと並んで使えるのが effort です。Fable 5・Opus 5・Sonnet 5はいずれもeffortで思考の深さを指定できます。難しい調査や設計では、モデルを上げる前に /effort でxhighやmaxへ引き上げる選択肢があります。

Sonnet 5は特に、この軸で幅を持たせやすいモデルです。低effortで安価に流し、必要な場面だけ高effortで深く考えさせる運用が同じモデル内で成立します。「Sonnetでは足りないからOpusへ」と判断する前に、effortを一段上げて再試行するだけで届く場面があります。モデルを上げると単価が上がり(Sonnet 5→Opus 5で標準価格比約1.7倍)、effortを上げてもコストは思考トークンの増分だけ、という違いです。

APIでは拒否とフォールバックを前提に組む

Fable 5とOpus 5には安全分類器が組み込まれており、照会がブロックされることがあります。このとき返るのはエラーではありません。HTTPステータスは200で、レスポンスの stop_reason が "refusal" になります。クライアント側は例外処理ではなく、正常系の分岐として扱う設計になります。

切り替えを自前で書かずに済む仕組みも用意されています。fallbacks パラメータ(ベータ)は、拒否時に別モデルへ自動で回す指定で、Claude APIでベータ提供されています。Opus 5の提供開始と同時にAutomatic Fallbacks(ベータ)も入り、こちらは利用可能な最良のモデルへ自動で流す挙動です。API側は明示的に有効化する形で、Claude.ai / Claude Code / Coworkで動くAssistantでは、Opus 5のサイバー分類器で弾かれたリクエストが既定でOpus 4.8へ流れます。

フォールバック時には切り替え先でプロンプトキャッシュを作り直すコストが発生しますが、この分はfallback creditとして払い戻されます。監視側では、stop_reason の内訳、フォールバック先で処理された比率、モデル別のトークン消費の3点を分けて記録しておくと判断が楽になります。発動率の目安として、Fable 5では95%超のセッションでフォールバックが発生しないと示されているため、自分たちのワークロードがその水準に収まっているかをデータで切り分けられます。

定額プランの枠内で使い分ける

APIを使わない構成でも、モデルの混ぜ方は設計できます。プラン別の既定は次のようになっています。

Proプランなら、日常の会話はSonnet 5のまま進め、判断が重い場面だけモデルピッカーでOpus 5へ切り替える形が組めます。Maxプランは既定がOpus 5になったので、逆に「軽い作業はSonnet 5へ落とす」方向の調整が効きます。上位モデルが既定のままだと、短い質問や定型の確認まで同じ枠を消費するためです。

キャッシュとBatchを重ねる

モデルの振り分けは、単価を下げる3つの手法のうち1つにすぎません。残る2つはprompt cachingとBatch APIで、いずれもモデル選択と直交します。

• モデルルーティング:作業の性質でモデルを振り分ける。上位モデルの呼び出し回数そのものを減らす
• prompt caching:システムプロンプト、ツール定義、参照コンテキストの静的部分を再利用する。キャッシュ読み取りは入力単価の0.1倍
• Batch API:即時性の不要なバルク処理を回す。入力・出力とも50%引き

3つは掛け算で効きます。Haiku 4.5に降ろした分類処理をBatch APIで流し、共通のシステムプロンプトをキャッシュに載せる。この構成なら、同じ処理を上位モデルの逐次実行で回した場合と比べて、累計コストは桁で変わります。キャッシュの仕組みと適用判断はprompt cachingの解説が詳しいところです。

旧世代から移すときに確認する3点

現行4系統への移行で引っかかりやすいのは、モデルIDの差し替えそのものではありません。thinkingの指定方式、トークン数の増分、IDの固定という3点です。

thinkingの指定方式が最初の関門です。thinking: {"type": "enabled", "budget_tokens": N} の形式はFable 5・Opus 5・Sonnet 5では受け付けられず、Sonnet 5に送ると400エラーになります。思考の深さは effort で制御する方式へ書き換えます。Fable 5はさらに厳しく、{"type": "disabled"} によるthinkingの無効化も非サポートです。Claude Code側の MAX_THINKING_TOKENS=0 や alwaysThinkingEnabled の設定でも無効化できません。旧モデル向けにthinkingをオフにする実装が残っていると、そのままでは移行できない箇所です。

トークン数の増分が2つ目です。Fable 5のトークナイザーはOpus 4.7世代で、旧世代モデルと同じテキストでもトークン数がおよそ30%多くカウントされます。max_tokens の設定値とコスト見積もりは、移行時に実測し直す必要があります。Sonnet 5もSonnet 4.6比でトークン数が増える方向で、8月末までの導入価格はこの増分を織り込んでSonnet 4.6からの移行がほぼコスト中立になるよう設定されたとされます。9月1日以降の標準価格では、同じテキスト量あたりの実コストが上がる可能性があります。

モデルIDの固定が3つ目です。現行世代のIDは日付サフィックスを持ちませんが、いずれも挙動が固定されたスナップショットで、中身が入れ替わるエイリアスではありません。claude-opus-5 と書けば、その挙動はそのまま固定されます。一方、Claude Codeの /model opus のような系統名の指定は解決先が動きます。v2.1.219でOpusを選んだときに起動するモデルがOpus 4.8からOpus 5へ替わったのが、その実例です。本番運用では、意図せぬ挙動変化を避けるために明示的なID指定を選ぶ判断があります。

プロンプト自体の書き直しは、基本的に不要です。同系統内の更新では大きな書き換えを求められない設計になっており、Opus 4.8からOpus 5への乗り換えでも料金体系ごと据え置きです。ただしFable 5については、細かいタスク分割やステップ指示を作り込むほど性能を引き出しにくくなる傾向が示されています。手順ではなく成果を渡す、大きいタスクを分割せずに渡す、という方向へ寄せた書き方が合います。

よくある質問

Opus 5とFable 5はどう使い分けますか?

コンテキスト長や知性のピークが物を言う作業ではFable 5、それ以外の最上位ワークではOpus 5という切り方になります。Opus 5はCursorBench 3.2の最大effortでFable 5のピークまで0.5ポイント差、コストは半額です。加えてFable 5には30日のデータ保持が必須という制約があり、ZDR契約下では選べません。攻撃的セキュリティや生物研究のように安全分類器の発動が想定される領域も、最初からOpus 5を選ぶほうが運用は単純になります。

Claude CodeでOpusを選ぶと何が起動しますか?

v2.1.219以降はOpus 5(claude-opus-5)です。既定が替わるのはOpusの系統だけで、セッション全体の既定モデルが置き換わるわけではありません。自分で別のモデルを明示的に選んでいれば、その選択が優先されます。特定の作業でOpus 4.8を使いたい場合は、これまでどおり /model で選び直せます。

無料プランでもモデルを選べますか?

無料プランの既定モデルはSonnet 5ですが、モデルを切り替える機能はPro以上の有料プランに限られます。Fable 5も無料プランでは利用できません。

Haiku 4.5はどこまで任せられますか?

判定基準が機械的に明確な作業なら、上位モデルと遜色ない精度が出ます。JSON抽出、明示パターンの分類、URL抽出、字数カウントなどが該当します。判断の余地がある評価、たとえば文章の質や独自視点の有無を測る作業では精度が安定しないため、Sonnet 5以上を使う形になります。

画像入力はどのモデルでも使えますか?

使えます。現行のFable 5 / Opus 5 / Sonnet 5 / Haiku 4.5はすべてテキストと画像の入力に対応しており、画像を扱うからといってモデル選択が制約されることはありません。

モデルが更新されたら既存のプロンプトを書き直す必要がありますか?

同系統内の更新では基本的に不要です。ただし思考の制御を活かすなら、effortの指定を足すだけで挙動が変わります。世代をまたぐ移行では、前述のthinkingの指定方式とトークン数の増分の2点だけ確認する形になります。

このページの更新方針と更新履歴

Claudeのモデル構成は数か月単位で入れ替わります。このページは特定の年月に紐付けず、モデルが追加・廃止されるたびに現行構成へ書き換えて維持します。表の値、既定モデル、対応バージョンはいずれもその時点の最新に置き換えるため、過去の構成を確認したい場合はClaude Fable 5の解説など各モデルの個別記事のほうが適しています。

• 2026-07-25: Opus 5の提供開始に合わせて全面改稿(Opusクラスの記載をOpus 4.8からOpus 5に差し替え、高速モードと組み合わせ設計の節を追加)

まとめ

現行4系統の割り当ては、既定はSonnet 5、判断の質が要る場面はOpus 5、大量処理はHaiku 4.5、長く曖昧な自律タスクだけFable 5に集約されます。Opus 5がFable 5に半額で迫ったことで、上位2系統の境界はデータ保持要件とタスクの曖昧さに移りました。単価の階段は大きく見えますが、Batch APIとprompt cachingを重ねれば実コストは額面よりかなり縮みます。

そして最大の効き目は、モデルを1つ選ぶことをやめる設計にあります。Claude Codeならサブエージェントの model と opusplan、APIならフォールバックの前提化。どちらも「重い判断を上位に、量産を下位に」という同じ割り当てを、手動の切り替えなしで固定する仕組みです。Claudeのモデル体系やプロダクト全体の見取り図から把握し直したい場合は、Claudeの全体像をまとめた完全ガイドもあわせて参考にしてください。