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

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

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

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

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

1. 既定はSonnet 5。大半の作業は品質・速度・コストのバランスで足ります
2. 結果の質が意思決定に直結するならOpus 5。採点、設計、レビューのように、判断の深さがそのまま成果へ響く場面です
3. 判定基準が明確で呼び出し回数が多いならHaiku 4.5。単価差が累計で効いてきます
4. 長く曖昧な自律タスクはFable 5.1。入力・出力の単価はOpus 5の2倍ですが、キャッシュ読み取りは半額なので、文脈の読み直しが支配的な作業ほど差は縮みます

Opus 5の登場で動いたのは2番目と4番目の境界で、Fable 5.1の登場でその境界がもう一度動きました。7月には、Opus 5がCursorBench 3.2の最大effortでFable 5のピークまで0.5ポイント差に迫り、それを半額で出していました。9月のFable 5.1はCursorBench 3.2.0で73.4%と、Opus 5の70.0%に3.4ポイント差を付け直しています。1Mトークンのコンテキストと128Kトークンの最大出力はOpus 5も備えるため、残る差は知性のピーク、長く曖昧な作業での粘り、そしてキャッシュ読み取りの単価です。

Fable 5.1の側にも譲れない条件があります。全トラフィックで30日のデータ保持が必須で、ゼロデータ保持(ZDR)の契約下ではAnthropicが明示的に認めた場合を除いて選べません。ペネトレーションテストやライフサイエンス研究のような領域では安全分類器がOpusへ転送するので、最初からOpusクラスを選ぶほうが運用は単純になります。仕様の細部はClaude Fable 5.1の解説にまとめてあります。

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

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

スペック比較

思考の制御方式が、実装に最も直結する差です。Fable 5.1・Opus 5・Sonnet 5は、モデル自身が思考の要否と深さを決めるadaptive thinkingに一本化されており、深さは effort パラメータ(low / medium / high / xhigh / max)で調整します。Haiku 4.5だけが thinking の budget_tokens を受け取る従来方式です。旧世代向けに budget_tokens を送る実装が残っていると、Sonnet 5では400エラーになります。Fable 5.1にはさらに固有の制約が3つあります。tool_choice の any / tool(強制ツール呼び出し)が400エラーになること、生成したthinkingブロックを古いモデルが読めないこと、会話の途中を編集すると以降のthinkingブロックが無効になることです。

コンテキストの壁も判断を左右します。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の入力$2 / 出力$10は、当初2026年8月31日までの導入価格として発表されていましたが、2026年8月10日に恒久的な標準価格になることが公式発表され、予定されていた入力$3 / 出力$15への値上げは撤回されました。Batch APIを使えば全モデルで入力・出力とも50%引きです。即時性の不要なバルク処理なら、実質単価は半分になります。Opus 5の単価はOpus 4.8から据え置きなので、Opus 4.8を主軸に組んでいたワークロードは料金の再試算なしで乗り換えられます。詳しい発表内容はOpus 5の登場を伝えた記事で扱っています。

キャッシュ読み取りの列だけは、単価の階段と逆向きです。Fable 5.1の$0.25はOpus 5の半額で、Fable 5の$1から4分の1に下がりました。固定のシステムプロンプトやリポジトリの文脈を何十ターンも読み直すエージェントループでは、この読み取りが入力コストの大半を占めるため、入力側だけならFable 5.1がOpus 5を下回る場面が出ます。額面で2倍差が残るのは出力側で、Fable 5.1の実コストは「どれだけ出力を吐くか」でほぼ決まります。試算はClaude Fable 5.1の解説の料金の節に置いています。

額面の単価だけで比べると見落とす要素がもう1つあります。Fable 5.1・Opus 5・Sonnet 5はOpus 4.7世代のトークナイザーを使うため、同じテキストでも旧世代モデルよりトークン数がおよそ30%多くカウントされます。Opus 4.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です。

何時間も無人で走らせる実装や、複数のリポジトリにまたがる移行では、Fable 5.1が候補に上がります。Terminal-Bench 4.0で55.8%(Opus 5は52.3%)、CursorBench 3.2.0で73.4%(同70.0%)と、長いセッションでの差が数字にも出ています。

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

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

曖昧さの残る調査ではFable 5.1が候補に入ります。1Mトークンの奥深くにある事実をつなげて答える長文脈の想起が強化された領域で、複数ステップの調査で見つけたものを追いかける作業も伸びています。入力・出力の単価はOpus 5の2倍ですが、同じ文脈を何度も読み直す作業ではキャッシュ読み取りの安さが効きます。従来構成で時間がかかっている作業、途中で迷走しがちな作業だけを振り替えて、完了率と所要時間、そして usage の出力トークンとキャッシュ読み取りの比率を比べる入り方が現実的なところです。

日常利用

claude.aiでの日常利用は、Free / Proの既定であるSonnet 5がそのまま最適解になります。ProプランではOpus 5も選べるので、日常はSonnet 5、要所でOpus 5という切り替えが組みやすい形です。MaxプランはOpus 5が既定になったため、モデルを明示的に選ばずに使っている場合は自然にOpus 5が走り始めます。Fable 5.1はどのプランでも既定にならず、Maxではプランの枠内(週次上限の50%まで)、Proではusage credits経由で選びます。プランごとの枠の仕組みは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.1・Opus 5・Sonnet 5はいずれもeffortで思考の深さを指定できます。難しい調査や設計では、モデルを上げる前に /effort でxhighやmaxへ引き上げる選択肢があります。

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

