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

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

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

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

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

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

トークナイザーは、入力文をどこで区切ってトークンという単位に分けるかを決める辞書のような仕組みです。区切り方の粒度が細かくなれば、同じ文章でもトークン数は増えます。Claude 4.7で導入されたトークナイザーは、それ以前のモデルより細かい単位で区切るよう設計が変わったと見られ、結果として同じ入力でもトークン数が多く出ます。Anthropicは区切り方の変更理由そのものは公開していないため、狙いが多言語対応の精度向上なのか別の最適化なのかは断定できません。分かっているのは、結果として観測される約30%という増分の大きさと、対象になるモデルの範囲だけです。

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'

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

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

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

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

移行で何に影響するか

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

レート制限のうち、影響を受けるのはITPM(1分あたりの入力トークン数)側だけです。RPM(1分あたりのリクエスト数)は呼び出し回数で決まるため、1回のリクエストに含めるトークン数が増えても直接は変わりません。大量の入力を継続的に送り続けるバッチ処理やストリーミング処理ほど、ITPM側の余裕が新トークナイザーの増分で目減りしやすくなります。

プロンプトキャッシュ側は、同一モデル内でトークン列が完全一致するかどうかでヒットを判定する仕組みです。移行前後でモデルIDそのものを変えれば当然キャッシュは新規に作り直されますが、これはトークナイザーが変わったからではなく、モデルを切り替えたこと自体による挙動です。同じモデルを使い続ける限り、トークナイザーの違いがキャッシュのヒット率を直接下げることはありません。

コスト試算とコンテキストウィンドウの残量計算の2つが、実務で最も踏み外しやすい箇所です。Opus 5・Opus 4.8・Opus 4.7・Sonnet 5・Fable系・Mythos系を含む多くのモデルは1Mトークンのコンテキストウィンドウを持ちます。限度そのものが大きいため、少々の増分では上限に達しにくくなっています。一方、Sonnet 4.5のように200kトークンのコンテキストウィンドウにとどまるモデルでは、同じ増分がより早く上限へ近づきます。1リクエストに含められる画像・PDFページ数の上限も、1Mコンテキストのモデルでは600ページ、200kコンテキストのモデルでは100ページと差があります。大きなドキュメントを扱うほど、この余裕が効いてきます。1Mコンテキストの対象モデルと運用の目安はClaude 1Mコンテキストの実務活用にまとめています。

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

公式が示す約30%という数字は目安であり、増分は入力の性質に依存します。コードが多いプロンプトと自然文主体のプロンプトでは増え方が違うため、正確な影響を知るには自分の実データで確認するのが確実です。

手順は単純です。移行前と移行後、両方のモデルIDで同じリクエストを数え直すだけです。count_tokensに投げてinput_tokensを比較します。見積もりだけでなく、実際にメッセージを作成したときのusageレスポンスでも同様に確認できます。日常的に大量のプロンプトを流すパイプラインなら、移行作業の一環としてこの比較をスクリプト化しておくと、コスト試算のやり直しを毎回手作業でやらずに済みます。

実測するときは、1つのサンプル文だけで判断しないほうが安全です。コードブロックを多く含むプロンプトと、自然文中心のプロンプトでは増分の出方が違うため、実際の運用で流しているプロンプトのうち代表的なパターンをいくつか選び、それぞれで移行前後の差分を取ります。定型的なシステムプロンプト部分と、都度変わるユーザー入力部分を分けて計測すると、どちらが増分に効いているかも見えてきます。同じ計測を一度やって終わりにせず、モデルを再度切り替えるたびに繰り返す運用にしておくと、次のトークナイザー変更でも同じ手順で対応できます。

新トークナイザーは値上げではなく計測基準の変更

トークン数が増えると聞くと値上げのように感じますが、そう単純ではありません。トークン数の増加は測定基準の変化であって、Anthropicが同じ処理により多くの金額を請求する決定をしたわけではないためです。実際の請求額は、増えたトークン数と移行先モデル自身の単価の掛け算で決まります。単価が旧モデルと同じとは限らないため、「トークン数が30%増えた」という事実だけから「請求額も30%増える」とは言えません。

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

公式ドキュメントは、旧モデルで測ったトークン数を新モデルのコスト見積もりやコンテキストウィンドウ設計にそのまま使い回さないよう明記しています。移行時は必ず、これから使うモデルIDを指定して数え直すことが前提になっている書き方です。裏を返せば、この一手間さえ踏めば増分そのものは仕様として吸収でき、慌てて設計を作り直す必要はありません。問題が起きるのは、この一手間を省いて旧モデル時代の見積もりをそのまま信じ続けたときだけです。

まとめ

Claude 4.7以降のモデルとClaude Mythos Previewは、それ以前のモデルと異なるトークナイザーを使い、同じ入力でも約30%多いトークン数になります。境界線は4.7という世代で引かれ、Sonnet 5・Fable 5系・Mythos 5系もOpus 4.7で導入されたトークナイザーを共有します。影響が及ぶのは主にコスト試算とコンテキストウィンドウの残量計算で、レート制限のITPM枠にも運用次第で影響します。増分は入力内容に依存するため、公式の目安値をそのまま使わず、count_tokensで移行前後のモデルを実際に数え直して確認するのが確実です。トークン数の増加自体は値上げではなく計測基準の変更であり、数え直しさえ済ませれば設計をゼロから作り直す必要はありません。