トークナイザーとは？生成AIサービスごとの違いを比較してみた

はじめに

生成AIのAPI料金やコンテキストウィンドウは、「文字数」ではなく「トークン数」を基準に計算されます。そのため、見た目には同じ程度の長さの文章でも、利用するモデルや言語によって入力トークン数が変わることがあります。
この違いに関係するのが、文章をモデルが処理できる単位へ分割する「トークナイザー」です。

本記事では、トークナイザーの基本的な仕組みを整理したうえで、GPT、Claude、GeminiのトークンカウントAPIに同じ意味の日本語と英語を渡し、入力トークン数の違いを比較します。
なお、トークン数は生成AIの利用コストにも関係します。コーディングエージェントにおけるトークンとコストの関係については、以下の記事でも解説しています。

トークナイザーとは

GPTやClaude、Geminiなどの大規模言語モデルは、入力された文章を文字列のまま処理しているわけではありません。文章を一定の単位に分割し、それぞれを整数のIDへ変換してから計算します。この文章を分割する仕組みがトークナイザーです。
OpenAIの公式ドキュメントでは、トークンを「頻繁に現れる文字列を表す単位」と説明しています。短く一般的な単語が1トークンになることもあれば、長い単語が複数のトークンに分割されることもあります。
トークン化の流れを単純化すると、次のようになります。

1. 入力された文章を受け取る
2. トークナイザーが文章を部分文字列へ分割する
3. 各部分文字列をトークンIDへ変換する
4. モデルがトークンIDの列を処理する

たとえば、「生成AI」という文字列が常に「生成」と「AI」の2トークンになるとは限りません。「生成」が1トークンとして登録されている場合もあれば、さらに細かく分割される場合もあります。実際の分割単位は、トークナイザーが持つ語彙と分割規則によって決まります。

単語ではなくサブワードを使う理由

文章を単語単位で扱う場合、活用形や固有名詞、新しく生まれた言葉をすべて語彙に登録する必要があります。一方、1文字ずつ分割すると未知語には対応しやすくなりますが、文章全体のトークン数が増えてしまいます。Anthropicの公式用語集でも、大きなトークンは推論や事前学習時のデータ効率を高め、小さなトークンは珍しい単語や未知語を扱いやすくすると説明しています。
そこで、多くの大規模言語モデルでは、単語やサブワード、文字、バイトに相当する単位を、語彙と分割規則に応じて組み合わせて扱います。頻出する文字列は大きな単位として扱い、珍しい文字列は文字やバイトに相当する小さな単位へ分割することで、語彙の大きさと文章の長さのバランスを取ります。

なぜモデルごとにトークン数が違うのか

トークナイザーには、モデルが利用するトークンの一覧である「語彙」があります。どの文字列を1トークンとして登録するかは、トークナイザーごとに異なります。
たとえば、日本語でよく使われる文字列が語彙に多く含まれていれば、文章を比較的大きな単位で分割できます。一方、その文字列が登録されていなければ、漢字やひらがなをより細かく分割する必要があり、同じ文章でもトークン数が増えます。
この違いを生む主な要素は次のとおりです。

英語は単語の間に空白がありますが、日本語には通常、単語間の空白がありません。また、日本語では漢字、ひらがな、カタカナ、英数字が一つの文中に混在します。1トークンの大まかな目安として、OpenAIは英語で約4文字と説明しています。どちらも英語を基準にした近似値であり、日本語へそのまま適用できるものではありません。

OpenAIのTokenizerで同じ日本語を比較すると、GPT-5.x・o1/o3向けでは19トークン、GPT-4・GPT-3.5向けの旧方式では29トークンになりました。図では分割単位が色分けされており、「トークナイザー」という1語だけでも6トークンに分割されることがわかります。
このように、同じ提供元でも、モデルの世代やトークナイザーの違いによって分割結果が変わることを確認できました。

トークン数だけを取得するAPI

今回比較する3社は、いずれも回答を生成せず、入力トークン数だけを取得するAPIを提供しています。

OpenAIの入力トークンカウントAPIは、Responses APIと同じ形式の入力を受け取り、モデルが受け取るトークン数を返します。テキストだけでなく、メッセージ、画像、ファイル、ツール定義などもカウントできます。
AnthropicのToken Count APIも、Messages APIと同じメッセージ、システムプロンプト、ツール、画像、PDFなどを受け取れます。ただし、公式ドキュメントではカウント結果が推定値であり、実際のMessage作成時の入力トークン数とわずかに異なる場合があると説明されています。
Gemini APIのcountTokensは、指定したモデルのトークナイザーを入力に適用し、totalTokensとして結果を返します。
公式ドキュメントは次のとおりです。

• OpenAI：Counting tokens
• Anthropic：Token counting
• Google：Counting tokens

