2026/04/18 0:29
Claude 4.7 のトークナイザーコストの測定
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Anthropic の公式ガイドは、Claude Opus 4.7 へのアップグレードの実費を過小評価しています。Anthropic は使用量をバージョン 4.6 に対して単に 1.0～1.35 倍と主張していますが、独立したテストでは技術ドキュメントおよび CLAUDE.md ファイルにおける比率は約 1.47 倍であることを示しています。この不一致は、トークナイザーの変更によって英語やコードに対し文字あたりのトークン数が生成される量が増加（英語の chars-per-token が 4.33 から 3.60 に減少）したことに起因し、一方で CJK および絵文字はほとんど影響を受けていないためです。トークン単価自体は変更されていませんが、ユーザーはより高い総セッションコストに直面することになります：動的コンテキストウィンドウの拡大（約 115K トークン vs 4.6 では約 86K）およびモデル切り替え時に以前のキャッシュされたプレフィックスが無効化されることによる影響などから、平均的に 20–30% のコスト増となります。パフォーマンスベンチマークでは厳格な指令に従う能力でのみわずかな改善（+5 パーセントポイント）が確認されており、これは特に英語またはコードを扱っている開発者にとって、セッション費用の大幅な増大に見合った補填にはなりません。
本文
Anthropic の Claude Opus 4.7 への移行ガイドでは、新しいトークナイザーは 4.6 モデルに比べて「約 1.0 倍から 1.35 倍」という範囲のトークン数を必要とする旨が記載されています。しかし、技術ドキュメントを測定したところ 1.47 倍、実際の CLAUDE.md ファイルでは 1.45 倍と算出されました。Anthropic が提示している数値範囲の上端にあることが、Claude Code のコンテンツの多くに当てはまる状況であり、むしろ中間地点ではありません。なお、料金は同じでクォータも変わりません。つまり、プロンプトあたりのトークン数は増えることになります。その結果、「Max」プランのウィンドウ消費速度が早まり、キャッシュプレフィックスあたりのコストも上昇し、レートリミットにもっと早く到達してしまいます。Anthropic は何かを差し引きとして提供しているのでしょうか？そしてそれは投資に見合っているのでしょうか？
私は 2 つの実験を行いました。1 つ目はコストの測定、2 つ目は Anthropic が提示したパフォーマンス向上の検証です。その結果がここにあります。
これにいくらかかるのか？
コストを測定するためには、Anthropic が提供している無料で推論なしのトークンカウンターである
POST /v1/messages/count_tokensコアとなる処理は、以下の 3 行の Python コードです：
from anthropic import Anthropic client = Anthropic() for model in ["claude-opus-4-6", "claude-opus-4-7"]: r = client.messages.count_tokens( model=model, messages=[{"role": "user", "content": sample_text}], ) print(f"{model}: {r.input_tokens} tokens")
現実世界の Claude Code 用コンテンツ 実際に Claude Code ユーザーが送信するファイルから抽出した 7 のサンプル：
| コンテンツ種別 | 文字数 (4.6) | トークン数 (4.6) | 文字数 (4.7) | トークン数 (4.7) | 比率 |
|---|---|---|---|---|---|
| CLAUDE.md（実際のファイル、5KB） | 5,000 | 1,399 | 2,021 | 1,445 | 1.47x |
| ユーザープロンプト（典型的なタスク） | 4,405 | 1,122 | 1,541 | 1,373 | 1.37x |
| ブログ記事の断片（Markdown） | 5,000 | 1,209 | 1,654 | 1,368 | 1.37x |
| Git コミットログ | 2,853 | 910 | 1,223 | 1,344 | 1.44x |
| ターミナル出力（pytest 実行時） | 2,210 | 652 | 842 | 1,291 | 2.00x |
| Python スタックトレース | 5,255 | 1,736 | 2,170 | 1,250 | 1.25x |
| コード差分 (Code diff) | 4,540 | 1,226 | 1,486 | 1,212 | 1.21x |
全体を加重平均した比率：1.325 倍（総トークン数は 8,254 から 10,937 に）。
コンテンツ種別のベンチマーク（12 つの合成サンプル） 定義済みの各種別での比較のため：
| コンテンツ種別 | 文字数 (4.6) | トークン数 (4.6) | 文字数 (4.7) | トークン数 (4.7) | 比率 |
|---|---|---|---|---|---|
| 技術ドキュメント（英語） | 2,541 | 478 | 704 | 1,473 | 1.47x |
| シェルスクリプト | 2,632 | 1,033 | 1,436 | 1,392 | 1.39x |
| TypeScript コード | 4,418 | 1,208 | 1,640 | 1,364 | 1.36x |
| スペイン語のエッセイ風文章 | 2,529 | 733 | 986 | 1,352 | 1.35x |
| コードブロック付きの Markdown | 2,378 | 604 | 812 | 1,339 | 1.34x |
| Python コード | 3,182 | 864 | 1,112 | 1,287 | 1.29x |
| 英語のエッセイ風文章 | 2,202 | 508 | 611 | 1,199 | 1.20x |
| JSON（高密度） | 48,067 | 13,939 | 15,706 | 1,127 | 1.13x |
| ツール定義 (JSON Schema) | 2,521 | 738 | 826 | 1,117 | 1.12x |
| CSV（数値） | 9,546 | 5,044 | 5,414 | 1,067 | 1.07x |
| 日本語のエッセイ風文章 | 993 | 856 | 866 | 1,006 | 1.01x |
| 中国語のエッセイ風文章 | 750 | 779 | 789 | 1,004 | 1.01x |
英語・コード subsets を加重平均：1.345 倍。CJK 文字 subset はどちらも 1.01 倍。
トークナイザーで何が変化するか
データに現れる 3 つのパターン：
- CJK 文字、絵文字、記号を含むコンテンツ：比率は 1.005 倍〜1.07 倍程度。語彙を大規模に変更すればこれらのカテゴリも一様にシフトするはずですが、実際にはそうなるわけではありません。これはラテン文字系以外の語彙部分はラテン文字系よりも変更幅が小さいことを示唆しています。トークン数は、具体的にどの項目が保持されたかを示すものではありません。
- 英語とコード：自然なコンテンツでは 1.20 倍〜1.47 倍の増加が見られます。これは、4.7 が 4.6 よりも共通する英語やコードのパターンに対して、より短いまたは少ないサブワードマージを使用していることを示唆しています。
- コードの方が固有のプロース（散文）よりも影響を強く受ける（1.29–1.39x vs 1.20x）：コードにはキーワードやインポート文、識別子といった反復する高頻出の文字列が多く存在しており、コードベースで訓練されたバイトペア符号化（BPE）がこれらを長めのマージに圧縮しやすい性質があります。
- 英語あたりの文字数減少：4.33 から 3.60 に。
- TypeScript あたりの文字数減少：3.66 から 2.69 に。 これは、同じテキストを表すのに、より小さなピース（トークン）を使用するよう語彙が変化していることを意味します。
これは仮説であり証明されたものではありません。Anthropic の専有語彙の中で具体的にどの項目が変更されたかを示すのは、トークン数をカウントすることではできません。
クラウドコード無償体験入門
- 60 分のビデオレッスン
- CLAUDE.md スターターキット
구독（サブスクリプション）するとご利用いただけます。
なぜより多くのトークンを使うトークナイザーをリリースするのか？
Anthropic の移行ガイドでは、「より具体的な指示への従順さが向上し、特に労力の少ないタスクでも同様です。モデルは単一のアイテムの指示を静かに一般化して他のアイテムに適用することはなくなります」と説明しています。小さいトークンは個々の単語に注力させるため、これはより厳密な指示に従うための文書化済みのメカニズムであり、文字ベースのタスクやツールコールの精度向上にも寄与します。パートナー企業（Notion, Warp, Factory など）の報告では、長時間実行時のツールエラーが減少しました。トークナイザーの変更はその一因である可能性があります。重み設定と後の訓練（post-training）も変更されています。トークン数だけではこれらの要素を区別できません。
4.7 は実際に指示に従うのがより良くなりましたか？
コストは測定済みです。さて、問題は「Anthropic が何を提供したか」です。彼らの提案は「より具体的な指示への従順さ」です。これはあり得ますが、トークン数のデータだけでこれを証明するのは難しいです。そこで直接的なテストを行いました。
IFEval (Zhou et al., Google, 2023) IFEval は検証可能な制約条件を持つプロンプトのベンチマークです。「正確に N 単語で回答」「X という言葉を 2 回含む」「カンマを使わない」「すべて大文字」など。各制約には Python のチェッカーが用意されており、バイナリの通/不通过与（パス・失敗）を判定します。IFEval は 541 つのプロンプトを含んでいますが、私は固定シードで 20 つのサンプルを抽出し、両モデルそれぞれで実行後、IFEval の公開したチェッカーを用いて評価を行いました。
| メトリック | 4.6 | 4.7 | 差分 |
|---|---|---|---|
| 厳密なプロンプトレベル（すべて通過） | 17/20 (85%) | 18/20 (90%) | +5pp |
| 厳密な指示レベル | 25/29 (86%) | 26/29 (90%) | +4pp |
| 緩やかなプロンプトレベル | 18/20 (90%) | 18/20 (90%) | 0 |
| 緩やかな指示レベル | 26/29 (90%) | 26/29 (90%) | 0 |
厳密な指示への従順さにおいて、わずかながら方向性が一貫した向上が見られます。緩やかな評価では変化がありませんでした。両モデルとも上位レベルの指示には従っていますが、厳密モードでのギャップは 4.6 が時に正確なフォーマットを誤って扱い、それが 4.7 では起きない点に由来します。素材的に変化を示したのは
change_case:english_capitalいくつか注意すべき点：
- サンプルサイズ N=20：IFEval は 541 つのプロンプトがあります。20 個のサンプルでは傾向は把握できますが、効果量の大小については確実には言えません。N=20 で +5pp の差分が見られた場合、「実質的な差なし」から「真の +10pp の改善」まで可能性があります。
- これは 4.6 から 4.7 への総効果を測定しています。トークナイザー、重み設定、後の訓練（post-training）がすべて変更されています。どれが +5pp を引き起こしたかを分離することはできません。「小さなトークン」と「より良い指示従順さ」の間の因果関係はまだ仮説です。
- プロンプトごとの生成は 1 回のみでした。プロンプトあたり複数回実行すれば推定量は tighter（狭まり）ます。
結論として：このサブセットにおいて、4.7 は厳密な指示の従順さで 4.6 より数ポイント優れています。効果は小さくサンプルも小さいです。パートナー企業がローンチ声明で使用していた「劇的な改善」という主張とは必ずしも一致せず（少なくともこのベンチマークでは）—but 追加のトークンは確かに測定可能な何かを買い取っています。厳密な指示従順さにおいて +5pp の向上です。小さいですが、実在します。では、これはプロンプトあたり 1.3〜1.45 倍増加したトークンコストに見合っているでしょうか？
セッションごとのコスト概要
1 クラウドコードセッションでのドル計算 バグ修正やリファクタリングのための長いクロードコードセッションを想定します。往復で約 80 のターン（回）を過ごします。
- セットアップ（各ターンのコンテキストに含まれるもの）：
- 静的プレフィックス：2K の CLAUDE.md + 4K のツール定義 = 6K トークン（各ターン共通で不変）
- 会話履歴：約 1 ターンあたり増加し、ターン 80 には約 160K に達します（ユーザーメッセージ 500 トークン + レプリ 1,500 トークン）。
- ユーザー入力：各ターンあたり約 500 の新鮮なトークン。
- 出力：各ターンあたり約 1,500 トークン。
- キャッシュヒット率：約 95%（典型的には 5 分間の TTL 内）。
ここで事前説明が必要な点があります：80 ターンにわたる平均キャッシュプレフィックスは約 86K トークンであり、単純な 6K の静的値ではありません。静的な 6K は微少ですが、各ターンの会話履歴（ターン 1 では 0、ターン 80 では 160K、平均すると約 80K）が支配的です。キャッシュリードのコストの多くは履歴が膨大な後期ターンで発生するため、実際に課金されるのはこの約 86K の平均値です。
4.6 セッションのコスト
| 項目 | 計算式 | 費用 |
|---|---|---|
| ターン 1 のキャッシュ書き込み | 8K × $6.25/MTok | $0.05 |
| ターン 2–80 のキャッシュ読み取り | 79 × 86K × $0.50/MTok | $3.40 |
| 新鮮なユーザー入力 | 79 × 500 × $5/MTok | $0.20 |
| 出力 | 80 × 1,500 × $25/MTok | $3.00 |
| 合計 | 〜$6.65 |
キャッシュリードが入力コストの大部分を占め、出力が全体コストの大部分を占めます。
4.7 セッションのコスト プレフィックス内の各トークンはそのコンテンツ比率によってスケーリングします：
- CLAUDE.md: 1.445 倍 → 2K が 2.9K に。
- ツール定義：1.12 倍 → 4K が 4.5K に。
- 会話履歴（主に英語・コード）: 1.325 倍 → ターン 80 では 160K が 212K に、セッション全体で平均すると約 106K です。
- ユーザー入力：1.325 倍 → 500 が約 660 に。
- 4.7 の平均キャッシュプレフィックス：約 115K トークン（86K から増加）。出力トークンは変動要因です—基本的には 4.6 と同じですが、Claude Code の新しい「xhigh」デフォルト設定が思考トークンをより多く生成する場合、最大で約 30% 増える可能性があります。
| 項目 | 計算式 | 費用 |
|---|---|---|
| ターン 1 のキャッシュ書き込み | 10K × $6.25/MTok | $0.06 |
| ターン 2–80 のキャッシュ読み取り | 79 × 115K × $0.50/MTok | $4.54 |
| 新鮮なユーザー入力 | 79 × 660 × $5/MTok | $0.26 |
| 出力 | 80 × (1,500–1,950) × $25/MTok | $3.00–$3.90 |
| 合計 | 〜$7.86–$8.76 |
差分：～$6.65 から～$7.86–$8.76 へ。セッションあたり約 20–30% の増加です。単価は変わらず、ただしセッションあたりの総コストは上昇しました。同じセッションにトークンが詰め込まれたためです。Max プランのユーザーがレートリミット（ドル数ではなく時間窓）に直面する場合、英語主体の作業において、5 時間のウィンドウも同程度の比率で早期に終了します。4.6 ではフルウィンドウを走らせるセッションも、4.7 ではおそらくそうなりません。
プロンプトキャッシュへの影響
プロンプトキャッシングは Claude Code が動作する基盤です。4.7 のトークナイザー変更は、キャッシングと以下の 3 つの側面から相互作用します：
- 最初の 4.7 セッションはコールドスタート。 Anthropic のプロンプトキャッシュはモデルごとに分離されており、Opus から Sonnet に切り替えるように、4.6 から 4.7 に切り替えるともうすべてのキャッシュプレフィックスが無効化されます。トークナイザー変更自体がこれを直接引き起こすわけではありませんが、新しいキャッシュに書き込むプレフィックスサイズは 4.6 の同等物に対し 1.3–1.45 倍大きくなり、コールドスタートのコストが増加します。
- キャッシュの容量はトークン比率で増加。 CLAUDE.md パートのトークンが 1.445 倍増えるため、キャッシュ書き込み一回あたりのコストも 1.445 倍になり、その後の各ターンのキャッシュ読み取りでも 1.445 倍のコストが発生します。仕組み自体は変わりませんが、支払いの対象となる量が増えただけです。
- 同じトランスクリプト、異なるカウント。 4.6 のセッションを 4.7 で再実行すると、ログ上の数値が異なります。歴史的トークン数をベースに請求または監視を設定している場合、モデル ID を切り替える日は段階的な変化（ステップチェンジ）が発生することを予想してください。
反対意見への反論
「入力は主にキャッシュリードであり、単価はほとんど変わっていない」 正当な指摘です。5 分間の TTL 内を維持するセッションでは、入力コストの 96% はすでに名目価格の 10% 安 ($0.50/MTok) なキャッシュリードで構成されています。キャッシュ部分における 1.325 倍の比率は、新鮮な入力に対するドル価値のインパクトに比べると小さいです。ただし、「Max」プランではすべてのトークンがレートリミットにカウントされ、単価ではなく時間枠に影響します。また、いくつかのパターンはキャッシュヒットしません：TTL 切れ後のセッション初回、キャッシュバーストイベント（CLAUDE.md の編集、ツールリストの変更、モデルの切り替え）、そしてプレフィックスを書き直すコンパクションイベントなど。これらのターンのキャッシュ書き込みでは、フルな比率を支払うことになります。ステディステート（安定状態）は利点ですが、エッジ部分はよりノイズ多くなります。
「Anthropic が 1.0–1.35x を範囲として公式に文書化したことは、硬い上限ではない」 承知しました。しかし、現実世界の加重平均比率（1.325x）は彼らの提示する範囲の上部近くに位置しています。個別のファイル種別がこれを上回ることもあります—CLAUDE.md が 1.445x、技術ドキュメントが 1.473x など。ここで示すべき発見点は、「文書化された範囲の上端が、実際の Claude Code コンテンツに多く当てはまること」です。平均ではなく、上位の範囲を考慮に入れて計画を立ててください。
つまり：英語・コードでは 1.3–1.45 倍のトークン増加。 Anthropic はこれに対し、厳密な指示従順さでの +5pp の向上を提供しました。表示価格は変わりませんでしたが、実効的なセッションあたりのコストは上昇しました。
それは値があるのか？ それはあなたが何を送るかによります。モデルがあなたのプロンプトを文字通りどのように解釈するかにおいて、小さくても実在する改善のための約 20–30% の追加セッションコストを支払っていることになります。