1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIは日本語が苦手?トークンとデータで見る言語格差の現実

1
Posted at

これ、気のせいじゃない

ChatGPTに同じこと聞いても、日本語と英語で回答の精度が違う気がする——そう感じたことがある人は多いと思う。

結論から言うと、気のせいじゃない。

自分はAI開発駆動基盤を作る中でこの問題に本気でぶつかって、コンテキスト定義を英語で書くようにした。そのときに調べた内容をまとめる。


まず数字を見る

Webコンテンツの言語別シェア(Statista, 2024年1月):

言語 シェア
英語 約50〜55%
スペイン語 約6%
日本語 約4%

日本語は英語の10分の1以下しかない。

LLMは大量のデータから学ぶ。OpenAI・Anthropic・Googleはすべて英語圏の企業で、当然学習データも英語中心だ。日本語で書かれたパターンを学習する機会が根本的に少ない。これがすべての出発点になる。


トークンの話

APIを叩いたことがあれば知ってると思うけど、LLMはテキストをトークン単位で処理する。課金もトークン単位。

ここに大きな罠がある。

BPEベースのトークナイザー(GPT・Llama等)では、英語は1単語あたり1〜1.5トークンで処理できる。ところが日本語・中国語・韓国語(CJK)は、学習コーパスでの出現頻度が低いため文字のマージが進まず、1文字あたり約1トークンになってしまう。

実際に比べるとこうなる:

英語:「The MVP scope should be completed within 2 weeks」
→ 約11トークン

日本語:「MVPスコープは2週間以内に完了できる範囲とする」
→ 約18〜22トークン

同じ意味で約2倍。CJKテキスト全体でみると英語の4〜5倍のコストになるという試算もある(llm-calculator.com, 2025)。


おまけ:「言」より「ゼウス」の方が賢い件

これが個人的に一番ひどいと思った話。

論文(arxiv:2305.15425)によると、GPT-4のトークナイザーでは:

  • 「言」(言う、という超頻出漢字)→ 3トークン必要
  • 「ゼウス」(ギリシャ神話の神)→ 専用トークンあり
  • 「サーティワン」(アイスクリームチェーン)→ 専用トークンあり

英語由来のカタカナ語の方が、日常的な漢字より効率よく処理される。トークナイザーが学習データのバイアスをそのまま反映した結果だ。


ベンチマークでも差は出る

東工大のSwallow LLM Leaderboard v2(2025年)では、日本語6タスクと英語6タスクで同じモデルを評価している。

GPT-5のスコアを見ると:

  • 日本語タスク平均:0.891
  • 英語タスクのスコア:0.875

最強モデルですらこの差がある。オープンソースモデルだとさらに開く。

また、主要なLLMベンチマークの75%以上が英語向けに設計されていて、非英語のテストは後付けが多い(Medium, 2025)。「多言語対応」と謳っていても、実際の非英語推論能力は同じ深さでテストされていないのが現状だ。


じゃあどうするか

答えはシンプルで、英語でプロンプトを書いて日本語で出力させる。

# やりがちなパターン
「MVPスコープは2週間以内に完了できる範囲を目安にしてください」

# こうする
「Target an MVP scope that one person can release within 2 weeks.
Always respond in Japanese.」

最後の Always respond in Japanese の一行で出力は日本語になる。

自分がAI開発駆動基盤のコンテキスト定義を英語で書いているのはこれが理由で、実際にトークン消費が30〜50%減った。システムプロンプトやRAGのインデックス設計でも同じ考え方が使える。

# 日本語で書いてたやつ
output_quality:
  言語: "入力言語に関わらず常に日本語で回答する"

# 英語に変えたやつ
output_quality:
  language: "Always respond in Japanese regardless of input language."

月に大量のAPIリクエストを処理するシステムだと、この差がそのまま月額コストに響く。


一応フォローしておくと

この差は縮まってきている。

LLM-jpが開発した llm-jp-3-13b-instruct はクローズドソースと同等の性能を達成している。ELYZAのLlama-3-ELYZA-JPやCyberAgentLM、東工大のSwallowシリーズなど、日本語特化モデルの開発は急速に進んでいる。

ただ今の時点では、システムを作るなら英語プロンプト + 日本語出力の構成を取った方が精度もコストも有利というのが自分の結論。


まとめ

指標 数字
学習データの日本語比率 約4%(英語の1/10以下)
日本語のトークン消費 英語比1.5〜3倍
CJKのAPI処理コスト 英語の4〜5倍
英語向けに設計されたベンチマーク 75%以上

英語でプロンプトを書いて Always respond in Japanese を末尾に付ける。 これだけで精度とコストの両方が改善する。


参考

  • Statista「Languages most frequently used for web content as of January 2024」
  • Swallow LLM Leaderboard v2(東京工業大学)https://swallow-llm.github.io/swallow-leaderboard-v2.en.html
  • Open Japanese LLM Leaderboard(Hugging Face × LLM-jp)
  • arxiv:2305.15425「Language Model Tokenizers Introduce Unfairness Between Languages」
  • arxiv:2404.11553「Language Ranker: A Metric for Quantifying LLM Performance Across High and Low-Resource Languages」
  • llm-calculator.com「Tokenization Speed and Efficiency Benchmarks (July 2025)」

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?