AIに質問を入力すると、まるで人間と対話しているかのように流暢な日本語で返答が返ってきます。しかし、大規模言語モデル(LLM)は、私たちが画面で見ている文章をそのまま「文字」や「言葉」として読んでいるわけではありません。AIが内部で実際に処理しているのは、「トークン」と呼ばれる細かな文字列の断片です。

トークンという言葉は、AIの利用料金を計算する単位や、一度に入力できる文章の長さの上限(コンテキスト長)の説明などで頻繁に登場します。耳にしたことはあっても、「トークンとは具体的に何を指すのか」「単語や文字と何が違うのか」を正確に説明できる人は多くありません。

言語モデルが文章をトークンに切り分ける仕組み、頻出する言葉を効率よくまとめるアルゴリズム、そしてなぜAIが文字の数を数え間違えるのかといった実務的な疑問まで、基礎から分かりやすく整理して解説します。

文字列を断片へ分割し整数IDへ変換、埋め込みでベクトル化する流れ。
解説図文字列を断片へ分割し整数IDへ変換、埋め込みでベクトル化する流れ。分割・ID・数値は架空例。

なぜAIは文字や単語そのままではなく「トークン」で読むのか

コンピュータやAIの頭脳であるニューラルネットワークは、言葉そのものを直接理解することはできません。計算できるのは「数値」だけです。そのため、AIが文章を処理するには、まず文字列を何らかのルールで分解し、それぞれを数値(番号)に変換する必要があります。

では、文章をどのような単位で分解すればよいのでしょうか。真っ先に思い浮かぶのは「単語ごと」または「文字ごと」に分ける方法です。しかし、言語処理の歴史において、この両者にはそれぞれ大きな壁がありました。

単語単位と文字単位が抱えていた壁

まず「単語単位」で分ける方法を考えてみましょう。英語であれば空白で区切られた単語ごと、日本語であれば形態素解析ツールを使って辞書にある言葉ごとに分ける方式です。人間にとって自然で意味が分かりやすいのが長所ですが、最大の欠点は「辞書に載っていない新しい言葉(未知語:Out-of-Vocabulary)」に対応できないことです。日々生まれる新語、流行語、専門用語、打ち間違いなどのすべてを網羅しようとすると、辞書のエントリが膨大になり、モデルのメモリや計算処理を圧迫してしまいます。さらに英語では動詞の語尾変化(play, played, playing)ごとに別の単語として登録しなければならず、効率的ではありません。

一方、「1文字単位」で分ける方法はどうでしょうか。アルファベットであれば26文字、日本語でも普段使う漢字やひらがな数千文字を登録しておけば、未知の単語が現れても文字の組み合わせで表現できるため、未知語で完全に処理が止まる事態は避けられます。しかし、文字単位にすると別の深刻な問題が生じます。文章全体の長さ(シーケンスのステップ数)が非常に長くなってしまうのです。「こんにちは」という挨拶だけでも5ステップ、長い文なら数百から数千ステップにも達し、後述するニューラルネットワークの計算負荷が跳ね上がってしまいます。また、1文字単体では意味の情報が薄いため、AIが文脈全体を効率よく捉えることが難しくなります。

解決策としての「サブワード」

単語単位の「意味のまとまりの良さ」と、文字単位の「未知語への柔軟さ」を両立させるために考案されたのが、「サブワード(Subword:単語より小さい構成要素)」という着想です。

多くの言語モデルは文章をトークンという処理単位の断片に分けて処理し、その区切りは単語や文字、意味の最小単位と一致するとは限らないという特徴を持っています。サブワード分割では、日常会話で頻繁に登場する一般的な単語は丸ごと1つの塊(トークン)として登録し、滅多に見かけない珍しい単語や複合語は、より小さな既知の断片に分解して処理します。

これにより、語彙辞書のサイズを数万から十数万程度という扱いやすい規模に抑えながら、どんなに珍しい言い回しや造語であっても、小さな断片や文字の組み合わせに分解して確実に処理できる柔軟性を手に入れたのです。

