世界を動かす技術を、日本語で。

クロードトークンカウンター、モデル比較機能を追加しました

概要

  • Claude Token Counter のアップデート内容
  • Opus 4.7 と他モデルのトークナイザー比較
  • トークン数増加による コスト影響
  • 画像・PDF 入力時のトークン変動
  • 実際の利用例や考察

Claude Token Counter アップデート概要

  • Claude Token Counter にモデル比較機能追加
  • Opus 4.7 が初めてトークナイザーを変更
  • 比較対象: Opus 4.7、Opus 4.6、Sonnet 4.6、Haiku 4.5
  • ClaudeのAPIは全モデルIDに対応
  • 実用上は Opus 4.7Opus 4.6 の比較が中心

Opus 4.7のトークナイザー変更点

  • Anthropic公式発表 :「Opus 4.7は新トークナイザー採用、テキスト処理効率向上」
  • 同一入力でのトークン数: 1.0~1.35倍 に増加(内容による差異)
  • 実測例: Opus 4.7のシステムプロンプト で1.46倍に増加
  • 価格設定は Opus 4.6と同一 :入力100万トークン=$5、出力100万トークン=$25
  • トークン増加により 実質40%程度のコスト増加 予想

画像入力時のトークンカウント

  • Opus 4.7 は高解像度画像に対応:最大2,576px(長辺)、約3.75メガピクセル
  • 旧モデル比で 3倍以上の画像対応力
  • 例:3456×2234ピクセル3.7MB PNGで、 Opus 4.7はOpus 4.6の3.01倍のトークン数
  • この3倍増加は 高解像度対応によるもの
  • 小さい画像(682×318ピクセル)では両モデルで ほぼ同じトークン数 (Opus 4.7: 314、Opus 4.6: 310)

PDF入力時のトークンカウント

  • 15MB・30ページのテキスト中心PDFで検証
  • Opus 4.7:60,934トークン
  • Opus 4.6:56,482トークン
  • 増加率は 1.08倍 と、テキスト単体よりも小さい差分

まとめ・考察

  • Opus 4.7 はトークナイザー刷新で トークン数が増加 しやすく、コストにも影響
  • 高解像度画像長文PDF では特に差が顕著
  • 小規模画像や短文では コスト差は小さい
  • 利用目的や入力内容 に応じたモデル選択が重要

Hackerたちの意見

Anthropicsがトークナイザーを変更した理由って何かあるの?この変更で品質が上がったのか、それとも単なる金儲けなの?

トークナイザーは、全体のモデルのトレーニングとパフォーマンスにおいて重要な部分だよね。リクエストごとの全体コストの一部に過ぎない。もしトークナイザーがより多くのトークンを生成するけど、その結果モデルが正しい答えに早く到達して、正しい答えを出さなかったから再プロンプトが少なくて済むなら、全体のコストはまだ低くなる可能性がある。比較はまだ続いてるけど、Opus 4.7は追加のトークナイザーのオーバーヘッドがあっても、平均して少ないトークンで答えにたどり着くかもしれないっていうのを見たことがある。だから、金儲けってわけじゃないよ。

どうしてそれが金儲けになるの? 新しいトークナイザーが同じ情報をエンコードするのにもっとトークンを必要とするなら、推論にかかるコストが増えるから、彼らにとってはお金がかかるんだよ。トークンごとに料金を取るのは、コストがトークンの数に比例するからなんだ。私の理解ではね。

私の使い方では、これがより良いモデルだね。ベンチマークもあるよ。

もし彼らが望むなら、$/トークンを倍にすることもできるよね。今の需要に追いつけてないみたいだし、そういう状況の時に企業が通常することだよ。お金を稼ぎたいなら、銀行ショットのアプローチは必要ないよ。

