Claudeの新トークナイザーでトークン数が30%増える仕組みと対処

Claude 4.7以降でトークナイザーが切り替わった

Claude 4.7以降のモデルは、それより前のモデルとトークナイザー(テキストをトークン列に分割する仕組み)そのものが違います。同じ入力文をこの新トークナイザーで数えると、旧モデルより約30%多いトークン数になります。増分は入力内容やワークロードの形によって変わり、常に一定の比率になるわけではありません。

対象になるのは、Claude 4.7以降のモデルとClaude Mythos Previewです。旧モデルで測ったトークン数をそのまま新モデルの見積もりに使い回すと、コストの試算もコンテキストウィンドウの残量計算もずれます。Anthropic APIのモデル選択・料金体系全体はAnthropic API完全ガイドで扱っています。

見積もりのずれは、count_tokensエンドポイントを直接呼んでいるアプリケーションだけの問題ではありません。プロンプトの長さを事前にトリミングする処理、会話履歴を圧縮する処理、月間コストの予算アラートを立てる仕組み。トークン数を裏側で参照しているあらゆる処理が影響を受けます。移行作業を「モデルIDを書き換えるだけ」で終わらせると、こうした周辺処理の前提が気づかないうちに崩れます。

同じ文章でトークン数が変わる仕組み

トークナイザーは、入力文をどこで区切ってトークンという単位に分けるかを決める辞書のような仕組みです。区切り方の粒度が細かくなれば、同じ文章でもトークン数は増えます。Anthropicは、新しいトークナイザーが幅広いタスクでの性能向上に寄与すると説明しています。ただし、区切り方の具体的な変更点は公開していません。

count_tokensエンドポイントは、渡したmodelパラメーターに応じたトークナイザーでカウントします。同じ文章を古いモデルIDと新しいモデルIDの両方に投げれば、この差分をそのまま観測できます。呼び出し自体は無料で、実際のメッセージ生成とは別枠のレート制限で動きます。数え直しのために何度呼んでも課金は増えず、通常のメッセージ生成の上限も消費しません。

# 同じ入力を旧モデルと新モデルで数えて差分を見る
curl -s https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6",
       "messages": [{"role":"user","content":"'"$PROMPT"'"}]}' \
  | jq '.input_tokens'
 
curl -s https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-opus-5",
       "messages": [{"role":"user","content":"'"$PROMPT"'"}]}' \
  | jq '.input_tokens'

count_tokensの値は推定で、実際に生成したときの入力トークン数とわずかにずれることがあります。システム最適化のためにAnthropicが自動で足すトークンが含まれる場合もありますが、課金の対象になるのは自分の入力分だけです。cache_controlブロックを付けて呼んでも、この呼び出しではキャッシュの処理は行われません。

新旧トークナイザーの対応関係

線は4.7という世代で引かれています。Opus 4.7で導入されたトークナイザーを、Fable 5系とMythos 5系も共有します。ここで紛らわしいのが、1Mトークンのコンテキストウィンドウという別の軸です。Opus 4.6は1Mコンテキストウィンドウを持つモデルの一覧に含まれますが、トークナイザーはOpus 4.7より前の旧世代のままです。「1Mコンテキストに対応しているか」と「新トークナイザーを使っているか」は別々の境界線で区切られており、どちらか一方だけで判断すると取り違えます。

Sonnet系では、Sonnet 5.5がSonnet 5と同じトークナイザーを使います。Sonnet 4.6・Sonnet 4.5・Haiku 4.5から移ると、同じ文章が約30%多いトークンになります。Sonnet 4.5とHaiku 4.5は旧トークナイザーのままなので、これらのモデルで測った数字は新しい側へ持ち込めません。

Sonnet 4.6以前のモデルは、まとめて旧トークナイザー側です。Opus系も同じ構図です。Opus 4.7で導入されたトークナイザーを、Opus 5.5を含む後のOpusモデルが引き継いでいます。Opus 4.6からOpus 5.5へ上げる場合は、モデルの世代が近く見えても、トークン数の基準が変わる移行になります。

Fable 5.1・Mythos 5.1・Fable 5・Mythos 5の4モデルは、同じプロンプトを投げれば互いに同じトークン数になります。トークナイザーが4モデルで共通だからです。5系の中での新しさではなく、この境界線がトークン数を左右します。Fable 5自体の仕様やコンテキストウィンドウはClaude Fable 5とはにまとめています。

