LLMトークナイザー
性能改善研究

PFNの知見から学ぶ「予測しやすい語彙」と
形態素解析フリーへの挑戦

azutake・2026/01/15

【導入: 1分】
・今回は「LLMトークナイザー性能改善研究」というテーマで話していこうと思います。
・LLMの性能はモデルサイズだけでなく、「どう言葉を区切るか」に大きく依存しており、ここを改善するだけでも性能の飛躍的向上が見込めます。
・PFNの事例や、Meta BLTの課題、そしてこの研究のコアである、独自の解決策について話していきます。

echo $(whoami)

01 / 15

azutake

X: @azutake_dev / Bluesky: @azutake.nicovideo.dev

ADHD持ちのコンサータが欠かせないヤク中。

株式会社ドワンゴ所属（課金システム周り 兼 カスタムキャスト企画開発）
※業務で研究開発は行っていません

個人活動

  • オンプレ(自宅)に構築したk8sやゲームサーバーなどの運用
  • リバースエンジニアリング
  • (LLMに限らず)研究開発

研究について(Disclaimer)

  • 機械学習は10年ほど独学で勉強・研究していますが、これまで業務で携わったことは無く、あくまでアマチュアです。
  • また、独学故に応用中心によるTry&Errorのため、基礎知識が浅い部分が多々あります。
  • 今回の研究も個人活動の一環で行っており、所属企業とは一切関係ありません。
【自己紹介: 1分】
・まずは簡単な自己紹介で、アズタケと申します。普段はドワンゴで課金システムの開発をしていますが、
・個人でLLMの研究開発やサーバー運用などを行っています。
・あとは面白そうだと思ったことは何でも飛びつく性格なので、割と何でも手を出してたりします。
・あとADHD持ちで、ワーキングメモリが弱いので、一応カンニングペーパーは用意したんですが、
スライドごとに記憶がリセットされがちなので、フィラーを多用するかもですが、多めに見てもらえると助かります。
azutake avatar

1. 背景：BPEトークナイザーの課題

02 / 15

ChatGPTやGeminiの現状

主流のBPE (Byte Pair Encoding) は、データ量に依存して結合ルールを学習する。

英語 (High Resource)

データが豊富で、適切な単語単位でトークン化されやすい。

Example → [Example] (1 token)

日本語 (Low Resource)

相対的にデータが少なく、結合が進まない。

例えば → [例][え][ば] (3 tokens)

→ 1文字1トークンになりがち。

問題点: 日本語は同じ情報を表現するのに必要なトークン数が多く、
推論速度（レスポンス）が遅くなり、コンテキストウィンドウも圧迫する。

【BPEの課題: 2分】
・一般的に使われているBPEですが、日本語には不利な側面があります。
・英語は1単語1トークンで綺麗に収まりますが、日本語はデータ量の差で細切れになりがちです。
・これはAPIコストや生成速度に直結する重要な問題です。
・例えば、LLMが日々進化している今でも、プロンプトにはよく英語が用いられています。これは、英語の方が効率的にトークン化できるからです。
・でも、実際には英語には無いニュアンスがあるので、日本語でも効率的に扱いたいというニーズがあります。

2. 効率と性能のトレードオフ

03 / 15

「トークン効率を上げれば良い」のか？

⚠️ 失敗例：過度な圧縮

[美味しい] vs [美味い]

これらを別々の巨大な1トークンとして登録してしまうと、
共通の「美味」という概念をモデルが捉えにくくなり、汎化性能が低下する。

【圧縮のジレンマ: 2分】
・じゃあ無理やりくっつければいいかというと、そうではありません。
・「美味しい」と「美味い」を別々のIDにすると、共通する概念が失われます。
・LLMは、「言葉」をそのまま理解しているわけではなく、IDの集合として理解しています。なので、闇雲に圧縮すると、似た言葉が全く別の物として扱われ、学習効率が落ちてしまいます。
・つまり、処理の効率と理解のしやすさはトレードオフの関係にあるわけです。

3. PFNのアプローチ：形態素解析による調整

04 / 15

