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

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

ClaudeのモデルはFable 5.1 / Opus 5.5 / Sonnet 5.5 / Haiku 5.5の4系統です。スペックと料金の比較、用途別の使い分け、複数モデルを1つのワークフローに混ぜる設計をまとめます。

ClaudeのモデルはFable 5.1 / Opus 5.5 / Sonnet 5.5 / Haiku 5.5の4系統です。9月1日にFableクラスがFable 5からFable 5.1へ進みました。9月22日にはOpusクラスがOpus 5からOpus 5.5へ、9月28日にはSonnetクラスがSonnet 5からSonnet 5.5へ入れ替わりました。10月7日にはHaikuクラスもHaiku 4.5からHaiku 5.5へ進みました。入力単価の開きは100倍($0.10から$10)で、コンテキストは4系統とも1Mトークンです。スペックと料金、用途ごとの向き不向き、そして複数のモデルを1つのワークフローに混ぜる設計をまとめます。

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

Haiku 5.5は2026年10月7日に提供が始まり、Haiku 4.5はレガシーに移りました。Haiku 4.5の退役は、早くても2026年10月15日です。

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

モデル一言でいうとこういうときに選ぶ
Claude Fable 5.1一言でいうとOpusの一段上に置かれたMythosクラスこういうときに選ぶOpus 5.5を高effortにしても届かない推論や、長く曖昧な自律タスク
Claude Opus 5.5一言でいうと迷ったら最初に試す主力こういうときに選ぶ実装・設計・レビュー・エージェント運用の大半
Claude Sonnet 5.5一言でいうと速度と品質のバランス型こういうときに選ぶ範囲が明確な日常の実装・調査・資料作成を、速度と単価優先で回す
Claude Haiku 5.5一言でいうと最速かつ最安こういうときに選ぶ抽出・分類・大量バッチ・リアルタイム応答

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

  1. 起点はOpus 5.5。単価がOpus 5より2割下がり、Sonnet 5.5との差は2倍まで縮みました
  2. 速度と単価を優先するならSonnet 5.5。単価はOpus 5.5の半分で、Sonnet 5より30%以上速いと公表されています
  3. 判定基準が明確で呼び出し回数が多いならHaiku 5.5。単価差が累計で効いてきます
  4. Opus 5.5で評価が届かない作業だけFable 5.1。入力・出力の単価はOpus 5.5の2.5倍で、キャッシュ読み取りもOpus 5.5のほうが安くなりました

Opus 5.5の登場で動いたのは1番目と4番目の境界です。7月にはOpus 5がFable 5に迫り、9月1日のFable 5.1がCursorBench 3.2.0で73.4%とOpus 5の70.0%に差を付け直しました。その3週間後のOpus 5.5は、Anthropicの公表値でCursorBench 4.0を既定effort(medium)のまま52.5%としました。これは最大effortのFable 5.1(51.8%)とOpus 5(46.6%)を上回る数字です。発表文は「ほとんどの作業でFable 5.1と同水準」としつつ、この水準ではベンチマークの差が実務差の信頼できる指標ではなくなったとも注記しています。

Fable 5.1の側には譲れない条件もあります。全トラフィックで30日のデータ保持が必須で、ゼロデータ保持(ZDR)の契約下ではAnthropicが明示的に認めた場合を除いて選べません。Opus 5.5はZDRで利用できます。ペネトレーションテストやライフサイエンス研究のような領域では、Fable 5.1でもOpus 5.5でも安全分類器が働きます。Claude Codeではサイバー系がOpus 4.8、生物学系がOpus 5へ再実行されます。仕様の細部はClaude Opus 5.5の解説とClaude Fable 5.1の解説にまとめてあります。

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

数字で見ると、4系統の差は単価の階段と、既定effortや強制ツール呼び出しの扱いに出ます。単価は$0.10から$10まで4段です。コンテキストと最大出力は、4系統とも1Mトークンと128Kトークンでそろっています。

