Claude 4.7のトークナイザー費用測定結果

 (claudecodecamp.com)
3 ポイント 投稿者 GN⁺ 13 일 전 | 2件のコメント | WhatsAppで共有
  • Claude 4.7は以前のバージョンより平均1.3〜1.45倍多くのトークンを生成し、同一の価格体系でセッション当たり20〜30%のコスト増が発生
  • 英語およびコードコンテンツでトークン増加が顕著で、**CJK（中国語・日本語・韓国語）**コンテンツはほぼ変化なし
  • より細かくなったトークン化により、命令追従性（Instruction Following）が約5ポイント向上し、特にフォーマットエラーが減少
  • キャッシュプレフィックスと会話履歴のトークン数が増え、キャッシュコストとレートリミット消費速度も上昇
  • 結果としてClaude 4.7は、精度と細かな命令実行の向上を得る代わりに、追加のトークンコストを負担する構造と評価される

Claude 4.7のトークナイザー測定結果

  • AnthropicのClaude Opus 4.7は、前バージョンの4.6より1.0〜1.35倍多くのトークンを使うと明記されているが、実測では1.45〜1.47倍程度であることが確認された
  • 同一の価格とクォータ条件でトークン数が増えることで、最大コンテキストウィンドウの消費速度増加、キャッシュプレフィックス費用の上昇、レートリミットへの早期到達などの影響が発生
  • 実験はコスト測定と命令追従性測定の2つの部分で構成

コスト測定方法

  • **Anthropic APIのPOST /v1/messages/count_tokens**エンドポイントを使い、同一コンテンツを4.6と4.7モデルにそれぞれ入力して、純粋なトークナイザー差分のみを比較
  • 2種類のサンプルセットを使用
    • 実際のClaude Codeユーザーが送信した7つの実使用サンプル
    • 英語、コード、構造化データ、CJK、絵文字、数学記号など12の人工サンプル

  • 実際のClaude Codeコンテンツ結果

    • 7つの実使用サンプルの加重平均比率は1.325倍（8,254 → 10,937トークン）
    • 主な例
    • CLAUDE.mdファイル: 1.445倍
    • ユーザープロンプト: 1.373倍
    • ブログ投稿: 1.368倍
    • コードdiff: 1.212倍

  • コンテンツタイプ別結果（12の人工サンプル）

    • 英語およびコードコンテンツ平均: 1.345倍
    • CJK（中国語・日本語・韓国語）コンテンツ平均: 1.01倍
    • 詳細例
    • 技術文書: 1.47倍
    • Shell script: 1.39倍
    • TypeScriptコード: 1.36倍
    • 英語散文: 1.20倍
    • JSON: 1.13倍
    • 日本語・中国語散文: 1.01倍

トークナイザーの変化パターン

  • CJK、絵文字、記号コンテンツは1.005〜1.07倍程度で、ほぼ変化なし
    • 非ラテン語の語彙は大きく変更されていないように見える
  • 英語およびコードコンテンツは1.20〜1.47倍増加し、コードは散文より影響が大きい
    • コード内の反復文字列（キーワード、import、識別子など）が細分化され、より多くのトークンに分割される
  • 英語の文字当たりトークン比率は4.33→3.60、TypeScriptは3.66→2.69に低下
    • 同一テキストがより小さな単位に分割されて表現される

より多くのトークンを使う理由

  • Anthropicは4.7で**「命令により文字どおり従う傾向」**を強調
  • より小さなトークン単位は**単語レベルの注意（attention）**を強化し、正確な命令実行、文字単位の作業、ツール呼び出し精度の向上に寄与
  • Notion、Warp、Factoryなどのパートナーはツール実行エラーの減少を報告
  • ただし、トークン化以外にも**モデル重みと事後学習（post-training）**が同時に変更されており、原因の切り分けは不可能