検証：3社のトークン数を比較する

ここからは、同じ意味の日本語と英語を用意し、GPT、Claude、Geminiの入力トークン数を比較します。

比較条件

比較対象には、2026年7月28日時点で各社が提供している現行モデルから、直近に公開された代表的なモデルを選びました。

今回の3モデルは、能力や料金の階層をそろえたベンチマークではありません。各社の現行モデルから1つずつ選び、同じ文章を入力した際のトークン数を比較することが目的です。
厳密には、トークナイザーは提供元やモデルファミリーごとに1つだけ存在するとは限らず、モデルや世代によって変わる場合があります。本記事は、各社から上記のモデルを1つずつ選んだ比較です。同じGPT内のSolとTerra、同じClaude内のOpusとSonnetなどを比較すれば、異なる結果になる可能性があります。

比較する文章

日本語と英語は、同じ内容になるように用意しました。直訳ではなく、それぞれの言語として自然な表現にしています。

生成AIを業務に導入する際は、回答の精度だけでなく、入力データの管理、運用コスト、担当者による確認手順も設計する必要があります。まずは対象業務を限定して検証し、処理時間や誤回答の傾向を測定します。その結果をもとにプロンプトや運用ルールを改善し、十分な効果を確認してから利用範囲を広げることが重要です。

When introducing generative AI into business operations, it is necessary to design not only for response accuracy, but also for input data management, operating costs, and review procedures performed by responsible staff. Start by limiting the target workflow, then measure processing time and patterns in incorrect responses. Based on the results, improve the prompts and operating rules, and expand the scope of use only after confirming sufficient benefits.

文章の意味をそろえることで、各モデルにおける日本語と英語の相対的なトークン効率を確認します。

比較コード

以下のコードでは、3社のトークンカウントAPIを順番に呼び出します。文章生成APIは呼び出さないため、出力トークンは発生しません。

import os

import anthropic
from dotenv import load_dotenv
from google import genai
from openai import OpenAI


JAPANESE_TEXT = (
    "生成AIを業務に導入する際は、回答の精度だけでなく、入力データの管理、"
    "運用コスト、担当者による確認手順も設計する必要があります。"
    "まずは対象業務を限定して検証し、処理時間や誤回答の傾向を測定します。"
    "その結果をもとにプロンプトや運用ルールを改善し、十分な効果を確認してから"
    "利用範囲を広げることが重要です。"
)

ENGLISH_TEXT = (
    "When introducing generative AI into business operations, it is necessary to "
    "design not only for response accuracy, but also for input data management, "
    "operating costs, and review procedures performed by responsible staff. "
    "Start by limiting the target workflow, then measure processing time and "
    "patterns in incorrect responses. Based on the results, improve the prompts "
    "and operating rules, and expand the scope of use only after confirming "
    "sufficient benefits."
)

load_dotenv()

models = {
    "GPT": os.getenv("OPENAI_MODEL", "gpt-5.6-sol"),
    "Claude": os.getenv("ANTHROPIC_MODEL", "claude-opus-5"),
    "Gemini": os.getenv("GEMINI_MODEL", "gemini-3.6-flash"),
}

openai_client = OpenAI()
anthropic_client = anthropic.Anthropic()
gemini_client = genai.Client()


def count_tokens(service, model, text):
    if service == "GPT":
        return openai_client.responses.input_tokens.count(
            model=model,
            input=[{"role": "user", "content": text}],
        ).input_tokens

    if service == "Claude":
        return anthropic_client.messages.count_tokens(
            model=model,
            messages=[{"role": "user", "content": text}],
        ).input_tokens

    return gemini_client.models.count_tokens(
        model=model,
        contents=text,
    ).total_tokens


texts = {"日本語": JAPANESE_TEXT, "英語": ENGLISH_TEXT}
results = {}

print("| サービス | モデル | 言語 | 文字数 | トークン数 |")
print("| --- | --- | --- | ---: | ---: |")

for service, model in models.items():
    for language, text in texts.items():
        tokens = count_tokens(service, model, text)
        results[(service, language)] = tokens
        print(f"| {service} | `{model}` | {language} | {len(text)} | {tokens} |")

print("\n| サービス | 日本語 / 英語のトークン比 |")
print("| --- | ---: |")

for service in models:
    ratio = results[(service, "日本語")] / results[(service, "英語")]
    print(f"| {service} | {ratio:.3f} |")

認証情報は.envへ設定します。必要なパッケージと実行手順は、付属するREADME.mdにまとめています。

実行結果

結果の考察

