Claudeのモデルの選び方 — 開発者ブログが示す4モデルの起点

claude.devの開発者ブログが2026年11月9日、Playbooksとして「Which Claude model should you build with? Fable, Opus, Sonnet, or Haiku」を公開しました。著者はAddy Osmani氏です。現行の一般提供モデルはHaiku 5.5、Sonnet 5.5、Opus 5.5、Fable 5.2の4つで、どれから始めるかを作業別に示しています。4モデルの仕様の一覧はClaudeモデルの一覧と比較、自分のタスクでの測り方はタスク単価で比べる記事にあり、ここでは開発者ブログが示した起点と手順を扱います。

要点

答えは短く、ほとんどの作業はOpus 5.5のmedium(既定のeffort)から始めます。

• Claude Codeの既定モデルがOpus 5.5で、トークン単価はFable 5.2の半分
• 下げる先はSonnet 5.5(仕様が明確な作業)とHaiku 5.5(分類・ルーティング・抽出のような大量処理)
• 上げる先はFable 5.2(最難関の技術案件、Opus 5.5のhighでも足りない場合、長時間の無人実行)
• モデルを動かす前にeffortを動かす。highを超えた1段は、大きいモデルと同じだけ費用が増えることがある
• 複数モデルを混ぜる設計は、自分のタスクで測って、単一モデルのどの点よりも良いときだけ残す

全体像は、モデル選びを「単価の高低」から「終わった1タスクあたりの費用と結果」に置き直すことです。

4モデルの出発点はどう分かれるか

4モデルとも、コンテキストウィンドウは1Mトークン、最大出力は128Kトークンです。差がつくのは単価、速度、thinking(思考)の扱いです。キャッシュ読み取りは100万トークンあたり、Haiku 5.5が$0.01(100K以下)、Sonnet 5.5が$0.10、Opus 5.5とFable 5.2が$0.20です。

作業別の起点は、ブログの表を次のように整理できます。

表のうち、見落としやすい注記が2つあります。

• 仕様が明確でも、Sonnet 5.5で足りるとは限りません。移行や性能最適化は仕様が明確でも難しく、Opus 5.5、大がかりならFable 5.2が候補になります。
• 複雑な財務モデルや、大量の資料から作る文書は、文書作成でもOpus 5.5から始めます。

Fable 5.2のAPI既定effortはhighで、Claude Codeではmediumです。Sonnet 5.5もAPIはhigh、Claude Codeはmediumです。Opus 5.5とHaiku 5.5は両方ともmediumです。自分の環境の値は/effort statusで確かめられます。

Fable 5.2の発表そのものはFable 5.2とMythos 5.2の発表記事にまとめています。Sonnet 5.5を選ぶ側の論点はSonnet 5.5の使い分けが詳しいです。

単価が高くても、1タスクの費用は高いとは限らない

核心は「トークン単価とタスク単価は別物」という点です。裏付けとして3つの実測が挙がっています。

1. Terminal-Bench 3.0で、前世代のFable 5.1をmaxで回すと58.0%、Opus 5.5のhighは58.9%で、トークンは半分でした
2. FrontierCode 2.0では、Fable 5.2のhighが45.3%、Opus 5.5のmaxが45.5%でほぼ並び、1タスクの費用はFable 5.2が約半分でした
3. SWE-bench ProでOpus 5.5のeffortを動かすと、mediumはhighより約2.5ポイント低く費用は約70%、lowは約8ポイント低く費用は約3分の1、xhighは約1.4ポイント高く費用は2.5倍でした

ここから出てくる手順が、Opus 5.5をhighより上に上げる前にFable 5.2を試すことです。日常の作業では、引き続きOpus 5.5のmediumが起点です。

小さいモデルにも限界があります。Haiku 5.5のような小型モデルは、結果を機械的に確かめられる大量処理では強い一方で、長いエージェントのループには向きません。比較するときは典型的なタスクだけでなく、最も重いタスクも値付けします。ある20問の検索ベンチマークでは、2問が支出の43%を占めていました。