命令追従性テスト

  • **IFEvalベンチマーク（2023, Google）**を使用: 「正確にN語で答えよ」「カンマなしで書け」など、541個のプロンプトのうち20サンプルをテスト
  • 結果
    • 厳格モードのプロンプト単位: 4.6 → 85%、4.7 → 90%（+5ポイント）
    • 厳格モードの命令単位: 86% → 90%（+4ポイント）
    • 緩和モードでは差なし
  • 改善は主にフォーマット関連エラーの減少で発生
  • 単一プロンプト（change_case:english_capital）でのみ明確な差を確認
  • 標本数が少なく（+5ポイントは統計的に不確実）、小さいが一貫した改善と評価される

Claude Codeのセッション単位コスト計算

  • 80往復の会話セッションを仮定
    • 静的プレフィックス: 6Kトークン（CLAUDE.md 2K + ツール定義 4K）
    • 会話履歴: ターンごとに2Kずつ増加し、80ターンで160Kに到達
    • 入力/出力: ターン当たり500 / 1,500トークン
    • キャッシュヒット率: 95%

  • 4.6基準のセッションコスト

    • | 項目 | 計算 | コスト |
    • | --- | --- | --- |
    • | 初回キャッシュ書き込み | 8K × $6.25/MTok | $0.05 |
    • | キャッシュ読み取り（79回） | 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倍 → 160K → 212K
    • ユーザー入力: 1.325倍 → 500 → 660
    • 平均キャッシュプレフィックス: 約115Kトークン
    • | 項目 | 計算 | コスト |
    • | --- | --- | --- |
    • | 初回キャッシュ書き込み | 10K × $6.25/MTok | $0.06 |
    • | キャッシュ読み取り（79回） | 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 |
    • セッション当たり20〜30%のコスト増で、トークン単価の変化なしに発生
    • Maxプラン利用者は同じ時間枠内でセッション終了時点がより早くなる

プロンプトキャッシュへの影響

  1. モデルごとにキャッシュが分離されるため、4.7への切り替え時に既存の4.6キャッシュは無効化
    • 最初のセッションはキャッシュ未適用状態で始まり、より大きなプレフィックスコストが発生
  2. キャッシュ量自体が1.3〜1.45倍増加し、読み取り・書き込みの両方が同じ比率で上昇
  3. 同一の会話ログでもトークン数が変わるため、過去比の請求額・モニタリング指標に断絶が発生

反論と解釈

  • 「入力の大半はキャッシュ読み取りなので影響は軽微」

    • キャッシュヒット率が高い場合はコスト影響は小さいが、TTL切れ、キャッシュ無効化、モデル切り替え時には全体比率でコスト増となる

  • 「1.35倍は上限ではなく範囲だ」

    • 実測値は上限付近（1.325倍）に集中し、一部ファイルはこれを超過
    • 実運用では上限基準で計画するのが安全

結論

  • 英語およびコード中心の作業ではトークン使用量が1.3〜1.45倍増加
  • 命令追従性は約+5ポイント改善し、小幅ながら実質的な向上
  • セッション当たりコストは20〜30%上昇、トークン単価は同一
  • 結果として、より高い精度と細かな命令実行のために追加コストを支払う構造と評価される

関連記事

2件のコメント

 
kaydash 12 일 전

Claude 4.7ではなく、Opus 4.7です
 
