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

20日前原文(simonwillison.net)

概要

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.7 と Opus 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の事前学習は今までで最も多くのデータで訓練されたようだね。トークナイザーに帰納的バイアスを入れるのは、ただの悪いアイデアだと思う。

└

モルフェームトークン化アプローチを調べていたんだけど、もっと過激にセマンティックプリミティブトークナイザーを作ることにしたんだ。[1] つまり、kill、killed、killerはすべて同じセマンティックなつながりとトークンを共有する、例えば[KILL]、[KILL, BEFORE]、[KILL, SOMEONE]みたいな感じ。これはセマンティックプリミティブ（WierzbickaのNSM）と絵文字に基づいていて、最初にこれに興味を持ったのはその楽しいアイデアからなんだ。これまでに6回の反復をテストして、10kの語彙でうまくトレーニングされて応答も良かったけど、文法がちょっと荒くなった。今は8回目の反復に取り組んでいて、主に文法と言語を改善するためにやってる。小さい語彙は維持できなかったみたいで、すべての改善が32kの語彙サイズの範囲に戻ってしまった。今週のさらなるテストがまだ残ってる。[1] https://github.com/frane/primoji

└

可哀想なエド。

これが、私がClaudeのサブスクリプションの利用を再考させる rugpull だよ。「無料で使える」部分が損失リーダーとして資金提供されるのが終わりに近づいてる。Claudeから離れる中で、私の希望は、非常に賢いローカルLLM（qwen 3.6、見てるよ）にシンプルな問題を送り続けて、Claudeはその極端な価格に見合った純粋に極端な問題のために取っておくことだね。

└

他のLLMよりもかなり賢い/優れたLLMは、競合の10倍や100倍のプレミアムを請求できるべきだと思う。タクシーとバスの価格差や、実際の弁護士を雇うのと、バーで友達にビールを渡して無知な意見をもらうのを比べてみて。

└

量子化されたモデルの回答の質は、フルモデルを使うよりも明らかに悪いよ。Alibabaのコーディングプランを通じてQwen 3.6 Plusを使った方がいい。

└

これは私がClaudeのサブスクリプションを再考させるきっかけになっている rugpull だね。モデルは良いからまだ使ってるけど、100ドルのプランで限界がちょっと早くなってるのに気づいてる。20ドルのプランはもっと役に立たないだろうね。これをrugpullとは呼ばないけど、変更には良い技術的理由があるかもしれない。でも、私たちにそのことを伝えてくれない限り、確信は持てないよね。技術的なブログ記事があれば、変更やトークナイザーについてもっと知れそうなのに、"企業秘密"を守りたいからできないんだろうな（そのせいでコミュニティがrugpulledされてると感じるのが残念）。

└

今のところ、/model claude-opus-4-6を実行できるよ。

本当に驚いたのは、1. Anthropicがなぜ変更を行ったのか、どのように変更したのかについて何も発表していないこと 2. 誰も逆アセンブルしていないこと。無料のトークンカウントAPIを使えば簡単にできそうだし（Google Vertex AIのトークンカウントエンドポイントは2000リクエスト/分、つまり約300万リクエスト/日をサポートしているみたいで、逆アセンブルするには十分そう）。

└

簡単にできそうだね何を待ってるの？ ;)

これらの増加は、応答の質や応答を微調整するために必要な反復回数の削減で相殺されているんじゃない？

└

おそらく、時々だけだね。

└

4.7がうまく機能するタスクの範囲だけで、4.6は最適に動かなかった場合ね。もし両方のモデルがリトライなしでタスクを一発でこなせるなら、イテレーションの数はすでに下限に達してるってこと。これはサブタスクレベルにも当てはまるよ。もし両方のモデルが、どのファイルが変更すべき機能を実装しているかを判断するために3つのファイルを読む必要があるなら、「正しいファイルじゃない」っていう結論を出すのは簡単だとしても、トークンのコストは3つのファイル分かかるってこと。これはサブエージェントの最適化の課題にも関連してる。おそらく、外側の高能力モデルはそのコンテキスト内のすべてを使ってより良いパフォーマンスを発揮できるけど、能力の低いサブエージェントを問題に派遣する方が全体的には安くつくかもしれない。AnthropicはOpusとHaikuの間で入力トークンのコストが5:1だけど、Googleは8:1（Gemini Pro : Flash Lite）、OpenAIは12:1（GPT 4.2 : 4.2 nano）だよ。

