言語別に最も安い LLM は？Tokenizer コストを実測

多言語テキストで常に最安となる LLM はない。同じ文章で計測すると、欧州言語、ヒンディー語、韓国語では GPT-5.5、中国語では Kimi K2.5、日本語では DeepSeek の課金 token 数が最も少なかった。Claude Fable 5、Opus 4.8、Sonnet 5 は同じ tokenizer を共有しており、送信した全サンプルで token 数が一致した。どの言語でも最少にはならない。同じ英語の段落が Claude では 90 token、DeepSeek では 55 token として課金される。固定部分を除いた差は、日本語で 1.3 倍、中国語で 2.2 倍に達する。課金単位は token だ。入力コストは、各言語が文字にどれだけ意味を詰め込めるかと、各モデルの tokenizer がその文字体系をどれだけ効率よく圧縮できるかで決まる。この 2 つは掛け合わされるため、文字単位で見た印象とは異なる結果になる。

TL;DR

• Claude Fable 5、Opus 4.8、Sonnet 5 は同じ tokenizer を共有している。どの言語でも最少にはならず、最安モデルの 1.2〜2.3 倍になる。
• 最も効率のよい tokenizer は言語によって変わる。欧州言語、ヒンディー語、韓国語では GPT-5.5、中国語では Kimi、日本語では DeepSeek が最少。
• 文字単位では CJK が 3 倍不利に見えるが、意味単位では中国語は英語とほぼ同等で、日本語と韓国語は 1.5〜2.4 倍になる。
• コストは、文字体系の情報密度と tokenizer のカバー範囲の積で決まる。カバー範囲が狭いと差が増幅する。GLM のヒンディー語は、同モデルの英語の 4.9 倍。
• ローカライズしても、通常はコストを削減できない。token 数を基準に、言語ごとにモデルを選ぶべきだ。

計測は 2026-07-08 に Synthorai gateway 経由で行った。ローカル tokenizer は使わず、常に各 provider が返した token 数を採用している。繰り返し実行しても、すべて同じ結果になった。

課金単位はテキストではなく token

課金は token 単位だが、token は文字でも単語でもない。各モデルは独自の語彙を持つ tokenizer を採用しているため、同じ文でもモデルごとに token 数が変わる。その token 数に単価が掛かる。つまり、テキストが何 token になるかと、1 token あたりの価格という 2 つの要素が同時に変わる。

一般的な料金ページに載っているのは後者だけだ。この記事では前者を計測した。意味をそろえた 3 種類の文章を 7 モデル（claude-fable-5、claude-opus-4-8、claude-sonnet-5、deepseek-v4-flash、glm-5.2、gpt-5.5、kimi-k2.5）へ送り、各モデルが入力として課金した token 数を取得した。

カジュアルな文章（土曜の市場を描いた話）は 9 言語で用意した。技術解説（exponential backoff を使う retry）とニュース短報（市の予算案に関する採決）は、英語、中国語、日本語、韓国語、ドイツ語、ヒンディー語で用意している。さらに Python 関数と JSON の tool-call データも加えた。英語以外の文章は、忠実に訳し、短縮しないよう指示して機械翻訳した後、人手で一部を確認した。翻訳による冗長さは実際に結果を乱す要因になる。後述する文体別の検証では、その影響をおよそ 20% 以内と見積もっている。

token 数は常に provider 側の値を使った。Claude 系は実際に Messages を呼び出して usage.input_tokens を読み取った。gateway は現時点で count_tokens を proxy していない。OpenAI 互換モデルでは、小さなリクエストを実行して usage.prompt_tokens を取得した。請求結果と食い違うローカル tokenizer を使わないためだ。どのリクエストにも chat template や role marker など、数 token 分の固定 framing が含まれる。この影響を除くため、2 文字の baseline サンプルを計測して差し引いた。この記事に掲載する比率はすべてこの固定部分を除いた値であり、framing ではなくテキスト自体を比較している。

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

