Claude Opus 4.7の新トークナイザーでプロンプト料金は上がる？

LLM APIの費用を見るとき、価格表の「100万トークンあたり」だけを見ていませんか。実は、同じ文章でもモデル側のtokenizer（トークナイザー）が変わると、請求計算に使われるトークン数が変わることがあります。

トークナイザーとは、文字列をモデルに渡す前に小さな単位へ分割するルールのことです。多くのLLM APIでは、このトークン数が料金計算の単位の一つになっています。

Claude Opus 4.7は、その影響が見えやすい例です。Anthropicのドキュメントでは、新しいトークナイザーがテキスト処理時に従来モデルと比べて約1x〜1.35xのトークンを使う可能性があり、最大で約35%多くなるものの、増加幅は内容によって変わると説明されています。また、同じ入力でも/v1/messages/count_tokensでClaude Opus 4.7とClaude Opus 4.6を比べると、返ってくるトークン数は異なるとされています。

結論：上がる可能性はある。ただし「全件35%増」ではない

最も正確に言うなら、新トークナイザーによって同じプロンプトのinput tokensが増え、input-token単価が変わらない場合には入力コストが上がる可能性があります。

ただし、Anthropicが示しているのは「約1x〜1.35x」であり、しかも内容によって変わるという説明です。したがって「Claude Opus 4.7にすると、すべてのプロンプトが一律35%高くなる」と読むのは行き過ぎです。

さらに、トークン増加率をそのまま請求額の増加率と考えるのも危険です。Anthropicのpricingでは

Base Input Tokens

Cache Writes

Cache Hits

Output Tokens

なぜ同じ文章なのにトークン数が変わるのか

トークン数は、文字数や単語数と同じではありません。OpenAIのtiktokenガイドは、対象のencodingを使って文字列が何トークンになるかを数える方法を示しています。Geminiのドキュメントでも、Gemini APIへのinputとoutputは、テキストや画像を含めてtokenizeされると説明されています。

そのため、文字数やざっくりした換算率だけで費用を見積もると、精度は限られます。実務上見るべきなのは、対象モデルが実際に返すtoken countです。Claude Opus 4.7とClaude Opus 4.6でcount_tokensの結果が変わるという説明は、トークナイザー変更だけで同じ内容のカウントが変わり得ることを示しています。

「最大35%増」をどう読むべきか

よくある受け止め方	より正確な読み方
Opus 4.7ではプロンプト料金が必ず35%上がる	過度な単純化です。公式の説明は約1x〜1.35xで、内容によって変わります。
同じ入力がより多くのトークンとして数えられることがある	正確です。Anthropicは、Opus 4.7の新トークナイザーでは従来モデルより多いトークンを使う可能性があり、Opus 4.6とはtoken countが異なると説明しています。
トークナイザー変更はcontext limitだけの話で、料金には関係ない	不十分です。API pricingではinput、output、cacheなどのtoken usageが料金項目として扱われます。
文字数から概算すれば十分	粗い予算感には使えても、移行判断には不十分です。公式のtoken counterで実測するのが安全です。

コストはどう見積もるか

input tokensだけを単純化して見るなら、考え方は次の通りです。

追加の入力コスト ≈（新トークナイザーのinput tokens − 旧トークナイザーのinput tokens）× input-token単価

ただし、これは入力部分だけの見積もりです。実際の請求には、output tokens、cache writes、cache hits、その他の料金項目が関わる場合があります。Anthropicのpricingはこれらの項目を分けており、OpenAIとGeminiにもそれぞれ公式pricingがあります。

モデル移行前にやるべき5つの確認

1. user messageだけでなく、実際のpayload全体を使う

本番環境でモデルに送っている内容は、user messageだけとは限りません。system指示、長いcontext、ファイル、画像などが含まれる場合があります。Geminiのドキュメントはinputとoutputがtokenizeされると説明しており、OpenAIのtoken counting guideもテキストと画像を含むinput token countingを示しています。

2. 対象モデルの公式token counterを使う

OpenAIにはresponses.input_tokens.countのドキュメントとtiktokenのガイドがあり、Geminiにはcount_tokensのドキュメントがあります。AnthropicもOpus 4.7の説明で/v1/messages/count_tokensに触れ、Opus 4.7ではOpus 4.6と異なるトークン数が返るとしています。

3. 内容タイプごとにサンプルを取る

短いテストプロンプトを1本だけ測っても、全体の影響は見えません。AnthropicはOpus 4.7のトークン増加幅が内容によって変わると説明しています。高トラフィック、長文context、高コスト、頻出パターンのpayloadを分けて比較するのが現実的です。

4. token deltaを公式pricingに当てはめる

まず新旧モデルのinput token countを比較し、その差分を対象モデルの公式pricingで入力コストに換算します。そのうえで、outputやcacheなどの項目を総コストモデルに戻します。Anthropic、OpenAI、Geminiはいずれも公式pricingを公開しています。

5. 必要ならプロンプトやcache戦略を見直す

差分が小さければ、予算や監視の更新だけで足りるかもしれません。一方、高トラフィックのpayloadで明確に高くなるなら、プロンプトの圧縮、contextの短縮、cache戦略の見直し、1リクエストあたりコストの再計算を検討する価値があります。大切なのは「35%」という見出しだけで判断せず、公式counterと公式pricingで影響を数値化することです。

まとめ

新しいトークナイザーは、同じプロンプトのトークン数を増やす可能性があります。Claude Opus 4.7については、Anthropicがテキスト処理時に従来モデルの約1x〜1.35x、最大約35%多いトークンを使う可能性があると説明しています。ただし、その増加幅は内容によって変わります。

本当に確認すべきなのは、見出しの「35%」ではありません。自社・自分の実際のpayloadでinput tokensがどれだけ増えるのか、outputの挙動は変わるのか、cache関連の料金項目がどう効くのか、そして対象ベンダーのpricingがどう適用されるのかです。

移行前に公式token counterで測り、公式pricingに当てはめる。これが、プロンプトが実際に高くなるかを判断するための最も堅実な方法です。