Claude Haiku 5.5とSonnet 5.5の違い — 価格・effort・遅延の選び方

Claude Haiku 5.5とSonnet 5.5は、コンテキストウィンドウも最大出力も同じです。差が出るのは価格、既定のeffort、遅延、そしてAPI上の細かな制約です。入力単価で見ると、Haiku 5.5は100万トークンあたり$0.10から、Sonnet 5.5は$2です。

この記事は、2つのモデルのどちらに処理を割り当てるかを決めるための材料をまとめます。モデル全体の一覧はClaudeモデル一覧、Sonnet 5.5そのものの仕様はClaude Sonnet 5.5の解説にあります。

仕様の比較表

公式のモデル比較表から、2つのモデルで値が分かれる行と揃っている行を並べます。

揃っている行は、Adaptive thinking、100万トークンのコンテキスト、128Kの最大出力、Jun 2026の知識カットオフです。モデルを替えても、これらを理由に設計を変える必要はありません。

遅延は、公式が「現行ラインナップ内での相対評価」と断っています。実際の遅延はプロンプトの長さ、出力の長さ、thinkingのeffortで変わります。自分のワークロードで測った値が最終判断です。

価格差は20倍、ただし条件が3つある

基本単価の比は、入力も出力も20倍です。Haiku 5.5が$0.10と$0.50、Sonnet 5.5が$2と$10です。

仮に1回の処理で入力2,000トークン、出力300トークンを使い、これを100万回回すとします。

• Haiku 5.5: 入力2,000 MTok × $0.10 = $200、出力300 MTok × $0.50 = $150、合計$350
• Sonnet 5.5: 入力2,000 MTok × $2 = $4,000、出力300 MTok × $10 = $3,000、合計$7,000

この試算は、2つのモデルが同じトークン数を使う前提です。出力にはthinkingのトークンも含まれるため、effortの設定次第で実際の差は動きます。

条件1: Haikuは100,000トークン超で単価が上がる

Sonnet 5.5を含む4.6以降の多くのモデルは、100万トークンまで同じ単価です。Haiku 5.5だけは、プロンプトが100,000トークンを超えるリクエストで高い単価になります。

プロンプト長にはキャッシュの読み取りと書き込みも数えます。一部がキャッシュに当たっていても、閾値を超えたリクエストは高い単価です。

長い資料を丸ごと渡す処理では、Haikuでも入力が$0.50になります。それでもSonnetの入力$2の4分の1、出力$2.50はSonnetの$10の4分の1です。差は縮みますが、逆転はしません。

条件2: キャッシュ読み取りの割引率が違う

キャッシュ読み取りは、通常は基本入力の10%です。Opus 5.5とSonnet 5.5は5%、Haiku 5.5は10%の扱いです。

Sonnet 5.5のキャッシュ読み取り$0.10は、Haiku 5.5の通常の入力単価と同じです。共通の長いプレフィックスを何度も読ませるなら、Sonnetでもキャッシュが効く限り入力側のコストは抑えられます。Haikuへの切り替えで削れるのは、主に出力側と、キャッシュに乗らない入力です。

条件3: Batch APIは両方とも半額

Batch APIの割引は両モデル共通で50%です。Haikuは入力$0.05・出力$0.25、Sonnetは入力$1・出力$5になります。Haikuの高プロンプト向け単価も、バッチでは入力$0.25・出力$1.25に下がります。

既定effortの違いが挙動とコストを動かす

Haiku 5.5は、Haikuとして初めてeffortのレベルを持つモデルです。既定はmediumで、Sonnet 5.5のhighより一段低い設定から始まります。

Haiku 5.5向けのプロンプトガイドは、レベルを次のように使い分けています。

• low: チャット、短いツールタスク、単純で大量のリクエスト。最も安く最速
• medium: 既定。エージェント型のコーディングを含む大半の作業の出発点
• high: 知識労働、長めのエージェントタスク、指示への厳密な追従
• xhigh / max: 評価で品質向上が確認できる場合だけ。思考も返答も大幅に長くなるため、Sonnet 5.5でも評価して性能・コスト・速度を比べるよう案内されている

最後の項目は、2モデルの境界を示しています。Haikuのeffortをxhighまで上げて使うくらいなら、Sonnet 5.5で試す価値があるという位置づけです。

effortをhighにしたHaikuと、highのSonnetでは、単価の差がそのまま残ります。「Haikuをhighで回して品質が足りるか」は、モデルを上げる前に試せる手段です。

注意点が2つあります。

• Haiku 5.5でthinkingを無効化するthinking: {"type": "disabled"}は、low・medium・highでのみ有効です。xhighとmaxでは400エラーになります
• リクエストの間でトップレベルのeffortを変えると、その会話のメッセージ部分のプロンプトキャッシュが無効になります。会話の途中で変えるなら、Claude APIとGoogle Cloudではメッセージ単位のeffort変更(ベータ)でキャッシュを保てます

effortを変えたときの精度とコストの関係は、Terminal-Bench 3.0で見るeffortの効き方にも整理があります。

精度の差はどれくらいか

モデル選択の公式ガイドに、GPQA Diamond(198問)の比較があります。Opus 5.5が91%、Sonnet 5.5が91%で並び、Haiku 5.5は85%です。Opus 5.5との差は6ポイントでした。

この結果には注記が付きます。Sonnet 5.5がOpus 5.5に並んだのは、Opus 5.5が生物学の問題で1回の実行あたり6問を拒否し、Sonnet 5.5は1問だったためです。拒否を不正解として数えているので、回答した問題だけで見るとOpus 5.5が約2ポイント上回りました。