スペック比較

項目Fable 5.1Opus 5.5Sonnet 5.5Haiku 5.5
モデルIDFable 5.1claude-fable-5-1Opus 5.5claude-opus-5-5Sonnet 5.5claude-sonnet-5-5Haiku 5.5claude-haiku-5-5
コンテキストウィンドウFable 5.11MトークンOpus 5.51MトークンSonnet 5.51MトークンHaiku 5.51Mトークン
最大出力Fable 5.1128KトークンOpus 5.5128KトークンSonnet 5.5128KトークンHaiku 5.5128Kトークン
思考の制御Fable 5.1adaptive(常時オン、既定effortはhigh)Opus 5.5adaptive(常時オン、既定effortはmedium)Sonnet 5.5adaptive(既定effortはAPIでhigh、Claude Codeとアプリでmedium)Haiku 5.5adaptive(既定effortはmedium)
画像入力Fable 5.1対応Opus 5.5対応Sonnet 5.5対応Haiku 5.5対応

思考の方式は、4系統ともモデル自身が思考の要否と深さを決めるadaptive thinkingにそろいました。実装で差が出るのは既定effortと周辺の制約です。深さは effort パラメータ(low / medium / high / xhigh / max)で調整します。API上で既定effortが medium なのはOpus 5.5とHaiku 5.5です。Opus 5.5は指定を省くと、Opus 5(high)より浅く考えます。旧世代向けに budget_tokens を送る実装が残っていると、現行4系統のいずれでも400エラーになります。Fable 5.1・Opus 5.5・Sonnet 5.5にはさらに共通の制約が3つあります。tool_choice の any / tool(強制ツール呼び出し)が400エラーになること、生成したthinkingブロックを古いモデルが読めないこと、会話の途中を編集すると以降のthinkingブロックが無効になることです。

Haiku 5.5は強制ツール呼び出しを受け付けますが、応答はツール呼び出しから始まり、thinkingブロックは付きません。会話の途中を編集すると以降のthinkingブロックが400エラーになる制約は、Haiku 5.5にもあります。

コンテキストの壁は、Haiku 5.5で外れました。Haiku 4.5の200Kトークンでは届かなかったリポジトリ横断の調査や長大なログの一括解析も、Haiku 5.5なら分割せずに渡せます。Fable 5.1・Opus 5.5・Sonnet 5.5の1Mトークンに長文の追加プレミアム料金はなく、900Kトークンのリクエストも9Kトークンと同じ単価で課金されます。Haiku 5.5は例外で、プロンプトが10万トークンを超えると入力$0.50・出力$2.50に上がります。

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

項目Fable 5.1Opus 5.5Sonnet 5.5Haiku 5.5
データ保持Fable 5.130日保持が必須(ZDRは明示的な許可がある場合のみ)Opus 5.5ZDRでも利用可Sonnet 5.5ZDRでも利用可Haiku 5.5—
高速モード(fast mode)Fable 5.1対象外Opus 5.5対応(Claude APIのresearch preview)Sonnet 5.5対象外(遅延はFastクラスと表示)Haiku 5.5対象外
Claude Codeでの扱いFable 5.1v2.1.257以降で選択可(fable エイリアスの解決先)Opus 5.5v2.1.280で opus と既定モデルの解決先にSonnet 5.5v2.1.284以降で sonnet エイリアスの解決先(Anthropic API)Haiku 5.5v2.1.293以降で haiku エイリアスの解決先(Anthropic API)
サブスクリプションFable 5.1Max・プレミアムシートはプランに含まれる(週次上限の50%まで)。Pro・標準シートはusage credits経由Opus 5.5Pro・Max・Team・EnterpriseでClaude Codeの既定Sonnet 5.5各プランで選択可Haiku 5.5各プランで選択可