なお、トークンの説明として「意味の最小単位」という表現が使われることがありますが、これは厳密には正しくありません。言語学でいう意味の最小単位(形態素)とは異なり、モデルのトークンは文法的な意味とは無関係に、出現頻度の統計に基づいて機械的に分割された文字列の断片です。

トークン化の基本手順とBPEの仕組み――辞書作りと分割の二段階

AIが文章を受け取ってから計算を始めるまでの処理は、大きく分けて「トークン化(Tokenization)」と「埋め込み(Embedding)」という独立した段階に分かれています。

トークン化と埋め込み(Embedding)の違い

トークン化とは、入力された文字列をルールや辞書に基づいて「トークン」に分割し、それぞれの断片に対応する整数番号(トークンID)を割り当てる前処理です。この段階では、まだAIの意味理解や高度な思考は行われていません。あらかじめ定められた変換規則に沿って、文字の並びを整数のリストへ置き換えているだけです。

整数の並びに変換されたトークンIDは、次の「埋め込み(Embedding)」の段階へと渡されます。埋め込み層では、各トークンIDが高次元の密な数値ベクトル(数百から数千個の実数の並び)へと変換され、モデルが計算可能な空間に配置されます。トークン化は文字列を整数列にする前処理であり、ベクトルに変換する埋め込みとは明確に区別される技術です。

BPE(バイト対符号化)アルゴリズム

現代の多くの言語モデルで広く採用されている代表的なサブワード分割手法が、BPE(Byte Pair Encoding:バイト対符号化)です。BPEはもともとデータの可逆圧縮アルゴリズムとして開発されたものですが、自然言語処理の分野で語彙を構築する手法として応用されました。

BPEを正しく理解するためには、「語彙の学習(辞書作り)」と「入力テキストの分割(推論)」という2つの段階を明確に分ける必要があります。

#### 1. 語彙の学習(辞書作り) モデルの開発時、膨大なテキストデータ(コーパス)を用意して、どのようなトークンの辞書を作るかを学習します。

  1. 最初に、コーパス内のすべての単語を文字単位(またはバイト単位)の断片に分解します。
  2. コーパス全体を通して、隣り合って最も頻繁に出現する2つの断片(ペア)の組み合わせを数えます。
  3. 最も頻度が高いペアを1つの新しい断片として統合(マージ)し、辞書(語彙リスト)に登録します。
  4. この統合操作を、あらかじめ決めた目標の語彙サイズ(例えば32,000語や100,000語など)に達するまで繰り返します。

どの断片とどの断片をどの順番で結合したかという記録は、「マージルール」として保存されます。頻繁に使われる言葉ほど早い段階で1つの大きなトークンにまとまり、滅多に使われない言葉は分割された小さな断片のまま残ります。

#### 2. 入力テキストの分割(推論・適用) 辞書とマージルールが完成した後は、新しい文章が入力されるたびにそのルールを適用します。文章をまず最小単位に分解し、保存されているマージルールの優先順位に従って可能な限り断片を結合していきます。結合が終わったら、それぞれの断片に辞書で決められたトークンID(例えば、説明用の仮の例として「私」=1042、「は」=285 のような整数)を割り当てます。

方式に応じた前処理と正規化の注意点

トークン化の前段階として、テキストをどのように整えるかという前処理の設計も方式によって異なります。

初期の言語処理では、言語ごとに単語を区切るルールを細かく作り込んでいましたが、多言語への適用が困難でした。そこで考案されたのが、GoogleのSentencePieceなどの枠組みです。SentencePieceは、空白を特別な文字(メタ記号「_」U+2581など)に置き換えて通常の文字と同じように扱うことで、空白で区切らない日本語や中国語でも英語と同じ仕組みで分割できるようにしました。これにより、トークン列から元の文章を一対一で完全に復元できる「可逆性(ロスレス)」が確保されています。

