【独自調査】日本語でAIを使うと「約1.5倍」高く付く？　AI利用のコスパを左右する“トークン効率”を比較：Deep Insider AI Practice

AIの料金体系が使用量を意識する形へ移りつつある今、「日本語」はAI利用のコストにどれほど影響するのか。GPT-5.5やClaude Opus 4.7など主要モデルを実測し、トークン効率からモデル選びを考える。

» 2026年05月13日 05時00分公開

[一色政彦，デジタルアドバンテージ]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　日本語でAIを使うと、英語よりも高く付くと言われます。もしそれが本当なら、日々のAIコーディングや業務でのAI活用のコストは、私たちが思っている以上に「使う言語」に左右されていることになります。では、日本語は実際にどれくらい不利なのでしょうか。GPT、Claude、Geminiなどの主要LLM（大規模言語モデル）では、その差にどのような違いがあるのでしょうか。本稿では、独自に作成したベンチマークを基に、言語ごとのトークン効率を比較します（図1）。

　そもそもトークンとは、AIが文章を処理するときの単位です。人間にとっては同じ意味の文章でも、AIの内部では言語や表記によって異なる数のトークンに分割されます。多くのAIサービスでは、この入力トークン数や出力トークン数が料金、利用上限、コンテキストウィンドウ（AIが一度に扱える情報量）に関係します。つまり、同じ内容を伝えているつもりでも、ある言語では少ないトークンで済み、別の言語では多くのトークンを消費する可能性があります。この差が、ここでいう「トークン効率」です。

図1　主要5モデルにおける言語別トークン効率の比較
同じ意図の入力文を複数言語（英語、日本語、中国語、韓国語、スペイン語、フランス語、アラビア語、ヒンディー語の8言語）で用意し、入力トークン数を比較したものです。英語を1.00xとした倍率で、数値が大きいほど、英語より多くの入力トークンを消費することを意味します。日本語の平均は1.48xで、今回の条件では英語より約1.5倍多くなりました。なお、比較対象は入力トークンのみで、出力トークン、キャッシュ済みトークン（同じプロンプトを使い回すときに再利用され、通常より割安になるトークン）、思考トークン（リーズニングと呼ばれる思考プロセスの中で、内部で消費されるトークン）は含みません。結果はサンプル文、翻訳表現、各モデルのトークナイザー、OpenRouterのusage値に依存します。

　これまで、ChatGPTやClaude、GitHub Copilotのようなサブスクリプション型のAIサービスでは、利用者がトークン数を細かく意識しなくても使える場面が多くありました。もちろん実際には利用上限があり、一定時間（例：5時間）や一定期間（例：1週間）ごとに使える量が決まっていたり、追加クレジットで利用量を増やせたりする仕組みがあります。それでも利用者にとっては、細かなトークン単価よりも、「月額料金の範囲内で、いかにうまく使うか」が主な関心事でした。

　しかしこの前提は変わりつつあり、AIツールの料金体系は、月額サブスクリプションから、使った量に応じてコストが発生する従量課金へと移り始めています。象徴的なのがGitHub Copilotです。GitHubは2026年6月1日から、Copilotの利用量をGitHub AI Creditsで管理する使用量ベースの課金モデルへ移行すると発表しました。こうした流れの中では、どれだけ少ないトークンで同じ作業を進められるか、つまりAI利用のコスパを左右する「トークン効率」が、実務上の関心事になっていく可能性が高いでしょう。

　本稿では、図1などのベンチマーク結果を基に、日本語でAIを使うとトークン効率にどれくらい差が出るのかを確認しながら、従量課金時代のAI利用で気を付けたいポイントを整理していきます。

英語と比べて約1.5倍のコスト増となる「日本語税」とは

　前掲の図1を見ると、5モデル平均で日本語は英語比1.48xとなっています。つまり今回の条件では、同じ意図の入力文でも、日本語は英語より約1.5倍多くの入力トークンを消費したことになります。日本語でAIを使うだけで、英語より余分にトークンを支払っているように見えるため、こうした状況は日本語税（Japanese Tax）と呼ばれることもあります。