以下は、カジュアルな文章について、言語別、tokenizer 別に計測した入力 token 数だ。Claude の 3 モデルは全サンプルで同じ値を返したため、1 列にまとめている。詳細は後述する。残り 2 種類の文章でも同じ傾向が再現されており、後半の集計に含めた。chars 列は各言語版の文字数だ。文字体系によって意味の詰め込み方が異なるため、英語では 254 文字必要な内容を、中国語では 77 文字で表現できる。

ここから 2 つの事実が分かる。Claude の列が 3 モデルで共通なのは、Claude Fable 5、Opus 4.8、Sonnet 5 が、言語、code、JSON を含むすべてのサンプルで同じ token 数を返したためだ。3 モデルとも Opus 4.7 で導入された tokenizer を使っている。1 モデルで計測した token 数を、残り 2 モデルにもそのまま適用できる。この列は、ヒンディー語以外の全行で最大になっている。ヒンディー語だけは GLM の 192 がさらに多い。各言語で最少のモデルを 1.00 とし、固定部分を差し引いた token 数で正規化した結果が次の表だ。固定部分を先に除いているため、上表の生値を単純に割った値とは一致しない。

英語の行で 4 モデルが並んでいるのは丸めの結果ではない。この文章では DeepSeek、GLM、GPT-5.5、Kimi のすべてが固定部分を除いて正確に 50 token だった。Claude はこの文章で最少 tokenizer の 1.3〜2.2 倍、3 種類の文章全体では 1.2〜2.3 倍になる。これは語彙構成に由来するため、モデルが提供されている限りすべての呼び出しに影響する。技術解説とニュース短報でも順位は同じだった。2 つを合計すると、中国語は Claude が 212 net token、Kimi が 114 で 1.9 倍、ヒンディー語は Claude が 477、GPT-5.5 が 210 で 2.3 倍になった。ただし、常に 1 位になるモデルはない。最少の列は言語によって変わる。

• GPT-5.5 は、ドイツ語、フランス語、スペイン語、イタリア語、ヒンディー語、韓国語で最少となり、英語でも最少に並ぶ。英語の同率とフランス語、スペイン語、イタリア語の結果は、カジュアルな文章に限る。語彙は Latin script に最適化されているほか、Devanagari と Hangul にも強い。
• Kimi K2.5 は中国語で最少となり、CJK 全体でも競争力がある。
• DeepSeek-v4 は日本語で最少となり、中国語でも上位に入る。
• GLM 5.2 は多くの言語で中位だが、ヒンディー語では表中で最悪の値を記録した。カジュアルな文章では最少モデルの 2.59 倍で、GPT-5.5 が 69 net token なのに対して 179 net token を消費する。フォーマルな文章ではさらに悪化し、Claude をも上回る唯一の列になった。

差は通常の文章に限らない。Python 関数では Claude が最少モデルの 1.61 倍、JSON の tool-call では 1.29 倍だった。JSON は主に記号と短い ASCII key で構成され、どの tokenizer でも似た処理になるため、差が小さい。大きな tool schema を毎 turn 再送する長時間稼働の agent では、この差が turn ごとに積み上がる。こうしたケースでは caching が効く。prompt caching シリーズで仕組みを解説している。

文字単位で見ると CJK のコストを見誤る

ここまでの表ではモデル間を比較した。モデルを固定しても言語によって token 数は変わるが、文字数だけを見た印象とは一致しない。tokenizer の指標としてよく引用されるのは 1 文字あたりの token 数で、この指標では CJK が突出する。Claude では 100 文字あたりの net token 数が、中国語で約 114、韓国語で 106、日本語で 94、英語で 32 となる。この列だけを見ると、CJK には 3 倍のコストがかかるように見える。しかし、課金されるのは文字ではなく意味に対してだ。意味をそろえた文章は、どの言語でも同じ内容を伝えている。Claude でカジュアルな文章を計測し、両方の見方を並べると次のようになる。