一方で、文字の表記揺れ(全角・半角の違いや異体字)を統一するために「NFKC正規化」などのUnicode正規化を事前に行う方式もあります。正規化を行うと入力の揺らぎに強くなる半面、全角英数が半角に統一されたり特定の記号が別の文字に置き換わったりするため、元の文字列を完全には復元できなくなる非可逆性を持つ点には注意が必要です。

また、未知語への耐性も方式によって異なります。文字単位のBPEでは辞書に含まれない未知の文字が出現すると「<unk>(未知語トークン)」に置き換わってしまうことがありますが、テキストを文字ではなくバイト(UTF-8のバイト列)単位で扱う「Byte-level BPE」を採用している近代的なモデルでは、あらゆる文字が最終的に1バイト単位の数値にまで分解できるため、未知語記号を出すことなくすべての文字列を表現できます。

1単語が複数の断片に分かれる実例――エンコーディングによる違い

人間にとって1単語に見える文字列でも、採用するエンコーディング方式や語彙辞書によって複数の断片に分割され、6つなどの断片に分かれる場合があります。

代表的な具体例として、英語の辞書に載っている非常に長い単語「antidisestablishmentarianism(国教廃止反対論、28文字)」を見てみましょう。人間にとっては明らかに英語の1つの単語ですが、言語モデルがこの単語をどのように認識するかは、モデルが持っているトークナイザーの辞書によって異なります。

OpenAI Cookbookの公式解説(how to count tokens with tiktoken)に掲載されている実行結果によると、この単語(前後に空白を含まない形)を入力した際、以下のように分割されます。

エンコーディング方式主な対応モデル分割されるトークン数トークンの分割内訳(例)
cl100k_baseGPT-4, GPT-3.5-Turbo など6トークンanti + dis + establishment + arian + ism など(6断片)
o200k_baseGPT-4o など6トークン語彙サイズ20万の辞書でも頻度に応じて6断片に分割
r50k_base初期のGPT-3(davinci等)5トークン語彙サイズ約5万の旧辞書では5断片に分割

このように、語彙辞書のサイズが大きい最新のモデルであっても、その単語がコーパス内で丸ごと出現する頻度が低ければ、より小さな部品(接頭辞や語根など)へと分割されます。逆に、語彙数が少ない旧モデルの方が偶然5つの断片にまとまることもあり、「語彙数が多いほど常にトークン数が減る」とは一概に言えないのがサブワード分割の特徴です。

日本語における文字数とトークン数の関係

日本語を入力した場合のトークン分割も見てみましょう。たとえば「大規模言語モデル」というフレーズがあります。

このフレーズは、日本語の文字数として数えると「大・規・模・言・語・モ・デ・ル」のぴったり8文字です。文字単位で処理するシステムであれば、そのまま8つのトークンになります。

しかし、現代の言語モデルのトークナイザーにかけると、モデルの語彙辞書に「大規模」「言語」「モデル」といった日本語の熟語や単語がサブワードとして登録されているため、おおむね3つから4つのトークン程度に効率よくまとめられます。文字数よりも少ないトークン数で表現できるわけです。

かつては「英語に比べて日本語はトークン消費量が数倍多く、割高になる」という話がよく知られていました。これは初期のモデルが英語のテキストを中心に学習され、語彙辞書の中に日本語の漢字や単語がほとんど登録されていなかったためです。辞書にない漢字はUTF-8のバイト単位(漢字1文字につき3バイト)に細かく分解されてしまい、文字数の3倍近いトークンを消費していました。

しかし近年のモデルでは、多言語のデータが豊富に学習され、トークナイザーの語彙数も10万から20万規模へと大幅に拡大されたため、日本語の主要な語彙もひとまとめのトークンとして扱えるようになり、消費効率は格段に向上しています。「日本語は英語の〇倍トークンを消費する」といった固定的な数値で覚えるのではなく、使用するモデルのエンコーディング方式や辞書設計によって効率が大きく変動することを理解しておく必要があります。

コンテキスト長・計算負荷・利用料金への影響