1つのベンチマークの数字です。自分の分類タスクや抽出タスクで同じ差が出るとは限りません。差を測るには、実際のログから数十件を抜き、結果を判定する検査を書いて、2つのモデルに流します。公式のコスト最適化ガイドも、タスクあたりのコストをスコアと並べて記録する手順を勧めています。

Haikuに落としやすい処理・落としにくい処理

公式のモデル選択表は、Haiku 5.5を「最低の遅延と価格」が必要な場面に置き、リアルタイムのアプリ、大量の知的処理、コスト重視の運用、サブエージェントのタスクを例に挙げています。Sonnet 5.5は「日常的なコーディング、エージェント、業務ワークロードの速度と能力」で、コード生成、データ分析、コンテンツ作成、視覚理解、エージェント的なツール利用が例です。

この記述を、運用の判断に置き換えると次のようになります。

公式は、効率優先の進め方も示しています。まずHaiku 5.5で実装し、十分に検証して、能力の不足が確認できた場合だけ上のモデルに上げる流れです。逆にSonnet 5.5から始めて、評価が通る処理からHaikuに降ろす進め方でも、結論は同じ評価結果で決まります。

Haikuで会話を作るなら押さえる点

Haiku 5.5には、チャットボットとして使う場合の注意が公式のプロンプトガイドにあります。

• ユーザーが反論したり、例外を求めたりしても、システムプロンプトのルールを守らせたいときは、ガイドが示す一文をシステムプロンプトに足す。厳密な追従が重要ならhighのeffortも併用する
• 返信に推論めいた文が混ざる現象は、thinkingを無効にした場合やlowで起きやすい。出たら、adaptive thinkingとmediumに戻す
• 長いエージェントプロンプトでは、lowだと検索を飛ばす、途中で止まる、検証を省くといった挙動が出やすい

切り替えで外せない制約

Haiku 5.5は、次の点でHaiku 4.5から挙動が変わっています。Sonnet系からHaikuへ処理を移すときも、同じ項目を確認する価値があります。

• アシスタント側のprefill(最後のassistantターンで続きを書かせる方法)は、thinkingを切っていても400エラー
• temperatureとtop_p、top_kは、既定値以外を指定すると400エラー
• Priority Tierは非対応
• 安全分類器による拒否(stop_reason: "refusal")があり、サーバー側のフォールバックはない。同じリクエストを再送しても、多くは再び拒否される
• Amazon Bedrockでは、構造化出力(output_config.formatやstrict: trueのツール)が使えない

Priority Tierを前提に容量を確保している構成や、Bedrockで構造化出力に頼っている構成では、価格の前にここで詰まります。

1つの会話でモデルを混ぜる場合

thinkingブロックの読み取りには、向きがあります。Haiku 5.5は、Sonnet 5.5が出したthinkingブロックを読めません。APIはエラーを返さず、そのブロックを黙って捨てます。逆にClaude APIとGoogle Cloudでは、Sonnet 5.5がHaiku 5.5のブロックを読めます。

つまりSonnet側の推論を引き継いだままHaikuに切り替えても、推論は引き継がれません。会話の途中でモデルを混ぜる設計では、この非対称性を前提にします。

さらに、Haiku 5.5のthinkingブロックは、それを生成したアカウント(またはリンクされたアカウント)でしか有効になりません。別アカウントが送ったブロックは、モデルに届く前に捨てられます。

Claude Codeでの使い分け

Claude Codeのサブエージェント定義にあるmodel: haikuは、Anthropic APIの環境でv2.1.293以降、Haiku 5.5に解決されます。切り替えの詳細はv2.1.293のリリースノートにあります。

役割ごとにモデルを割り当てる設計の考え方は、サブエージェントのモデル配分設計が詳しく扱っています。ここでは、2モデルを分けるときの定義の形だけを示します。

次の例は、ログの分類を担当する読み取り専用のサブエージェントです(形式の例として書いたもので、公式サンプルの出力ではありません)。

---
name: log-triage
description: エラーログを原因カテゴリに分類する。調査や修正はしない
tools: Read, Grep
model: haiku
---
 
渡されたログを読み、原因を次のいずれか1つに分類してください。
timeout / auth / schema / dependency / unknown
根拠となる行番号を1つ添えて、1行で返してください。

分類結果がunknownになった場合だけ、メインのセッションに戻して調べさせる、という段階にしておくと、Haikuの出力を機械的に検査できます。

APIで直接呼ぶ場合は、effortを明示して比較します。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-haiku-5-5",
    "max_tokens": 4000,
    "thinking": {"type": "adaptive"},
    "output_config": {"effort": "low"},
    "messages": [{"role": "user", "content": "..."}]
  }'

同じ入力でmodelをclaude-sonnet-5-5、effortをhighに替えて流し、応答の品質とusageのトークン数を並べると、自分のタスクでの差が見えます。max_tokensにはthinking分も含まれるため、小さすぎる値だとthinkingブロックの後で止まり、本文が空になることがあります。

Haikuに降ろす前の確認項目

• 入力の大半が100,000トークン以下か。超えるなら入力$0.50・出力$2.50で再計算する
• 共通プレフィックスのキャッシュ読み取りが、Sonnet 5.5の5%課金でどれだけ安くなっているか
• prefill、temperature、Priority Tier、Bedrockの構造化出力に依存していないか
• 拒否(refusal)を受けたときの処理が、クライアント側にあるか
• Sonnetで既に回している処理を、mediumのHaikuとhighのSonnetで同じ検査にかけたか

使い分けの全体像と、Opus 5.5を含めた線引きは、開発者ブログが示すSonnet 5.5とOpus 5.5の使い分けにあります。Haikuを入れる場合も、まず検査を作り、通った処理だけを降ろす順序が安全です。降ろしたあとの早期停止や検証漏れは、Haiku 5.5のプロンプトガイドの文面で調整できます。