　ただし、日本語だけが突出してトークン効率が低いというわけではありません。中国語は平均1.01xで英語とほぼ同等でしたが、スペイン語は1.29x、フランス語は1.40x、韓国語は日本語と同じ1.48x、アラビア語は1.58x、ヒンディー語は1.69xでした。今回の比較では、日本語は英語や中国語より多くの入力トークンを消費する一方、アラビア語やヒンディー語ほど英語との差が大きいわけではありませんでした。

　なぜこのような差が生まれるのでしょうか。その鍵を握るのが、AIがテキストを数字の断片（＝トークン）に分解するトークナイザーという仕組みです。トークナイザーの設計はモデルによって異なりますが、今回の結果から見ると、英語・中国語・日本語ではおおむね次のような違いがあると考えられます。

英語： 英単語の多くが“ひとまとまり”として扱われるよう設計されており、少ないトークンで表現されやすい
中国語： 漢字1文字当たりの情報密度が高く、少ないトークンで意味を表しやすい傾向がある
日本語： 漢字、ひらがな、カタカナ、英数字、記号が混在するため、英語の単語のように“ひとまとまり”として扱われにくく、細かいトークンに分割されやすい

　なお、トークン効率が低いと、料金だけでなく、コンテキストウィンドウの消費にも影響します。日本語入力が英語比1.48倍のトークンを使うなら、単純計算では、同じコンテキストウィンドウで扱える情報量は英語の約68％（＝1÷1.48）にとどまります。そのため、チャットで長文を処理するような場面では、日本語はやや不利になりやすいと考えられます。ただし、AIコーディングではコードやログなど英数字中心の情報も多いため、通常の文章チャットほど大きな差にはならない可能性があります。

トークン効率対決： GPT-5.5 vs. Claude Opus 4.7

　今回の調査で特に興味深かったのは、2026年5月初旬時点におけるOpenAIの最新モデル「GPT-5.5」と、Anthropicの最新モデル「Claude Opus 4.7」を比べたとき、日本語のトークン効率に大きな差が出た点です（図2）。

図2　GPT-5.5とClaude Opus 4.7の直接対決は、日本語においてのみClaudeが圧倒
英語を1.00xとした入力トークン数の倍率です。数値が大きいほど、英語より多くの入力トークンを消費します。多くの言語ではClaude Opus 4.7の方が高く出ていますが、日本語ではGPT-5.5が1.73x、Claude Opus 4.7が1.39xとなり、GPT-5.5の方が多くの入力トークンを消費しています。

GPT-5.5：全体では効率的だが、日本語ではトークン数が増えやすい

　GPT-5.5の日本語は1.73xで、今回比較したモデルの中でも高い値になりました。一方で、GPT-5.5の多言語全体の平均は1.33xです。5モデル比較ではむしろ低い水準で、全体としてはトークン効率の良い部類に入ります。つまりGPT-5.5は、全体的に効率が悪いモデルではありません。むしろ、日本語だけが相対的にトークン数が増えやすいと見るのが自然です。

　さらに追加比較を見ると、GPT-5.4、GPT-5.5、GPT-4o miniの言語別比率はほぼ同じ値でした（図3）。具体的には日本語はいずれも1.73x前後で、中国語、韓国語、スペイン語、フランス語などもほぼ同じ傾向です。少なくとも今回の測定条件では、GPT系のトークン効率はモデル世代をまたいでも大きく変わっていないように見えます。これは結果を予測しやすいという意味では実務上の安心材料ですが、日本語については英語との差が残り続けており改善されていないともいえます。

図3　OpenAIのGPT系4モデルにおける言語別トークン効率の比較
英語を1.00xとした入力トークン数の倍率です。GPT-5.4、GPT-5.5、GPT-4o miniはほぼ同じ傾向で、日本語はいずれも1.73xとなっています。GPT OSS 120Bは全言語でやや低めですが、日本語では1.52xでした。

Claude Opus 4.7：新トークナイザーで、日本語の相対的な不利さが小さい