PFN (Plamo-2) は、「LLMにとって都合の良い分割」を経験則に基づいて定義した。

形態素解析を使うことで、英語・日本語共にトークン効率とLLMの理解しやすさを調整している

人間によるバランス調整

  • 複合語 (新車): [新] + [車] に分割。
    → 他の語彙と意味を共有させる。
  • 単一語 (キャベツ): [キャベツ] で1つ。
    → 分割しても意味がないものは圧縮。

「形態素解析」をアンカーにすることで、
過度な圧縮を防ぎつつ効率を高めることに成功。

【PFNの解: 2分】
・PFNはこの問題を「形態素解析」で解決しました。
・人間が理解できる「意味の単位」で区切ることで、モデルにとっても理解しやすく、かつ効率的な分割を実現しています。

4. 既存アプローチに残る「3つの壁」

05 / 15

形態素解析ベースの手法には、運用・拡張における重大な課題がある。

① 未知語・新語への対応コスト

「きゅんです」「ぴえん」のような新語が出るたびに辞書メンテが必要。
辞書にない言葉は意図しない分割になり、性能劣化の原因になる。

② パフォーマンスコスト

大規模コーパスから語彙を収集する際、全テキストに対して形態素解析を実行する必要があり、前処理時間が膨大になる。

③ 多言語展開の壁

言語ごとに最適な解析エンジン（MeCab, Sudachi, SentencePiece等）を選定・チューニングする必要があり、スケーラビリティがない。

【課題提起: 2分】
・しかし、この手法には運用上の壁があります。
・新語への対応、計算コスト、そして何より「言語ごとにエンジンを用意する」という手間です。
・世界中の言語に対応しようとした時、これでは破綻します。
・特に当初はPFNのやり方を真似しようとしましたが、自然言語処理が盛んでない言語では形態素解析器が存在しないか、精度が低くて話になりませんでした。
・また、各言語ごとの形態素解析を一つのドキュメントで全て実行する必要もあり、前処理の速度も課題になりました。
・例えば、Plamo2も英語と日本語に対しては非常に強いですが、アジア圏でも韓国語や中国語はトークンがイマイチでした。

5. 別の道：Meta BLTの試みと課題

06 / 15

Meta BLT (Byte Latent Transformer)

トークナイザーを廃止し、バイト列を直接パッチ化して処理する手法。

BLTのアプローチ

文字をバイト(0-255)で扱い、固定長のパッチにまとめてエンコード。

BLTの不都合な真実

  • ASCIIバイアス: 1バイト文字(英語)に有利。
  • 固定パッチサイズ (Hyperparameter):
    「何文字を1パッチにするか」を人間が決める必要がある。
    英語なら4文字、日本語なら2文字が最適...といった言語差に対応できない。

多言語対応において、「固定長」で区切ることは本質的な解決にならない。

【BLTの深掘り: 2分】
・近しい取り組みとして、MetaのBLTについても実験を行いましたが、ココにも罠がありました。
・特に「パッチサイズ」の問題です。BLTはハイパーパラメータで、「何文字まとめるか」を人間が決める必要があります。
・英語と日本語では情報の密度が違うため、固定長で切るとどちらかが犠牲になります。
・あと、バイトベースなのでASCII、つまり英語に有利で、マルチバイト文字には不利だったことも課題でした。

6. CLTの全体アーキテクチャ

07 / 15

これらの課題を解決するために考案したのが、
Character Latent Transformer (CLT) です。

1. Input

Raw Text

(Unicode)
→

2. Decompose

High/Low Byte

(Unicode分解)
→

3. CIF

Encoder

(動的圧縮)
→

4. Latent

Concepts

(LLM入力)

設計思想 (Core Concepts)

  • Unicode分解: バイトではなく文字ベースで公平化。
  • CIF (動的圧縮): 固定長パッチを廃止し、情報密度で区切る。
  • Latent Prior: 圧縮された「概念」をLLMが処理する。

BLTの「パッチサイズ固定」問題を
CIFによる「動的区切り」で解決するアプローチです。