GN⁺ 13 일 전
Hacker Newsの意見

  • LLMの性能/コスト曲線が対数的な形で存在することを前提にすると、Opus 4.5+がこの曲線上の新しい点なのか、それとも単により高い性能のためにコストが急増する区間に位置しているだけなのかは不明
    Anthropicが価格を急速に引き上げているのは、運用コスト急騰を反映しているサインかもしれない
    モデル評価グラフでx軸をコストの対数で表示する慣行が、こうした現実を隠していると思う

    • Toby OrdのAIエージェントの時間当たりコスト分析を参照した。彼の性能/コストフロンティアという概念はもっと注目されるべきだ
    • もう開発者が作業に合ったモデルサイズと努力水準を適正化(right-sizing)すべき時期だと思う
      とにかく最高モデルを使う時代は終わった。作業に応じて複数の点を選べる選択肢が必要だ
      複雑な作業にはより大きなモデルを使って、一度に5時間分のトークンを使い切っても構わないと思う
      ただ、こうした選択の複雑さを嫌う人も多いだろうし、今後は      スマートルーティング      の試みが増えると予想する
    • AnthropicはIPOを控えており、ユーザー当たり収益拡大の圧力が大きい。結局、実際のモデル運用コストを反映した価格構造へ向かっている
    • モデルがシリコンに直接実装されれば、コストは下がり速度は速くなるだろう。Taalasのような試みは参考になる
    • もし顧客がより高いコストを受け入れる意思があるなら、はるかに強力なモデルも提供できると思う
      たとえばAppleのように超高価なオプションを望む顧客層が存在するように、超高性能LLM市場にも可能性がある

  • 多くの人はAIモデルのコストに注目するが、実際には人間がAIコーディングエージェントを調整しレビューする時間のほうがはるかに高くつく
    $200/月は趣味には高いが、ビジネスの観点ではごく小さい水準だ
    重要なのはモデルが仕事をどれだけうまくこなすかであり、現在の価格帯では時間当たり効率が鍵だ

    • うちのチームは今年Claudeで3つの製品をリリースした。特に9人で6か月を見込んでいたプロジェクトを、2人で2か月で終えた
      Claudeサブスクリプションの経済的価値は1万〜4万ユーロ規模だと思う。
      価格が100倍になっても買うだろう。ただし2万ユーロ/月になれば代替案を検討するが、現時点では生産性向上が圧倒的だ
    • $200は企業にとってはほぼ負担にならないが、個人の趣味としては正当化しにくい
    • 私のOpenclawインスタンスはOpus利用で1日$200請求された。ルーティング最適化のほうが大きな問題だ。$1/時間のときはよかったが、$15/時間では競争力が落ちる

  • モデル品質の向上はいずれ収益逓減の領域に達すると思う
    8K vs 16Kディスプレイのように、ほとんどのユーザーは違いを体感できない
    20〜30%のコスト上昇があるなら、それに見合う可視的な価値向上が必要だ

    • だから研究の大半がコーディング分野に集中しているのだと思う。難易度が上がり続け、経済的価値も維持されるからだ
      一方で一般的な対話型クエリはすでに飽和状態で、モデル間の差別化が難しい
    • 99%正確に見えても、1日10万回の意思決定を行うなら小さな誤差が積み重なって大きな問題になる
    • ローカルで実行可能な4Kモデルが出てきたら、大手研究所は厳しくなるだろう。それでもGoogleは広告収益があるので耐えられそうだ
    • 作業の種類による。たとえば新薬設計では95%完成と100%完成の差が、価値にして数十倍の違いを生む
    • Web検索や要約用途ではすでに限界に達しているが、コーディングの複雑さは無限に拡張できる

  • GitHub Copilotのモデル倍率(multiplier) が3から7.5に増加した
    Microsoftが損失を減らそうとしている試みに見える
    公式ドキュメント参照

    • だから私たちの組織では「Opus 4.7は絶対に有効にするな」と勧告した。4.6(3x)と4.5(3x)は問題ないが、4.7(7.5x)はコストパフォーマンスがまったくない
    • 最近Opus 4.6は推論品質の低下を見せている。結論を急ぎ、論理を省略する。大きなブレークスルーがなければ急激な品質低下(en****) が来そうだ

  • 記事タイトルは誤解を招く。トークン数は増えたが、作業当たりコストは異なるかもしれない
    Opus 4.7がOpus 4.6と同じ推論経路を使わないと仮定している
    Artificial AnalysisのIntelligence Indexの結果を待つべきだ

    • 内部ベンチマークではOpus 4.7は50%安く、性能スコアは80%(vs 60%)だった
    • 記事タイトルを「Claude Opus 4.7 costs 20–30% more per session」から中立的に修正した
    • 28件の作業比較実験の結果では、4.7は旧バージョンの4.6と同程度のコストで、新バージョンの4.6より約20%高い
    • 個人データ基準では、4.7は4.6よりコストが高く、性能向上は不明確だった
    • 公式発表グラフでも、「strictly better」という主張の根拠を確認した

  • 昨日Opusを使ったときは驚くほど良かったのに、今日は単純な作業でも繰り返しミスする
    3回目も同じ問題を指摘しなければならず、セッションが頻繁に切れ、コンパクション(compaction) が過剰に発生する
    結局Sonnetに戻ることにした

    • これはバグではなく計算量削減ポリシーだ。今後さらにひどくなるだろう
    • LLMは人格ではない。確率分布からサンプリングしている以上、悪いセッションが出る確率は100%だ。コンテキストを初期化して再試行すべきだ
    • 私も最近Opus 4.7を使っていて、ひどい結果を頻繁に見ている。モデルが自ら誤りを認めて再試行する様子がやるせなかった

  • 最近よく思うのは、「本当にもっと強力なモデルが必要なのか？」ということだ
    業界は性能競争にばかり没頭し、効率性と持続可能性を見失っている
    今後は0.5B〜1Bパラメータのモデルを特定作業向けに最適化する方向が重要だと思う

    • 私もSonnet 4.6をローカルで回せるなら十分満足だろう
      CPUs Aren’t Deadの記事のように、GoogleのGemma 4 E2Bモデルはスマホでも動き、GPT-3.5-turboを上回る
      Artificial AnalysisのIntelligence Indexによれば、最新の2Bモデルは3〜4年前の175Bモデルと同程度の性能を出す
      Gemma 4 E4BはGPT-4oを上回ることすらある
      この傾向なら、近いうちにノートPCでも最高水準のモデルを動かせるようになるだろう
    • 多くの人がSonnet 4.6にOpus 4.5級の性能を期待していたが、現実はそうではなかった
    • 効率性では金にならない。大手LLM企業にとっては推論コストを高く維持するほうが利益になる
      「新モデルがヤバい」といった宣伝は結局FOMOマーケティングだ
    • 誰もが高級計算機を必要としているわけではない。必要な水準のツールを選ぶことが重要だ
    • しかし「怠惰で不正確なモデル」に満足することはできない。この問題を解決する研究所が決定的優位を握るだろう

  • インド・コルカタの菓子売りたちは原材料価格が上がっても値上げできず、サイズを小さくして対応した
    人々の心理的適応はこのように働く

    • 世界中で似たようなことが起きている。菓子の包装はそのままだが中身は減った。プリングルズの筒でさえ薄く短くなっている
    • こうした現象はShrinkflationと呼ばれる

  • Anthropicは4.7でxhighモードを新たに導入した
    maxモードはトークン使用量が多く、過剰な推論を引き起こす可能性があるため、ほとんどの場合はxhighを推奨する
    公式ドキュメント参照

    • xhigh段階を追加してmaxをさらに遠くへ押しやったのは、まるで「これは11まで上がる」という感じだ

  • 実際のコード基準では、Opus 4.7は約30%のトークン増加を示した
    重要なのは「4.7が4.6よりどんな新しい能力を与えるのか」だ
    まだ判断するには早く、価値があるならコスト増を受け入れられる

    • 議論の中で興味深いのは、多くの人が新モデルを追う一方で、Sonnet 4.6だけでも十分効率的だということだ
      作業範囲を狭めればレビューと管理がしやすくなり、小さなdiffで素早く修正できる
      Copilotのトークン消費が7倍になるなら、むしろワークフローの分断が起きそうだ
    • 最近4.6が性能低下したという不満が多い
    • 4.6がどれだけ長く維持されるのかわからない。企業向けはもう少し続くだろうが、個人サブスクリプション利用者はまもなく選択肢を失いそうだ