トークナイザとは何か？基本定義からサブワード手法と日本語対応・実装ガイドまで
エバープレイ編集部トークナイザとは — 基本定義
トークナイザ（tokenizer）は、自然言語処理（NLP）において生のテキストを「トークン」と呼ばれる単位に分割するソフトウェアやアルゴリズムのことです。トークンは単語・部分語（サブワード）・文字・バイトなど様々な粒度があり、モデルや用途に応じて設計されます。トークナイゼーションは、前処理の一部であると同時にモデルの性能や計算コスト、語彙設計に大きく影響します。
なぜトークナイザが重要か
語彙サイズと一般化：語彙を単語ごとにすると語彙数が膨大になり、希少語（OOV: Out-Of-Vocabulary）が増える。サブワード手法は希少語を再現可能にしつつ語彙を抑える。
計算コストとトークン数：トークン数はモデルの入力長に直結し、推論時間や料金（クラウド/LLM）に影響する。英語では1トークンは概ね4文字程度とされるケースが多い（モデルや資料による）。
多言語対応：言語ごとの形態的特性（スペースの有無、語形変化、文字体系）に適した手法選択が必要。
トークナイザの主な種類
ホワイトスペース/正規表現ベース：空白や句読点で単純に分割する。高速だが日本語など空白のない言語には不向き。
形態素解析（モルフォロジカル）ベース：日本語などでMeCabやSudachi、Kuromoji等を用いて語彙素に分け、品詞や基本形を取得する。言語依存の精度は高いが辞書や設定に依存。
文字単位：文字ごとに分ける。語彙は小さいがシーケンス長が長くなりやすい。
サブワード（部分語）手法：BPE、WordPiece、Unigramなど。現在の多くのニューラルモデルで標準的に使われる。語彙数と未知語処理のバランスが良い。
バイト/バイトレベルBPE：テキストをバイト列として扱うことでUnicodeや未知文字に頑健（例：GPT-2のbyte-level BPE）。
代表的なサブワード手法
サブワード手法は、頻出の文字列を語彙として保持し、未知語を既存のサブワードの組み合わせで表現します。主な手法と特徴は次の通りです。
BPE（Byte Pair Encoding）
原理はデータ圧縮のBPEを応用し、頻出する隣接文字列（ペア）を逐次結合して語彙を作る。学習時にマージを繰り返し語彙を得るため、高頻度の語句は単一トークンになり、低頻度は分割される。機械翻訳や多くの実装で使われる（Sennrich et al., 2015）。
WordPiece
GoogleのWordPieceは確率論的な語彙構築手法で、ある語を分割したときの尤度を最大化するように語彙を構築する。BERTなどで広く採用され、接頭辞/接尾辞の表現に強い設計になっている（Schuster & Nakajima 等）。
Unigram（確率モデル）
SentencePieceで採用されるUnigram言語モデルは、候補サブワード集合から尤度に基づいて語彙を選択する。分割の確率を直接扱えるためサブワードの多様性や正則化（subword regularization）との相性が良い（Kudo & Richardson）。
実装とライブラリ
SentencePiece：Googleのツール。文字列正規化から語彙学習（BPE/Unigram）・エンコーディングまで一貫して行える。言語非依存で日本語の前処理にも使われる。
Hugging Face Tokenizers：Rustで高速実装されたライブラリ。BPE/WordPiece/Unigram等をサポートしPython/Node等から利用可能。
MeCab / Sudachi / Kuromoji / Juman++：日本語の形態素解析器。辞書を切り替えて語彙や分割粒度を調整できる。
日本語の特殊性と対処法
日本語は単語間にスペースを持たないため分割が難しく、形態素解析器による分割が古典的に用いられてきました。しかし近年はSentencePiece等のサブワード手法を直接生テキストに適用するケースも増えています。
形態素解析を先に行い、得られた語彙をさらにサブワード分割するハイブリッド手法が精度的に有利な場合がある。
形態素解析は固有名詞や新語に弱い一方、サブワードはそれらを柔軟に扱えるが語彙意味の切れ目を必ずしも反映しない。
特殊トークンと後処理
多くのモデルは[CLS], [SEP], , ,
トークン数とコストの実務的影響
LLMの利用では「トークン数＝課金・制限」に直結します。英語では概ね1トークンが4文字前後とされますが、言語・文字コードにより変わるため、実運用では対象データで実測することが大事です。長文処理やストリーミング、要約、検索インデックス設計などにおいてトークン効率は重要です。
設計上の注意点とベストプラクティス
用途に応じた粒度選択：分類や検索なら粗め（語彙寄り）、ニューラル生成や翻訳ならサブワードが無難。
正規化とUnicode：NFKCなどの正規化で表記ゆれを抑える。ただし言語固有の正規化（日本語の長音符等）には注意。
同一語彙での学習・推論の整合性：学習時のトークナイザと推論時のトークナイザは同一化すること。そうでないと語彙ミスマッチや性能低下を招く。
トークン化の可逆性：生成タスクではデトークナイズで意味を破壊しないことが重要。
簡単な例（英語・日本語）
英語例："unbelievable"
単語分割：["unbelievable"]（未学習語が問題）
WordPiece：["un", "##believable"] または ["un", "##believ", "##able"]（語幹や接辞を表現）
BPE：頻度により ["unbel", "ievable"] のように分かれる可能性あり
日本語例："自然言語処理"
形態素解析：["自然", "言語", "処理"]
SentencePiece（サブワード）：["▁自然", "▁言語", "処", "理"] のように空白記号で語境界を示す形式が一般的
まとめ
トークナイザは単なる前処理ではなく、モデル性能、コスト、多言語対応性に深く関わる重要なコンポーネントです。用途や対象言語、運用上の制約を踏まえて、ホワイトスペース・形態素解析・サブワード（BPE/WordPiece/Unigram）・バイトレベルなどから最適な手法を選ぶ必要があります。また、学習・推論で同じトークナイザを使うこと、正規化や特殊トークンの扱いを明確にすることが実務上の基本ルールです。
参考文献
- SentencePiece（GitHub）
- Hugging Face Tokenizers（GitHub）
- Sennrich, Haddow & Birch, "Neural Machine Translation of Rare Words with Subword Units" (BPE)
- Devlin et al., "BERT: Pre-training of Deep Bidirectional Transformers"（WordPiece採用の事例）
- OpenAI GPT-2 byte-level BPE 実装（参考）
- OpenAI API（トークン換算の目安など）
- MeCab（形態素解析器）
- Sudachi（日本語形態素解析）
投稿者プロフィール
