この記事は Synthorai ブログの記事あなたの言語で最も安い LLM は？トークナイザーのコストを実測したの転載です。原文（多言語対応）はリンク先をご覧ください。

多言語テキストで一律に最も安い LLM は存在しない。同じ文章で測ると、ヨーロッパ言語・ヒンディー語・韓国語では GPT-5.5 が最も少ないトークンを課金し、中国語では Kimi K2.5、日本語では DeepSeek が最も少ない。Claude Fable 5、Opus 4.8、Sonnet 5 は一つのトークナイザーを共有しており（送ったすべてのサンプルでカウントが一致した）、最も少なくなることは一度もない。同じ英語の段落は Claude では生で 90 トークン課金されるが、DeepSeek では 55 トークンだ。正味のプレミアムは日本語の 1.3 倍から中国語の 2.2 倍まで幅がある。課金単位はトークンなので、価格表ではめったに見えない 2 つの要素が入力コストを決める。ある言語が意味を文字にどれだけ密に詰め込むか、そして各モデルのトークナイザーがそのスクリプトをどれだけうまく圧縮したかだ。この 2 つは掛け算になり、その積は文字あたりの見方から予想されるものとは違ってくる。

TL;DR

Claude Fable 5、Opus 4.8、Sonnet 5 は一つのトークナイザーを共有し、最も少なくなることはない。どこでも最安カウントの 1.2〜2.3 倍。
最安のトークナイザーは言語で入れ替わる。ヨーロッパ言語・ヒンディー語・韓国語では GPT-5.5、中国語では Kimi、日本語では DeepSeek。
文字あたりでは CJK は 3 倍悪く見えるが、意味あたりでは中国語はほぼ同等、日本語と韓国語は 1.5〜2.4 倍になる。
コストはスクリプト密度とトークナイザーのカバレッジの積。カバレッジが欠けると倍増する（GLM はヒンディー語を英語の 4.9 倍で課金する）。
ローカライズでコストが下がることはめったにない。トークンで言語にモデルを合わせよ。

カウントは Synthorai ゲートウェイ経由で 2026-07-08 に測定した。常に各プロバイダー自身のカウントを使い、ローカルのトークナイザーは使っていない。すべてのカウントは繰り返しても同一だった。

課金単位はテキストではなくトークン

課金はトークン単位だが、トークンは文字でも単語でもない。各モデルは独自の語彙を持つ独自のトークナイザーを積んでおり、同じ文でもモデルごとにトークン数が変わる。そのトークン数にトークン単価が掛かるので、変動する要素は 2 つある。テキストが何トークンになるか、そして 1 トークンがいくらかだ。

たいていの価格表は後者の数字しか載せていない。この記事では前者を測る。意味的に対応する 3 つの文章を 7 つのモデル（claude-fable-5、claude-opus-4-8、claude-sonnet-5、deepseek-v4-flash、glm-5.2、gpt-5.5、kimi-k2.5）に送り、各モデルが入力として課金した数を読み取った。

くだけた語り口の文章（土曜の市場の話）は 9 言語で用意した。技術的な説明（指数バックオフによるリトライ）とニュース速報（市の予算採決）は英語・中国語・日本語・韓国語・ドイツ語・ヒンディー語で用意した。Python の関数と JSON のツール呼び出しの塊も加えている。英語以外のバージョンは、忠実に・圧縮しないという指示のもとで機械翻訳し、手で抜き取りチェックした。翻訳の冗長さは実際に交絡要因になるが、後述のレジスターの節でおよそ 20% に収まることを示す。

カウントは常にプロバイダー自身のものを使う。Claude 系は実際の Messages 呼び出しで usage.input_tokens を読む（ゲートウェイは現時点で count_tokens をプロキシしていない）。OpenAI 互換モデルは小さな呼び出しで usage.prompt_tokens を読む。請求と食い違うローカルのトークナイザーこそ、この方法が避けたい失敗だ。1 つだけ制御が必要な点がある。どのリクエストにも数トークン分の固定の枠組み（チャットテンプレート、ロールマーカー）が付くので、2 文字のベースラインサンプルを測って差し引く。この記事のすべての比率はこの枠組みを差し引いた正味であり、枠組みではなくテキストを比較している。

同じテキストを 5 種類の tokenizer で

以下は、物語形式の文章に対する入力 token 数を、言語別・tokenizer 別に生の値で示したものだ。Claude の 3 モデルは全サンプルで同一の値を返したため 1 列にまとめてある（詳細は後述）。残り 2 つの文章も同じ傾向を示すので、後段でまとめて扱う。chars 列はその言語版の文字数だ。文字体系ごとに情報の詰め方が違うため、英語が 254 文字を要する内容を、中国語は 77 文字で表現している。

