トークン

概要

トークンは、LLM（大規模言語モデル）が文章を読み書きするときの最小単位です。モデルは文章を文字のままでも単語のままでもなく、「サブワード」と呼ばれる中間的な断片に切り分けてから処理します。たとえば英語の “unbelievable” は “un” + “believ” + “able” のような断片に、日本語の「東京都に住んでいます」は「東京」「都」「に」「住んで」「い」「ます」のような断片に分かれます。この切り分けを行うプログラムがトークナイザです。

トークンが実務で重要なのは、LLMにまつわる数字がほぼすべてトークン単位で決まるからです。API料金は入出力のトークン数に対する従量課金、モデルが一度に扱える文章量（コンテキスト長）は「12.8万トークンまで」のようにトークン数で表され、生成速度も「毎秒何トークン出せるか」で語られます。LLMを使う開発では、文字数ではなくトークン数で物事を見積もる感覚が欠かせません。

なお、認証・認可の文脈で登場する「アクセストークン」や JWT の「トークン」はまったく別の概念です。どちらも「何かを代理する小さな断片」という語源を共有しているだけで、この記事で扱うのはLLMの処理単位としてのトークンです。

なぜ生まれたか

機械学習で言語を扱うには、まず文章を離散的な単位の列に変換し、各単位に番号（ID）を割り振る必要があります。素直な候補は「単語」と「文字」の2つですが、どちらにも深刻な問題がありました。

単語単位では、語彙が爆発します。英語だけでも活用形・複合語・固有名詞・スペルミスまで含めれば単語の種類は事実上無限で、モデルが持てる語彙表（数万〜数十万件）には到底収まりません。語彙表にない単語はすべて「未知語」として同じ記号に潰されてしまい、“unbelievable” を初めて見たモデルは、“believe” を知っていてもその知識をまったく活かせません。一方、文字単位なら未知語は消えますが、系列が極端に長くなり、モデルは「文字を綴って単語を組み立てる」ところから学ばなければならず、計算量も学習の難易度も跳ね上がります。

サブワード分割は、この2つのトレードオフの中間解です。BPE（Byte Pair Encoding）に代表される手法は、大量のテキストで「頻繁に隣り合う文字の組」を繰り返し結合していき、「よく出る単語は1トークン、珍しい単語は既知の断片の組み合わせ」という語彙を自動構築します。頻出語はまるごと覚えて効率を稼ぎ、初見の単語も断片に分解すれば必ず表現できる — 語彙爆発と未知語問題を同時に解消したこの方式が、現在のLLMの標準になりました。

詳細

トークナイザの働き

トークナイザは、学習時に構築した語彙表（マージ規則）に従って、入力文字列をトークン列に分割し、各トークンを整数IDに変換します。モデル本体はこのID列しか見ておらず、内部では各IDが埋め込みベクトルに変換されてトランスフォーマーに入力されます。生成時はこの逆で、モデルが「次のトークンのID」を1つずつ選び、トークナイザがそれを文字列に復元します。LLMの生成が1トークンずつ進むのはこのためで、生成速度がトークン数に比例するのも自然な帰結です。

日本語はトークン効率が悪い

トークナイザの語彙は学習データの頻度分布から作られるため、学習データの大半を占める英語が最も「お得」に切り分けられます。英語なら1単語が概ね1〜2トークンに収まるのに対し、日本語は同じ内容を伝えるのに1.5〜3倍程度のトークンを消費するのが一般的です。ひらがな1文字が1トークン、漢字1文字が2〜3トークンに分解されることも珍しくありません（近年のモデルは多言語対応が進み、この差は縮まりつつあります）。

これは実務に直結します。同じ意味の文章でも、日本語で書くと英語よりAPI料金が高く、コンテキスト長を早く使い切り、生成に時間がかかるのです。「日本語の文字数 × 約1〜2 ≒ トークン数」という粗い目安を持ちつつ、正確な見積もりには各社が提供するトークナイザ（tiktoken など）で実測するのが確実です。

トークンで決まる3つの数字

第一に料金。LLMの API は「入力100万トークンあたり何ドル、出力100万トークンあたり何ドル」という従量課金が標準で、出力側が数倍高いのが通例です。RAG のように長大な文書をプロンプトへ詰め込む構成では、入力トークン数がコストの支配項になります。

第二にコンテキスト長。モデルが一度の推論で参照できるのは固定数のトークンまでで、これを超えた分は入りません。「会話履歴が長くなると昔の話を忘れる」現象の正体は、履歴が窓に収まるよう切り詰められているだけです。プロンプトエンジニアリングで「何をコンテキストに入れ、何を削るか」を設計する際の予算単位もトークンです。

第三に速度。生成は1トークンずつの逐次処理なので、応答時間は出力トークン数にほぼ比例します。長い出力を求めるほど待ち時間もコストも増える — 「必要なものだけを短く出させる」工夫が効くのはこのためです。

落とし穴 — トークン分割が生む不思議な挙動

LLMの奇妙な失敗の多くはトークン分割に由来します。有名な例が「strawberry に r はいくつ？」に誤答する問題で、モデルは単語を文字の列としてではなくトークンの塊として見ているため、文字数勘定や逆さ読みが苦手です。数値も桁ごとに不規則に分割されるため算術を間違えやすく、日本語の固有名詞が不自然な位置で割られて扱いを誤ることもあります。「モデルは文字を読んでいるのではなく、トークンを読んでいる」という視点を持つと、こうした挙動の理由と回避策（文字を空白区切りで渡す、計算はコードにやらせる等）が見えてきます。