現行の4系統は、いずれもPriority Tierの対象外です。現行世代へ移ると、Priority Tierの容量は使えなくなります。Haiku 4.5でPriority Tierを契約している場合は、移行前に容量の扱いを決めておきます(Haiku 4.5の退役は早くても2026年10月15日です)。

高速モード(fast mode)は、Opusを通常の最大2.5倍速で動かす代わりに基本料金の2倍を払う仕組みです。Opus 5.5なら入力$8 / 出力$40、旧Opus 5なら$10 / $50になります。対象はOpus 5.5・Opus 5・Opus 4.8です。Claude APIでのresearch previewとして提供されています。Bedrock・Google Cloud・Microsoft Foundry・Claude Platform on AWSでは使えません。Claude Codeの /fast からはv2.1.219でOpus 4.7が外れ、同じv2.1.219で /model ピッカーのOpus行が「Opus (1M context)」表示になりました。バージョンごとの変更点はClaude Code v2.1.219のリリースノートとv2.1.280のリリースノートにまとめてあります。

料金比較

モデル入力(100万トークン)出力(100万トークン)キャッシュ読み取り
Fable 5.1入力(100万トークン)$10出力(100万トークン)$50キャッシュ読み取り$0.25(入力の0.025倍)
Opus 5.5入力(100万トークン)$4出力(100万トークン)$20キャッシュ読み取り$0.20(入力の0.05倍)
Sonnet 5.5入力(100万トークン)$2出力(100万トークン)$10キャッシュ読み取り$0.10(入力の0.05倍)
Haiku 5.5入力(100万トークン)$0.10(10万トークン超は$0.50)出力(100万トークン)$0.50(10万トークン超は$2.50)キャッシュ読み取り$0.01(入力の0.1倍。10万トークン超は$0.05)
Haiku 4.5(レガシー)入力(100万トークン)$1出力(100万トークン)$5キャッシュ読み取り$0.10(入力の0.1倍)
Opus 5(レガシー)入力(100万トークン)$5出力(100万トークン)$25キャッシュ読み取り$0.50(入力の0.1倍)
Sonnet 5(レガシー)入力(100万トークン)$2出力(100万トークン)$10キャッシュ読み取り$0.20(入力の0.1倍)

Sonnet 5.5の入力$2 / 出力$10はSonnet 5と同額です。Sonnet 5の価格は当初2026年8月31日までの導入価格として発表されましたが、2026年8月10日に恒久的な標準価格になり、入力$3 / 出力$15への値上げは撤回されています。Sonnet 5.5は必要なトークンが少なく、タスク単価は最大30%安くなるとされています(Anthropic公表値)。Batch APIを使えば全モデルで入力・出力とも50%引きです。即時性の不要なバルク処理なら、実質単価は半分になります。Opus 5.5はOpus 5から入力・出力が2割、キャッシュ読み取りが6割下がり、Anthropicは既定設定の典型的なワークロードでOpus 5より40%安くなると説明しています。発表内容はClaude Opus 5.5の解説で扱っています。

キャッシュ読み取りの列は、単価の階段どおりに並びません。Fable 5.1の$0.25はFable 5の$1から4分の1に下がりましたが、Opus 5.5の$0.20はそれよりさらに安く、Sonnet 5.5の$0.10はその半額です。Fable 5.1がOpus 5に対して持っていた「読み直しが多いほど有利」という利点は、Opus 5.5に対しては成り立ちません。入力・出力・キャッシュ読み取りのどれを取ってもFable 5.1のほうが高く、Fable 5.1を選ぶ理由は単価ではなく知性のピークに絞られます。

額面の単価だけで比べると見落とす要素がもう1つあります。Fable 5.1・Opus 5.5・Sonnet 5.5・Haiku 5.5はOpus 4.7世代のトークナイザー(Sonnet 5.5はSonnet 5と共通)を使います。そのため同じテキストでも旧世代モデルよりトークン数がおよそ30%多くカウントされます。Haiku 4.5から移ると、単価が下がっても同じ文章のトークン数がおよそ30%増える点を見込む必要があります。Opus 4.6以前の世代から移行する場合、単価の差にこの増分が重なります。これは机上の概算で、実際の差はプロンプトの構成とキャッシュヒット率で変わります。