タスク単価で測る具体的な手順はClaudeのモデル選びはタスク単価で比べるに、Opus 5.5のeffort別の点差と費用はOpus 5.5のeffortをSWE-bench Proの点差と費用で選ぶにあります。

足りないときは、モデルより先に何を動かすか

Playbookは、結果が足りないときの順序を明示しています。

結果を自動で確かめられるなら、さらに安い手があります。全件をlowで走らせ、失敗した分だけhighで再実行する方法です。同じSWE-bench Proの部分集合では、Opus 5.5のlowで回して失敗分をhighで再実行すると、約97%が通り、1件あたり約$0.17でした。全件をhighで回すと95.3%で$0.29です。

速さだけが欲しいなら、Claude APIのOpus 5.5とFable 5.2にはfast modeがあります。同じモデルのまま出力速度を上げ、料金は割増になります。

世代交代で速度も上がりました。Fable 5.2はFable 5.1より出力が最大30%速く、Sonnet 5.5はSonnet 5より30%速くなっています。

モデルを混ぜるとき、何が起きるか

切り替えは区切りのよい場所で

プロンプトキャッシュは、書き込んだモデルに属します。別のモデルに切り替えた最初のターンでは、会話全体にキャッシュ書き込みの料金がかかります。Claude Codeなら、切り替え前に/compactをかけるか、短い計画メモを持った新しいセッションを始めると、そのターンが小さくなります。APIでは、全履歴の代わりに、これまでの作業の要約でテキストを始めます。

thinkingブロックにも注意が要ります。各ブロックは生成したモデルを記録していて、読めるのは一部のモデルのブロックだけです。

この表は、Claude APIとClaude Models on Google Cloud(Google managed)での関係です。読めないブロックはAPIが落とし、リクエスト自体は成功しますが、新しいモデルは前のモデルの推論なしに作業します。Fable 5.2から一般提供の他のモデルへ移すと、推論は必ず失われます。

サブエージェントは小さいモデルに載せる

サブエージェントは独立したコンテキストで動き、要約を返します。トークンの費用は、そのサブエージェントが動くモデルの単価で決まります。Claude Codeでは、定義ファイルのmodelにhaikuかsonnetを書きます。Playbookの例は次のとおりです。

---
name: log-reader
description: Reads test output and logs, and reports each failing case. Use after a test run.
tools: Read, Grep, Glob, Bash
model: haiku
---
 
Read the logs you're given. For each failure, report the file, the test name and the first error line. Don't edit any files.

.claude/agents/log-reader.mdとして保存します。小さいモデルに任せるのは、ファイル探し、テスト実行、ログ読みのような、間違いが見つけやすい作業です。コードの編集と判断はメインのモデルに残します。小さいモデルが検索結果を読み違えると、メインのモデルが間違ったファイルを開いてトークンを使うためです。

CLAUDE_CODE_SUBAGENT_MODEL環境変数は、モデルを指定していないサブエージェントの既定を決めます。サブエージェントのドキュメントによると、この変数が効く順序はv2.1.251で変わり、現在はフロントマターのmodelのほうが優先されます。

注意が必要な最近の変更が2つあります。

もう一つ、opusplanエイリアスの扱いも書かれています。これはplanモードでOpus、実行でSonnetを使います。つまりコード編集がSonnetに載る構成で、上の「編集はメインのモデルに残す」という助言とは逆向きです。既定にする前に、自分のタスクで測るよう勧めています。サブエージェントを統合するかどうかの判断は、サブエージェントをメインループに畳む判断基準も参考になります。

advisorと大量処理の分担は、効く条件が狭い

advisorツール(ベータ)は、速く安い実行役のモデルと、強い助言役のモデルを組みます。実行役が作業の途中で助言役に相談できる仕組みで、トークンの大半は実行役の単価で課金されます。

