この記事は次の言語でもお読みいただけます:繁體中文 · English · 한국어 · Bahasa Indonesia · Bahasa Melayu · ไทย · Português (Brasil) · Español · Türkçe · Tiếng Việt
先に結論を書きます。トークンには業界共通の定義がありません。トークンは、モデルごとに学習の段階で固定される「切り分け表」で決まります。同じ文章を別のモデルに入れれば切り出される数は変わり、同じ会社のモデルでも世代が違えば変わります。つまり「1トークンは何文字か」という問いには経験則しかなく、固定された指標はありません。
業界で本当に統一されているのは、トークンそのものではなく料金の構造です。100万トークンあたりいくら、入力と出力は別料金、という部分です。この違いは、コストの試算表を作る段階になると致命的に効いてきます。
トークンとは何か:目的は圧縮で、意味の理解ではない
トークンは、モデルが文章を切り分けた最小の処理単位です。切り分け方はBPE(Byte Pair Encoding)と呼ばれる系統のアルゴリズムから来ていて、手順は3つです。
- 膨大なテキストを集計し、いっしょに出てくることが多い文字の組み合わせを繰り返し結合していきます。
- 結合した結果を1冊の語彙表にまとめます。規模はふつう5万〜20万項目です。
- それ以降の入力は、すべてこの表と照らし合わせて切り分けます。
ポイントは、このアルゴリズムの目的が圧縮であって、意味の理解ではないことです。よく出てくる文字列、たとえば英語のtheやand、中国語の「的」「因為」、プログラムのfunctionなどは、まとめて1トークンになります。逆にめったに出てこない語は細かく砕かれ、人名や固有名詞、誤字は3〜5トークンに分かれることがよくあります。
つまりトークンは「文字」でも「単語」でもなく、「そのモデルが知っている最小の部品」です。これが、この後に出てくるコストの話すべての前提になります。
なぜ統一規格はありえないのか
老喬も最初は不思議に思いました。2026年にもなって、これほど基本的な料金単位に規格がないのはなぜなのか。
答えは、語彙表がモデルの重みの一部で、学習が終わったら変えられないからです。語彙表は本質的にモデルの部品のひとつで、外部の仕様書ではありません。標準化しようにも、技術的に手をかける場所がないのです。2社に同じ語彙表を使えと求めるのは、同じモデルを使えと求めるのと変わりません。
ここから、さらにつまずきやすい状況が生まれます。同じ会社でも、世代が変わるとトークナイザーが変わることがあります。ClaudeはOpus 4.7の世代でトークナイザーを変えていて、同じ文章でも前の世代とはトークン数が違います。去年作ったコストモデルは、世代交代の時点で合わなくなっています。しかもエラーは出ず、見積もりが黙ってずれていくだけです。
経験則:見積もりには使えるが、価格提示には使えない
| 内容の種類 | おおよその換算 | 補足 |
|---|---|---|
| 英語 | 1トークン=約4文字、約0.75語 | 業界でもっともよく引用される目安 |
| 中国語 | 漢字1字=約0.6〜1.5トークン | 幅が広い。理由は次の節 |
| プログラムとJSON | 明らかに多め | インデント、波かっこ、引用符にもすべてお金がかかる |
| 画像 | サイズに応じて換算 | 1枚で1,000〜2,000トークンがよくある |
この表の使い道はひとつだけで、「この仕事はやる価値があるか」を判断するためのものです。ざっくりつかんで、取りかかるかどうかを決めるならこれで十分です。ただし、見積もり、予算、顧客への約束に関わるなら、この表は使えません。中国語とプログラムでは誤差が2倍に達することがあるからです。
中国語はなぜ不利で、しかもどれだけ不利かが一定しないのか
UTF-8では、漢字1字が3バイトです。そのモデルの語彙表に使っている語が収録されていれば、2〜3文字が1トークンにまとまることもあります。収録されていなければ、ほぼバイト単位の切り分けに戻ってしまい、1字で2〜3トークンを消費します。
つまり中国語のトークン効率は、そのモデルが学習した中国語データがどれだけ厚いかで決まります。これはあまりはっきり語られないコストの差です。同じ中国語の文章でも、会社の違うモデルではコストが2倍以上違うことがあり、それは単価表を見てもまったくわかりません。
日本語も、漢字やかなはUTF-8で1文字3バイトなので、同じ仕組みが働きます。ただし本記事は日本語の換算値を扱っていないため、日本語の文章で正確な数を知りたいときは、使うモデルで実際に数えてください。
老喬が「単価の比較」という比べ方をあまり信用しないのは、このためです。単価が安くても安いとは限りません。中国語のトークン効率が3割悪いモデルは、単価が2割安くても、実際には高くつきます。
料金の構造:ここが業界で共通の部分
| 項目 | 業界の慣行 |
|---|---|
| 料金の単位 | すべて100万トークンあたり何ドル |
| 入力と出力 | 別々に課金され、出力はふつう4〜5倍高い |
| キャッシュ(prompt caching) | 繰り返し使う冒頭部分をキャッシュに書き込むと、読み出しは通常の入力の約10分の1で済むことが多い |
| バッチ処理 | 即時の応答が要らないまとめ処理は、ふつう半額 |
| 思考トークン | 出力として数えられ、中身が見えなくても課金される |
2026年年中のAnthropic公式APIを例にとると、Claude Opus 5はおよそ入力5ドル、出力25ドル、Sonnet 5は2ドルと10ドル、Haiku 4.5は1ドルと5ドルです(いずれも100万トークンあたり)。価格は変わります。ここで数字を挙げたのは見積もりに使ってもらうためではなく、構造を見てもらうためです。出力はいつも入力の4〜5倍です。
この構造は、設計の判断を直接変えます。長いレポートを出力する機能と、分類だけして3文字しか出力しない機能では、入力の量が同じでもコストが一桁違うことがあります。コストを下げたいなら、まず見るべきは出力の列です。
もっとも過小評価されやすいこと:コストは直線的に増えない
老喬が、いちばん独立して取り上げる価値があると考えている点です。
モデル自体には記憶がありません。会話の1往復ごとに、それまでの履歴を全部送り直して、ようやく直前まで何を話していたかがわかります。20回目の往復であなたが「はい」と一言送っても、実際の課金は、それまでの19往復の全文をもう一度入力として数えたものになります。
数学的に言えば、長い会話のコストは直線ではなく、二乗に近い形で増えていきます。実務上は、ここから3つのことが言えます。
- 長い会話のコストは後半に集中し、均等には分布しません。3往復目では安く感じても、30往復目の1往復あたりのコストはその10倍になっていることがあります。
- システムプロンプトは、毎回の往復で繰り返し課金される固定費です。最初に一度払えば終わり、ではありません。詳しく書き込んだキャラクター設定は、一言話すたびにその分を払っていることになります。
- キャッシュの仕組みは、まさにこのために存在します。変わらない冒頭部分を固定しておけば、繰り返しの部分は約10分の1の価格で読み戻せます。長い会話には、今のところこれがもっとも効く手です。
正確な数字を知る方法はひとつだけ
そのモデル自身のトークナイザーで実際に数えることです。
Anthropicにはcount_tokensというエンドポイントがあり、呼び出すときには実際に使うモデル名を指定する必要があります。モデルによって数字が違うからです。OpenAI側でこれに当たるのは、tiktokenというライブラリです。
ここに、よくある誤差の原因があります。tiktokenでClaudeの使用量を見積もると、約15〜20%少なく出ます。中国語とプログラムではずれがさらに大きくなります。2社の切り分け表は別物なので、もともと代わりに使うべきではありません。老喬は、こうして作られたコスト試算表を一つならず見てきました。結果として実際の請求額は見積もりより2割高くなり、しかも原因が見つかりませんでした。
4つの場面と、それぞれの計算方法
| 場面 | 使うべき方法 |
|---|---|
| ざっくりつかんで、やるかどうか決める | 経験則。英語は文字数÷4、中国語は文字数×1 |
| 見積もりを出す、予算に組み込む | 本番で使うモデル名でcount_tokensを実行して実測する |
| すでに稼働していて、コストを管理したい | 毎回返ってくる使用量の項目を見る。特にキャッシュのヒット率 |
| 複数の会社の価格を比べる | 同じサンプルをそれぞれの会社のトークナイザーで実測する。単価だけで比べない |
この4つの違いは精度ではなく、その数字を使って何を決めるかにあります。「やるかどうか」を決めるときに2割外れても問題ありません。「顧客からいくらもらうか」を決めるときに2割外れたら、その2割はあなたの利益から出ていきます。
最後に冒頭の問いに戻ります。トークンとは何か。それはそのモデルが知っている最小の部品で、モデルごとに知っているものが違います。これを受け入れてはじめて、コストモデルは正しい土台の上に立ちます。
よくある質問
1トークンは何文字ですか?
決まった答えはありません。英語はおよそ1トークンが4文字、約0.75語です。中国語はおよそ漢字1字が0.6〜1.5トークンです。中国語の幅がこれほど広いのは、UTF-8で漢字1字が3バイトあり、その語がモデルの語彙表に収録されているかどうかで結果が2倍以上変わるからです。これらの数字はやるかどうかの見積もりにしか使えず、価格の提示には使えません。
トークンにはなぜ業界の統一規格がないのですか?
語彙表がモデルの重みの一部で、学習が終わったら変えられないからです。語彙表は本質的にモデルの部品で、外部の仕様書ではないので、標準化しようにも技術的に手をかける場所がありません。2社に同じ語彙表を使えと求めるのは、同じモデルを使えと求めるのと同じです。同じ会社でも世代交代でトークナイザーが変わることがあり、去年作ったコストモデルが今年はもう合わないこともあります。しかもエラーは出ません。
tiktokenでClaudeの使用量を見積もってもいいですか?
おすすめしません。tiktokenはOpenAIのトークナイザーなので、Claudeの見積もりに使うと約15〜20%少なく出ます。中国語とプログラムではずれがさらに大きくなります。正確な数字を出す方法はひとつで、そのモデル自身のトークナイザーで実測することです。Anthropicではcount_tokensエンドポイントを使い、呼び出すときに実際に使うモデル名を指定します。
長い会話ほどコストが高くなるのはなぜですか?
モデル自体に記憶がなく、毎回それまでの履歴を全部送り直すからです。20回目の往復で送った「はい」の一言も、実際にはそれまでの19往復の全文を入力としてもう一度数えています。そのためコストは直線ではなく、二乗に近い形で増えます。ここから、システムプロンプトは毎回繰り返し課金される固定費だということもわかります。prompt cachingは、この部分を抑えるために存在しています。
単価が安いモデルなら、必ず節約になりますか?
そうとは限りません。中国語のトークン効率は、そのモデルが学習した中国語データの厚さで決まり、同じ中国語の文章でも会社の違うモデルではトークン数が2倍以上違うことがあります。これは単価表には一切表れません。中国語のトークン効率が3割悪いモデルは、単価が2割安くても実際には高くつきます。比べるなら、同じサンプルをそれぞれのトークナイザーで実測する必要があります。
本記事のキーワード:トークン 文字数、トークンとは、トークン 何文字、トークナイザー、BPE、AI 料金 トークン、API 料金、prompt caching、count_tokens、tiktoken
出典: 中国語版の初公開日は2026年9月15日、最終更新日は2026年9月15日です。料金は2026年年中時点のAnthropic公式APIの参考価格で、今後変わる可能性があります。文字数の換算の目安は英語と中国語についてのもので、日本語の換算値は扱っていません。
この日本語版は、繁体字中国語の原作記事をもとにしています。joelin.cc. 海外の読者にもわかりやすいよう、表現や説明を調整しています。 内容の基準となるのは繁体字中国語の原文です。完全な内容は中国語の原文をご覧ください。