右側の 2 列は異なる結果を示す。中国語が最も分かりやすい。100 文字あたりの token 数は最大だが、この文章を意味単位で比べた場合、英語との差は 1.07 倍にすぎない。英語で 254 文字かかる内容を 77 文字で表現できるため、1 文字あたりの高い token 数と少ない文字数がほぼ相殺される。3 種類の文章全体でも同じ傾向だが、完全に相殺されるわけではない。中国語は Claude の英語に対して平均 1.17 倍で、モデルによって 0.95〜1.32 倍だった。1 文字あたりの指標が示す 3 倍ではなく、ほぼ同等だ。

日本語と韓国語にも同じ見かけ上の問題があるが、相殺効果は中国語ほど強くない。どちらも 1 文字あたりの token 数は多い。中国語の漢字が 1 文字に単語全体を詰め込むのに対して、Hangul と日本語の仮名は、おおむね 1 音節を 1 文字で表すためだ。その結果、中国語なら 77 文字で済む文章に、韓国語では 143 文字、日本語では 136 文字必要になる。文字数が多く、1 文字あたりの token 数も多いため、相殺されずに積み上がる。Claude で 3 種類の文章を平均すると、意味単位では韓国語が英語の 1.96 倍、日本語が 1.56 倍で、どちらも実際に高コストだ。1 文字あたりの列だけを見れば、中国語と大きくは違わない。

ドイツ語は中国語と逆だ。1 文字あたりの token 数は 48 と低く、英語に近い。一方で文字数は 289 と、ここで比較した言語の中で最も多い。複合語が長いため、合計では 1.68 倍になる。コストはこの 2 軸の積で決まる。片方だけを見ると判断を誤る。

数値が変わる理由は 2 つの要因の積

上の全表に共通するルールは、次の式で表せる。

文章の token 数 ＝（同じ意味を表すために必要な文字数）×（1 文字あたりの token 数）

第 1 の要因は文字体系の情報密度であり、モデルではなく言語側の特性だ。中国語だけが例外なのではなく、連続したスペクトラムになっている。表語文字を使う中国語は、1 文字に 1 形態素を詰め込めるため、最も密度が高い。日本語の仮名や韓国語の Hangul は音を表すので密度が下がり、必要な文字数が増える。Devanagari や Latin alphabet はさらに密度が低い。1 文字あたりの意味量は、中国語から英語に向かって徐々に減っていく。

第 2 の要因は、モデルの語彙がその文字体系を 1 文字あたり何 token で表現するかだ。これはモデルごとに異なる。BPE tokenizer は学習 corpus から複数文字の merge を学ぶ。頻繁に見た文字体系には効率のよい token が割り当てられるが、出現頻度の低い文字体系では 1 文字ずつ、場合によっては byte 単位に近い encoding へ fallback する。1 文字が 2〜3 token になることもある。同じ 3 言語について、1 文字あたりの net token 数を示す。

この表から 3 つのことが分かる。中国語の合計値が特殊に見えるのは、第 1 の要因が極端だからだ。Claude は中国語の圧縮効率が低く、1 文字あたり 1.14 token で、一部の漢字を今も 2 token に分割している。それでも文字数が 77 しかないため、合計は大きくならない。中国で学習されたモデルは 1 文字あたり 0.52〜0.58 token まで効率よく圧縮できるため、それぞれの英語とほぼ同等になる。ヒンディー語の差は密度ではなく、第 2 の要因によるものだ。GLM は Devanagari 1 文字あたり 0.91 token を消費する。語彙に Devanagari の複数文字 merge がほぼないため、1 文字 1 token に近い。一方、GPT-5.5 は音節 cluster 全体をカバーするため 0.35 token で済む。同じ文字体系に対するカバー範囲の差だ。Claude は英語でも 1 文字あたり 0.32 token と、DeepSeek の 0.20 より多い。モデル全体の baseline が高く、そこに各言語固有の差が加わるため、すべての言語で token 数が多くなる。