トークンという単位は、AIの理論的な仕組みだけでなく、私たちが実際にAIを使ったりシステムを開発したりする際の「実用面」に直結しています。

コンテキスト長(文脈窓)の正しい捉え方

言語モデルには、一度に入力・処理できる文章の長さに上限があります。これを「コンテキスト長(文脈窓、コンテキストウィンドウ)」と呼びます。

モデルのカタログやプレスリリースを見ると「128kコンテキスト対応」といった表記をよく目にします。この「128k」という数値は、千単位の概数(約128,000トークン)を表す目安の表現であり、コンピュータの2進数計算である131,072語(2の17乗)を常に指しているわけではありません。また、文字数ではなく「トークン数」の上限であるため、日本語の文字数に換算すると扱える文字数は文脈や表現によって変動します。システム開発や業務で厳密な上限管理を行う場合は、通称の「128k」を鵜呑みにせず、各モデルの公式技術仕様書に記載されている厳密な整数の上限値を確認することが重要です。

もし会話や入力がこのコンテキスト長の上限を超えてしまった場合、AIの挙動は一律ではなく、システムの実装方針によって大きく異なります。

  • 忘却・切り詰め(Truncation):古い会話の履歴を先頭から順に切り捨て、直近のトークンだけを枠内に収めて処理を続行する方式。チャットUIなどでよく採用されます。
  • エラー停止:APIなどの直接的な呼び出しにおいて、制限を超えた瞬間にリクエストを拒否してエラーを返す方式。
  • 要約・圧縮(Summarization):エージェントシステムなどで、過去の長いやり取りをバックグラウンドで自動的に要約し、要約文(少数のトークン)に圧縮してコンテキスト内に残す高度な方式。

自己注意機構(Self-Attention)と計算負荷の二乗則

なぜAIは、一度に無限のトークンを処理することができないのでしょうか。その理由は、Transformerモデルの中核をなす「自己注意機構(Self-Attention)」の計算構造にあります。

標準的な自己注意機構では、入力されたすべてのトークンが、文章内の他のすべてのトークンとどのように関連しているかを総当たりで計算します。トークンの総数を N とすると、計算量とメモリ消費量は N の二乗(O(N^2))に比例して増大します。

トークン数が2倍になれば計算負荷は約4倍になり、トークン数が10倍になれば計算負荷はおよそ100倍に膨れ上がります。このため、トークン数を伸ばすことはハードウェアのメモリと処理速度に強烈な負荷をかけます。近年では長大な文章を効率よく処理するための計算効率化技術や近似アルゴリズムが次々と提案されていますが、トークン数の増大がシステム全体の負荷や応答速度の低下につながる基本原理は変わりません。

API利用料金の仕組みと確認手順

クラウドを通じて言語モデルを利用するAPI(Application Programming Interface)では、課金の基準単位としてトークン数が使われます。

一般に、ユーザーが送信したプロンプトのトークン数(入力トークン)と、AIが返答として生成したトークン数(出力トークン)は分けて集計され、それぞれ異なる単価が設定されています。多くの場合、出力トークンの方が入力トークンよりも単価が高く設定されます。入力トークンはモデルが一括して並列に読み込めるのに対し、出力トークンは後述するように1トークンずつ確率計算を繰り返しながら生成するため、サーバーの演算リソースを長時間占有するからです。

ただし、出力トークンが入力トークンの何倍の価格に設定されているか(2倍なのか、3倍なのか、あるいはそれ以上か)は、モデルの世代、ベンダー各社の価格戦略、運用の効率化によって頻繁に改定されます。「出力は入力の〇倍」といった固定的な数値を暗記するのではなく、定期的にプロバイダーの最新公式料金表を確認する運用を徹底してください。

トークン化がもたらすAIの得意と不得意

言語モデルが文章を「トークン」の単位で処理しているという事実は、AIの驚異的な文章生成能力を生み出していると同時に、人間からは不自然に見える特有の「苦手分野」を生み出す原因にもなっています。

次トークン予測という動作原理

