価格表を開いて、Haiku 5.5 の入力が 100 万トークンあたり 0.10 ドルと読んだとき、私は桁を一つ読み違えたのだと思いました。4.5 は 1 ドルでしたので、念のため二度見しました。
読み違いではありませんでした。ただ、同じ表の下の段に、もう一つの行があります。入力が 10 万トークンを超えるリクエストは、単価が 5 倍になるのです。安くなったという印象のまま移行を始めると、どこかで逆の驚きに出会う気がして、まず手元で計算してみることにしました。
最初にお伝えしたいのは、境目は 10 万ではなく、4.5 で測っていた数字なら約 7.7 万トークンだということです。理由は、トークナイザが変わるためです。
公式の数字を並べる（2026 年 10 月 13 日に確認）
| 項目 | Haiku 4.5 | Haiku 5.5 |
|---|---|---|
| モデル ID | claude-haiku-4-5 | claude-haiku-5-5（日付付き ID なし） |
| 入力 / 出力（100 万トークンあたり） | 1 ドル / 5 ドル | 0.10 ドル / 0.50 ドル（入力 10 万以下） |
| 10 万超のリクエスト | 単価は変わらない | 0.50 ドル / 2.50 ドル（5 倍） |
| キャッシュ読み取り | 0.10 ドル | 0.01 ドル（10 万超は 0.05 ドル） |
| コンテキスト / 最大出力 | 20 万 / 6.4 万 | 100 万 / 12.8 万 |
| 同じ文章のトークン数 | 基準 | 約 30% 増 |
見落としやすいのは二点です。一つは、10 万の判定にキャッシュの読み取りと書き込みも含まれること。もう一つは、判定がリクエストごとで、キャッシュに当たっていても超えれば高い単価が適用されることです。
境目と請求を、実際に計算してみた
公式の数字をそのまま関数にして、4.5 で使っていたトークン数を入れると 5.5 でいくらになるかを出すスクリプトを書きました。以下の出力は、このスクリプトを実際に動かした結果です。API への送信はしておらず、計算だけです。
"""Haiku 4.5 -> 5.5: 同じ呼び出しの1リクエスト単価を比べる（USD / 100万トークン）"""
INFLATE = 1.30 # 公式: 同じ文章が約30%多いトークンになる
P45 = dict(inp=1.00, out=5.00, cache=0.10)
P55_LO = dict(inp=0.10, out=0.50, cache=0.01) # 入力全体が 100,000 以下
P55_HI = dict(inp=0.50, out=2.50, cache=0.05) # 100,000 超（5倍）
THRESH = 100_000
def cost45(fresh, cached, out):
p = P45
return (fresh*p["inp"] + cached*p["cache"] + out*p["out"]) / 1e6
def cost55(fresh, cached, out):
fresh, cached, out = fresh*INFLATE, cached*INFLATE, out*INFLATE
# 判定は cache 読み書きを含む入力の合計
p = P55_HI if (fresh + cached) > THRESH else P55_LO
return (fresh*p["inp"] + cached*p["cache"] + out*p["out"]) / 1e6, p is P55_HI
if __name__ == "__main__":
print(f"{'4.5換算の入力':>12} {'4.5':>9} {'5.5':>9} {'比':>6} 段")
for n in (10_000, 50_000, 70_000, 76_000, 77_000, 80_000, 120_000):
a = cost45(n, 0, 1000)
b, hi = cost55(n, 0, 1000)
print(f"{n:>12,} {a:9.5f} {b:9.5f} {b/a:6.2f} {'上段' if hi else '下段'}")
print("境目(4.5換算):", f"{THRESH/INFLATE:,.0f}")
# 境目をまたぐ前後で 5.5 自身の単価がどれだけ跳ねるか
lo = cost55(76_900, 0, 1000)[0]; hi = cost55(77_000, 0, 1000)[0]
print(f"76,900 -> 77,000 : {lo:.5f} -> {hi:.5f} ({hi/lo:.2f}倍)")
# 同じ 90,000(4.5換算) をキャッシュ読み 60,000 + 新規 30,000 で送る場合
print("cache込み 90,000:", f"4.5={cost45(30_000,60_000,1000):.5f}", f"5.5={cost55(30_000,60_000,1000)[0]:.5f}")実行結果です。
4.5換算の入力 4.5 5.5 比 段
10,000 0.01500 0.00195 0.13 下段
50,000 0.05500 0.00715 0.13 下段
70,000 0.07500 0.00975 0.13 下段
76,000 0.08100 0.01053 0.13 下段
77,000 0.08200 0.05330 0.65 上段
80,000 0.08500 0.05525 0.65 上段
120,000 0.12500 0.08125 0.65 上段
境目(4.5換算): 76,923
76,900 -> 77,000 : 0.01065 -> 0.05330 (5.01倍)
cache込み 90,000: 4.5=0.04100 5.5=0.02665予想と違ったのは次の二点です。
- 境目をまたいでも、5.5 は 4.5 より安いままでした（比が 0.13 から 0.65 へ）。移行して損をするわけではありません。
- 一方で、5.5 同士で比べると、境目の直前（76,900）と直後（77,000）のあいだで 5.01 倍の差が出ます。プロンプトを数百トークン削るだけで請求が 1/5 になる地点が存在するということです。
「安くなったから気にしなくてよい」と「境目の手前に収める価値がある」は、両方とも本当でした。
移行で 400 になる項目
単価の話を先にしましたが、動かなければ請求も発生しません。公式の移行ガイドでは、4.5 で動いていたコードが次のように変わります。
| 4.5 の書き方 | 5.5 での扱い |
|---|---|
thinking: {"type": "enabled", "budget_tokens": N} | 400。adaptive と output_config.effort へ |
temperature / top_p / top_k | 削除。top_k は何を入れても 400、top_p は 0.99 以外 400 |
| 末尾に assistant メッセージ（prefill） | thinking を切っていても 400。user で終える |
computer_20250124 | 400。computer_toolset_20260801 へ |
| thinking ブロックを返送する際の前方改変 | system・tools・過去のメッセージを変えると 400 |
見つけ方は、Sonnet 5.5 向けに書いたスキャナがほぼそのまま使えます。Haiku 5.5 では top_p の扱いと computer use の項目が増える点だけ、パターンを足してください。
max_tokens にも一点あります。thinking のトークンが max_tokens に含まれるため、4.5 で十分だった上限のままだと、thinking ブロックの直後に stop_reason: "max_tokens" で止まり、本文が空のことがあります。
resp = client.messages.create(
model="claude-haiku-5-5",
max_tokens=4000, # 4.5 で 1000 だった呼び出しも、まず余裕を持たせる
thinking={"type": "adaptive"},
output_config={"effort": "low"}, # 軽い分類・抽出は low から試す
messages=[{"role": "user", "content": text}],
)
# 先頭が thinking ブロックでも壊れない読み方
answer = next((b.text for b in resp.content if b.type == "text"), "")
if resp.stop_reason == "max_tokens" and not answer:
raise RuntimeError("thinking で上限に達しました。max_tokens を増やします")個人開発で小さなスクリプトから API を呼んでいる私自身も、この書き方をまず自分の呼び出しに当てはめるつもりでおります。レスポンスの先頭を決め打ちで読んでいる箇所が、一番先に壊れそうだからです。
直す順番
- 4.5 の呼び出しログから、入力トークンの分布を取ります。7.7 万を超える呼び出しが何割あるかを数えます
- 超える呼び出しは、プロンプトを削れるか（古い履歴・重複した資料）を先に検討します。削れれば 5 倍の差が消えます
- 400 になる項目を直し、
max_tokensに余裕を持たせて動かします - 動いてから、
effortを下げて品質と費用の落としどころを探ります
Priority Tier は Haiku 5.5 では使えません。優先枠を前提にしていた構成だけは、別に容量を見積もる必要があります。
次のアクション
今日は、ご自身の呼び出しログから入力トークンの上位 1% を一つだけ取り出し、7.7 万を超えるかどうかを確かめてみてください。超えていなければ、この記事のほとんどは読み飛ばしていただいて構いません。
価格表の安さは、境目の手前にいる間だけ素直に効く。 この線引きだけは、次のモデルでも先に確かめるようにしております。
Sources: Claude Haiku 5.5 migration guide、What's new in Claude Haiku 5.5、Pricing