　Claude Opus 4.7の日本語は1.39xでした。GPT-5.5の1.73xと比べるとかなり低い値です。少なくとも今回の条件では、トークン効率の面でClaude Opus 4.7の方が日本語向きだといえるかもしれません。一方で、Claude Opus 4.7の多言語全体の平均は1.54xで、GPT-5.5の1.33xより高く出ています。全体ではGPT-5.5の方が効率的に見えるものの、日本語だけを見るとClaude Opus 4.7の方が有利に見える、という対照的な結果です。

　この差の背景として考えられるのが、Claude Opus 4.7で導入された新しいトークナイザーです。図4を見ると、従来のClaude系モデルでは日本語が英語比1.95x前後だったのに対し、Claude Opus 4.7では1.39xまで下がっています。少なくとも今回のベンチマーク条件では、Opus 4.7の新トークナイザーによって、英語に対する日本語の相対的な不利さがかなり小さくなったように見えます。

図4　AnthropicのClaude系4モデルにおける言語別トークン効率の比較
英語を1.00xとした入力トークン数の倍率です。Claude Haiku 4.5、Claude Sonnet 4.6、Claude Opus 4.6では日本語がいずれも1.95xですが、Claude Opus 4.7では1.39xとなっており、日本語の英語比が大きく下がっています。

　ただし、ここで見ているのは、各モデル内で英語を1.00xとした相対比です。つまり、Claude Opus 4.7の絶対的な入力トークン数が、従来モデルより必ず少なくなるという意味ではありません。AnthropicはOpus 4.7について、同じ入力でも従来モデルと比べてトークン数が約1.0～1.35倍になる場合があると説明しています。今回の結果は、あくまで「英語と比べたときの日本語の増え方」が小さくなった、という意味で捉えるのが正確です。

　実際に絶対トークン数で見ると、Claude Opus 4.6からOpus 4.7で日本語はほぼ横ばいであり、英語側のトークン数が大きく増えたことで、日本語の英語比が下がって見えている可能性が高いです。この点は、次の節であらためて確認します。

実際の入力トークン消費量の比較：英語比だけでは見えない意外な結果

　ここまで見てきたのは、各モデルの英語入力を1.00xとしたとき、他の言語が何倍の入力トークンになるかという比較でした。この見方は、「同じモデルの中で、日本語が英語よりどれくらい不利なのか」を見るには便利です。

　しかし、モデル選定ではもう一つ別の視点が必要です。それが、モデル間で見たときの実際の入力トークン消費量の大きさです。英語に対する日本語の倍率が小さくても、そもそもそのモデル全体の入力トークン数が多ければ、実際には多くのトークンを消費している可能性があります。

図5　主要モデルにおける入力トークン消費量の絶対比較（最小値を基準）
表全体で最も入力トークン数が少なかった組み合わせ（Kimi K2.6と中国語）を1.00xとし、各モデル・各言語の入力トークン数がその何倍になるかを示しています。英語を基準にした図ではなく、モデル間と言語間をまとめて、入力トークン消費量の大きさを比較するための図です。

　図5で特に目立つのはClaude Opus 4.7です。先ほどの図2の英語比では、Claude Opus 4.7の日本語は1.39xで、GPT-5.5の1.73xより低く見えていました。つまり、英語に対する日本語の増え方だけを見ると、Claude Opus 4.7は日本語向きに見えます。

　ところが、入力トークン消費量そのものに近い見方をすると、Claude Opus 4.7は平均2.62xで、かなり大きな値です。GPT-5.5とGPT-5.4は平均1.48x、Gemini 3.1 Proは1.36x、Qwen3.6 27Bは1.47xでした。つまりClaude Opus 4.7は、英語比で見た日本語の不利は小さいものの、入力全体では多くのトークンを消費する可能性があります。

　この違いは、Claude Opus 4.7の新トークナイザーによって、英語側のトークン数も大きく増えていることと関係していると考えられます。従って、モデル選定では「英語に対する日本語の倍率」だけでなく、「実際にどれだけ入力トークンを消費するか」も併せて見る必要があります。

　ただし、入力トークン数が多いからといって、そのまま料金が高いと断定することもできません。実際の費用は、モデルごとの単価、出力トークン、キャッシュ済みトークン、思考トークン、回答品質や再実行回数によって変わります。ここで見ているのは、あくまで入力側のトークン消費量であることには留意してください。