大規模言語モデルの根底にあるタスクは、驚くほどシンプルです。それは「提示されたトークンの並びの次に、どのトークンが来る確率が最も高いか」を予測することです。これを「次トークン予測(Next-Token Prediction)」と呼びます。

AIは、文章全体をあらかじめ完成図として思い浮かべてから一気に書き出しているわけではありません。

  1. これまでの入力トークン列を読み込む。
  2. 語彙辞書にあるすべてのトークンの中から、文脈的に次に来る確率の分布を計算する。
  3. 確率に基づいて次のトークンを1つ選んで出力する。
  4. 出力したトークンを入力の末尾に追加し、再び次のトークンを予測する。

この単純なステップを高速で繰り返すことによって、あたかも論理的に思考して文章を組み立てているかのような、自然で滑らかな長い文章が生成されます。

なぜAIは文字を数えられないのか――strawberry問題としりとり

AIの普及に伴い、世界中で話題になった有名な現象があります。「strawberry(イチゴ)という単語の中に、アルファベットの 'r' は何文字含まれていますか?」と質問すると、どんなに賢い最新のAIでも「2文字です」と自信満々に誤答してしまう、いわゆる「strawberry問題」です(正解は3文字)。

また、日本語で「しりとりをしましょう」と持ちかけても、直前の単語の最後の文字ではなく途中の文字から始まる言葉を返してしまったり、文字の並べ替え(アナグラム)を解かせると支離滅裂な回答を出したりすることがあります。

これらの失敗が起きる最大の原因は、AIの知能が足りないからではなく、「AIは文字を見ていない」からです。

人間は strawberry という文字列を画面上で見るとき、's', 't', 'r', 'a', 'w', 'b', 'e', 'r', 'r', 'y' という個々の文字の並びとして視覚的に認識できます。しかし、AIの視界に入るのは文字ではなく、トークナイザーによって切り分けられた straw と berry という2つの「トークンID(番号)」です。

AIにとって、それらのトークンは「イチゴに関連する意味的な概念の塊」として見えており、その塊の中に具体的にアルファベットが何文字並んでいるのかを直接数えているわけではありません。文字数を答えるとき、AIは記憶の中の統計的な連想に基づいて「それらしい数字」を出力しているに過ぎないため、文字のカウントや末尾の文字の判定で頻繁にミスを起こしてしまうのです。

実務での確実な対策

この弱点に対して、「単語の文字と文字の間に空白を入れて入力すれば、強制的に1文字1トークンになって正しく数えてくれる」というテクニックが語られることがあります。しかし、これも万能ではありません。トークナイザーの語彙構成やマージルールによっては、空白付きの文字の組み合わせが別のサブワードとして認識されることもあり、確実に1文字1トークンになるとは限らないからです。

文字数を厳密に数えさせたり、特定の位置の文字を正確に抽出させたりしたい場合の実務上の確実な解決策は、AI自身に目視で数えさせるのをやめさせることです。代わりに「Pythonなどのスクリプトを書いて文字数をカウントし、その実行結果を出力してください」と指示するか、コード実行環境(コードインタプリタ機能)を併用して、プログラムの正確な文字列処理関数(len() や正規表現など)に計算を担当させるのが最も確実で再現性の高い手順です。

教材ツールで体験する文字とバイト列の関係

トークンという概念をより身近に体感するために、コンピュータが文字をどのようにデータとして扱っているのか、その一番底にある「バイトへの変換」を体験してみましょう。

INTERACTIVE

実際に動かして確かめる

条件や数値を変え、本文で説明した関係を確認できます。
表示値は仕組みを理解するための学習用モデルです。大きな画面で使う

上記の教材ツール「UTF-8 byte tokenizer · Web Encoding API」は、Webブラウザ標準のWeb Encoding API(TextEncoder)を使用して、入力したテキストがどのような「UTF-8バイト列(16進数の並び)」に変換されるかを視覚的に確認できる基礎教材です。

文字とバイト列の対応関係