用途別の使い分け

コーディング

コーディングの起点はOpus 5.5とSonnet 5.5の2択になります。Opus 5.5の発表では、マージされるかどうかを測るFrontierCodeで既定effort(medium)のまま54.6%とされています。20万行のコードベースの監査と修正を、Opus 5が20時間超かけた作業に対して3時間弱で終えた事例も示されました。複数ファイルにまたがるリファクタリングや、判断を挟みながら長時間走らせる作業ほど差が出ます。

一方、範囲が明確な日常の機能追加やバグ修正はSonnet 5.5で十分に届きます。公表値のTerminal-Bench 4.0はSonnet 5.5が70.6%で、Opus 5.5(Xhigh)の66.4%を上回りました(Sonnet 5は10.3%)。ただしマージされるかどうかを測るFrontierCodeは52.1%(Xhigh。Maxでは46.2%)で、Opus 5.5の54.4%(Sonnet 5.5発表の比較表)には届きません。複雑で判断の持続が要る仕事はOpus 5.5が明確に強いとされています。境界の目安は、出力をそのまま使うならSonnet 5.5、出力を根拠に何かを決める(マージ可否、設計採否、公開判断)ならOpus 5.5です。

何時間も無人で走らせる実装や、複数のリポジトリにまたがる移行でも、先に測る価値があるのはOpus 5.5です。HAProxyをCからRustへ移植した公表事例では、Opus 5.5が9.5時間、Fable 5.1が12時間でした。Fable 5.1が候補に上がるのは、Opus 5.5を高effortにしても完了率が届かないときです。

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

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

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

日常利用

claude.aiでの日常利用は、Sonnet 5.5で足りる場面が大半です。

Claude Codeでは、v2.1.280からPro・Max・Team・Enterpriseとも既定がOpus 5.5になったため、モデルを明示的に選ばずに使っている場合は自然にOpus 5.5が走ります。軽い作業が多いなら、sonnet(v2.1.284以降はSonnet 5.5)へ明示的に切り替える調整が効きます。Fable 5.1はどのプランでも既定にならず、Maxではプランの枠内(週次上限の50%まで)、Proではusage credits経由で選びます。プランごとの枠の仕組みはClaude料金プラン比較で扱っています。

コスト重視の大量処理

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

作業別の早見表

作業第一候補理由
Opus 5.5で届かない高難度の推論・自律実行第一候補Fable 5.1理由公式が上限突破用に位置付けるクラス
大規模コードベースの横断調査・移行第一候補Opus 5.5理由1Mコンテキストと128K出力で分割せずに扱え、キャッシュ読み取りが$0.20と安い
文書・スプレッドシート・スライドを白紙から完成まで第一候補Opus 5.5理由知識労働の評価(GDPval-AA v2.1)で1846と、Fable 5.1の1735を上回る(Anthropic公表値)
設計レビュー・多観点の採点第一候補Opus 5.5理由判断の深さがそのまま成果に出る
複数ファイルにまたがるリファクタリング第一候補Opus 5.5理由自己検証を挟みながら長い作業を続けられる
日常の実装とバグ修正第一候補Sonnet 5.5理由範囲が明確な作業なら速度と品質のバランスが取れている
調査・要約・文章生成第一候補Sonnet 5.5理由情報統合の質と応答速度を両立できる
構造化データの抽出第一候補Haiku 5.5理由基準が明確なら精度も足りる
大量バッチの分類・採点第一候補Haiku 5.5理由累計コストの差が大きく出る
リアルタイムの応答第一候補Haiku 5.5理由体感速度が決定的になる

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

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

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

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

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

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

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

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

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

/model opusplan

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

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

