Claude Media
Claudeの日本語トークン消費が英語より多い理由

Claudeの日本語トークン消費が英語より多い理由

Claudeは1トークンが英語で約3.5文字相当ですが、日本語では同じ基準が崩れます。根拠と実測の方法をまとめました。

1トークン=英語3.5文字という基準が日本語で崩れる

Claudeは同じ内容を伝えるのに、日本語だと英語より多くのトークンを使います。1トークンは英語でおよそ3.5文字に相当し、正確な値は言語によって変わります。この基準からのずれが、日本語利用時のコストとコンテキストウィンドウの消費に直結します。Anthropicは言語別の具体的な倍率を公開していませんが、用語集の記述と実測方法を組み合わせれば、自分のワークロードで正確な数字を出せます。

用語集が定義するトークンの基準とその限界

Anthropicの用語集は、トークンを「言語モデルの最小単位で、単語・部分単語・文字、あるいはUnicodeの場合はバイトに対応する」と定義したうえで、次のように述べています。

Tokens are the smallest individual units of a language model, and can correspond to words, subwords, characters, or even bytes (in the case of Unicode). For Claude, a token approximately represents 3.5 English characters, though the exact number can vary depending on the language used.

「3.5文字で1トークン」はあくまで英語での目安です。日本語・韓国語・アラビア語のような非ラテン文字言語について、Anthropicは具体的な倍率を公表していません。ネット上で言われる「2〜3倍」という数字は、Anthropicが発表した値ではなく第三者による独自の検証結果です。事実として確認できる範囲と、自分で確かめられる範囲は分けて扱う必要があります。

なぜ非ラテン文字言語ほどトークンを消費しやすいのか

多くの大規模言語モデルは、BPE(バイト対符号化)のようなサブワード分割方式でテキストをトークン化します。頻出する文字の並びをまとめて1つのトークンに割り当てる仕組みで、学習データに占める割合が大きい言語ほど、まとまった単位を1トークンとして獲得しやすくなります。Anthropicは、Claudeのトークナイザーが具体的にどの方式を採用しているかを公表していません。ここから先の説明は、Claude固有の仕様としてではなく、サブワード分割方式一般に共通する性質として読んでください。

学習コーパスは英語を中心とした構成が大半を占めるため、英語の頻出単語やその一部は効率よく1〜2トークンにまとまります。一方、日本語・韓国語・アラビア語のような非ラテン文字言語は、学習データに占める割合が相対的に小さく、まとまった単位を獲得しにくい傾向があります。加えて、これらの言語の文字はUTF-8で複数バイトを使うため、まとまった単位を獲得できなかった文字はバイト単位に近い粒度まで分解されることがあります。トークナイザーの語彙表に十分な大きさの単位が無ければ、同じ情報量を伝えるのに必要なトークン数は増えます。

この現象自体は、Claudeに限らず主要な大規模言語モデル全般で報告されています。トークナイザーの言語間の不公平性を扱った学術研究(arXiv:2305.15425)は、同じ内容を表現するのに必要なトークン数が言語によって大きく異なることを複数のモデルで確認しており、非ラテン文字言語ほど不利になりやすいという傾向は、Claude固有の欠陥ではなく業界共通の技術的な特性です。

自分のテキストで実測する方法

言語別の正確な倍率を知りたいときは、トークンカウントエンドポイントで同じ内容の英語文と日本語文を数え、直接比較するのが最も確実です。count_tokensで送信前にトークン数を数える方法で解説されている手順を、英語と日本語の2パターンで実行するだけで済みます。

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "Please summarize the key findings of this quarterly report in three bullet points."}]
  }'

同じ意味の日本語文に差し替えて、model は変えずにもう一度実行します。

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "この四半期レポートの主な要点を3つの箇条書きで要約してください。"}]
  }'

戻ってくる input_tokens を比べれば、そのモデル・そのテキストでの実際の倍率が分かります。トークンカウントは無料で使え、実際のメッセージ作成とは別のレート制限が適用されるため、本番の会話に影響を与えずに何度でも試せます。この数値はあくまで推定値で、実際の課金対象トークン数とは小さくずれることがあります。

意味は同じでも情報量は違う — 文字数とバイト数のずれ

日本語は英語より少ない文字数で同じ内容を表現できますが、UTF-8では1文字あたりのバイト数が英語よりずっと大きくなります。上のcurl例と同じ英日ペアで、実際の文字数とUTF-8バイト数を数えると次のようになります。

内容文字数UTF-8バイト数
英語文(quarterly report...)文字数82文字UTF-8バイト数82バイト
同じ内容の日本語文文字数32文字UTF-8バイト数94バイト

日本語は文字数こそ英語の半分以下ですが、UTF-8バイト数では英語を上回ります。トークナイザーがまとまった単位を獲得できず文字・バイト単位に近い粒度まで分解する場面が増えるほど、この生のバイト数の差がトークン数の差にも表れやすくなります。文字数の少なさだけを見て「日本語のほうがコンパクトで安いはず」と判断すると、実際のトークン数と食い違うことがあります。

新しいトークナイザーでどう変わったか