エージェントが長いアクションチェーンを実行しているとき、トークンカウントはすごく重要だよ。隠れたコストはリトライループで、エージェントのアクションがタイムアウトして再試行する時、全ての前のツールコールの結果を含むフルコンテキストを再送信するんだ。1回の失敗した支払いコールは、成功したものの3倍のトークンを消費することがある。トークンレベルでの可視性は大事だけど、アクションレベルでの可視性も必要だよね — この副作用は実際に実行されたのか、それとも静かに失敗したのか？

これは完全に正当なことだよ。毎日これを非難しているんだ。会社Xはトークン1つあたり10ドル請求するのに対し、会社Yは7ドルだけど、実際には会社Xの方が安いんだ。トークンの消費はトークナイザーに依存していて、企業はBPEのような標準アルゴリズムを使ってトークナイザーを作っている。でも、ハードウェアアクセスに対して料金を請求していて、システムが偏っていることもある。例えば、英語で話すと、スペイン語で書くよりも17%少なく消費するし、中国語の文字で書くと英語話者に比べてトークン消費が大幅に減るんだ。これについてはHNで何度も書いてきたけど、何らかの理由で言及するたびに、投稿がフラグされるんだよね。

└

中国語がLLMにとってもっと「良い」言語なのか、よく考えてるんだ。すべての文字がトークンだから、すぐに終わるし。変なサブワードのナンセンスもないし、無作為な単語の塊に適用される奇妙なセマンティクスもない。おそらく、1:1に非常に近い形でトークン化できることには利点があると思う。

誰か、トークン管理のベストプラクティスについて良いヒントやリソースを持ってる人いる？今、Opus 4.7で一つのプロンプトで制限に引っかかっちゃったんだ。今のところ読んでるのは、 -タスクの複雑さに応じてモデルを選択的に使う -大きなリポジトリをもっと消化しやすくて関連性のあるデータ構造にエンコードして、常に再取り込みしないようにする -Claudeに出力をXトークンに制限するよう頼む（出力トークンは高いからね） -たくさんの入力コンテキストを与えて無駄な試行を減らす -HeadroomとRTKを使う -使ってないMCPを無効にして、CLAUDE.mdからスキルに移すでも、誰か良いヒントやリンク、ツールがあったら教えてほしいな。今、1日に2回もレート制限に引っかかってるから。

└

あなたの単一のプロンプトは何だったの？それはかなりありえないと思うけど。

└

これらのヒントをシェアしてくれてありがとう！RTKとHeadroomをチェックしたけど、Headroomは実際にCLI出力圧縮のためにRTKを使ってるみたいだね。https://github.com/chopratejas/headroom#compared-to

└

grepよりもトークン効率の良いコード検索ツールを作ってるんだ。まだ具体的な数字は出てないけど、長いセッションを取るのにはうまくいってるよ。https://github.com/ebcode/SourceMinder

これは素晴らしいデータだけど、実際に答えなきゃいけない質問の一部に過ぎないんだ。つまり、特定の入力に対して、答えにどれくらいのトークンが使われるのか、そしてその答えの質はどれくらい高いのかってこと。トークナイザーを測ることは、コストと利益のトレードオフの一つの入力に過ぎないよ。

Anthropicは同業他社よりも先行してたけど、リリース間での価値のネガティブな変化について顧客の不満を聞けないなら、彼らの地位は揺らいでいくよ。最終的には何のアドバンテージも残らなくなるだろうね。

ハクソク