language	chars	fable-5 / opus-4-8 / sonnet-5	deepseek-v4	glm-5.2	gpt-5.5	kimi-k2.5
en	254	90	55	63	57	60
zh	77	96	50	58	69	50
ja	136	136	101	116	114	129
ko	143	160	104	123	93	129
hi	196	147	124	192	76	133
de	289	146	92	92	75	104
fr	259	111	76	79	66	93
es	253	112	75	79	66	91
it	272	127	84	91	78	100

目立つ事実が 2 つある。Claude が 3 モデルで 1 つの数字なのは、Claude Fable 5、Opus 4.8、Sonnet 5 が全サンプル（各言語、コード、JSON すべて）で同一の値を返したからだ。3 モデルとも Opus 4.7 で導入された tokenizer を積んでいるので、1 つ数えれば全部の値がわかる。そしてその列は、Hindi を除くすべての行で最大だ。Hindi だけは GLM の 192 がさらに悪い。各言語で最も少ないモデルが 1.00 になるよう net 値で正規化した（先に envelope 分を引いているため、これらの比は上の生セルの割り算とは一致しない）。

language	fable-5 / opus-4-8 / sonnet-5	deepseek-v4	glm-5.2	gpt-5.5	kimi-k2.5
en	1.64	1.00	1.00	1.00	1.00
zh	2.20	1.12	1.12	1.55	1.00
ja	1.33	1.00	1.07	1.11	1.24
ko	1.77	1.15	1.28	1.00	1.38
hi	2.01	1.72	2.59	1.00	1.78
de	2.03	1.28	1.16	1.00	1.38
fr	1.75	1.20	1.12	1.00	1.41
es	1.76	1.19	1.12	1.00	1.37
it	1.68	1.11	1.10	1.00	1.27

英語行の 4 モデルの同点は丸めのせいではない。DeepSeek、GLM、GPT-5.5、Kimi はこの文章でぴったり 50 net token に揃う。Claude はこの文章で最も少ない tokenizer の 1.3 倍から 2.2 倍、3 文章全体では 1.2 倍から 2.3 倍を消費する。これは vocabulary の性質であり、モデルの寿命が尽きるまですべての呼び出しに効いてくる。技術文とニュース文も同じ順位を再現する。両者を合計すると、Claude は中国語で 212 net token を課金し（Kimi の 114 に対して 1.9 倍）、Hindi では 477 になる（GPT-5.5 の 210 に対して 2.3 倍）。ただし、その下に唯一の勝者はいない。最も少ない列は言語によって入れ替わる。

GPT-5.5 はドイツ語、フランス語、スペイン語、イタリア語、Hindi、韓国語で最少、英語では最少タイだ（タイと fr/es/it は物語文でのみ成立する）。vocabulary が Latin 系文字に最適化されており、Devanagari と Hangul でも健闘する。
Kimi K2.5 は中国語で最少、CJK 全般で競争力がある。
DeepSeek-v4 は日本語で最少、中国語でも僅差で続く。
GLM 5.2 はほとんどの言語で中位だが、Hindi ではマトリクス中で最悪のセルを出す。物語文で最少の 2.59 倍（GPT-5.5 が 69 net token のところ 179）、フォーマルな文章ではさらに悪く、Claude をも上回る唯一の列だ。

このペナルティは文章に限らない。Python 関数では Claude が最少の 1.61 倍、JSON の tool-call では 1.29 倍を消費する。JSON の差が小さいのは、構造化テキストの大半が句読点と短い ASCII キーで、どの tokenizer もほぼ同じように扱うからだ。大きな tool schema を毎ターン再送する長時間稼働の agent では、このターンごとの税が積み重なる。そこで caching が効いてくる。仕組みは prompt-caching シリーズで扱っている。

文字あたりで測る罠：CJK は見た目ほど課金されない

上の表ではモデル同士を比較した。今度はモデルを固定してみると、言語によってトークン数はやはり変わる。ただし、文字数だけを見たときの印象とは違う動き方をする。トークナイザの数値として最もよく引用されるのは 1 文字あたりのトークン数で、この指標では CJK が突出する。Claude では 100 文字あたりの正味トークン数が中国語で約 114、韓国語で 106、日本語で 94 なのに対し、英語は 32 だ。この列だけを見れば CJK は 3 倍の課金に見えるが、それは見る列を間違えている。課金されるのは意味に対してであって文字数ではない。そして揃えた文章は、どの言語でも同じ意味を運んでいる。ナラティブの文章について、Claude での両方の見方を並べる。

