トークナイザアーキテクチャ（トークナイザアーキテクチャ）
トークナイザアーキテクチャとは、自然言語テキストをLLMが処理可能なトークン列に変換するシステムの設計構造である。BPE、Unigram、WordPiece等の分割アルゴリズム、語彙構築戦略、特殊トークン設計を包含し、モデルの性能・効率・多言語対応能力を根本的に規定する。
トークナイザアーキテクチャは、LLMパイプラインの最初と最後に位置する基盤コンポーネントである。入力テキストをトークンIDの列に変換（エンコード）し、モデル出力のトークンIDをテキストに復元（デコード）する。トークナイザの設計はモデルの語彙サイズ、推論効率、多言語性能、さらにはコスト構造（API課金はトークン数ベース）に直結する。
概要
トークナイザの役割は「人間が読めるテキスト」を「モデルが処理できる数値列」に変換することだが、この変換方法の選択がモデル全体の性能を左右する。2026年現在、主要LLMのトークナイザ設計は以下の3つの軸で分類される：
- 分割アルゴリズム: BPE（GPT系）、Unigram（Gemma系）、WordPiece（BERT系）
- 語彙サイズ: 32K（Llama 2）〜256K（Gemini 2.0）
- 前処理: バイトレベル（GPT-4）、文字レベル（BERT）、SentencePiece（言語非依存）
トークナイザの設計判断が影響する要素：
| 設計要素 | 影響範囲 | トレードオフ |
|---|---|---|
| 語彙サイズ | 推論速度・メモリ・圧縮率 | 大語彙=高圧縮だがembedding層巨大化 |
| 分割アルゴリズム | 未知語処理・一貫性 | BPE=決定的、Unigram=確率的 |
| バイトフォールバック | 多言語・特殊文字対応 | 対応範囲拡大だがトークン数増加 |
| 特殊トークン | 機能制御・安全性 | 多機能だが語彙を消費 |
| 正規化 | 入力の一貫性 | 情報損失のリスク |
主要トークナイザの比較
| モデル | アルゴリズム | 語彙サイズ | 実装 | 特徴 |
|---|---|---|---|---|
| GPT-4/4o | BPE | 100,277 | tiktoken | バイトレベルBPE、高速Rust実装 |
| Claude 4 | BPE | ~100K | 非公開 | 多言語最適化、長文効率化 |
| Llama 3/3.1 | BPE | 128,256 | SentencePiece | 前世代32Kから4倍拡張 |
| Gemma 2/4 | Unigram | 256,000 | SentencePiece | Google最大語彙、多言語強化 |
| Gemini 2.0 | Unigram | 256,000 | 非公開 | Gemma共通語彙 |
| Qwen3 | BPE | 151,936 | tiktoken | 中日英最適化 |
| Mistral 3 | BPE | 32,768 | SentencePiece | 小語彙高効率 |
トークナイザの内部処理フロー
テキスト「Hello, world!」の処理例（GPT-4 tiktoken）：
- 正規化: Unicode正規化（NFC/NFKC）、空白の統一
- プレトークン化: 正規表現パターンでテキストを初期チャンクに分割（空白、句読点、数字で区切り）
- サブワード分割: BPE/Unigramアルゴリズムでチャンクをトークンに分割
- ID変換: トークン文字列を語彙テーブルで整数IDに変換
- 特殊トークン付加:
<|im_start|>,<|im_end|>等のコントロールトークンを追加
語彙サイズの設計戦略
語彙サイズはトークナイザ設計の最重要パラメータの1つである。
小語彙（32K）の利点：
- Embedding層が小さくメモリ効率が良い
- 訓練データが少なくても各トークンの学習が充分
- モデルサイズが小さい
大語彙（128K-256K）の利点：
- テキストの圧縮率が高い（同じ文が少ないトークンで表現可能）
- 多言語対応が容易（各言語のトークンを十分に収録可能）
- 推論時の生成ステップ数が減少し、レイテンシが改善
Llama 2（32K）→Llama 3（128K）の語彙拡張では、英語テキストで15%、非英語テキストで最大50%のトークン圧縮改善が報告された。
よくある質問（FAQ）
Q1: トークナイザの語彙サイズがAPI料金に影響しますか？ A: 間接的に大きく影響します。語彙が大きいトークナイザほどテキストを少ないトークンで表現できるため、同じ文章でもAPI呼び出しのトークン数（＝課金対象）が減少します。例えばLlama 3（128K語彙）はLlama 2（32K語彙）と比較して日本語テキストで約40%少ないトークンで表現可能です。
Q2: なぜモデルごとにトークナイザが異なるのですか？ A: トークナイザは訓練データの言語分布やモデルの用途に最適化されるためです。英語中心のモデルは英語の圧縮率を優先し、多言語モデルは各言語に均等なトークン割り当てを目指します。また、コード特化モデルではプログラミング言語のキーワードや構文を効率的にトークン化する設計が採用されます。
Q3: トークナイザを後から変更できますか？ A: 原則として不可能です。トークナイザはモデルのEmbedding層と密結合しており、語彙を変更すると全パラメータの再学習が必要です。ただし、既存語彙にトークンを追加する「語彙拡張」は限定的に可能で、新言語対応やドメイン特化に利用されます（追加トークンのEmbeddingのみ再学習）。
Q4: 日本語はなぜトークン数が多くなりがちですか？ A: 英語中心の訓練データで構築された語彙では、日本語の漢字・ひらがな・カタカナの組み合わせが十分にカバーされず、1文字ずつまたはバイト単位に分割されるためです。Llama 2では「東京」が4-6トークンに分割されていましたが、語彙拡張されたLlama 3では1-2トークンで表現可能になりました。
まとめ
- トークナイザはLLMの入出力を規定する基盤アーキテクチャ
- BPE（GPT/Llama系）とUnigram（Gemma/Gemini系）が2大主流
- 語彙サイズは32K-256Kの範囲で、大語彙ほど圧縮率・多言語性能が向上
- 語彙設計はAPI料金・推論速度・多言語性能に直結する重要な設計判断
- トークナイザの後からの変更は事実上不可能、初期設計が極めて重要