今回の文章では、Geminiが日本語・英語ともに79トークンで、3モデルの中で最も少ない結果になりました。GPTは日本語が117トークン、英語が85トークン、Claudeは日本語が141トークン、英語が130トークンでした。
日本語のトークン数を英語のトークン数で割ると、GPTでは日本語が約37.6％、Claudeでは約8.5％多くなりました。一方、Geminiは日本語と英語がどちらも79トークンだったため、比率が1.000になっています。
ただし、Geminiの日英比が1.000になったのは、今回用意した一組の文章でトークン数が偶然一致した結果です。日本語と英語が常に同じトークン数になることや、Geminiがあらゆる日本語文章を効率よく分割できることを意味しません。入力する文章が変われば、比率も変わります。
また、この結果だけで「日本語が得意なモデル」を決めることはできません。トークン数は文章の分割効率を示しますが、日本語の読解精度、指示への追従性、回答品質を直接示す指標ではないためです。

比較結果をどう捉えるか

トークン数が少ないと入力効率は上がる

同じ情報を少ないトークンで表現できれば、同じコンテキストウィンドウへより多くの文章を入れられます。また、入力トークン数に応じた従量課金では、他の条件が同じであれば入力コストも抑えられます。
特に、長い日本語文書を扱うRAG、議事録の要約、契約書の確認、問い合わせ履歴の分析などでは、文章ごとの差が処理件数に応じて積み上がります。そのため、実際に利用するデータを各モデルのカウントAPIへ渡し、導入前にトークン数を確認することには実務上の意味があります。

トークン数だけで料金は比較できない

トークン数が最も少ないモデルが、必ずしも最も低コストとは限りません。各社で100万入力トークンあたりの料金が異なるほか、プロンプトキャッシュ、バッチ処理、長いコンテキストに対する追加料金などの条件も異なります。
料金を比較する場合は、今回取得したトークン数に各モデルの入力単価を掛け、実際のリクエスト条件に合わせて計算する必要があります。

APIが返す値は純粋な文章の分割数とは限らない

今回利用するAPIは、実際のリクエストに近い入力トークン数を返します。そのため、文章本体だけでなく、メッセージの役割や境界など、APIの入力構造を表すトークンが含まれる場合があります。
各社でメッセージ形式や内部処理が異なるため、この比較は「同じ文字列を各トークナイザーへ直接渡した純粋な分割数」ではなく、「同じ文章をユーザーメッセージとして送る場合の入力トークン数」と捉えるのが適切です。

一つの文章だけで一般化しない

トークンの分割結果は、文章に含まれる単語、漢字、記号、英数字、専門用語などによって変わります。今回の結果は、用意した一組の文章に対する結果です。
実際のモデル選定では、対象業務で使う文書を複数用意し、トークン数だけでなく、回答品質、処理時間、料金も合わせて評価する必要があります。また、モデルの更新でトークナイザーが変わる可能性もあるため、モデルIDと計測日を記録しておくことが重要です。

まとめ

トークナイザーは、入力された文章をモデルが処理できるトークンへ分割する仕組みです。モデルや世代によって語彙や分割規則が異なるため、同じ文章を渡しても入力トークン数は一致しません。
本記事の要点は次のとおりです。

• トークンは必ずしも単語や1文字と一致せず、頻出する部分文字列を単位として扱う
• GPT、Claude、Geminiはいずれも、文章を生成せずに入力トークン数だけを取得するAPIを提供している
• 日本語と英語のトークン数を比べると、モデルごとの相対的な入力効率を確認できる
• トークン数が少ないことは、日本語の回答品質が高いことを直接意味しない
• 実務では、対象データを使ってトークン数、料金、回答品質、処理速度を合わせて評価する

トークン数は、生成APIのレスポンス受信後に確認するだけでなく、リクエストを送る前にも計測できます。長い文書や大量の入力を扱うシステムでは、各社のカウントAPIを使って実データの傾向を把握しておくと、モデル選定やコスト試算の精度を高められます。

生成AI活用支援サービスのご紹介

Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた様々な支援をご提供しています。

1. 無料診断パック：業務・プロセスの現状を無料で診断し、生成AI活用の可能性をレポートします。
2. 検証（PoC）パック：診断で有効性が確認された業務を対象に、プロトタイプ構築を支援します。
3. コンサルティングサービス：生成AI導入戦略の策定から運用体制構築までを包括的に支援します。
4. Plain RAG：社内文書をもとに回答し、社内問い合わせを効率化するAIチャットパッケージです。

生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。

執筆・編集

Tech Fun Magazine R&Dチーム

Tech Funの生成AI研究に携わるエンジニアが、最新のAIモデル動向やプロンプト設計、実業務への応用手法など、生成AIに特化した知見を執筆・編集しています。
モデル評価や業務シナリオに応じたAI活用設計など、日々のR&D活動で得られる実践的なノウハウをわかりやすく紹介します。