見落としやすいのが、Mythos Previewというプレビュー版のモデルも新トークナイザー側に含まれる点です。ただしこのモデルは2026年6月9日に非推奨になっています。提供終了日は未定です。新しく検証環境を組むなら、同じトークナイザーを使うMythos 5系のモデルで数えるほうが、後から差し替える手間が出ません。

「正式リリースされた最新モデルだけが対象」と思い込んでいると、プレビュー環境で測った結果と本番モデルの見積もりが食い違い、原因の特定に余計な時間がかかります。手元で使っているモデルIDが表のどちら側に属するかは、count_tokensのレスポンスを実際に見る前に、まずモデル一覧で確認しておくと無駄がありません。

移行で何に影響するか

数え直しを怠ると、影響は1か所にとどまりません。関わる範囲を分けて見ます。

レート制限のうち影響が出るのはITPM(1分あたりの入力トークン数)側です。RPM(1分あたりのリクエスト数)は呼び出し回数で決まるので、1回に含めるトークン数が増えても変わりません。

ITPMに数えられるのは、最後のキャッシュブレークポイント以降のinput_tokensとcache_creation_input_tokensです。cache_read_input_tokensは、ほとんどのモデルで数えられません。キャッシュを効かせているワークロードほど、増分がITPMへ及ぶ割合は小さくなります。逆に、毎回異なる長い入力を流すバッチ処理は、増分がそのまま上限へ響きます。

上限の大きさはモデルごとに違います。Start tierの表で並べると、Fable 5.xだけ桁が小さくなっています。

同じ約30%の増分でも、上限が500,000のFable 5.xでは余裕の減り方が目立ちます。

コスト試算とコンテキストウィンドウの残量計算の2つが、実務で最も踏み外しやすい箇所です。コンテキストウィンドウの規模はモデルで大きく違い、増分が効く速さも変わります。

限度が大きいので、少々の増分では上限に届きにくい構成です。ただし、1Mに収まるかどうかの判断は、旧モデルで測った数字ではなく新トークナイザーで数え直した値で行います。1Mコンテキストの対象モデルと運用の目安はClaude 1Mコンテキストの実務活用にまとめています。

移行時に自分のワークロードで実測する

約30%は目安で、増分は入力の性質に依存します。Opus 5.5の移行ガイドは、同じ増分をOpus 4.7より前のモデルと比べて1倍〜1.35倍(内容により最大約35%)という幅で示しています。同じ公式の中の表現の違いで、上振れ側は3割強まで見込むという意味です。Sonnet 5.5の移行ガイドでも、Sonnet 4.6・Sonnet 4.5・Haiku 4.5と比べて同じ文章が約30%多いトークンになるとされています。

コードが多いプロンプトと自然文主体のプロンプトでは増え方が違うので、自分の実データで確かめます。

変わるのは請求単価ではなくトークンの数え方

トークン数が増えると聞くと値上げのように感じますが、変わったのは数え方です。実際の請求額は、増えたトークン数と移行先モデル自身の単価の掛け算で決まります。単価が旧モデルと同じとは限らないため、「トークン数が30%増えた」という事実だけから「請求額も30%増える」とは言えません。

一方で、単価が変わらないモデル間の移行なら、同じ文章の請求額は数え方の分だけ実際に増えます。見出しの「単価ではなく数え方」は、値上げが無いという意味ではなく、増減の原因を切り分けるための言い方です。

壊れるのは、移行前に立てた計画(コスト試算・コンテキストウィンドウの設計・レート制限の余裕度)のほうです。実際にメッセージを送って処理させる分には、トークナイザーの違いでAPIの動作は壊れません。移行のチェックリストには「モデルIDを切り替える」に加えて「切り替え先のモデルで主要なプロンプトを数え直す」を入れておくと、この種のずれを事前に潰せます。

公式ドキュメントは、旧モデルで測ったトークン数をコスト見積もりやコンテキストウィンドウの設計に使い回さないよう明記しています。一手間をかければ、増分そのものは仕様として吸収できます。

まとめ

境界線は4.7という世代です。Opus 4.7以降に加えてSonnet 5系・Fable 5系・Mythos 5系が新トークナイザーで、旧モデルの見積もりを引き継ぐとコストとコンテキストウィンドウの計算が狂います。ITPMの余裕はキャッシュ読み取りの割合とモデルごとの上限で決まるので、移行先のモデルIDで数え直した結果を基準にするのが確実です。