(同じ AI 倫理の論文、英語版と日本語版 を Claude に要約させただけなのに、消費トークン数が全然違う…。英語 4,800字 = 約 1,200 トークン、日本語 4,800字 = 約 3,100 トークン。同じ内容で 約2.5倍 食ってる。)
(うちの 業務AIコスト見積もり、英語前提で組まれてる気がする。日本語クライアント案件で全部使ったら API 月額が想定の2.5倍 になる可能性ある。…これは月曜の朝会で言うべきだ。ホワイトボードに数字を全部書いて、凡田さんに見せよう。)
あ、川口、まだいるの?…これ、ホワイトボード何の数字?「英 1,200 / 日 3,100 / 比率 2.58」…えっ 日本語って英語の2.5倍トークン食う の?
はい、自主研究で気づきました。原因は トークナイザー という、文章を LLM の 「ひと噛み」 に切る前処理装置です。英語は 単語1つ ≒ 1トークン で済むのに、日本語は ひらがな1文字 ≒ 1トークン、漢字 1文字 ≒ 1〜2トークン。同じ意味の情報量でもトークン数が膨らむ んです。…これクライアント案件のコスト見積もりに直結するので、明朝の朝会で共有しようと思って整理してました。
- ひとことで言うと、LLM が文章を読む前に、文を 「ひと噛み」 サイズの細切れに刻む下ごしらえ装置。AI は文字をそのまま読まず、必ずこの刻んだ単位(トークン)で処理する。イメージは料理の下ごしらえ — 食材を一口大に刻んでから調理に回す。
- 刻み方の基本は 「よく出る言葉は1個のまま、珍しい言葉は部品に分けて」。そして この刻み方が API 料金とコンテキスト枠の消費を直接決める(課金はトークン単位。刻むアルゴリズム=BPE 等の中身は本文で)。
- 実務の落とし穴: 日本語は英語の約 2〜3倍トークンを食う。同じ意味の文章でも、API コストもコンテキストの消費も 2〜3倍に膨らむ — 見積もりで一番やられる所。
LLM はテキストを直接読まない。必ず トークナイザー という前処理装置を通って、文章は整数 ID の並び(=トークン列)に変換される。プロンプト (#043) も、コンテキスト枠 (#042) の食い方も、この装置の挙動に支配される。
本記事の核心: 「同じ意味の文章でも、言語によってトークン消費量が大きく異なる」。日本語は英語の約2-3倍。これを知らずに業務 AI のコスト見積もりをすると、本番運用で2-3倍の請求書が来る。
定義 — テキストを 「整数 ID の並び」 に変換する前処理装置
トークナイザーの仕事は2段階:
- 分割: 入力テキストを 「トークン」 という単位に切る(例: 「I love AI」 → [「I」, 「 love」, 「 AI」])
- ID 変換: 各トークンを、あらかじめ決められた 語彙表 上の整数 ID に変換する(例: [「I」, 「 love」, 「 AI」] → [40, 1842, 16124])
LLM 本体は、この 整数 ID の並び しか見ない。テキストの 「文字」 を直接扱うわけではなく、整数のシーケンスとして処理する。「これがトークン数1個」 と 「ひと噛み」 単位 (#003) が決まる場所がここ。
逆方向(LLM の出力を読める日本語に戻す)も同じ装置がやる: 整数 ID → トークン文字列 → 連結。これを デコード と呼ぶ。
仕組み — サブワード分割(BPE)で語彙サイズを抑える
素朴な発想だと、トークナイザーは「単語ごとに切る」のが直感的(英語: スペース区切り、日本語: 形態素解析)。だが現実の LLM はこの方法を採用していない。理由は 語彙爆発: 世界の単語数(固有名詞・新語・スペル違いを含めると数千万)を全部 ID で持つと、語彙表が巨大すぎて学習も推論も非効率になる。
そこで主流になったのが サブワード分割(代表的アルゴリズム = BPE: Byte Pair Encoding)。考え方はシンプル:
- 大量の学習データを見て、よく出てくる文字列ペア を統計的に見つける
- 頻出ペアは そのまま1トークン(例: 英語 「the」 は1トークン、「unprecedented」 は 「un」 + 「preced」 + 「ented」 の3トークンに分割)
- 結果的に、よく出る単語は1トークン、珍しい単語は複数トークンに分かれる という効率的な語彙表ができる
主要 LLM の語彙サイズ:
| モデル | トークナイザー名 | 語彙サイズ | 特徴 |
|---|---|---|---|
| GPT-3.5 / GPT-4 | cl100k_base | 約 10万 | 多言語対応、日本語は弱め |
| GPT-4o / GPT-5 | o200k_base | 約 20万 | 日本語含む多言語効率を大幅改善 |
| Claude(現行) | 独自(Anthropic) | 非公開 | 多言語対応、日本語は比較的効率 |
| Llama 3 | tiktoken-based | 約 12.8万 | OSS、多言語拡張済み |
| Gemini | SentencePiece 系 | 約 25.6万 | 多言語特化、日本語効率良好 |
語彙サイズが大きいほど、1トークンに詰め込める情報量が増える(=同じ文章を少ないトークンで表現できる)。一方で、語彙表自体のメモリやモデル末尾の出力層が肥大化する、というトレードオフがある。GPT-4o の o200k_base は、日本語効率を改善するために語彙サイズを倍増させた典型例。
日本語が英語より2-3倍割高な理由 — 漢字とひらがなの 「拾われ方」
本記事の核心: 「なぜ日本語のほうがトークン数が膨らむのか」。本質は、トークナイザーは英語コーパス中心で学習されている 場合が多いから。英語の語彙は手厚く、日本語は薄い。
具体的に、川口が実測した数字:
| 言語 | 文字数 | トークン数 | 1トークンあたりの文字数 |
|---|---|---|---|
| 英語(AI論文 一節) | 約 4,800字 | 約 1,200 トークン | 約 4.0 字/トークン |
| 日本語(同じ内容の翻訳) | 約 4,800字 | 約 3,100 トークン | 約 1.5 字/トークン |
| → 同じ意味の文章で、日本語は英語の 約 2.58倍 のトークンを消費 | |||
原因を分解すると:
- 英語: BPE 学習で頻出単語(the, of, and, is, …)が1トークンに圧縮される。「unprecedented」 のような難語でも3-4トークン程度。1単語 ≒ 1.3トークン が平均
- 日本語のひらがな: 文字種が少ないので各文字がほぼ独立した1トークン。「こんにちは」 は5トークン
- 日本語の漢字: 文字種が膨大(常用漢字だけで2,136字)、稀少な漢字は UTF-8 のバイト列に分解 されて 1文字 = 2〜3トークン に膨らむ。「龍」 や 「鬱」 などは2-3トークン
- カタカナ語: ひらがなと同程度の効率
結果として、同じ情報量を伝えるのに日本語は 2-3 倍のトークンを使う。GPT-4o の o200k_base や Gemini SentencePiece は 日本語の頻出単語(「こんにちは」「ありがとう」「東京」「政府」等)を1トークン化 する改良を入れていて、これだけで実測 1.3-1.5 倍まで圧縮できる。モデル選択でコストが大きく変わる。
コンサル感覚 — クライアント案件で見落とすと痛い3点
本記事の核心メッセージは 「トークナイザーの挙動は API コストとコンテキスト枠の食い方を直接決める。日本語業務AIでは英語前提の見積もりは2-3倍ズレる」。実務での3つの注意点:
① コスト見積もりは 「日本語実測」 で出す: API は トークン課金(入力トークン × 単価 + 出力トークン × 単価)。日本語クライアント案件で「英語のドキュメント体系で見積もったら本番で2.5倍の請求」、よくある事故。OpenAI Tokenizer / Anthropic の Token Counting API / tiktoken ライブラリ で日本語実測を取ってから見積もる。
② コンテキスト枠 (#042) の食い方も2-3倍: Claude 200K のコンテキスト枠も、日本語だと実質 約 8万字(文庫本0.6冊分)。英語だと 200K = 文庫本1.5冊分。「日本語の長文を投げると Claude でも詰まる」 場面が出る、設計で考慮が必要。
③ モデル選択がコストを大きく動かす: 同じ Anthropic でも、Claude Haiku 4.5 と Opus 4.7 ではトークン単価が10倍以上違う。長文日本語処理が多いなら、日本語効率の高いモデル(GPT-4o の o200k / Gemini SentencePiece / Claude 最新版)を選ぶだけで、月額の体感コストが半減 することがある。クライアント提案では 「どのモデル × どの言語 × どんなトークン数」 の表を必ず出すのがプロの作法。
昨夜の自主研究結果です。日本語 API コストは英語前提の約2.5倍、つまり今動いてるクライアント3社の案件は、本番で 請求が見積もりの2-3倍 になるリスクがあります。即時、見積もり再計算を提案します。
えっ、深夜にホワイトボードでそんな計算してたの…。川口、ちゃんと帰ってる?働き方改革 の文脈で部長として叱るべきところだけど、内容が部長会の議題にできるレベルでヤバい。…これ パワポ にして部長会で共有 するから、図表だけ昼までに作って。
あら、私の 銀座カフェ巡り Instagram の英語キャプションを Claude に翻訳させてもらってますけど、日本語に変換するときだけ妙に時間がかかる と思ってましたの。これそういう理由でしたのね。今度から 英語キャプションだけ生成 してもらって、日本語は自分で書きます。コスト圧縮ですわよ、ホホ。
フッ、私が 推し配信のスパチャ文面 を毎週練り上げる時に、最近 日本語より英語の方がスパチャの上限文字数枠に多く詰め込める 違和感はあったんだが、こういう仕組みだったか。…とはいえ私の推しは 日本語の繊細なニュアンス でなければ伝わらないので、コスト効率を諦めて日本語を選ぶ。これは 「愛のトレードオフ」 だ。
(御託さんが 「愛のトレードオフ」 で締めた…まあ、いい。川口の自主研究で 3案件の見積もり再計算 という現場のヤバさが出てきたのは、今期 一番のお手柄かもしれない。)
読者の疑問 — なぜ AI は 「意味は分かるけど聞いたことない造語」 を生成できるのか?
「トークン辞書は固定なのに、AI はどうやって新語を作るのか?」「PMF力」「現場知集約度」のような 聞いたことはないが意味は通る単語 が出てくる現象、これはトークナイザーだけでは説明できない。表層(サブワード組み合わせ)+ 深層(意味ベクトル演算)の2層構造 で起きている。
表層 — サブワードの組み合わせで未知の文字列が出る
本記事で見た通り、トークン辞書は単語そのものではなく サブワード(部分文字列)の集合。「PMF力」も分割すると [「PMF」, 「力」] のような既知サブワードの並び。個々のパーツは辞書にあるが、その並び順は辞書にない ので、結果として 「新語」 が表面化する。
これだけでも造語生成は説明できる。ただし「なぜ意味が通る組み合わせばかり出てくるのか?」までは答えられない。
深層 — 意味ベクトル空間で 「新しい場所」 を指している
本質はこちら。各トークンは 意味ベクトル(埋め込み(#002))を持っていて、LLM 内部ではトークン同士のベクトルを 足し算・引き算 しながら次のトークンを決めている。古典的に有名な例:
「王」 − 「男性」 + 「女性」 ≒ 「女王」(word2vec の演算)
LLM 内部でも同じ仕組み。「PMF(プロダクトマーケットフィット)」の意味ベクトル + 「能力 / 度合い / 強さ」の方向ベクトル → ベクトル空間に 新しい 「場所」 が計算される。この場所に 既存の単語が割り当てられていない 場合、最も近いサブワードの組み合わせ(=「PMF」+「力」)で出力される。
「意味は分かるけど聞いたことない」の正体
- 意味ベクトル空間では明確な場所を指している(=意味が成立)
- でも語彙表にその場所を直接指す単語が登録されていない(=造語になる)
- 最近傍のサブワード組み合わせで出力 される(=「PMF力」「現場知集約度」のような形)
逆に「ぴゃーらん」のような 意味のない適当な造語 が出にくいのは、意味ベクトル空間にそういう 「場所」 が存在しないから。LLM は 座標(=意味)を持って動いている ので、結果として 意味的に意味のある未知単語 を吐く傾向が出る。デタラメより 「それっぽい造語」 の方が確率的に有利、というのが内部の力学。
コンサル感覚: クライアントから「うちの AI、たまに変な造語出すんだけど大丈夫?」と相談されたら、「意味的には根拠のある造語、サブワード辞書の限界とベクトル空間の自由度のギャップから出る現象」 と説明できる。完全に止めることは構造上できないが、温度を下げるかプロンプトで「既存の用語のみ使ってください」と制約をかけることで頻度は減らせる。
応用 — Tokenizer 実測ツールと多言語LLMの設計
本記事の余談として、実務的なツールと設計トピック:
- OpenAI Tokenizer(
platform.openai.com/tokenizer): ブラウザでテキストを貼ると即トークン分割が見える、最速の実測ツール。 - tiktoken(OpenAI 公式 Python ライブラリ): API 呼ぶ前にコストを計算できる、業務スクリプトで必須。
- Anthropic Token Counting API: Claude 用、SDK で
messages.count_tokens()が使える。 - 多言語 LLM の設計: GPT-4o の o200k_base や Gemini の SentencePiece は 日本語/中国語/韓国語の頻出語彙を意図的に1トークン化 して効率改善。「マルチリンガル LLM の真の差別化はトークナイザー設計」と言われる所以。
- 専用語彙の追加: 業務 AI で社内専門用語(製品名、社内略語)が頻出する場合、ファインチューニング (#027) 時に 専用トークンを追加 する設計もある(コスト削減 + 精度向上)。
コンサル感覚: クライアントから「日本語業務 AI が思ったよりコスト高い」と相談されたら、最初に確認すべきは 「使ってるモデルのトークナイザーは何か?」。GPT-3.5 (cl100k) → GPT-4o (o200k) に乗り換えるだけで日本語コストが 2-3割削減 されるケースもある。