Playbookはadvisorの効果を控えめに見ています。プラットフォームのコストガイドが載せる4つの組み合わせのうち、実行役だけの場合を明確に上回ったものはありませんでした。Opus 5.5(high)にFable 5.1を助言役に付けた内部ベンチマークは、90.1%で1回あたり$2.92です。Opus 5.5単独のhighより1.7ポイント高いだけで、費用は約2.1倍でした。この差は実行ごとのばらつきの端にあり、effortを上げて得られる差と同程度です。まず実行役が実際にどれだけ相談しているかを測るよう勧めています。

一方、1つのコンテキストに収まらない大量の作業では、上位モデルが分割して多数の安価な作業役に配り、結果を統合する構成が働きます。約2,200万トークンのソースコードを対象にした内部の欠陥探索で、Opus 5.5が統率しSonnet 5.5が最大25並列で働く構成は、Opus 5.5単独の既定effortより費用が約3分の1少なく、スコアはほぼ同じでした。依存する一連の手順や、1つのコンテキストに収まる作業では、計画と統合の費用のほうが大きくなるため向きません。

移行の前に、モデル名の置き換えだけで済まない点を確かめる

どの現行モデルもツール使用と画像入力に対応していますが、リクエストを別のモデルに移す前に試すべき差があります。

Haiku 5.5のthinkingは、Claude Codeでは切れません(設定ドキュメントの記載)。APIでの扱いと混同しないよう注意が要ります。

Claude Code、Claude Agent SDK、Claude Managed Agents経由でリクエストを組み立てているなら、Fable 5.2の保存された思考に対して何かを変える必要はありません。自前のコードで履歴を編集している場合は、追記のみにして、切り替え前に試します。

セーフティのフォールバックは、Claude Codeでは検出されたリクエストが古いモデルで再実行されることがあり、どのモデルかはトランスクリプトの通知で分かります。Fable 5.2はFable 5.1と同じフォールバック先を引き継いでいて、サイバーセキュリティはOpus 4.8、生物はOpus 5です。

複数のモデルを同じシステムで動かすなら、いちばん厳しいモデルに合わせてリクエストを組みます。履歴は追記のみ、tool_choiceはautoとstrictツール、コンテンツブロックは種類で読み、プロンプトとツールの説明は最も文字どおりに受け取るモデルでも解釈がぶれない精度で書きます。そうすれば、コード変更なしにステップを1段上げ下げできます。ルーティングの規則が単純なら、ステップの種類ごとにモデルを決める処理はコードに持たせ、モデルには選ばせません。

自分の作業で測る手順

公開されたベンチマークは出発点のモデルを決める材料です。確定の前に、候補を自分のタスクで試します。

Claude Codeで手早く確かめるなら、バックログの1件を2つのモデルで走らせ、/usageの表示を比べます。

/effort status
/model opus
/usage
/model fable
/usage

「常に高いモデル」はもう既定ではない

結論は「大きいほど良い」の逆を向いています。起点はFable 5.2ではなくOpus 5.5のmediumで、上げる条件はhighでも足りなかったときに限られます。しかもその前に、自己検証の用意とeffortの調整という安い手が2つ並びます。

これは費用の話であると同時に、運用の話です。モデルの切り替えは、キャッシュの再書き込みとthinkingブロックの喪失を伴います。頻繁に行き来する設計は、単価の差で得られるものを簡単に食いつぶします。切り替えるなら、タスクの区切りで、要約を持って移るのが前提です。

もう一つ、助言役の効果をあえて控えめに書いているのも特徴です。実行役が相談しなければ効かないという指摘は、構成を足す前に実測するという、文書全体の姿勢と一致しています。

まとめ

• Claude Codeを日常的に使うなら、Opus 5.5のmediumを起点にし、足りない場面でhigh、さらにFable 5.2の順で確かめます
• 大量処理やサブエージェントを動かす場面では、Haiku 5.5とSonnet 5.5に載せる作業を「間違いが見つけやすいもの」に絞ります
• APIで複数モデルを切り替える人は、履歴を追記のみにし、tool_choiceをautoにして、いちばん厳しいモデルに合わせた書き方にそろえます
• 構成を足すかどうかは、タスク単価と成績を自分の作業で測ってから決めます。モデルの一覧と比較はClaudeモデルの一覧と比較にあります