モデルの切り替えと並んで使えるのが effort です。Fable 5.1・Opus 5.5・Sonnet 5.5はいずれもeffortで思考の深さを指定できます。難しい調査や設計では、モデルを上げる前に /effort でxhighやmaxへ引き上げる選択肢があります。Opus 5.5は既定が medium なので、Opus 5で high 前提に組んだ評価は、effortを明示して取り直す対象です。

Sonnet 5.5は特に、この軸で幅を持たせやすいモデルです。低effortで安価に流し、必要な場面だけ高effortで深く考えさせる運用が同じモデル内で成立します。ただしeffortの水準は再較正されているため、Sonnet 5の設定は持ち越さず再スイープします。エージェント系はmediumから測るのが出発点です。「Sonnetでは足りないからOpusへ」と判断する前に、effortを一段上げて再試行するだけで届く場面があります。モデルを上げると単価が上がり(Sonnet 5.5の$2 / $10からOpus 5.5の$4 / $20で2倍)、effortを上げてもコストは思考トークンの増分だけ、という違いです。

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

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

Fable 5.1・Opus 5.5・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 5.5のサイバー分類器で弾かれたリクエストは既定でOpus 4.8へ、生物学で弾かれたリクエストはOpus 5へ再実行されます。Opus 5.5の分類器はOpus 5より範囲が広く、内部推論を応答に再現させる要求も reasoning_extraction のカテゴリーで拒否されることがあります。

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

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

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

プランClaude Codeの既定(v2.1.280以降)v2.1.280より前Fable 5.1の扱い
FreeClaude Codeの既定(v2.1.280以降)Claude Codeは対象外v2.1.280より前—Fable 5.1の扱い利用不可
ProClaude Codeの既定(v2.1.280以降)Opus 5.5v2.1.280より前Sonnet 5(当時のSonnet)Fable 5.1の扱いusage credits経由
MaxClaude Codeの既定(v2.1.280以降)Opus 5.5v2.1.280より前Opus 5Fable 5.1の扱いプランに含まれる(週次上限の50%まで)
Team / EnterpriseClaude Codeの既定(v2.1.280以降)Opus 5.5v2.1.280より前Team StandardはSonnet 5、それ以外はOpus 5Fable 5.1の扱いプレミアムシートで含まれ、標準シートはusage credits経由

ProもMaxも既定がOpus 5.5になったので、「軽い作業はSonnetへ落とす」方向の調整が効きます。上位モデルが既定のままだと、短い質問や定型の確認まで同じ枠を消費するためです。Opus 5.5の登場にあわせて、Pro・Max・Team・シート制Enterpriseの5時間あたりの利用上限も引き上げられました。

キャッシュとBatchを重ねる

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

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

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

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

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

thinkingの指定方式が最初の関門です。thinking: {"type": "enabled", "budget_tokens": N} の形式は、現行の4系統すべてで受け付けられません。Sonnet 5.5に送ると400エラーになります。思考の深さは effort で制御する方式へ書き換えます。Haiku 4.5から移る場合も、thinking を adaptive と effort の指定に書き換えます。{"type": "disabled"} によるthinkingの無効化は、Fable 5.1・Opus 5.5・Sonnet 5.5の3モデルで400エラーです。Haiku 5.5は disabled を high 以下のeffortで受け付けます。Sonnet 5.5には代わりに between_tools があり、low / medium / highのeffortでだけ使えます。Fable 5.1とOpus 5.5では、Claude Code側の MAX_THINKING_TOKENS=0 や alwaysThinkingEnabled の設定でも無効化できません。旧モデル向けにthinkingをオフにする実装が残っていると、そのままでは移行できない箇所です。Fable 5からFable 5.1へ、Opus 5からOpus 5.5へ、Sonnet 5からSonnet 5.5へ移る場合は、次の2点が加わります。強制ツール呼び出し(tool_choice の any / tool)の廃止と、会話履歴を追記専用にする制約です。Opus 5.5とSonnet 5.5は、computer useの computer_20251124 も受け付けません。対象はClaude APIとGoogle Cloudです(Sonnet 5.5はAmazon Bedrockなら受け付けます)。Sonnet 5.5をexecutorにしてadvisorツールを使う場合、Opus 4.8・Opus 4.7・Sonnet 5のadvisorは400になります。Opus 5.5やFable 5.1などに替えます。手順はClaudeモデルの移行ガイドにまとめています。

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

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

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