【CLTアーキテクチャ説明: 2分】
・BLTの課題を受けて設計したのが、このCLTです。
・まず入力をUTF-32のUnicodeで分解し、ASCIIバイアスを消します。
・次に、BLTでの課題としてあった、「パッチサイズ」の問題を取り除くために、「CIF」というモジュールを通します。
・ここで動的に情報を圧縮し、「概念（Latent）」を作ってからLLMに渡す、というパイプライン構成にしました。
・こうすることで、多言語に対しても柔軟に対応できるようになり、更に一度概念化することで、CLTとLLMを分離出来るようにしようと考えて実験を行いました。

7. 技術詳細：動的な区切り (CIF)

08 / 15

CLTの核となる技術、Continuous Integrate-and-Fire (CIF) の仕組み。

Input: "a"
Weight: 0.2
+
Input: "nt"
FIRE!
→
Token: "ant"

動作原理

  • 情報量（予測の難しさ）をバケツに溜めていく。
  • 閾値を超えたら「発火」して区切る。

メリット

  • ハイパーパラメータ不要: 言語ごとの最適な長さを人間が決める必要がない。
  • 完全なデータ駆動: 英語でも日本語でも、その言語の情報密度に合わせて勝手に区切る。
【CIFの解説: 2分】
・唐突にCIFという言葉が出てきましたが、これは音声認識のSpeech-transformerなどでよく使われている技術で、可変長の情報を扱うためのメカニズムです。
・CIFを簡単に説明すると、「コップに水を溜める」ようなものだと言えて、
・文字を読んでいって、「まだ意味が続くな」と思ったら水を溜める。
・予測困難な箇所、例えば意味の切れ目などで水が溢れ、そこで区切ります。
・これにより、固定長ではなく、情報の密度に応じた「人間らしい」区切りが可能になる、というわけです。
・こうすることで、BLTの課題であった「パッチサイズ」を人間が決める必要が無くなるし、単語ごとの情報密度に応じた区切りが出来るようになると考えて導入しました。

8. 検証結果：フルCLTの限界

09 / 15

検証したフルアーキテクチャ

[CLT Encoder] → [Prior Layer] → [LLM] → [CLT Decoder]

✅ 意図通りの動作

  • CIFは機能し、可変長の「概念(Prior)」が生成された。
  • 生の文字ではなく「概念」のみを使って学習・推論を実施。

❌ 致命的なコスト

  • Next Token Prediction が難解:
    「概念」の境界が動的に変わるため、Prior Model (次トークン予測) の学習が極めて不安定。
  • 収束に莫大な計算資源が必要で実用的ではない。
【失敗談: 1分】
・理想的なアーキテクチャが組めたと思ってワクワクしながら実験を開始したら、一応試み自体は成功しました。
・確かに、CIFもEncoderも期待通りに動いて、Unicodeから「概念」を生成し、LLMで推論することが出来ました。
・これが行えることで、いわゆるストロベリー問題もBLT同様に対応出来ましたし、推論コストもトークンベースと比べても大差が無く、モデルとしては成功でした。
・ただ、学習コストが異常なまでに高く、数十GB程度の小規模なデータセットでも、
Prior Modelの学習が非常に不安定で、推定で従来の1000倍以上の学習コストがかかることが発覚しました。
・人間の脳みたいに文脈も一切無い「概念」を元に予測し続けるのは、LLMにとって荷が重すぎました。
・ちなみに余談ですが、一般的にLLMで学習初期にある「単純に同じトークンを繰り返す」のではなく、
「似た文字の言葉をどんどん繋げていく言葉遊び」みたいなことが自然に発生したのがかなり面白かったです。

9. 発想の転換

10 / 15

Prior Modelによる「概念生成」を行う

⬇

Encoderによる「区切り(Segmentation)」のみを利用する

新しい仮説

CLT Encoderは「予測しやすさ」に基づいて区切っているはず。
→ その区切り結果を集めれば、PFNが求めていた「理想的な語彙」になるのでは？