コンピュータは、あらゆる文字を「文字コード」という取り決めによって管理しています。世界中のすべての文字に一意の番号を割り当てた国際規格が「Unicode(ユニコード)」です。そして、その番号をコンピュータが扱いやすい8ビット(1バイト)単位のデータ列に変換する代表的な符号化方式が「UTF-8」です。

ツールに文字を入力してみると、文字の種類によって変換されるバイト数が異なることが分かります。

  • 半角のアルファベットや数字(ASCII文字):1文字につき「1バイト」で表現されます(例:A は 0x41)。
  • ひらがな・カタカナ・日常的な漢字:日本語の文字の多くは、UTF-8では1文字につき「3バイト」のデータとして表現されます。
  • 一部の絵文字や特殊な異体字:サロゲートペアなどを伴う複雑な文字は、1文字につき「4バイト」を消費します。

このように、私たちが画面で見ている「1文字」は、メモリや通信のレベルでは異なる長さのバイト列として存在しています。

教材ツールの位置付けと限界

このツールを観察するにあたって、絶対に混同してはならない重要な注意点があります。

教材ツールはブラウザ標準のWeb Encoding APIを用いたUTF-8バイト列への変換と文字対応を表示するものであり、特定言語モデルのBPEトークン数や利用料金・入力上限を直接算出するものではありません。

ツールが表示しているのは、あくまで文字符号化の基礎である「文字からUTF-8バイト列への変換」です。一方、実際の言語モデルが採用しているBPEなどのサブワード分割は、このバイト列や文字列をもとに、さらに巨大な語彙辞書(数万〜数十万語)に照らし合わせて複数のバイトや文字をより大きな「トークン」へとまとめ上げる、もう一段上の処理を行っています。

文字がバイトに変換される基礎レイヤーと、バイトや単語がモデルのトークンにまとめられる応用レイヤーという「2つの階層の違い」を明確に整理しておくことが、AIのデータ処理を正しく理解するための鍵となります。

トークンに関するよくある疑問(FAQ)

Q1. トークンは日本語の「形態素(品詞の最小単位)」と同じものですか?

いいえ、異なります。学校の国語で習う形態素は、文法や意味のまとまりに基づいて人間が定義した言語学的な単位です(例:「走る」「美しい」など)。これに対し、言語モデルのサブワードトークンは、膨大なテキストデータの中でどの文字やバイトが隣り合って頻出したかという統計情報に基づいて、機械的に切り分けられた断片です。そのため、文法的には不自然な場所で単語が途切れてトークンになったり、逆に複数の単語がくっついて1つのトークンになったりすることが日常的に起こります。

Q2. トークン数を節約するために、句読点を削ったり不自然な略語を使うべきですか?

実務上、そのような節約方法は推奨されません。極端に助詞を抜いたり句読点を削ったりすると、文章の構造や修飾関係が曖昧になり、AIが文脈を正しく読み取れなくなって回答の精度が著しく低下するリスクがあるためです。わずかなトークン数を削るために回答の品質を犠牲にしては本末転倒です。トークン数を抑えたい場合は、不自然な文字の切り詰めを行うのではなく、前提条件を箇条書きで整理したり、不要な前提の重複を省いたりして、論理的で無駄のないプロンプトを設計することが効果的です。

結び

トークンは、人間が紡ぎ出す豊かな言葉の世界と、数値計算しか行えないAIの脳(ニューラルネットワーク)をつなぐ、不可欠な「架け橋」です。

文章を細かな断片に分けるサブワードという知恵によって、AIは未知の言葉にも柔軟に対応しながら、膨大な知識を扱いやすいサイズで記憶し、高速に処理する力を手に入れました。その一方で、言葉を文字ではなくトークンの塊として見ているからこそ生じる独特の苦手分野も存在します。

トークンという最小単位の仕組みとその限界を正しく理解しておくことは、AIの予期せぬミスを見抜き、業務や開発においてAIの真の性能を引き出すための確かな土台となります。

出典・参考資料

出典・参考資料(追補)