よくある質問

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

まずOpus 5.5で試し、高effortにしても評価が届かない推論や長時間のエージェント作業だけFable 5.1へ回す、という切り方が公式の推奨順です。単価は入力・出力でFable 5.1がOpus 5.5の2.5倍、キャッシュ読み取りもOpus 5.5の$0.20のほうが安くなります。加えてFable 5.1には30日のデータ保持が必須という制約があり、ZDR契約下ではAnthropicの明示的な許可がない限り選べません。Opus 5.5はZDRで使えます。

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

v2.1.280以降はOpus 5.5(claude-opus-5-5)です。v2.1.219〜v2.1.279はOpus 5でした。v2.1.280ではモデルを指定しないときの既定もPro・Max・Team・EnterpriseでOpus 5.5に替わっています。自分で別のモデルを明示的に選んでいれば、その選択が優先されます。Opus 5を使い続けたい場合は claude-opus-5 をモデルIDで指定します。同様に /model fable はv2.1.257以降Fable 5.1を起動し、Fable 5を使うにはモデルIDで指定します。

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

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

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

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

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

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

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

同系統内の更新では基本的に不要です。ただし思考の制御を活かすなら、effortの指定を足すだけで挙動が変わります。世代をまたぐ移行では、前述のthinkingの指定方式とトークン数の増分の2点だけ確認する形になります。Fable 5からFable 5.1へ、Opus 5からOpus 5.5へ、Sonnet 5からSonnet 5.5へは、強制ツール呼び出しと履歴編集の2点を追加で確認します。Haiku 4.5からHaiku 5.5へ移る場合も、会話履歴を追記専用にする制約が加わります(強制ツール呼び出しは引き続き使えます)。Sonnet 5.5では thinking の disabled も400になります。computer_20251124(APIとGoogle Cloud)とadvisorの組み合わせも確認対象です。

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

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固有の制約を追記)
  • 2026-09-23: Opus 5.5の提供開始に合わせて改稿。Opusクラスの記載をOpus 5からOpus 5.5に差し替え、起点のモデルをOpus 5.5に変更し、料金・既定effort・Claude Codeの既定モデル・フォールバック先を更新した
  • 2026-09-29: Sonnet 5.5の提供開始に合わせて改稿。Sonnetクラスの記載をSonnet 5からSonnet 5.5に差し替え、スペック・提供条件・使い分け・移行時の確認点を更新した(Haiku 5.5は予告のみで未提供)
  • 2026-10-10: Haiku 5.5の提供開始に合わせて改稿。Haikuクラスの記載をHaiku 4.5からHaiku 5.5に差し替え、スペック・料金・Claude Codeでの扱い・Priority Tierの対応を更新した

まとめ

現行4系統の割り当ては次のとおりです。起点はOpus 5.5、速度と単価を優先する日常作業はSonnet 5.5、大量処理はHaiku 5.5、Opus 5.5で届かない推論と長く曖昧な自律タスクはFable 5.1です。Fable 5.1がキャッシュ読み取りでOpus 5を下回ったのは3週間だけで、Opus 5.5が入力・出力・キャッシュ読み取りのすべてでFable 5.1より安くなりました。上位2系統の境界は単価ではなく、Opus 5.5を高effortにしても届くかどうかと、データ保持要件に移っています。単価の階段は大きく見えますが、Batch APIとprompt cachingを重ねれば実コストは額面よりかなり縮みます。

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

この記事を共有:XはてブLinkedIn