Claude Opus 4.7のトークナイザ更新で請求額が最大1.45倍に膨らむ独立計測データ
目次
Claude Opus 4.7のAPI価格は4.6と同じで据え置き。
ただしトークナイザが更新されていて、同じ入力テキストが4.6比で最大1.35倍のトークン数になるとAnthropicが注記していた。
このトークン膨張の実測データが出揃ってきた。
Bill Chambersが公開したコミュニティベースのTokenomics Leaderboardと、Claude Code Campの独立計測記事（Hacker News 438pts、コメント444件）の2本で、実務ワークロードの膨張率がおおむね1.2〜1.45倍に収まることが判明している。
Anthropicの注記レンジ上限を超えるケースが普通に観測されていて、Opus 4.7への単純差し替えは実質1〜3割の値上げに相当する。
リリース詳細自体は Claude Opus 4.7のxhighエフォートとセルフベリファイ 側で別途扱っているので、この記事ではトークナイザ変更のコスト影響に絞る。
なぜトークナイザが変わるとコストが上がるのか
APIの請求はトークン単位。
1Mトークンあたり$5（入力）・$25（出力）というレートカードは4.6から据え置かれているが、同じテキストを送っても分割されるトークン数が増えれば請求額はそのぶん増える。
flowchart LR
A[同じプロンプト文字列] --> B[Opus 4.6<br/>トークナイザ]
A --> C[Opus 4.7<br/>新トークナイザ]
B --> D[100トークン]
C --> E[132トークン]
D --> F[課金: 100 × レート]
E --> G[課金: 132 × レート<br/>+32%]「同じ価格で頭が良くなった」と見せかけて、実際には同じ仕事をさせた時の請求額が1〜3割増える。
Anthropic公式ドキュメントはこの事実を注記しているが、「コード・英文は下限寄り、多言語や構造化テキストは上限寄り」と定性的な記述に留まっていた。
Bill ChambersのTokenomics Leaderboard
tokens.billchambers.me/leaderboard は、コミュニティから匿名で収集したリクエストペアを集計するツール。
仕組みはシンプルで、ユーザーが手元のClaude APIリクエストを送信すると、同じ入力をOpus 4.6と4.7のそれぞれのトークナイザで数え直し、膨張率を集計する。
個別入力は匿名化されて合算されるだけで、生のリクエスト本文は保存されない設計。
実データに基づく「コミュニティ平均」が一次ソースとして使えるのがこのリーダーボードの価値で、特定の書き方に偏った合成ベンチマークではない。
Claude Code Campによる実務サンプル19種の独立計測
Claude Code Campの記事は、Anthropicが提供する無料のトークンカウントAPI POST /v1/messages/count_tokens を使い、実際のClaude Code利用ログとシンセティックな基準テキストの両方で膨張率を測っている。
計測に使われたAPIエンドポイントは、モデル推論を走らせずトークナイザだけを通すので、モデル挙動の差分と純粋なトークナイザ差分を切り分けられる。
実Claude Codeワークロード（7種）
| コンテンツ | 膨張率 |
|---|---|
| CLAUDE.mdファイル | 1.445x |
| ユーザープロンプト | 1.373x |
| ブログ本文抜粋 | 1.368x |
| Git log出力 | 1.344x |
| ターミナル出力 | 1.291x |
| スタックトレース | 1.250x |
| コードdiff | 1.212x |
加重平均は1.325x。
Anthropic公式の1.0〜1.35xレンジの上限付近に実務サンプルの中心値が来ているのが重要なポイント。
「代表値が1.2x」ではなく「代表値が1.33x前後」というのが実態。
シンセティック基準（12種）
| コンテンツ | 膨張率 |
|---|---|
| テクニカルドキュメント | 1.47x |
| シェルスクリプト | 1.39x |
| TypeScript | 1.36x |
| スペイン語散文 | 1.35x |
| Pythonコード | 1.29x |
| 英語散文 | 1.20x |
| CJK（中日韓） | ≒1.01x |
構造化テキストや多言語散文が上限近くまで跳ねる一方、CJKはほぼ横ばいという結果。
日本語ユーザーにとっては意外に朗報で、日本語本文を送るだけなら膨張はほぼない。
問題はCLAUDE.mdやプロンプトに英語指示文・コード断片・Markdown構造を大量に含むケースで、Claude Codeの実ワークロードがまさにこれに該当する。
Claude Codeセッション単位のコスト試算
Claude Code Campの試算では、80ターンのClaude Codeセッション（プロンプトキャッシュあり）で次の差が出た。
| 項目 | Opus 4.6 | Opus 4.7 |
|---|---|---|
| セッションコスト | $6.65 | $7.86〜$8.76 |
| 増加率 | 基準 | +18〜32% |
プロンプトキャッシュを使っていても、キャッシュ読み込み分も新トークナイザでカウントされるため、膨張ぶんがキャッシュ割引を貫通して請求に乗る。
「キャッシュ使っていれば影響ないだろう」は誤解。
Max 5x/20xプランではクォータ枯渇が加速する
Claude Code Max 5x/20xプランを使っていると、ドル建ての請求書が届かないぶんトークン膨張の影響が見えにくい。
ただしクォータの内部カウントもトークンベースで動いているため、同じ作業で1.3倍トークンがカウントされれば、クォータの枯渇も1.3倍速くなる。
もともと Max 5xプランが1.5時間でクォータを使い切る という報告が出ており、Anthropicはクォータの絶対値（5時間ウィンドウあたり何トークンまで使えるか）を公開していない。
この不透明な基準値の上に、同じ作業が1.3倍カウントされるトークナイザ更新が乗る構図になっているので、4.7に差し替えた直後から「想定より早く上限に到達する」体感が強まる。
4.6時点のクォータ消化ペースを基準にしているユーザーは、移行後に体感ペースを上方修正しておく必要がある。
指示遵守の向上とのトレードオフ
Claude Code Campの記事は、トークン膨張に見合うモデル側の改善があるかも追検証している。
Google IFEvalベンチマーク（全541プロンプトから20件サンプル）で、strict評価の指示遵守率が85%から90%に上がった一方、loose評価では変化なし。
サンプル数が少ないので方向性のみの参考値だが、厳密な指示の守り方は確かに改善しているという結論。
ただしこれは「コストが増えた分を能力で相殺できるか」という素朴な問いには答えていない。
SWE-bench Verified +6.8pt、MCP-Atlas +14.6ptなどのAnthropic公式ベンチが正しく実務に乗るかどうかは、個別ワークロードで測るしかない。
膨張率1.35倍超の事例と現実的な値上げ幅
公式注記の上限1.35xを超えるケースは確かに観測されている。
Bill ChambersのリーダーボードとClaude Code Campの実測を合わせて読むと、次のような傾向が見える。
| コンテンツ | 膨張率 |
|---|---|
| CLAUDE.md単体 | 1.40〜1.45x |
| シェル・設定ファイルの一部 | 1.40x近辺 |
| コミュニティ平均 | 1.20〜1.35x |
CLAUDE.md単体で1.4倍超が観測されるのは、英文指示とMarkdown構造とコード断片が混在してトークナイザ差分が最大化されるためと考えられる。
1.45x膨張は希少だが、Claude Code系のヘビーユーザーは「同じ設計書を読ませると1.4倍課金される」シナリオを現実的に想定しておいたほうがいい。
月額基準で言うと、Opus 4.6で月$3,000使っていたワークロードは、そのまま4.7に差し替えた場合$3,600〜$4,350の請求になる可能性がある。
移行時に取るべきアクション
ワークロード別に実測してから判断するのが最も堅実。
手順としては次の流れ。
- 既存の4.6リクエストのサンプルを5〜10件確保する
- 各サンプルに対し
POST /v1/messages/count_tokensを両モデルで走らせる - 加重平均で自分のワークロードの膨張率を出す
- 月額請求 × 膨張率 で実質値上げ幅を見積もる
追加で見ておきたいのが、プロンプトキャッシュの再構築コスト。
4.6から4.7に切り替えると、既存のキャッシュプレフィックスは新トークナイザで再トークナイズされるため、キャッシュヒット率が一時的に落ちる。
切り替え直後の1週間は請求額が普段より高めに出るので、ロールアウト計画に組み込んでおく。
他モデルのトークン経済との比較
トークン単位の従量課金はClaude固有の話ではなく、OpenAI Codexのトークン従量課金 などでも同様の構造がある。
Codexは価格改定時に「同じタスクを同じトークン数で処理できる」方向で値下げ寄りに動いたのに対し、Opus 4.7は「価格据え置き＋トークン膨張」で実質値上げに動いた点が対照的。
どちらのモデルプロバイダも「トークンあたりレート」だけ見ても実コストは把握できず、自分のワークロードのトークン分布を計測しないと本当の請求額は予測できない、というのが近年の共通テーマになってきている。
Bill Chambersのリーダーボードの使い方
Tokenomicsリーダーボードは、自分のAPIキーを使って計測データを送信すると、コミュニティ合計に匿名で加算される仕組み。
個別入力そのものは保存されないと明記されているが、念のため機密プロンプトや顧客データを含むリクエストは避けて、合成サンプルや公開データで計測するのが無難。
送信データは集計されて膨張率の中央値・四分位値として可視化される。
自社ワークロードが「コミュニティ平均より悪い側」にあるか「良い側」にあるかを相対評価できるので、値上げ交渉や予算調整の材料として使える。
Opus 4.7の能力向上はリアルなものなので、単純な「値上げだから使うな」とはならない。
ただし予算管理の観点では、差し替えた瞬間に2〜3割請求が跳ねる前提で予算枠を取り直しておくのが安全。