BPEトークナイザー（Byte-Pair Encoding Tokenizer）（ビーピーイートークナイザー）とは？

BPEトークナイザー（Byte-Pair Encoding Tokenizer）とは、テキストを頻出する文字・文字列のパターンで統合しながらサブワード単位に分割するアルゴリズムであり、[LLM（大規模言語モデル）](slug: llm)の入出力コストおよび処理速度に直結する基盤技術である。

アルゴリズムの仕組み

BPEはもともとデータ圧縮の手法として生まれた。これをNLP分野に応用したのが現在のトークナイザーの原型だ。動作原理はシンプルで、まず全文字を個別の単位として扱い、隣接する2つの記号のうち最も出現頻度が高いペアを1つの新しい記号に統合する。この操作を語彙サイズの上限に達するまで繰り返すことで、頻出語はそのまま1トークンに、希少語はサブワードや文字単位に分解される語彙テーブルが完成する。

具体的なプロセスを整理すると次のようになる。

コーパス収集: 学習対象テキストを大量に集め、文字レベルに展開する
頻度カウント: 隣接ペアの出現回数を全コーパスで集計する
マージ操作: 最頻ペアを新トークンとして語彙に追加し、コーパス内の該当箇所を置換する
反復: 設定した語彙サイズ（例: 3万〜10万トークン）に達するまでマージを繰り返す

この結果、「running」は run + ning に、「unhappiness」は un + happiness のように分割され、未知語でも意味のある断片として扱えるようになる。

なぜトークン設計がコストに直結するのか

[トークン（Token）](slug: token)は LLM の課金・速度・コンテキスト長のすべての基準単位となる。同じ文章でも語彙設計の質によってトークン数は大きく変わり、[AI ROI（AI投資対効果）](slug: ai-roi)に直接影響を与える。英語中心の語彙テーブルを日本語テキストに適用すると、漢字1文字が複数トークンに分解されることも珍しくなく、処理コストが数倍に膨らむケースがある。

[マルチリンガルNLP（多言語自然言語処理）](slug: multilingual-nlp)の文脈では、この問題はさらに深刻だ。低リソース言語ではそもそも学習コーパスが少なく、頻出ペアが形成されにくいため、単語が細かいサブワードや文字単位まで分解されやすい。こうした課題への対応策の一つとして、語彙をUnicodeのバイト列上で構築するバイトレベルBPEがある。バイトレベルBPEは未知語を原理的にゼロにできる汎用性を持つ一方、1文あたりのトークン数が増加し、モデルが意味的なまとまりを学習しにくくなるというトレードオフを抱える。

主要モデルでの採用状況と派生手法

GPT系モデルはBPEをベースとした「tiktoken」ライブラリを採用し、Claude や Gemini も独自にチューニングされたサブワードトークナイザーを利用している。近年はBPEとは独立した確率モデルベースのアルゴリズムである Unigram Language Model も広く使われており、SentencePiece はBPEとUnigramの両アルゴリズムを実装したツールキットとして多くのモデルで採用されている。[ベースモデル（Foundation Model）](slug: foundation-model)の設計段階でどのトークナイザーを選択するかが性能に大きく影響する。

[ファインチューニング](slug: fine-tuning)や[PEFT](slug: peft)でモデルをカスタマイズする場合も、ベースモデルのトークナイザーをそのまま引き継ぐのが一般的だ。語彙を後から追加・変更すると埋め込み層の再学習が必要になり、コストが跳ね上がるためである。

実務での注意点

[RAG（Retrieval-Augmented Generation）](slug: rag)パイプラインを構築する際、[チャンクサイズ](slug: chunk-size)の設定はトークン数を基準に行うことが多い。このとき「文字数 ≠ トークン数」という前提を見落とすと、コンテキストウィンドウのオーバーフローや検索精度の低下につながる。特に日本語・中国語・アラビア語など非ラテン系言語では、同じ文字数でも英語の2〜4倍のトークンを消費することがあるため、言語別にトークン換算係数を把握しておくことが望ましい。

また[ハルシネーション（Hallucination）](slug: hallucination)の一因として、トークン分割の粒度が意味境界とずれることが指摘されている。固有名詞や専門用語が不自然に分割されると、モデルが誤った文脈で語を再構成するリスクが高まる。語彙設計の段階でドメイン特化語彙を追加するか、[プロンプトエンジニアリング](slug: prompt-engineering)で表記を統一するかを検討することが、精度向上への現実的なアプローチとなる。