これは今回の 7 モデルだけに見られる現象ではない。研究では token premium と呼ばれている。Petrov らによる NeurIPS 2023 の研究では、数百の言語ペアを計測し、同じ 2 つの根本原因を確認している。意味あたりの文字数が言語によって異なり、文字体系に対する tokenizer のカバー範囲も異なる。低 resource 言語では最大 15 倍の premium があり、その結果、コストと latency が増え、利用可能な context window も実質的に狭くなる。premium の高い言語では、同じ context 予算で保持できる意味量が減るためだ。vendor の投資によって差は縮小している。独立した計測によると、中国語は GPT-3 世代の語彙では英語より token 数が 182% 多かったが、GPT-4o では 24% まで縮小した。今回の GPT-5.5 で計測した 32% 増や、中国で学習されたモデルのほぼ同等という結果に近い。カバー範囲を広げるには語彙 slot が必要であり、vendor はそこへの投資を続けている。

ローカライズでコストを削減できるか

ここまでの結果から、「Claude は言語による差が小さいのでローカライズを無視できる」「中国系モデルは中国語が安いので、ローカライズすればコストを削減できる」と考えるのは誤りだ。3 種類すべての文章を用意した 5 言語について、各モデル自身の英語に対する平均値を示す。

Claude は言語によらず一定ではない。韓国語は英語の 1.96 倍、ヒンディー語は 2.40 倍かかる。中国語が 1.17 倍に収まるのは、その言語だけで成立する結果であり、モデル全体の特性ではない。中国系モデルも、中国語で英語を大きく下回るのではなく、同等になるだけだ。表全体で最良なのは Kimi の 0.95 倍で、自モデルの英語より 5% 少ない。ほかはすべて同等か、それ以上になる。ヒンディー語、日本語、韓国語では、同じ中国系モデルの premium が Claude より大きい。これらの文字体系が学習の中心から外れているためだ。「vendor X が安い」のではない。各モデルは、自身の英語と比べた場合、学習データに近い言語で最も効率がよい。

文体によっても値は変わる。カジュアルな文章は最も有利なケースだ。技術用語や外来語は、非 Latin 系の語彙で merge が不足しやすいため、技術解説やニュース短報ではほぼすべての言語で倍率が上がる。Claude のドイツ語は、カジュアルな文章の 1.68 倍から技術解説では 2.29 倍に上昇する。GLM のヒンディー語は、ニュース短報で自モデルの英語の 5.98 倍に達する。1 種類の文章だけで benchmark すると、その翻訳が最も自然に収まった言語が実態以上によく見える。カジュアルな文章だけでは Kimi の中国語が 0.80 倍だったが、3 種類を通すと 0.95 倍になった。

自モデルの英語比だけで判断するのも誤りだ。実際に支払うのは絶対的な token 数に対してであり、この基準では 9 言語中 8 言語で Claude が最も高い。唯一、GLM のヒンディー語だけが Claude を上回る。「Claude の英語に比べて安い」中国語コンテンツでも、カジュアルな文章では Claude が 88 net token、Kimi が 40 net token だ。コスト削減のためにローカライズするのではなく、言語ごとにモデルを選ぶべきだ。中国語なら Kimi または DeepSeek、ヒンディー語と韓国語なら GPT-5.5、日本語なら DeepSeek になる。品質面で Claude が勝つ可能性はあるが、token コストではどの言語でも 1 位にならない。

token 数だけでは請求額は決まらない

token 数の倍率は 1 token あたりの価格と組み合わせて初めて意味を持ち、両者は掛け合わされる。Claude Fable 5 の入力価格は 100 万 token あたり $10、Opus 4.8 は $5、Sonnet 5 は導入価格の終了後に $3 となる。3 モデル共通の tokenizer は、中国語を最少モデルの 2.2 倍に数える。そのため、代替ルーティング先との単価差に、この token 数の premium がさらに掛かる。逆も起こる。token 数が少ないモデルでも単価が高ければ、1 call あたりのコストは高くなる。どちらか一方だけでは請求額を判断できない。ほかの vendor の価格は tokenizer より頻繁に変わるため、ここには掲載しない。上記の token 数は、計算の中で長く使える側の値だ。