language	chars	net tokens	tokens / 100 chars	tokens vs English
en	254	82	32	1.00
zh	77	88	114	1.07
ko	143	152	106	1.85
ja	136	128	94	1.56
hi	196	139	71	1.70
de	289	138	48	1.68
it	272	119	44	1.45
es	253	104	41	1.27
fr	259	103	40	1.26

右側の 2 列は食い違う。最も極端なのが中国語だ。この集合で 1 文字あたりの密度は最も高いのに、この文章での意味あたりのプレミアムは英語の 1.07 倍にすぎない。英語が 254 文字で表す内容を中国語は 77 文字で運ぶので、1 文字あたりの高いレートが小さな文字数に掛かり、ほぼ相殺される。3 つの文章すべてでこの相殺は成り立つが、魔法ではない。中国語は Claude 自身の英語に対して平均 1.17 倍、モデルによって 0.95 倍から 1.32 倍で、文字あたりの列が示す 3 倍ではなく、ほぼ同等だ。

日本語と韓国語は、当然次に浮かぶ疑問に答える。同じ錯覚だが、相殺は弱い。どちらも 1 文字あたりの密度が高い。ハングルと日本語のかなは、中国語の漢字のように 1 文字へ単語まるごとを詰め込むのではなく、おおむね 1 音節につき 1 文字で音を綴るからだ。だから中国語が 77 文字で言う文章に、韓国語は 143 文字、日本語は 136 文字を要する。文字数が多いところに高い文字あたりレートを掛けると、相殺されずに積み上がる。Claude では 3 つの文章を通して意味あたりで韓国語が英語の平均 1.96 倍、日本語が 1.56 倍になる。文字あたりの列は中国語とよく似て見えるのに、どちらも本当に高くつく。

ドイツ語は中国語の鏡像だ。文字あたりのレートは低い（48、英語に近い）が、ここにある言語で文字数は最も多く（289、複合語のせいだ）、それでも合計は 1.68 倍になる。コストは 2 つの軸の積であり、どちらか一方だけを読むと誤解する。

数字が動く理由：2 つの要素の掛け算

上のどの表の裏にも、次の 1 つの式がある。

ある文章のトークン数 = （意味を表すのに必要な文字数）×（文字あたりのトークン数）

第 1 の要素は、その文字体系の情報密度だ。これは言語の性質であり、モデルの性質ではない。中国語だけが例外というわけではなく、密度は連続的なスペクトルになっている。表語文字である中国語は 1 文字に 1 つの形態素を詰め込むので、最も密度が高い端に位置する。日本語のかなや韓国語のハングルは音を綴るので密度は下がり、より多くの文字が必要になる。デーヴァナーガリーやラテン系のアルファベットはさらに密度が低い。文字あたりの意味量は、中国語から英語へと段階的に下がっていく。

第 2 の要素は、その文字を 1 文字表現するのにモデルの語彙が何トークンを費やすかで、これは完全にモデル固有だ。BPE トークナイザーは学習コーパスから複数文字のマージを学ぶ。よく見た文字はコンパクトなトークンになり、あまり見なかった文字は 1 文字ずつ、あるいはバイト単位のエンコーディングへとフォールバックする。この場合、1 文字が 2〜3 トークンになることもある。同じ 3 言語について、文字あたりの正味トークン数は次のとおり。

文字あたりトークン数	中国語	ヒンディー語	英語
Claude	1.14	0.71	0.32
DeepSeek	0.58	0.61	0.20
GPT-5.5	0.81	0.35	0.20
GLM 5.2	0.58	0.91	0.20
Kimi K2.5	0.52	0.63	0.20

この表は 3 つのことを説明している。まず、中国語が合計値で特別に見えるのは、第 1 の要素で極端だからだ。Claude の中国語圧縮は弱く（文字あたり 1.14 トークン、依然として一部の漢字を 2 分割している）ても、文字数が 77 しかなければ合計は大きくならない。そして中国製モデルは中国語を十分に圧縮できる（0.52〜0.58）ので、自分の英語とほぼ同水準に収まる。次に、ヒンディー語のプレミアムは密度ではなく第 2 の要素によるものだ。GLM はデーヴァナーガリー 1 文字に 0.91 トークンを費やす。語彙に複数文字のデーヴァナーガリーのマージがほとんどないため、ほぼ 1 文字 1 トークンになる。一方 GPT-5.5 は音節クラスタごとカバーして 0.35 で済む。これは同じ文字に対するカバレッジの差だ。最後に、Claude はどこでも高い。英語ですら文字あたりのレートが高く（0.32 に対して DeepSeek は 0.20）、このモデルレベルのベースラインが言語ごとの分に上乗せされる。