逆方向も成り立ちます。Fable 5.1は medium でFable 5と同等の結果がより安く出るとされ、low でもOpusやSonnetとタスク単価で競うケースがあります。上位モデルを下位モデルへ落とす前に、Fable 5.1の低effortを1度測ると選択肢が増えます。Fable 5.1とOpus 5では、会話の途中でeffortだけを変えるシステムメッセージ(ベータ)も使え、プロンプトキャッシュを壊さずに難しいステップだけ深く考えさせられます。

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

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

切り替えを自前で書かずに済む仕組みも用意されています。安全分類器の拒否を1回のAPIコール内で別モデルへ自動再送するserver-side fallback(サーバーサイドフォールバック)がClaude APIでベータ提供されており、fallbacks パラメータに "default" を指定すると、拒否のカテゴリーに応じた推奨モデルへ自動で再試行されます。Fable 5.1のフォールバック先はOpus 4.8とOpus 5です。API側は明示的に有効化する形で、Claude Codeでは、Fableモデルのサイバー分類器で弾かれたリクエストは既定でOpus 4.8へ、生物学で弾かれたリクエストはOpus 5へ再実行されます。

フォールバック時には切り替え先でプロンプトキャッシュを作り直すコストが発生しますが、この分はfallback creditとして払い戻されます。Fable 5.1では、生成したthinkingブロックをフォールバック先が読めないため、APIがそのブロックを落としてから再試行する点も設計に入れておく箇所です。監視側では、stop_reason の内訳、フォールバック先で処理された比率、モデル別のトークン消費の3点を分けて記録しておくと判断が楽になります。

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

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

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

キャッシュとBatchを重ねる

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

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

3つは掛け算で効きます。Haiku 4.5に降ろした分類処理をBatch APIで流し、共通のシステムプロンプトをキャッシュに載せる。この構成なら、同じ処理を上位モデルの逐次実行で回した場合と比べて、累計コストは桁で変わります。ただしキャッシュはモデルを切り替えると当たらなくなるため、1つのワークフローで複数モデルを混ぜると、モデルごとに書き込みが発生します。読み直しの多い主ループは1つのモデルに寄せ、サブタスクだけ別モデルへ降ろす形が、キャッシュとルーティングを両立させる組み方です。キャッシュの仕組みと適用判断はprompt cachingの解説が詳しいところです。

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

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

thinkingの指定方式が最初の関門です。thinking: {"type": "enabled", "budget_tokens": N} の形式はFable 5.1・Opus 5・Sonnet 5では受け付けられず、Sonnet 5に送ると400エラーになります。思考の深さは effort で制御する方式へ書き換えます。Fable 5.1はさらに厳しく、{"type": "disabled"} によるthinkingの無効化も400エラーです。Claude Code側の MAX_THINKING_TOKENS=0 や alwaysThinkingEnabled の設定でも無効化できません。旧モデル向けにthinkingをオフにする実装が残っていると、そのままでは移行できない箇所です。Fable 5からFable 5.1へ移る場合は、強制ツール呼び出し(tool_choice の any / tool)の廃止と、会話履歴を追記専用にする制約が加わります。

トークン数の増分が2つ目です。Fable 5.1のトークナイザーはOpus 4.7世代で、旧世代モデルと同じテキストでもトークン数がおよそ30%多くカウントされます。max_tokens の設定値とコスト見積もりは、移行時に実測し直す必要があります。Sonnet 5もSonnet 4.6比でトークン数が増える方向ですが、Sonnet 5の単価(入力$2 / 出力$10)はSonnet 4.6(入力$3 / 出力$15)よりも低く、しかもこの単価は恒久価格として確定しているため、トークン数の増分を踏まえても実コストが上がる可能性は低いとみられます。

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

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

よくある質問

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

長時間の自律実行、長文脈の読み直し、文書・スプレッドシート・スライドの作成ではFable 5.1、それ以外の最上位ワークではOpus 5という切り方になります。入力・出力の単価はFable 5.1がOpus 5の2倍ですが、キャッシュ読み取りは半額なので、文脈の読み直しが多い作業では入力側の差が逆転します。加えてFable 5.1には30日のデータ保持が必須という制約があり、ZDR契約下ではAnthropicの明示的な許可がない限り選べません。ペネトレーションテストやライフサイエンス研究のように安全分類器がOpusへ転送する領域も、最初からOpus 5を選ぶほうが運用は単純になります。

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

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

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

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

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

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

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

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

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

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

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

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

• 2026-07-25: Opus 5の提供開始に合わせて全面改稿(Opusクラスの記載をOpus 4.8からOpus 5に差し替え、高速モードと組み合わせ設計の節を追加)
• 2026-09-03: Fable 5.1の提供開始に合わせて改稿(Fableクラスの記載をFable 5からFable 5.1に差し替え、キャッシュ読み取り単価の逆転とベンチマークの更新、Fable 5.1固有の制約を追記)

まとめ

現行4系統の割り当ては、既定はSonnet 5、判断の質が要る場面はOpus 5、大量処理はHaiku 4.5、長く曖昧な自律タスクと文脈の読み直しが多い作業はFable 5.1に集約されます。Opus 5がFable 5に半額で迫ったあと、Fable 5.1がベンチマークで差を付け直し、キャッシュ読み取りをOpus 5の半額まで下げたことで、上位2系統の境界は「出力偏重か読み直し偏重か」と、データ保持要件・分類器の転送領域に移りました。単価の階段は大きく見えますが、Batch APIとprompt cachingを重ねれば実コストは額面よりかなり縮みます。

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