トークナイザー

ざっくり言うと

ChatGPT・Claude・Geminiの基盤モデルは、それぞれ異なるトークナイザーを使っています。各社APIでは、トークン数が従量料金やコンテキストウィンドウの消費に影響します。一方、消費者向けチャットの月額プランはプラン料金と利用条件で提供され、利用者がトークン単位で直接請求されるとは限りません。

イメージ

正確には

OpenAI のヘルプセンターでは、トークンを「単語や単語のかけら(common sequences of characters)」と説明したうえで、英語ではおおむね 1 トークン ≒ 4 文字 / 100 トークン ≒ 75 単語 という目安を示しています。OpenAI のモデルは GPT 系で BPE(Byte Pair Encoding) 系のトークナイザーを使っており、GPT-4o では o200k_base というトークナイザーが採用されています。

Anthropic の公式ドキュメントでは、Claude が独自のトークナイザーを使っており、コンテキストウィンドウの消費もこのトークナイザーの数え方で決まると説明されています。トークン数を正確に数えたい場合は API 提供の count_tokens エンドポイントを使うことが推奨されています。

Claude Sonnet 5では新しいトークナイザーが採用され、同じ文章でもClaude Sonnet 4.6より約30%多いトークンになると案内されています。増え方は文章によって異なるため、旧モデルで数えた値を料金や上限の見積もりに流用せず、利用するモデルを指定して数え直します。

Google AI for Developers のドキュメントでも、Gemini が独自のトークナイザーを持っており、1 トークン ≒ 約 4 文字(英語) という目安と、countTokens API でトークン数を確認できることが案内されています。

Hugging Face の NLP コースでは、LLM で使われる代表的なトークナイザー方式として、BPE(Byte Pair Encoding)・WordPiece・Unigram(SentencePiece) の 3 種類が紹介されており、いずれも「よく出てくる文字列のかたまりを 1 トークンにまとめる」という発想で作られています。

モデルごとのトークナイザーの違い

つまり「包丁の銘柄が会社ごとに違う」状態です。同じ「こんにちは、元気ですか?」という文章でも、どの包丁で切るかによってシャリの個数が変わります。

なぜ日本語はトークン数が増えがちなのか

英語と比べて、日本語(や中国語・韓国語)はトークン数が増える傾向があります。これはトークナイザーの多くが、もともと英語中心のデータで「どの文字列のかたまりを 1 個にまとめるか」を学習したためです。

• 英語の "the" や "ing" などは頻繁に出てくるので 1 トークンにまとめられている
• 日本語の漢字・ひらがなはそこまで頻度が高くないので、1 文字単位や数バイト単位で分割されることがある

ただし、新しい世代のモデル(GPT-4o の o200k_base、Gemini、Claude など)では日本語向けの語彙が以前より増えているため、昔より日本語のトークン効率は改善されています。「日本語は英語よりトークン数が増えやすいことがある」くらいに捉え、実際の差はモデル・トークナイザー・文章内容・料金体系ごとに確認する、という見方が安全です。

トークナイザーが決めるもの

つまり、トークナイザーは「API料金・速度・品質」のすべてに地味に効いてくる縁の下の力持ちです。利用者から見えにくいですが、AI モデルを使うときの「入り口の設計」を担っています。

よくある勘違い

特に、プロンプトをテンプレート化して何度も使う場合は、最初に1回だけでもトークン数を確認しておくと、あとで「なぜか上限に当たる」「思ったより料金が増える」といったつまずきを減らせます。

注意点

やってみよう

関連用語として「トークンとは」「LLM(大規模言語モデル)」「コンテキストウィンドウ」の記事も合わせて読むと、AI モデルの入り口まわりの仕組みが立体的に見えてきます。