これは私たちの 7 モデルに特有の癖ではない。研究文献ではこの現象をトークンプレミアムと呼び、Petrov et al.（NeurIPS 2023）は数百の言語ペアにわたって測定している。根本原因が同じ 2 つ（意味あたりの文字数が言語ごとに異なり、トークナイザーのカバレッジが文字ごとに異なる）で、低リソース言語では最大 15 倍のプレミアムがつくこと、そして帰結も同じ（コストが上がり、レイテンシが上がり、使えるコンテキストウィンドウが減る。プレミアムの高い言語は同じコンテキスト予算をより少ない意味で埋めるからだ）を明らかにしている。この差はベンダーが投資するにつれて縮まる。独立した計測によれば、中国語は GPT-3 世代の語彙では英語比 +182% だったトークン数が、GPT-4o では +24% になっており、私たちが GPT-5.5 で計測した +32% や中国製モデルで計測した同水準に近い。カバレッジは語彙スロットで買うものであり、ベンダーは買い続けている。

ローカライズでコストが下がることはあるのか

罠のセクションを読んで「Claude は言語をまたいでフラットだからローカライズは無視していい」「中国系モデルは中国語が安いからローカライズすれば節約になる」と受け取りたくなる。どちらも間違いだ。以下は 3 つの文章すべてが揃っている 5 言語について、各言語をそのモデル自身の英語と比べて平均した値だ。

vs own English	zh	de	hi	ja	ko
Claude	1.17	2.11	2.40	1.56	1.96
DeepSeek	1.00	1.94	3.11	1.85	1.99
GLM 5.2	1.03	1.77	4.89	2.03	2.31
GPT-5.5	1.32	1.53	1.70	2.09	1.72
Kimi K2.5	0.95	2.20	3.15	2.18	2.41

Claude はフラットではない。韓国語は英語の 1.96 倍、ヒンディー語は 2.40 倍かかる。中国語が 1.17 倍あたりに収まっているのは 1 言語だけの偶然であって、モデルの性質ではない。中国系モデルも中国語でパリティを下回るわけではなく、ようやくパリティに届いている程度だ。表全体で最良のセルは Kimi の 0.95 倍で、自身の英語より 5% 下回るだけ。それ以外のセルはすべて同等かそれ以上のコストになる。ヒンディー語、日本語、韓国語では、これらのモデルは Claude より小さいどころか大きいペナルティを負う。それらの文字体系が学習の中心から遠いからだ。パターンは「ベンダー X が安い」ではない。どのモデルも、自身の英語と比べて最もリーンになるのは学習データに最も近い言語だということだ。

レジスターもこの数値を動かす。カジュアルな物語文が最も条件のいいケースで、技術文とニュース文はほぼすべての倍率を押し上げる。専門用語や借用語こそ、非ラテン系の語彙がマージを持たない部分だからだ。ドイツ語は Claude で 1.68 倍（カジュアル）から 2.29 倍（技術）まで上がり、GLM のヒンディー語はニュース文で英語の 5.98 倍に達する。1 文章だけのベンチマークは、最も条件のいい翻訳になった言語を実際より良く見せる。だからこそ、単一の物語文では Kimi の中国語が 0.80 倍だったが、3 文章では 0.95 倍になった。

そもそも「自身の英語との比較」というレンズが間違っている。支払うのは絶対的なトークン数であり、そこでは 9 言語中 8 言語で Claude が最も高い。唯一 Claude を上回るのは GLM のヒンディー語の列だけだ。「Claude の英語と比べて安い」中国語コンテンツも、物語文では Kimi の 40 トークンに対して Claude では正味 88 トークンかかる。だから取るべき手は、節約のためにローカライズすることではなく、言語にモデルを合わせることだ。中国語は Kimi か DeepSeek、ヒンディー語と韓国語は GPT-5.5、日本語は DeepSeek。Claude はどの言語でもトークンコストで勝つことはないが、品質では依然として勝つ可能性がある。

数量は請求額の半分でしかない