Claude4.7以降のモデル(Claude Fable 5.1・Claude Mythos 5.1を含む)は新しいトークナイザーを採用しており、同じ入力テキストでも旧世代のモデルよりおよそ30%多いトークン数になります(詳しい仕組みはClaudeの新トークナイザーでトークン数が30%増える仕組みと対処を参照)。この増加率自体は言語を問わず内容に応じて変動しますが、日本語コンテンツで実際に確かめたい点は「もともと英語よりトークンを消費しやすい日本語テキストに、この30%増がさらに乗る」という掛け合わせです。旧世代モデルで測った日本語の倍率は新世代ではそのまま使えないため、移行前に count_tokens で日本語サンプルを数え直してください。

出力側でも同じ非対称が起きる

ここまでの実測方法は入力(プロンプト)側の話ですが、同じ非対称はClaudeが生成する出力側にも及びます。日本語で長い応答を生成させると、同じ内容を英語で生成させる場合よりも出力トークン数がかさみやすくなります。料金は言語を区別せず入力・出力それぞれのトークン数に対して一律で発生するため、日本語で長文回答を大量生成する用途ほど、想定より早くコストと max_tokens の上限に到達します。

max_tokens を英語での目安のまま流用していると、日本語では文の途中で応答が打ち切られる場面が増えます。応答言語を日本語に固定するアプリケーションでは、max_tokens を英語向けの目安より余裕を持たせて設定し、実際の出力トークン数は usage.output_tokens で確認しながら調整するのが安全です。

利用形態別の影響度早見表

利用形態影響度対応
日本語のシステムプロンプトが長い運用影響度明確な影響あり対応システムプロンプトを英語で書き、ユーザー向け出力だけ日本語を指定する構成に切り替えると節約できる場合がある
日本語のRAGドキュメントを大量に読み込む運用影響度明確な影響あり対応コンテキストウィンドウの消費が英語主体の運用より速いため、チャンクサイズの見直しとcount_tokensでの事前計測が必須
日本語チャットログの要約・分析影響度条件次第対応ログ量が少なければ影響は小さいが、長期ログの一括要約ではコンテキストウィンドウの上限に早く到達しやすい
応答は日本語だが指示はほぼ英語のみ影響度ほぼ影響なし対応出力トークンの増分はあるが、入力側の膨張は限定的

長い日本語コンテキストを繰り返し読み込む構成では、Anthropic APIのPrompt Cachingを理解するで解説されているプロンプトキャッシュを併用すると、トークン数そのものは変わらなくても再計算コストを抑えられます。トークン数の増加とキャッシュによるコスト削減は別のレイヤーの話なので、両方を組み合わせて考える必要があります。

モデル別の多言語性能とあわせて見る

トークン消費量とは別の軸として、モデルの多言語での応答精度そのものにも言語差があります。日本語のベンチマーク相対性能は英語比93〜97%程度で、モデル世代によって幅があります(例: Sonnet4.5系で96.8%、Haiku4.5系で93.5%)。低リソース言語ではより大きな差が出ます。この精度差の詳細はClaudeの多言語性能を言語別データで見るで扱っており、本記事のトークン消費量とは独立した論点として区別しておく必要があります。同じ「日本語は不利」という印象でも、コストの話と精度の話は原因も対策も別です。

よくある質問

漢字とひらがな・カタカナでトークン消費に差はあるか

言語全体としての倍率と同様、文字種別の細かい差についてもAnthropicは数値を公表していません。漢字は1文字あたりの情報量が大きく、ひらがな・カタカナは表音文字で1文字の情報量が小さいため、同じトークナイザーでも扱われ方が変わる可能性はありますが、推測で断定はできません。専門用語が多い漢字主体の文章と、口語的なひらがな主体の文章を、それぞれ count_tokens に投げて比較すれば、自分のユースケースでの実際の差が分かります。カタカナ語が多い文章(外来語の技術用語を多用する文章など)も同様に、漢字・ひらがな中心の文章とは違う挙動を示す可能性があるため、実際に扱うドキュメントの文体に近いサンプルで測るのが最も参考になります。

英語に翻訳してから送信すればコストを抑えられるか

入力側だけを見れば、英語のほうがトークン効率は良くなります。ただし、翻訳の手間や翻訳精度の劣化というコストが別途発生し、Claudeからの応答を日本語で受け取りたい場合は出力側の非対称がそのまま残ります。翻訳を挟む構成が有利になるのは、入力テキストが長大でAnthropicへの送信コストが支配的な場合に限られ、短い対話が主体のチャットボットのような用途では翻訳のオーバーヘッドのほうが大きくなることもあります。

まとめ

1トークンは英語で約3.5文字相当ですが、正確な値は言語によって変わります。日本語・韓国語・アラビア語のような非ラテン文字言語がこの基準からずれやすいことは、BPEトークナイザーの一般的な性質として技術的に説明できます。日本語固有の倍率そのものは公表されていないため、正確な数字が必要なワークロードでは count_tokens エンドポイントで自分の実際のテキストを英語版・日本語版の両方で数え、直接比較するのが最も確実です。Claude4.7以降でトークナイザー自体が変わっている点も踏まえ、古いモデルで測った数字は新しいモデルの見積もりに使い回せません。

この記事を共有:XはてブLinkedIn