表示価格ではなく、実効入力コストを比較するべきだ。実際の traffic 構成を各候補モデルで計測し、token 数にそのモデルの入力単価を掛ける。中国語または韓国語中心の product では、最安モデルの順位が入れ替わる可能性がある。その差は丸め誤差ではなく、継続的に 1.5〜2 倍になる。cache でも同じで、重要なのは表示価格ではなく、hit 率で重み付けした実効コストだ。provider 比較で計算方法を解説している。同じ英語でも Sonnet 5 が Sonnet 4.6 より 41% 多く数える理由など、version 間の違いは Sonnet 5 の tokenizer に関する記事にまとめた。

結論

• token コストは、文字体系の情報密度と tokenizer のカバー範囲の積で決まる。第 1 の要因は言語、第 2 の要因はモデルが決める。どちらか一方だけでは判断を誤る。
• Claude Fable 5、Opus 4.8、Sonnet 5 は、すべての言語で最少モデルの 1.2〜2.3 倍になる。英語でも 1 文字あたりの token 数が多いためだ。
• 最も効率のよいモデルは言語ごとに異なる。欧州言語、ヒンディー語、韓国語では GPT-5.5、中国語では Kimi、日本語では DeepSeek が最少。GLM はヒンディー語に弱く、ほぼ 1 文字 1 token になる。
• フォーマルな文体や技術文書では、ほぼすべての言語で倍率が上がる。実際に提供する文体で benchmark する必要がある。
• コスト削減を目的にローカライズするのではなく、絶対的な token 数を基準に言語とモデルを組み合わせる。その後、各モデルの単価を掛けて実効コストを比較する。

FAQ

最も安い LLM tokenizer はどれか？ 言語によって異なる。意味をそろえた同じ文章を 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 は同じ tokenizer を使っているか？ 使っている。すべてのサンプルで、言語、code、JSON を問わず 3 モデルの token 数が一致した。Opus 4.7 で導入された tokenizer を共有しているため、1 モデルの計測結果をほかの 2 モデルにも適用できる。Fable 5 の請求額が高いのは、token 単価だけが原因だ。

Claude では中国語が英語より高いか？ わずかに高い。3 種類の文章を意味単位で平均すると 1.17 倍になる。中国で学習されたモデルでは、ほぼ同等だ。文字単位では、英語が 100 文字あたり 32 net token なのに対し、中国語は約 114 net token と大幅に高く見える。しかし、中国語は同じ意味をおよそ 3 分の 1 の文字数で表現できるため、合計ではほぼ相殺される。

日本語と韓国語も中国語と同じ傾向か？ 半分だけ同じだ。1 文字あたりの token 数は中国語と同様に多いが、Hangul と仮名は音を表すため、同じ文章に必要な文字数が大幅に増える。中国語が 77 文字なのに対し、日本語は 136 文字、韓国語は 143 文字だった。1 文字あたりの高い token 数が相殺されないため、意味単位では Claude の日本語が英語の約 1.6 倍、韓国語が約 2 倍になる。7 モデル全体では 1.5〜2.4 倍だった。

自分の prompt で計測するにはどうすればよいか？ 実際に提供する文体の prompt を複数用意し、候補モデルへ送る。ローカル tokenizer を信用せず、usage field から provider 自身の入力 token 数を取得する。都合のよい文章を 1 つだけ使うと、言語によって約 20% よく見えることがあるため、複数の文章で試す。その後、各 token 数にモデルの入力価格を掛ければ、実際の traffic に対する実効コストを計算できる。

← ブログに戻る