「日本語は英語より token 効率がよい」——ネット上で広く流布されている主張です。直感的にも筋が通ります——漢字は情報密度が高く、1文字で英語数文字分の意味を担う。だからトークナイザーも日本語を優遇してくれるはず、という発想。
この直感はどれくらい正しいのか？OpenAI 公式の tiktoken ライブラリで6種類のタスク（短い指示、ビジネス文、翻訳、企画書、コード注釈、クリエイティブコピー）を実測しました。結果は——
同じ意味内容を日本語で書くと、現代 LLM 上で英語より 1.3〜2.2倍のトークンを消費します。中国語も 1.1〜1.6倍多く消費します。
この記事では、完全な実測データ、各ベンダーのトークナイザー挙動、直感が外れる理由、実務上の指針を一気に整理します。
🏆 要点まとめ
🔤 同じ意味を書くとき、どの言語がトークンを多く消費するか？（o200k_base / GPT-4o・GPT-5 実測中央値）
順位 言語 英語比 🥇 英語 1.0倍（基準） 🥈 中国語 1.34倍 🥉 日本語 1.73倍 4 韓国語 ~2.0倍 一言でまとめると：CJK は必ず英語より多くトークンを消費します——中国語で約30%増、日本語で約70%増。トークン数は API 請求額に直結します。プロンプトキャッシュや Batch API は絶対金額を圧縮できますが、この順位を覆すことはできません。日本語コストを本気で削るなら、各ベンダー tokenizer 比較表 をご覧ください——ただし日本語の場合、各ベンダー間の差は小さく、中国語ほど劇的な選択肢はありません。
5つの実測結論
- CJK は英語より token を消費する——現代 o200k_base（GPT-4o / GPT-5）：中国語 1.1〜1.6倍、日本語 1.3〜2.2倍。旧 cl100k_base（GPT-4 / Claude 3）：中国語 1.6〜2.5倍、日本語 1.7〜2.9倍
- タスク種別で差が大きい——短い指示はほぼ同等、長いビジネス文章や企画書では 1.5〜2.2倍
- トークナイザー世代差は本物——o200k_base は cl100k_base より CJK ペナルティを約 40% 削減
- 日本語は一貫して中国語より悪い——平仮名・片仮名が平均を押し下げる
- 唯一英語並みになるのは DeepSeek / Qwen——中国語特化の最適化で ~1.0倍を達成（ただし日本語はそこまで改善せず）
🔍 なぜ「CJK はトークンを節約する」という直感が生まれるのか
実測で覆される前に、その直感がもっともらしく聞こえる理由を3つ整理しましょう。
CJK が効率的に見える3つの手がかり
1. 漢字の情報密度は確かに高い
「学」一文字で、英語の “learn” / “study” / “scholarship” など複数の意味の土台を担います。1文字あたりの情報密度は表音文字より確かに大きい——直感的に「トークナイザーも日本語を優遇してくれるはず」となります。
2. 文字数は確かに少ない
同じ記事でも日本語版の文字数は英語版の 35〜55% 程度。見た目の長さで比較すると、日本語は「ずっと短く」見える——ここから「トークン数も少ないはず」と飛躍するのは自然な流れです。
3. 短い例の選び方次第で日本語が勝つこともある
適当に1〜2個の例を選んで計測すると、例えば：
EN: "Summarize this article in bullets" (6 tokens)
JA: 「箇条書きで要約してください」(7 tokens)のように接戦になり、たまたま条件次第で日本語が勝つこともある——そしてこの話が広まります。
なぜこの直感が崩れるのか
問題は実際のトークナイザーの挙動と直感的な情報密度が噛み合っていない点にあります：
-
漢字の情報密度はトークン数に反映されない。トークナイザーは漢字のほとんどを独立した1トークンとして切ります。1文字あたりの意味密度は「同じコンテキストスロットに多くの意味が収まる」に寄与しますが、「少ないトークンで済む」には寄与しません——コンテキストウィンドウには効いても、API 請求額には効かないのです。
-
文字数 ≠ トークン数。英語の “learn” は5文字ですが通常1トークン（トークナイザーが一般的な単語として結合）。日本語の「学」は1文字で1トークン——英語のトークナイザーの圧縮率が日本語よりはるかに高い。
-
短い例は大規模平均値の代表にはならない。1〜2例はトークナイザーの特定フレーズ最適化に当たる可能性があります。タスク横断の平均が真の姿を示します。
実証：200万文の大規模研究
研究者が 200万文のプロ翻訳データで英語と各言語のトークン比率を計測：
| 言語（英語基準） | 平均トークン倍率 |
|---|---|
| 英語 | 1.0倍（基準） |
| 中国語（標準中国語） | 1.76倍 |
| 広東語 | 2.10倍 |
| 日本語 | 2.12倍 |
| 韓国語 | 2.36倍 |
CJK は全部英語より token を食う。例外なし。
🧪 6タスク実測：tiktoken で測った真の数字
以下はすべて OpenAI 公式 tiktoken ライブラリでの実測値。現代モデルが実際に使用している2つのトークナイザーを対象としています：
- cl100k_base：GPT-4、Claude 3 系、初期 GPT-3.5
- o200k_base：GPT-4o、GPT-5 系、最新 OpenAI メインライン
Task 1：短い指示プロンプト
EN: "Summarize this article and list the top 5 key takeaways in bullet points."
ZH: 「摘要這篇文章，並以條列式列出前 5 個重點。」
JA: 「この記事を要約し、重要なポイントを5つ箇条書きで挙げてください。」| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 18 | 29 | 31 | 1.61倍 | 1.72倍 |
| o200k_base | 18 | 19 | 24 | 1.06倍 | 1.33倍 |
短い指示は CJK に最も優しいケース——o200k でもほぼ同等。
Task 2：ビジネス文章の段落
LLM が企業のテキスト処理をどう変えているかを論じた5文の段落。
| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 69 | 174 | 202 | 2.52倍 | 2.93倍 |
| o200k_base | 69 | 107 | 150 | 1.55倍 | 2.17倍 |
最悪ケース——長いビジネス文章を cl100k_base で処理すると日本語は約3倍に膨れ上がります。
Task 3：翻訳タスク（業績報告）
| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 56 | 120 | 139 | 2.14倍 | 2.48倍 |
| o200k_base | 56 | 79 | 101 | 1.41倍 | 1.80倍 |
Task 4：プロジェクト企画書
| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 90 | 177 | 197 | 1.97倍 | 2.19倍 |
| o200k_base | 89 | 119 | 145 | 1.34倍 | 1.63倍 |
Task 5：コード注釈
| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 22 | 46 | 54 | 2.09倍 | 2.45倍 |
| o200k_base | 22 | 29 | 41 | 1.32倍 | 1.86倍 |
Task 6：クリエイティブコピー
| Tokenizer | EN | ZH | JA | ZH/EN | JA/EN |
|---|---|---|---|---|---|
| cl100k_base | 46 | 99 | 100 | 2.15倍 | 2.17倍 |
| o200k_base | 44 | 60 | 70 | 1.36倍 | 1.59倍 |
📊 全タスク総括
| 指標 | cl100k_base 中 | cl100k_base 日 | o200k_base 中 | o200k_base 日 |
|---|---|---|---|---|
| 最小倍率 | 1.61倍 | 1.72倍 | 1.06倍 | 1.33倍 |
| 最大倍率 | 2.52倍 | 2.93倍 | 1.55倍 | 2.17倍 |
| 平均 | 2.08倍 | 2.32倍 | 1.34倍 | 1.73倍 |
覚えておくべき目安：
- GPT-4 / Claude 3 では：中国語 ≈ 2倍、日本語 ≈ 2.3倍
- GPT-4o / GPT-5 では：中国語 ≈ 1.3倍、日本語 ≈ 1.7倍
🧮 計測の詳細：日本語は文字数が少ないのにトークンが多い
最も直感に反する部分——Task 2 と Task 4 の実測で裏付けます：
| タスク | 英語文字数 | 日本語文字数 | 文字比 | o200k トークン比 |
|---|---|---|---|---|
| Task 2 ビジネス | 371 | 193 | 0.52倍 | 2.17倍 |
| Task 4 企画書 | 342 | 195 | 0.57倍 | 1.63倍 |
日本語は文字数が英語の約半分なのに、トークン数は 1.6〜2.2倍。そのメカニズム：
英語のトークナイザーは一般単語を結合する。“the”、“of”、“transformation”、“enterprise” は各々 1〜2 トークンで済みます（文字数が多くても）。英語の平均文字/トークン（CPT）は約 5.4。
日本語のトークナイザーはほとんど結合しない。漢字や仮名は基本的に1文字1トークン、稀な漢字は 2 バイト断片に切られることも。日本語の平均 CPT は約 0.9〜1.0。
この 約 5 倍の圧縮率差が「日本語は文字数が少ない」という優位を打ち消し、最終的にトークン数が多くなります。
等価でない翻訳の落とし穴に注意
ネット上で流れる「日本語はトークン節約」の例はしばしば翻訳の等価性を欠きます：
EN: "Summarize the following article and extract the top 5 key points in bullet format" (15トークン)
JA: 「以下の記事を要約し、上位5つの要点を箇条書きで抽出してください」(11トークン)一見日本語が 27% 節約に見えますが、英語版には「in bullet format」があり、日本語版は「抽出してください」と簡潔に書かれています——トークナイザー効率ではなく翻訳スタイルの差です。本記事の各 Task は公正な比較のため、意味論的に可能な限り等価な翻訳を使っています。
📈 トークナイザー世代差：o200k_base は本物の進歩
cl100k_base から o200k_base への移行で、OpenAI は CJK ペナルティを約 40% 削減しました：
| 言語 | cl100k 平均 | o200k 平均 | 改善幅 |
|---|---|---|---|
| 英語 | 1.00倍 | 1.00倍 | — |
| 中国語 | 2.08倍 | 1.34倍 | -36% |
| 日本語 | 2.32倍 | 1.73倍 | -25% |
⚠️ 逆行事例：Claude Opus 4.7 2026/4/16 リリースの Claude Opus 4.7 は新しいトークナイザーを採用。Anthropic 公式発表によれば CJK のトークン消費は前世代より 15〜35% 増加。トークナイザーの更新が常に改善方向とは限らない——「新しい＝ CJK にやさしい」と仮定してはいけません。
🆚 ベンダー別トークナイザー比較表（2026/4 月）
CJK の非効率は共通問題ですが、ベンダー間の差はなお大きい。実測中央値：
指標についての注意
この表は文字/トークン（CPT）——同じ言語内でのベンダー比較（どのベンダーが自言語に優しいか）に使います。上記の倍率表は同じ意味内容の言語間トークン比（どの言語が同じ内容で高コストか）。両方とも有効ですが測定対象が違うので混同しないこと。
| Tokenizer | 英語 CPT | 中国語 CPT | 日本語 CPT | 中国語順位 |
|---|---|---|---|---|
| DeepSeek V3 / V4 | ~5.0 | ~1.1〜1.2 | ~0.9 | 🥇 中国語最優 |
| Qwen シリーズ | ~4.8 | ~1.1〜1.3 | ~0.9 | 🥇 中国語最優 |
| GPT-4o / o200k_base | ~5.4 | ~1.0〜1.3 | ~0.9〜1.3 | 🥈 |
| Gemini 3.x | ~5.5 | ~1.0 | ~0.82 | 🥉 |
| Llama 3 系 | ~5.3 | ~1.0 | ~0.8 | 🥉 |
| Claude Opus 4.6 | ~5.5 | ~1.0〜1.1 | ~0.9 | 🥉 |
| GPT-4 / cl100k_base | ~5.4 | ~0.7〜0.8 | ~0.9〜1.0 | ❌ 中国語最低 |
| Claude Opus 4.7 | ~5.5 | ~0.75〜0.9 | ~0.7〜0.8 | ❌ 中国語最低 |
注目ポイント：
- 🇯🇵 日本語 CPT：どのベンダーも 0.7〜1.3 の範囲内で、特別優れたものはない
- 🇨🇳 中国語 CPT：DeepSeek / Qwen のみ CPT > 1.0（漢字1文字 < 1トークン）を達成、他はすべて1対1以下
- 🇺🇸 英語 CPT：全ベンダーが 4.8〜5.5 に収束
日本語ユーザーへの重要な示唆：日本語 tokenizer の最適化は現在どのメジャーベンダーも取り組んでおらず、各社の日本語効率差は小さい——日本語中心アプリでは、tokenizer 効率ではなく品質・エコシステム適合度・価格で選ぶべき。
🎯 CJK が依然として優位な3つの側面
トークンを多く消費することは事実ですが、「CJK で AI を使うと損」という結論にはなりません。正当な3つの優位性：
1. コンテキストウィンドウに多くの「意味」が入る
同じ意味のトークン数は多いものの、文字数は少ない——コンテキストウィンドウにまるごと書籍や契約書を詰め込む場合、日本語版が占める文字空間は小さい。トークン数がやや多くても、コンテキスト制限内に収まる情報量は英語版と同等以上になり得ます。
例：Claude Opus 4.7 の 1M トークンコンテキスト
| 言語 | トークンあたり文字数 | 1M トークンで収まる文字数 |
|---|---|---|
| 英語 | ~5.4 | ~540万文字 |
| 日本語 | ~0.9 | ~90万文字 |
90万文字の日本語 ≈ 標準的な新書3〜4冊分。情報量ベースでは、540万文字の英語版と同等の「意味」が入っている可能性があります。
2. 短い指示ではほぼ同等
Task 1 が示すように、短い指示プロンプト（<25 トークン）では日本語は 33% 増のみ——短い対話が中心のアプリ（カスタマーサポート、検索、シンプルなツール呼び出し）では CJK のコスト不利は軽微。
3. 特定用途では中国語特化モデルが逆転
DeepSeek V4 の中国語 CPT は 1.1〜1.2——すでに英語の密度に近い。加えて西洋モデルの 1/10〜1/50 の価格帯なので、中国語アプリでは GPT-4o より総コストが低くなる場合がある。
ただし日本語ではこの逆転は起きません——DeepSeek / Qwen は日本語を特別最適化していないため、日本語効率は他モデルと同等かわずかに劣る程度です。
💰 実際のコスト差：月額試算
シナリオ：日本語カスタマーサポートアプリ、月間100万会話、1会話あたり入力200文字・出力150文字（日本語）。
| モデル | 入力トークン（1会話） | 出力トークン（1会話） | 月間総トークン | 単価（$/M in / out） | 月額 |
|---|---|---|---|---|---|
| GPT-4o | ~330 | ~250 | 3.3B in / 2.5B out | $2.5 / $10 | $33,250 |
| Claude Opus 4.7 | ~360 | ~280 | 3.6B in / 2.8B out | $5 / $25 | $88,000 |
| DeepSeek V4 | ~270 | ~210 | 2.7B in / 2.1B out | $0.28 / $0.42 | $1,638 |
| Qwen-Max | ~270 | ~210 | 2.7B in / 2.1B out | ~$0.5 / $2 | $4,050 |
同じ日本語ワークロードで、DeepSeek は Claude Opus 4.7 の約 1/54 のコスト（品質は同等ではないので参考値）——「tokenizer 効率 × 単価」の組み合わせ効果の大きさを示す例。
🧠 賢そうに見える失敗パターン：「往復翻訳」戦略
英語がトークン効率よいと知ると、誰もが思いつく戦略があります：
「AI に日本語プロンプトを英語に翻訳させ → 英語で実行 → 出力を日本語に翻訳し戻す」
一見賢い。実測するとほぼ必ず高くつきます。 理由：翻訳を2回払い、その翻訳自体もトークンで課金されるため。
試算：長文書の分析
50,000 文字の日本語レポートを分析する場合：
| ステップ | 日本語ネイティブフロー | 英語ブリッジフロー |
|---|---|---|
| 1. 文書読み込み | 85K 日本語トークン | 85K 入力 → 57K 英訳出力 = 142K |
| 2. 分析実行 | 85K 入力 + 8.5K 出力 = 93.5K | 57K 入力 + 5.7K 出力 = 62.7K |
| 3. 出力翻訳戻し | — | 5.7K 英語 + 7.5K 日本語出力 = 13.2K |
| 合計 | 93.5K | 217.9K |
英語ブリッジは 2.3 倍のトークンを消費——完全な逆効果。
試算：短い意図 + 中程度の出力（コード生成）
「React の todo アプリを作って」のような短意図・長出力：
| ステップ | 日本語ネイティブ | 英語ブリッジ（英語で直接書く） |
|---|---|---|
| 1. プロンプト | 130 トークン | 75 トークン |
| 2. 実行 + 思考 | 35K | 25K |
| 3. 出力 | すでに日本語 | 解説を日本語に翻訳：3K |
| 合計 | 35K | 28K |
約 20% の節約——ただし英語でプロンプトを直接書いて、最初の翻訳ステップを飛ばす場合に限る。
この戦略が本当に節約になる3条件（すべて必要）
- ✅ プロンプトが短い、または英語で直接書く（最初の翻訳を飛ばす）
- ✅ 中間実行が重い（thinking トークンが多い推論タスク）
- ✅ 最終出力が短い、または翻訳戻しが不要（コード、技術文書は英語のままでよい）
CJK コスト削減で実際に効く方法
往復翻訳の代わりに、ハイブリッド戦略を：
| 手法 | 節約幅 | トレードオフ |
|---|---|---|
| システムプロンプトを英語化（ユーザー内容は日本語のまま） | 毎回呼び出しで固定節約、高頻度アプリで累積大 | モデルは英語システムプロンプトを完全に理解 |
| Few-shot 例を英語化 | 同上 × 例数 | 例を手動で用意する必要 |
| 出力を英語のまま（技術タスク） | 翻訳戻しステップ全体を省略 | ユーザーが英語を読める必要 |
| プロンプトキャッシング | 入力部分 50〜90% 割引 | 繰り返しプロンプトが必要 |
| 中国語処理に DeepSeek / Qwen | トークン -20〜30% + 単価 10〜50x 安 | 品質がやや劣る可能性（日本語ではメリット限定的） |
| 日本語プロンプトを簡潔に書く | 10〜20% | プロンプト磨きに時間 |
一言でまとめると：全文を双方向翻訳するのはやめる——ほぼ必ず高くつきます。静的部分を英語化、動的部分は CJK のまま、キャッシングを活用——これが実際に効く戦略です。
🛠️ 実務ガイダンス
コスト試算の心得
- 英語トークン数から日本語請求額を推定しない——少なくとも 1.3〜1.7倍（o200k）または 1.7〜2.9倍（cl100k）を掛ける
- モデル更新のたびに再計測——Opus 4.6 → 4.7 の CJK 悪化が教訓
- システムプロンプトと few-shot 例は毎回重複送信されるため、日本語のトークン膨張が累積する——プロンプトキャッシングで相殺できる
ベンダー選定
| 状況 | 推奨 |
|---|---|
| 日本語中心、コスト重視 | DeepSeek / Qwen（ただし日本語効率は他社と大差なし）または o200k 系 |
| 日本語中心、品質重視（法務・金融・コーディング） | Claude Opus 4.7 または GPT-5 |
| 多言語 / グローバルアプリ | GPT-4o / Gemini 3 |
| 短い高頻度コマンド | o200k クラスならどれでも差は小さい |
| 長文書類のバッチ処理 | トークナイザー効率を単価と一緒に検証 |
トークン圧縮テクニック
CJK の膨張は避けられない以上、コンテンツ側で工夫する：
- 簡潔な日本語を書く——冗長表現を避ける（「〜ということです」「〜するという行為を」など）
- 散文より構造化——箇条書き・表・key-value の方が長文より token を節約
- システムプロンプトを英語にする——ユーザー入力が日本語でも、システムプロンプトが英語でもモデル理解に支障なく、token を節約できる
- プロンプトキャッシングを積極活用——キャッシュされた日本語システムプロンプトは割引され、失われた効率の多くを回復できる
🧭 結論：直感ではなく実測を信じる
「CJK はトークンを節約する」はもっともらしく響く直感ですが、実測データの前で崩れます。漢字の情報密度はコンテキストウィンドウには効きますが、トークン請求額には効きません。
真の姿：
- 📉 CJK は現代 LLM で常に英語よりトークンを消費する——中国語 1.1〜1.6倍、日本語 1.3〜2.2倍
- 📈 トークナイザー更新は改善にも悪化にもなる（GPT-4 → 4o は 36% 改善、Opus 4.6 → 4.7 は 15〜35% 悪化）
- 💡 DeepSeek / Qwen は真の中国語トークナイザー最適化、ただし日本語ユーザーにはこの優位性は限定的
- 📊 CJK の「文字密度」優位はコンテキストウィンドウ層では残る——ただしトークンレベルの効率優位と混同しないこと
「日本語で AI と対話するとコストが下がる」という直感に頼らず、実測を信じることです。tiktoken や API の usage フィールドで代表的な 100 件を計測すれば、公開ベンチマークよりずっと正確な数字が得られます。
❓ よくある質問
「日本語はトークン効率がよい」が本当になる場合はあるのですか？
厳選された短文ではあり得ますが、通則ではありません。
cl100k_base（GPT-4 世代）には特定の高頻度日本語フレーズに対する最適化があり、短く一般的な文では日本語が同等またはわずかに勝ることがあります。しかしサンプルを拡大し等価な翻訳を使うと差は逆転します——2023年の arxiv 2305.15425 研究は200万文で日本語平均 2.12倍と示しており、本記事の6タスク実測と一致します。
覚えておくべきルール：現代 LLM で CJK は常にトークンを多く消費する。問題は「どれだけ多いか」だけ。
では、なぜコンテキストウィンドウは日本語の方が「多く入る」ように感じるのでしょうか？
文字数を感じていて、トークン数を感じていないからです。 1M トークンのコンテキストに日本語は約90万文字、英語は約540万文字入ります。一見英語の方が多く入りそうですが、「本の数で測る意味量」で比較すると、日本語の高い情報密度により90万文字でも新書3〜4冊分の内容を収められます。
結論：コンテキストウィンドウ層では CJK は負けていない（むしろ若干優位）が、API 請求層では CJK は負ける——この2つを分けて考える必要があります。
DeepSeek / Qwen は本当に日本語でも GPT / Claude より効率的ですか？
中国語では明確にイエス、日本語では大差なしです。
DeepSeek と Qwen は中国語コーパスへの学習偏重と、中国語寄りの語彙配分により、中国語 CPT で 1.1〜1.3 を達成——他の西洋モデルが 1.0 以下なのに対し明確な差があります。
しかし、これらのモデルは日本語を特別に最適化していないため、日本語 CPT は他モデルと同等かわずかに劣る程度。日本語中心のアプリでは、DeepSeek / Qwen はトークン効率で大きな優位性がなく、日本語品質で劣る可能性もあります——慎重に比較してください。
現在日本語でプロンプトを書いていますが、英語に変えるべきでしょうか？
ほとんどの場合、変える必要はありません。理由：
- 日本語でうまく書けるプロンプトは、下手な英語より性能がよい——表現の精度は 20% のトークン節約より遥かに重要
- プロンプト品質 > トークン効率——明確なプロンプトで1回で成功する方が、安くても3回リトライより割安
- CJK ペナルティは思ったより大きくない——o200k の日本語 1.7倍程度、プロジェクトの可否を変えるほどの差にはなりにくい
英語プロンプトを検討すべき場合：
- 大量に繰り返されるシステムプロンプトや few-shot 例（百万回の呼び出しで差が累積）
- 英語用語の方が精確な技術領域（AI、法務、医療）
- 高頻度でコスト敏感な API アプリ
ユーザー入力やモデル出力は日本語のままでよい——固定のプロンプトテンプレートのみ英語化を検討。
なぜ日本語は中国語より token を多く食うのですか？
日本語は3種類の書記系統を混ぜて使います：
- 漢字：中国語と同様、情報密度が高い
- 平仮名・片仮名：各仮名は1音節しか表さないが、1トークンを占有——「情報/トークン」比率が漢字より低い
- 外来語の片仮名表記（例：「コンピュータ」= computer）：1つの英単語が6つの片仮名 = 6トークンに膨張
したがって、高効率な漢字を含んでいても、仮名と外来語の拼音で平均値が押し下げられ、純粋な漢字中国語より悪くなります。これが本記事のすべての Task で日本語が中国語より悪い結果となっている理由です。
自分のアプリの token 消費量をどう測ればいいですか？
3つの方法（易から難へ）：
- gptforwork.com/tools/tokenizer — テキストを貼り付けるだけで GPT / Claude / Gemini / Grok のトークン数を確認
- OpenAI
tiktoken（Python）：import tiktoken enc = tiktoken.encoding_for_model("gpt-4o") print(len(enc.encode("あなたのテキスト"))) - 実 API 呼び出しで
usageフィールドを読む — レスポンスのinput_tokens/output_tokensが100% 正確な唯一の情報源（特に Claude / Gemini は tokenizer 非公開）
推奨：代表的な 100 件のプロンプトを実行して平均を取る——この数値は公開ベンチマークより自分のアプリに対してはるかに正確です。
関連記事：