まとめ： AI利用のコスパは「トークン効率」も含めて考える

　今回のベンチマークでは、日本語入力は5モデル平均で英語比1.48xとなり、英語より約1.5倍多くの入力トークンを消費しました。日本語でAIを使う場合、トークン効率という面では英語より不利になりやすい、というのがまず大きな結果です。ただし、その差はモデルによって大きく変わり、英語比だけを見るか、実際の入力トークン消費量まで見るかによっても印象は変わります。

　今回の調査から、現場で使うときの判断軸（※2026年5月初旬時点）を整理すると、次のようになります。

日本語の長文を大量に扱うなら： Gemini 3.1 ProやQwenのように、今回の条件で入力トークン消費量が少なかったモデルを候補に入れる
日本語の不利を小さくしたいなら： Claude Opus 4.7のように、日本語の英語比が低く出るモデルに注目する。ただし、実際の入力トークン消費量は別途確認する（参照：「次の一歩」）
GPT系を使うなら： モデル世代をまたいでも傾向が一貫しているため、予測しやすい一方、日本語では英語比が高めに出やすい点を意識する
英語で無理なく書けるなら： 長いプロンプトや定型指示だけでも英語にすると、トークン効率の改善につながる可能性がある

　もちろん、トークン効率が良いモデルが、必ずしも業務に最適なモデルとは限りません。実際のAI利用では、回答品質、思考能力、コーディング性能、出力トークン数、モデル単価、キャッシュの有無、再実行回数なども関係します。それでも、従量課金や利用上限を意識する場面が増えるほど、「どのモデルが賢いか」だけでなく、「どのモデルがどれだけのトークンを使うか」を見ることは重要になっていくでしょう。

　Deep Insider編集長の一色です。こんにちは。

　今回の調査で個人的に意外だったのは、日本語が「最悪」というわけではなかったことです。日本語は英語より不利ですが、図1を見る限り、韓国語と同程度で、アラビア語やヒンディー語よりは低く出ています。一方で、英語と中国語がかなり少ない入力トークンで済んでいることを考えると、やはり日本語ユーザーには一定の不利さがあると感じました。

　とはいえ、だからといって全てを英語で書けばよい、という話でもありません。無理に英語で書いた結果、意図がずれたり、説明が不足したりすれば、かえって再実行が増えてしまいます。日本語で正確に考え、日本語で伝える価値は依然として大きいはずです。その上で、長いプロンプトや定型指示、AIエージェント用のルール文などは、必要に応じて英語に圧縮する。そうした使い分けが現実的な落としどころになるのではないでしょうか。

　モデルごとの差も印象的でした。AnthropicはClaude Opus 4.7でトークナイザーを刷新したおかげで、日本語と英語の差がかなり小さくなったように見えました。一方で、実際の入力トークン消費量まで見ると、必ずしも単純に「Claudeが軽い」とは言えません。図5を見る限り、Gemini 3.1 ProやQwenのように、今回の条件では入力トークン消費量が少なく見えるモデルもあります。日本語の長文を扱う場面では、こうしたモデルも候補に入れるとよいでしょう。

　今後は、AIツールの料金体系がサブスクリプション中心から、より使用量を意識する形へ進んでいく可能性があります。そうなると、「どのモデルが賢いか」だけでなく、「どのモデルで、どの言語で、どれだけトークンを使うか」も実務上の判断材料になっていくはずです。だからこそ、その判断を一般論だけで済ませず、自分の用途に合わせて確かめていく姿勢が大切だと思います。

　今回の結果は、あくまで2026年5月初旬時点で、私が用意したサンプルと環境で測定したものです。モデルの仕様や料金体系は今後も変わり続ける可能性が高いため、次節の「次の一歩」で紹介する方法を使って、自分が使いたい候補モデルでも調査してみてください。

次の一歩：自分の候補モデルで「最新のトークン効率」を調べてみよう

　本稿で使用したベンチマークツールは、GitHubでオープンソースとして公開しています。

lang-token-benchリポジトリ

