同じ内容を日本語で入力するだけで、APIコストが英語の約1.5倍に膨らむ。LLMを日本語で使うなら、この「隠れコスト」を知っておく必要があります。

この記事でわかること：

  • 日本語が英語より多くのトークンを消費する仕組み
  • 6社のLLMで日本語トークン倍率がどれだけ違うか
  • モデル選びで実質コストを抑える考え方

日本語のトークン消費が膨らむ仕組み

https://x.com/so_ainsight/status/2049479833064034350

LLMの料金は「トークン数」で決まります。トークンとは、モデルがテキストを処理する最小単位です。英語では1単語が1〜2トークンに収まることが多いのに対し、日本語は1文字が1トークン前後になるケースが目立ちます。

この差が生まれる原因はトークナイザーの設計にあります。トークナイザーとは、入力テキストをトークンに分割する処理のことです。多くのLLMは英語中心の学習データでトークナイザーを構築しているため、英語の頻出パターン（”ing”や”tion”など）は1トークンにまとめられます。一方、日本語はひらがな・カタカナ・漢字が混在し、英語ほど効率的にまとめられません。

結果として、同じ意味の文章でも日本語は英語より多くのトークンを消費し、API料金が高くなります。

6社のLLMで倍率はこれだけ違う

@so_ainsight氏の検証によると、同じ内容を日本語と英語で比較した場合、6社平均で英語の約1.48倍のトークンを消費します。ただし、モデルごとの差は大きく開いています。

AnthropicのClaudeは日本語で英語の1.94倍と、ほぼ2倍のトークンを消費します。Legalscapeの検証でも、Claude Sonnet 4.5は1トークンあたり約1.02文字と、日本語のトークン効率が低い結果が出ています（参考）。

対照的に、GoogleのGemini 3.1は1.14倍にとどまり、英語とほぼ同等です。GeminiはSentencePieceベースのトークナイザーを採用しており、語彙サイズが262kと大きいことが効率の良さにつながっていると考えられます。SentencePieceは空白に依存しない分割方式を採用しているため、日本語のように単語間にスペースがない言語でも効率よくトークン化できます。

このモデル間の差により、同じ日本語タスクでもモデル選びだけで実質コストが最大1.7倍変わります。

トークン単価だけでは本当のコストは見えない

API料金表に載っている「1Mトークンあたり○ドル」は、あくまでトークン単価です。日本語を扱う場合、同じ文字数でもモデルによって消費トークン数が違うため、文字あたりの実質コストはトークン単価の順位と一致しません。

たとえばGPT-5とGemini 2.5 Proは、入力のトークン単価がどちらも$1.25/1Mトークンで同額です。しかしLegalscapeの実測では、1トークンあたりの日本語文字数がGPT-5は1.17文字、Gemini 2.5 Proは1.52文字でした。日本語100万文字あたりの入力コストに換算すると、GPT-5が約160円に対しGemini 2.5 Proは約123円と、約1.3倍の開きが生じます。

トークン単価が安く見えても、日本語のトークン効率が悪ければ実質コストは高くなります。日本語メインのプロダクトでは、トークン単価ではなく「文字あたりのコスト」で比較する視点が欠かせません。

コストを抑えるための実践的な視点

日本語のトークンコストを最適化するには、まずモデル選定の段階でトークン効率を確認します。出力品質が同等であれば、日本語トークン効率の高いモデルを選ぶだけでコストを大幅に削減できます。

次に、システムプロンプトの言語を見直します。ユーザー入力が日本語でも、システムプロンプトは英語で記述できるケースがあります。プロンプトが長いほど、この切り替えによるトークン節約効果は大きくなります。

最後に、日本語特化モデルの選択肢も検討に値します。PFN社のPLaMo 2.1 Primeは1トークンあたり1.85文字と、海外モデルを大きく上回るトークン効率を持っています。タスクの要件を満たすなら、海外フロンティアモデルよりも大幅にコストを抑えられます。

まとめ

新しいモデルが出るたびにトークン単価は下がっていきますが、日本語のトークン効率はトークナイザーの設計に依存するため、単価の値下げだけでは解消しません。モデルを比較するとき、料金表の横に「日本語の倍率」を並べる習慣をつけるだけで、コスト見積もりの精度は大きく変わります。