トークンの倍率は、トークン単価と並べて初めて意味を持ち、両者は掛け算で効いてくる。Claude Fable 5 は入力 100 万トークンあたり $10、Opus 4.8 は $5、Sonnet 5 は導入価格が終われば $3 だ。しかも中国語では、これらが共有するトークナイザーが最も効率のいいモデルの 2.2 倍でテキストをカウントする。つまりトークン数の割増が、そのモデルがルーティング先の代替モデルに対してもともと抱えている単価差にさらに乗ってくる。逆のパターンもある。カウントは効率的でも単価が高ければ、1 回の呼び出しコストは高くつく。どちらの数字も、単独では請求額を教えてくれない。他社の単価をここに載せないのは、トークナイザーよりも変わるスピードが速いからだ。上に挙げたカウントは、計算のうち長く通用する側の半分にあたる。

現実的な手は、表示価格を比べるのをやめて、実効入力コストで比べることだ。実際のトラフィック構成を各候補モデルでカウントし、そのモデルの入力単価を掛ける。中国語や韓国語の比重が高いプロダクトでは、この並べ替えでどのモデルが最安かがひっくり返ることがある。しかもその差は誤差レベルではなく、1.5 倍から 2 倍という安定したものだ。キャッシュを使うときに効いてくる数字が、表示単価ではなくヒット率で重み付けした実効コストであるのと同じ理屈で、これはプロバイダー比較で詳しく扱っている。この話をバージョン間で切り取ったもの、同じ英語で Sonnet 5 が Sonnet 4.6 より 41% 多くカウントする理由は、Sonnet 5 のトークナイザーに関する記事にある。

まとめ

トークンコストは、文字の密度とトークナイザーのカバレッジの掛け算だ。最初の要素は言語が、二つ目はモデルが決める。どちらか一方だけを読むと判断を誤る。
Claude Fable 5、Opus 4.8、Sonnet 5 は、どの言語でも最も効率のいいモデルの 1.2 倍から 2.3 倍になる。英語ですら 1 文字あたりの単価が高いからだ。
最も効率のいいモデルは言語ごとに異なる。ヨーロッパ言語、ヒンディー語、韓国語では GPT-5.5、中国語では Kimi、日本語では DeepSeek。GLM はヒンディー語が最も苦手で、ほぼ 1 文字あたり 1 トークンになる。
硬い文体や技術的な文体は、ほぼすべての言語で倍率を押し上げる。実際に本番で使う文体でベンチマークを取ること。
節約のためにローカライズするな。まず絶対トークン数で言語にモデルを合わせ、それから各モデルの単価を掛けて実効コストを比べること。

FAQ

一番安い LLM のトークナイザーはどれか？
言語によって変わる。同じ内容を揃えた文章で 7 モデルを比較したところ、ヨーロッパ系言語、ヒンディー語、韓国語では GPT-5.5 が最も少なく（英語は同点）、中国語では Kimi K2.5、日本語では DeepSeek-v4 が最少だった。Claude 系（Fable 5、Opus 4.8、Sonnet 5）はどの言語・文体でも最少にはならず、最安のトークン数の 1.2〜2.3 倍だった。

Claude Fable 5、Opus 4.8、Sonnet 5 は同じトークナイザーを使っているのか？
使っている。3 つとも、どの言語でも、コードでも、JSON でも、すべてのサンプルで同一のトークン数になった。いずれも Opus 4.7 で導入されたトークナイザーを積んでいるので、1 つで数えれば他にもそのまま当てはまる。Fable 5 の請求額が高いのは、トークン単価が高いというだけの理由だ。

Claude では中国語は英語より高いのか？
少し高い。3 つの文章の平均で、意味あたり 1.17 倍だった（中国で学習されたモデルではほぼ同等）。文字あたりで見ると差はずっと大きく見える（中国語は 100 文字あたり正味 114 トークン、英語は 32 トークン）が、中国語は同じ意味をおよそ 3 分の 1 の文字数で表せるので、合計するとほぼ相殺される。

日本語と韓国語も中国語と同じように振る舞うのか？
半分だけ同じだ。文字あたりの密度が高い点は中国語と共通する。ただしハングルとかなは音を書き綴るので、同じ文章に必要な文字数がずっと多くなる（日本語 136、韓国語 143 に対し、中国語は 77）。文字あたりの単価の高さがもう相殺されなくなるので、意味あたりで見ると Claude では日本語が英語の約 1.6 倍、韓国語が約 2 倍になり、7 モデル全体では 1.5〜2.4 倍になる。

自分のプロンプトでこれを測るには？
実際に運用している文体のプロンプトをいくつか各候補モデルに送り、ローカルのトークナイザーを信用せずに、プロバイダー自身が返す usage フィールドの入力トークン数を読む。都合のいい 1 文だけだとある言語を 2 割ほど過小に見せてしまうので、複数使うこと。あとは各トークン数にそのモデルの入力単価を掛ければ、自分のトラフィックでの実効コストが出る。