Opus 4.7のトークナイザーは、Opus 4.6の1.46倍のトークンを使ってるんだ。面白いね。残念ながらAnthropicは実際のトークナイザーを公開してないけど、私の推測では、モデルのパフォーマンスを上げるために、トークナイザーをより意味的に意識させたのかもしれない。どういうことかというと、例を挙げるね。(これが彼らが実際にやったこととは限らないけど、アイデアを説明するために。)gpt-oss-120bのトークナイザーを例に取ってみよう。いくつかのテキストがどうトークン化されるか見てみるよ(トークンを区切るために「|」を使うね):Kill -> [70074] Killed -> [192794] kill -> [25752] k|illed -> [74, 7905] kill -> [15874] killed -> [17372] 同じ単語(Kill, kill, kill)でも、大文字小文字や前にスペースがあるかどうかで、3つの異なるトークンができちゃうし、過去形だと別のトークンになる。これはテキストをエンコードする理想的な方法とは言えないよね。モデルは、これらのトークンが関連していることを力任せに学ばなきゃいけないから。じゃあ、もしこれをこうエンコードしたらどうなるか想像してみて:|kill |kill|ed kill| kill|ed |kill |kill|ed これだとずっと分かりやすいよね。モデルは「」が何か、「kill」が何か、「」が何か、そして「ed」(過去形の接尾辞)が何かを学べばいいだけで、それを組み合わせることができる。欠点は、トークンの使用量が増えることだけど、これが彼らがやったことなら驚かないな。もしくは、私の推測その2として、トークナイザーを完全に取り除いて、小さなトレーニングモデル(バイト潜在トランスフォーマーみたいな)に置き換えて、単にトークン数を「エミュレート」してるのかも。

彼らの古いトークナイザーは、先頭にスペースがある場合とない場合で同じトークンIDを使えるようにするスペースの圧縮を行っていたよ(文脈によってはスペースがあることが暗示されている場合に、スペースなしの記号が使われる)。

これは言語モデルが誕生して以来のやり方で、2018年頃から徐々に改善されてきたんだ。埋め込みモデルを見てみて。 > 彼らはトークナイザーを完全に取り除いた これは現在進行中の研究テーマで、まだ本当の解決策は見えていないね。

LLMは、似た情報をエンコードする異なるトークンを扱うように明示的に設計されていて、もしかしたら「学習」もするかもしれないね。この3blue1brownの動画、すごく参考になったよ!: https://www.youtube.com/watch?v=wjZofJX0v4M それに、LLMが異なる言語をどう扱うかも考えてみて。

これはすごく表面的で英語中心の見方だけど、まあ本当かもしれないね。非英語の言語では、特にChatGPTが、格変化の部分で苦しんでいるように思う。文脈に合わない形で単語を出力してることが多いし。実験をやってみたんだけど、ある単語を取って、モデル(ChatGPT、Gemini、Claude)にそれを分解させてみたんだ。条件としては、ルート + 接尾辞 + 終わりか、ルート + 終わりのどちらかにするっていうもの。どのモデルもこの二重性に気づかず、一つの解釈しか取らなかった。トークン化に対するアプローチは、文脈フリー(っぽい)文法を前提にしているけど、自然言語ではそうじゃないんだよね。「私は彼女のアヒルを見た」という例(他の有名な例も)も、広い文脈なしではユニークにトークン化できないから、トークナイザー自体がモデルであるか、モデルが意味空間を圧縮する必要があるんだ。

現在、形態素トークナイザーがモデルのパフォーマンスを助けるという証拠はほとんどないね[1]。ドイツ語のように(単語がくっつく)言語では、もう少し証拠があるけど(例えば、私が関わった論文[2])、全体的にはトークン化に関しても苦い教訓が真実だと思い始めてる。[1] https://arxiv.org/pdf/2507.06378 [2] https://pieter.ai/bpe-knockout/

これはほぼ確実に間違ってるね。ケースセンシティブな言語モデルは、ニューラル言語モデルが登場するずっと前からあったんだ。少なくとも10年前にはブーストツリーモデルで使ってたし、私のJavaのNLPツールも20年前にこれをやってた(やばい!)。もちろん、そこに新しさはないよ。PGの「スパムのための計画」に基づいてるから。例えばCountVectorizerを見てみて: https://scikit-learn.org/stable/modules/generated/sklearn.fe... 苦い教訓は、もっとデータを追加してトークナイザーを学習させた方がずっと良いってことだよ。新しいOpusトークナイザーがMythosの事前学習中に学んだ何かに基づいている可能性もあるし(もしかしたらそれが*学習されたMythosトークナイザー?)、Mythosの事前学習は今までで最も多くのデータで訓練されたようだね。トークナイザーに帰納的バイアスを入れるのは、ただの悪いアイデアだと思う。

Hacker Newsで議論の続きを見る