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

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

Claudeは同じ内容を伝えるのに、日本語だと英語より多くのトークンを使うと見込まれます。1トークンは英語でおよそ3.5文字に相当し、正確な値は言語によって変わります。この基準からのずれが、日本語利用時のコストとコンテキストウィンドウの消費に直結します。

日本語の倍率は文書ごとに変わるため、自分のテキストで測って出します。測る方法と、測らなくても手元で分かる文字数・バイト数の差を、この記事で順に示します。

用語集が定義するトークンの基準

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トークン」は英語での目安で、後半の "the exact number can vary depending on the language" が日本語にも当てはまります。この一文が、本記事の出発点です。

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

大規模言語モデルの多くは、BPE(バイト対符号化)のようなサブワード分割方式でテキストをトークン化します。頻出する文字の並びをまとめて1つのトークンに割り当てる仕組みで、学習データに多く現れる言語ほど、まとまった単位を1トークンとして獲得しやすくなります。以下は、Claude固有の仕様ではなく、サブワード分割方式一般に共通する性質です。

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

トークナイザーの言語間の不公平性を扱った学術研究(arXiv:2305.15425)は、同じ内容を表すのに必要なトークン数が言語によって大きく異なることを、複数のトークナイザーで確認しています。同論文は、同じ文を翻訳しても言語によって最大15倍の差が出うると述べています。非ラテン文字言語が不利になりやすいのは、Claudeだけの欠陥ではなく、この方式に共通する性質です。

文字数とバイト数で見ると、日本語は英語を上回る

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

日本語は文字数こそ英語の半分以下ですが、バイト数では英語を上回ります。文字数の少なさだけを見て「日本語のほうがコンパクトで安いはず」と判断すると、トークン数と食い違うことがあります。バイト数は分解された場合の上限に近い目安に過ぎず、実際のトークン数はトークナイザー次第で、バイト数と一致するわけではありません。

漢字・ひらがな・カタカナで比べる

文字種の違いがバイト数にどう出るかも、同じ方法で数えました。

漢字・ひらがな・カタカナは、いずれもUTF-8で1文字3バイトです。2.94や2.95と3.00の小さな差は、文中の半角数字「3」が1バイトで数えられるためです。バイト数の面では文字種による差はありません。トークン数が文字種でどう変わるかは別の話で、同じトークナイザーが漢字をまとまりで扱うか1文字ずつ分けるかは、count_tokens で測らないと分かりません。

文字数と、UTF-8バイト数は、次のコマンドで再現できます。

python3 -c 'import sys; s=sys.argv[1]; print(len(s), len(s.encode()))' "この四半期レポートの主な要点を3つの箇条書きで要約してください。"

出力は 32 94 で、文字数とバイト数の順に並びます。

自分のテキストで実測する手順

言語別の倍率は、トークンカウントエンドポイントで同じ内容の英語文と日本語文を数えて比べるのが確実です。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."}]
  }'

日本語版は content を差し替えるだけです。

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つの箇条書きで要約してください。"}]
  }'

count_tokens は、システムプロンプト・ツール定義・画像・PDFを含む、メッセージ作成と同じ形の入力を受け付けます。日本語のシステムプロンプトやツール説明文を本番と同じ形で渡せば、毎リクエストで再送する固定分をまとめて測れます。Web検索などのサーバーツールを含む入力は、invalid_request_error になります。

トークンカウントは無料で使えます。ただし、利用ティアに応じた1分あたりのリクエスト数の制限があります。メッセージ作成とは別の制限なので、本番の会話に影響を与えずに何度でも試せます。

数値は推定値で、実際に使われたトークン数と小さくずれることがあります。計測値にはシステム最適化のためにAnthropicが自動で加えたトークンが含まれる場合があり、これは課金の対象になりません。課金される量は、自分で送った内容だけに対応します。

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

Claude Opus 4.7以降のモデル(Claude Fable 5.1・Claude Mythos 5.1を含む)は、新しいトークナイザーを採用しています。同じ入力テキストでも、旧世代のモデルよりおよそ30%多いトークン数になります。増え方は内容とワークロードの形によって変わります。詳しい仕組みはClaudeの新トークナイザーでトークン数が30%増える仕組みと対処にあります。

この30%が日本語でどう出るかは、モデルとテキストで変わります。旧世代モデルで測った日本語の倍率は新世代にそのまま使えません。

count_tokens は、渡した model のトークナイザーで数えます。移行前の測り方は、同じリクエストを現行モデルと移行先モデルで1回ずつ数え、2つの input_tokens を比べる形です。

コンテキストウィンドウの目安も変わります。現行のトークナイザーでは、100万トークンは約55.5万語、約250万文字分です。旧世代のモデルでは、100万トークンに約75万語が入りました。日本語の長文を詰め込むときは、この文字数の目安より先にトークン数で測ります。

Claude 4.6以降のモデルは、100万トークンのコンテキストウィンドウを標準料金で使えます。900kトークンのリクエストも、9kトークンのリクエストと同じトークン単価で課金されます。日本語の長文で差が出るのは、単価ではなくトークン数の増え方です。

出力側は事前に数えられない

ここまでの実測方法は入力(プロンプト)側の話です。count_tokens は送るメッセージのトークン数を返すエンドポイントで、まだ生成されていない応答は数えられません。出力側のトークン数は、実際に応答を返させて usage.output_tokens で確かめます。

料金は入力・出力それぞれのトークン数に対して発生します。日本語で長文回答を大量に生成させる用途では、英語で回答させたときと出力トークン数がどれだけ違うかを、代表的な数件で測っておくと見積もりが安定します。

max_tokens は、英語の目安のまま決めず、日本語の出力で測った値から決めます。上限に達すると応答は途中で止まり、stop_reason が max_tokens になります。公式のストップ理由の表では、この場合に「max_tokens を上げるか、応答を続きから生成する」ことが対処として挙がっています。応答言語を日本語に固定するアプリケーションでは、usage.output_tokens と stop_reason を見ながら、余裕のある max_tokens を探る流れになります。

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

長い日本語コンテキストを繰り返し読み込む構成では、プロンプトキャッシュが効きます。仕組みはAnthropic APIのPrompt Cachingを理解するにまとまっています。キャッシュからの読み取りは、通常の入力単価の10%で課金されます。Claude Opus 5.5とSonnet 5.5では5%、Claude Fable 5.1とClaude Mythos 5.1では2.5%です。count_tokens のリクエストに cache_control を付けても、キャッシュは働きません。キャッシュが効くのは、実際にメッセージを作成するときだけです。キャッシュはトークン数そのものを減らさず、同じトークンに払う単価を下げます。日本語でトークン数が増える分は、このレイヤーで受け止める設計になります。

日本語のまま送るか、英語にして送るか

入力側だけを見れば、英語のほうがトークン効率は良くなる可能性があります。ただし翻訳には別のコストがかかります。判断は、入力の量と応答の言語で分かれます。

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

トークン消費量とは別の軸として、モデルの多言語での応答精度にも言語差があります。公式の多言語表では、英語を100%としたときの日本語は、Claude Sonnet 4.5で96.8%、Claude Haiku 4.5で93.5%です。

この精度差の詳細はClaudeの多言語性能を言語別データで見るで扱っています。同じ「日本語は不利」という印象でも、コストの話と精度の話は原因も対策も別です。トークンの消費は count_tokens で測り、精度は自分のタスクの評価で確かめます。

まとめ

見積もりに使う倍率は、使うモデルに自分の文書を count_tokens へ通した値だけです。長い日本語を毎回送るシステムプロンプトやRAGの文書から測り、モデルを世代交代させるときは測り直します。