【ピボット: 1分】
・このままでは、理論上実現出来ることを証明しただけで到底実用化出来ないので、一度原点に立って一番優先すべきことを再整理しました。
・考えた結果浮かんだのが、「開発者のバイアスを排除し、データ駆動で理想的な区切りを見つける」という本来の目的に立ち返ることでした。
・つまり、このアーキテクチャ丸ごとでの「生成」はやめて、「区切り方」だけを拝借しようと。
・Encoderがエントロピーに基づいて切った結果は、人間が苦労して形態素解析で作っていたものと同じか、それよりも良くなるはずだ、という仮説です。

10. 発見：Neural Vocab の品質

11 / 15

従来のBPEの傾向 (頻度ベース)

「たくさん出てくる形」をそのまま覚える

starting (1 token)
looked (1 token)

CLTの傾向 (エントロピーベース)

「意味の最小単位」で切れている

start + ing ← 接尾辞を分離
look + ed ← 過去形を分離

フィルタリング無しで、言語構造（Stem + Suffix）を自動発見。
PFNが目指した「意味のある分割」をデータのみで再現した。

【結果の強調: 2分】
・結果はご覧の通りです。
・CLTは教師無しでも、startとingを分けました。
・これはPFNが「新車」を分けたかった意図と完全に一致します。
・しかも、今回はPDCAの都合上英語メインのデータセットを使いましたが、これを英語だけでなく全言語で自動的に行えるのです。
・PFNはまとめ記事で使われている「名無しさん」を人間がフィルタリングして無意味な語彙が入らないようにしていましたが、 CLTはそんなことをしなくても自然に意味のある分割が実際に行えました。
・以上のことから、CLT Encoderが捉えている情報理論的な区切りは、人間が定義した形態素解析に非常に近く、形態素解析フリーな語彙生成器として機能することが分かりました。
・また、エントロピーモデルの作成はコストが非常に低いため、人間による膨大な手作業によるフィルタリング不要で、運用コストの大幅削減も期待できると考えています。

11. 実装：エイホーコラシック法

12 / 15

抽出された「Neural Vocab」をどう使うか？

× BPE (Byte Pair Encoding)

頻度による「再結合」を行ってしまうため、せっかくCLTが見つけた自然な区切り（例: ingの分離）を壊してしまう恐れがある。

○ エイホーコラシック法

生成された語彙を辞書として、トライ木を用いた最長一致を行う。

メリット:
CLTの意図した「意味分割」を100%再現しつつ、高速なトークナイズが可能。

【実装詳細: 1分】
・続いて、この語彙を実際にどう使うかも検討しました。
・この時点で語彙は既に出来上がっているので、あとはそれを使ってテキストをトークナイズするだけです。
・BPEで再学習させると元も子もないので、rustでエイホーコラシック法を使って、語彙データを辞書としてトークナイズする処理を実装して対応しました。

12. アプローチの比較まとめ

13 / 15
項目 PFN (Morphological) CLT (Entropy/CIF)
原理 言語学的知識 (辞書) 情報理論 (予測確率)
分割基準 人間が定義した形態素 データが示す情報密度
新語対応 辞書更新が必要 (コスト大) データさえあれば自動対応
多言語対応 言語ごとにエンジンが必要 全言語共通アーキテクチャ
「形態素解析フリー」による
開発者バイアスの排除と言語平等の実現
【総括: 2分】
・最後に比較です。
・PFNの手法は長年培われた辞書による「正解」をベースとし、人間がフィルタしているので、新語への対応などコストが非常に高いですが、
・CLTの手法は「データ」にだけ従うので、とにかく大量のデータを食わせ続けるだけで、低コストで、あらゆる言語に適用可能だというのが、実験で確認出来ました。

13. 結論と今後の展望

14 / 15
【結び: 1分】
・今回のまとめです。
・完全なEnd-to-Endモデルを作成するのは困難なため断念しましたが、
・この技術を使えば、開発者が言語ごとに調整することなく、高品質なLLMが作れるようになると考えています。
・全世界の情報に1秒未満でアクセスできる昨今、言葉の壁は重大な課題だと思っているので、真の多言語対応AIの実現に向け、これからも研究を続けていこうと思います。
・ご清聴ありがとうございました。

Thank You

Q & A