　興味がある方は、Claude CodeやOpenAI CodexなどのAIコーディングツールを使って、自分が使いたい候補モデルでも同様の調査を試してみてください。なお、このツールはPythonプロジェクトで、パッケージ管理と実行にはuvを使います。実行前にuvをインストールしておく必要があります（参考記事）。

　測定は主にOpenRouter経由でモデルを呼び出し、OpenRouterが返すobserved usageのprompt tokens（入力プロンプト側のトークン数）を記録する方式です。そのため、OpenRouterのアカウント、APIキー、必要に応じたクレジットが必要になります。実行すると費用が発生する可能性があるため、最初は必ず--dry-runオプションで対象モデルや実行件数を確認し、問題がないことを確認してから--yesオプションを付けて実行してください。APIキーは.envファイルに設定できますが、AIコーディングツールに.envの中身を読ませたり、表示させたりしないよう注意してください。※いずれの注意点もプロンプトに含めています。

　それでは以下のプロンプトを入力して始めましょう。

以下のGitHubリポジトリを使って、多言語トークン効率ベンチマークを実行してください。

https://github.com/isshiki/lang-token-bench

作業用フォルダーを作成し、リポジトリをクローンしてください。
README.mdとAGENTS.mdを確認し、プロジェクトの実行手順と安全ルールに従ってください。

今回比較したい対象モデルは以下です。OpenRouterのmodel_idとして扱ってください。

- openai/gpt-5.5
- anthropic/claude-opus-4.7
- google/gemini-3.1-pro-preview
- qwen/qwen3.6-27b
- moonshotai/kimi-k2.6

これらのモデルを対象にしたbenchmark suiteを使ってください。
既存のconfigs/benchmark_suites.yamlに該当suiteがある場合はそれを使い、ない場合は次のようなsuiteを追加してください。

suite名:
public_comparison_2026_05

model_ids:
- openai/gpt-5.5
- anthropic/claude-opus-4.7
- google/gemini-3.1-pro-preview
- qwen/qwen3.6-27b
- moonshotai/kimi-k2.6

重要:
- .envファイルの中身は読まない、表示しない、編集しない、コミットしないでください。
- APIキーの値は絶対に出力しないでください。
- OpenRouter APIキーは私が用意します。
- 実際のAPIリクエストを送る前に、必ずdry-runの結果を確認してください。
- Chat Completions APIを実行する場合は、私の確認後に--yesオプションを付けて実行してください。

まず依存関係をインストールしてください。

uv sync --extra openrouter --extra viz

必要に応じて、私にOPENROUTER_API_KEYの設定を依頼してください。
.envはアプリケーション実行時に読み込まれますが、あなたは.envの中身を直接確認しないでください。

最初に小さく確認してください。

uv run lang-token-bench openrouter validate-models --suite public_comparison_2026_05
uv run lang-token-bench run-suite --suite public_comparison_2026_05 --dry-run

dry-runの内容を日本語で説明し、実行予定モデル、言語、サンプル数、推定実行行数を確認してください。
問題がなければ、私の許可を得てから実際のAPIを実行してください。

uv run lang-token-bench run-suite --suite public_comparison_2026_05 --yes

実行後、以下を実行してください。

uv run lang-token-bench summarize --suite public_comparison_2026_05
uv run lang-token-bench plot --suite public_comparison_2026_05

生成されたCSV、Markdown、グラフを確認し、以下を分けて日本語で要約してください。

1. 各モデル内で、英語を1.00xとしたときの日本語の倍率
- 主にsummary_ratio_by_language_modelを見る
- これは「同じモデル内で、英語入力と比べて日本語入力が何倍のトークンになるか」として説明する

2. モデル間で比較したときの、実際の入力トークン消費量
- 主にsummary_token_count_by_language_modelとheatmap_relative_token_count_by_language_modelを見る
- これは「同じ内容を入力したとき、どのモデルがより多くの入力トークンを使うか」として説明する

最後に、日本語で使う場合に候補になりそうなモデルと、注意すべき点を整理してください。

注意:
- ratio_to_englishはモデル内の英語基準の倍率です。
- relative_token_countは表全体の最小入力トークン数を1.00xとした相対消費量です。
- この2つは意味が違うため、混同しないでください。