Llama-3、その圧倒的な性能の裏にある「日本語の壁」
日々、AIモデルの進化が続く中、多くの企業が最適な基盤モデルの選定と実装という課題に直面しています。最新のLLM（大規模言語モデル）を実際の業務プロセスやプロダクトに組み込もうと試行錯誤している開発現場や、次世代のシステム基盤を模索しているリーダーの方々にとって、Llamaシリーズの進化は常に注目の的です。
Llama 3の登場以降、その進化は目覚ましく、現在では128kコンテキストに対応したLlama 3.3や、MoE（Mixture of Experts）アーキテクチャを採用し最大1,000万トークンの長文脈を処理できるLlama 4など、圧倒的な性能を持つモデルが次々とリリースされています。小規模なパラメータサイズであっても、かつての巨大モデルに匹敵する推論能力を発揮する場面も珍しくありません。
しかし、実際にこれらのモデルへ日本語のタスクを入力してみると、ある実務的な課題に気づくはずです。
「レスポンスに時間がかかっているのではないか」
「APIの課金トークン数が、想定よりも膨らんでいないか」
実際のところ、Llama 3.3をはじめとする最新のLlamaシリーズは、英語においては極めて効率的ですが、日本語処理においては依然として「重い」という課題を抱えています。これはモデル自体の推論能力が低いわけではありません。モデルがテキストデータを認識するための窓口、すなわち「トークナイザー（Tokenizer）」の設計に起因しています。英語を中心に最適化されているため、日本語のテキストを処理する際にトークン数が膨張してしまうのです。
「日本語をもっと速く、コストを抑えて処理させたい」。現場の課題解決を最優先に考えた時、多くの開発チームが辿り着くのが「トークナイザー拡張（語彙追加）」という手法です。既存の辞書に日本語の語彙を追加し、処理の効率化を図るアプローチです。実際、Llama 3.1 SwallowやLlama-3-ELYZA-JP-8Bといった日本語強化モデルは、こうした技術や継続事前学習を駆使して生み出されています。また、日本語中心の業務であれば、最初から多言語対応に優れたQwen3系モデルを優先的に採用するという選択肢も有力です。
技術的な観点から言えば、トークナイザー拡張の効果は絶大です。適切に実装できれば推論速度は大幅に向上し、運用コストの削減にも直結します。しかし同時に、システム全体に影響を与えるリスクを伴うアプローチでもあります。安易に語彙を追加して再学習を施せば、せっかくのLlamaシリーズが持つ本来の高度な推論能力や汎用性を損なってしまうことになりかねません。
この「トークナイザー拡張」という技術の仕組みと、それに伴う技術的な代償を構造的に捉えることは、実運用において非常に重要です。単なる手順の紹介にとどまらず、なぜそれが有効なのか、そして導入によって何が犠牲になる可能性があるのか。システム全体を俯瞰し、理論と実践の両面から最適解を導き出すための判断材料を提示します。
なぜLlama-3は日本語処理が「非効率」なのか
まずは技術的な背景から整理していきましょう。なぜLlamaシリーズ（Llama 3.3やLlama 4など）は、デフォルトの状態だと日本語処理が非効率になりがちなのでしょうか。
英語中心モデルにおける日本語トークンの断片化問題
Llamaシリーズの最新モデルが採用しているトークナイザーは、OpenAIの主力モデルであるGPT-5.2（GPT-4oなどの旧モデルは2026年2月に廃止されました）でも採用されているTikToken（BPE: Byte Pair Encodingベース）の派生形です。このトークナイザーは、約128,000語彙（Vocab Size）を持っています。すでに公式で廃止・後継扱いとなっている旧世代のLlama 2が32,000語彙だったことと比較すると、表現力は4倍に増えています。
「12万語彙もあるなら、日本語も十分カバーされているのではないか」と期待されるかもしれませんが、実際の挙動は異なります。この128kの語彙の大半は、英語やコード、そして一部の多言語トークンに割り当てられており、日本語専用の単語は驚くほど少ないのが実情です。
結果として、日本語の文章は意味のある単語単位ではなく、意味を持たない細かいバイト列や文字単位にバラバラに分解されてしまいます。
例えば、「人工知能」という言葉を例に挙げます。
日本語特化のトークナイザー（例えばLlama-3.1-Swallowなどで採用される拡張トークナイザー）なら、「人工知能」で1トークン、あるいは「人工」「知能」で2トークンで処理できます。
しかし、Llamaシリーズのデフォルトトークナイザーでは、極端な場合、漢字1文字ずつ、あるいはバイト単位に分解され、5〜6トークン以上を消費してしまうことがあるのです。
バイトフォールバックが発生するメカニズム
技術的に少し掘り下げると、これはバイトフォールバック（Byte Fallback）と呼ばれる現象が頻発している状態です。
BPEアルゴリズムは、頻出する文字列をひとまとめにして1つのトークンとして登録します。しかし、語彙リストに存在しない文字列（未知語）が入力された場合、それを構成するUTF-8のバイト列まで分解して表現しようとします。
日本語の漢字は、UTF-8では通常3バイトで表現されます。もしその漢字が語彙リストになければ、モデルはそれを3つの別々のトークン（各1バイト）として処理せざるを得ない場合があります。これが「1文字＝3トークン」という非効率なケースを生む原因です。
Llama 3以降のモデルでは、旧世代（Llama 2）に比べて日本語の圧縮率は改善されていますが、それでも英語に比べれば非効率です。英語が1単語≒1.3トークン程度であるのに対し、日本語は1文字≒1〜1.5トークン程度消費することもあります。
トークン効率が推論速度とAPIコストに与える定量的インパクト
「トークン数が増えるだけなら、計算リソースを増やせば解決するのではないか」と思われるかもしれません。しかし、LLMにおいてトークン数の増加は、以下の3つの実務的なコスト増に直結します。
推論レイテンシ（速度）の悪化
LLMは「次の1トークン」を予測して生成する処理を繰り返します。同じ意味の文章を生成するのに、英語なら100回で済むループが、日本語だと200回必要になるということです。単純計算で、生成時間は2倍かかります。業務システムやユーザー体験（UX）において、この遅延は大きな課題となります。コンテキストウィンドウの実質的な縮小
Llama 3.3では最大128kトークン、Llama 4では最大100万（1M）トークンまで対応するよう拡張されていますが、トークン効率が悪いということは、同じトークン数の枠内に入れられる日本語の情報量が英語に比べて大幅に少なくなることを意味します。RAG（検索拡張生成）などで多くの社内ドキュメントを読み込ませたい場合、この「実質的な情報密度の低さ」は業務適用の足かせとなります。VRAM消費と計算量
Attention機構の計算量は、シーケンス長（トークン数）の増加に伴って増大します。入力トークンが無駄に長いと、それだけでGPUメモリ（VRAM）を圧迫し、スループットを低下させます。特に軽量モデル（SLM）をオンプレミス環境やエッジデバイスで運用する場合、VRAM容量は厳格な制約条件となるため、無駄なトークン消費は運用上見過ごせない問題です。
システム全体のボトルネックと解決への視点
Meta Llama 公式サイトが提供する技術仕様や、OpenAI 公式ドキュメント - Tokenizer、そしてHugging Face - Tokenizers Documentationなどの公式資料を参照しても明らかですが、トークナイザーが非効率であることは、単なる「文字数」の問題ではありません。それはシステム全体のパフォーマンスと経済合理性を毀損する根本的なボトルネックなのです。この課題を構造的に把握することが、日本語環境におけるLLM最適化の第一歩となります。
トークナイザー拡張の技術的メカニズム
では、この問題を解決するための「トークナイザー拡張」とは、具体的にモデル内部でどのような処理を行っているのでしょうか。ブラックボックスになりがちなこのプロセスを、アーキテクチャの観点から分解してみましょう。
BPE（Byte-Pair Encoding）アルゴリズムの再学習プロセス
まず行うのは、新しい語彙（Vocabulary）の獲得です。これにはSentencePieceやHugging Faceのtokenizersライブラリを使用します。
具体的には、大量の日本語テキストデータを用意し、BPEアルゴリズムを実行します。BPEは、データ内で最も頻繁に隣接して現れるバイトペア（文字の組み合わせ）を統計的に見つけ出し、それを新しいトークンとして登録していきます。
例えば、「東」「京」という文字が頻繁に並んで出てくるなら、「東京」という1つのトークンを作ります。さらに「東京」「都」が頻出すれば、「東京都」というトークンが作られます。
このプロセスを経て、Llama-3が元々持っていなかった「日本語の頻出単語」や「熟語」をリストアップします。通常、数千〜数万語彙を追加することが一般的です。
既存語彙と新規日本語語彙のマージ戦略
次に、Llama-3のオリジナルの語彙リスト（約128k）と、新しく学習した日本語語彙リストを統合（マージ）します。
ここで重要なのは、「重複の排除」と「IDの割り当て」です。オリジナルの語彙にも、偶然日本語が含まれている場合があります。それらと重複しないように新しい日本語語彙を追加し、既存のID（0〜128255）の続きから新しいID（128256〜）を割り振ります。
これにより、語彙サイズ（Vocab Size）は例えば128,256から140,000へと拡張されます。
埋め込み層（Embedding Layer）の次元拡張と初期化手法
ここからがシステム実装における重要なポイントとなります。トークンIDを増やしただけでは、モデルは機能しません。ニューラルネットワークの入口と出口を物理的に拡張する必要があります。
LLMの入力層には、トークンIDをベクトルに変換する埋め込み層（Embedding Layer）が存在します。これは巨大な行列（Matrix）です。
- 変更前:
[128256, hidden_dim](例: 128256行 x 4096列) - 変更後:
[140000, hidden_dim](例: 140000行 x 4096列)
このように行列の行数を増やします。同様に、最終層にあるトークン予測用のヘッド（Unembedding Layer / lm_head）も同じサイズに拡張します。
課題となるのは、「新しく追加した行（拡張部分）の値をどう初期化するか」です。
ここには数値が入っていなければ計算が成立しません。しかし、学習済みモデルには新しい日本語トークンのためのベクトル情報は存在していません。
実務上、一般的に取られる手法は以下の2つです。
- ランダム初期化: ガウス分布などに従ってランダムな小さな値をセットします。最も単純ですが、学習開始直後はモデルにとって「完全なノイズ」となるため、学習が安定するまで時間がかかります。
- 平均値初期化: 既存のトークンの埋め込みベクトルの平均値などを計算してセットします。あるいは、意味的に近い既存トークンのベクトルをコピーします。これにより、学習初期の不安定さを和らげることができます。
この「初期化」のアプローチが、拡張後のモデルの精度を左右する最初の分岐点となります。
「賢さ」と「速さ」のトレードオフ：拡張のリスク要因
仕組みとしては「枠を広げて、新しい単語を登録した」状態になります。しかし、冒頭で述べた通り、ここには運用を見据えた上で考慮すべき大きなリスクが存在します。
語彙サイズ増大によるパラメータ数の増加とメモリ負荷
まず、物理的なリソースへの影響です。語彙サイズを増やすと、モデル全体のパラメータ数が増加します。
「数万語彙増やす程度であれば、数十億パラメータのモデルにおいては誤差の範囲ではないか」と思われるかもしれません。しかし、Embedding層とlm_head層は非常に巨大です。例えば、隠れ層の次元（hidden_dim）が4096で、語彙を2万増やした場合、20,000 x 4096 x 2（入力+出力）個のパラメータが増加します。これだけで約1.6億パラメータの増加となります。
これは、推論時のVRAM使用量の増加に直結します。リソースが限られているエッジデバイスや小規模なGPUインスタンスで運用する場合、この増加がOOM（Out Of Memory）を引き起こす原因になり得るため、インフラ設計の段階で注意が必要です。
埋め込み層の学習不足による「未知語」状態の回避
さらに深刻なのは、「枠は作ったが、中身は空っぽ（あるいはノイズ）」という状態からスタートすることです。
新しく追加された日本語トークン（例: ID 130001 = "人工知能"）に対応する埋め込みベクトルは、初期化時点ではランダムな値か平均値です。モデルにとって、このベクトルはまだ「人工知能」という正確な意味を持っていません。
そのため、トークナイザー拡張を行った後は、必ず継続事前学習（Continued Pre-training）を行う必要があります。大量の日本語テキストを学習させ、新しく追加したトークンのベクトルを、文脈の中で適切な位置（意味空間上の座標）に最適化していくプロセスが不可欠です。
この学習プロセスが不十分だと、モデルは新しいトークンを適切に処理できず、出力が不自然になったり、以前よりも推論能力が低下したりする結果を招きます。拡張後に性能が落ちたというケースの大半は、この学習不足に起因しています。
破滅的忘却（Catastrophic Forgetting）のリスクと対策
そして、モデルの汎用性を維持する上で最大のリスクとなるのが「破滅的忘却」です。
新しい日本語トークンを学習させるために、日本語データばかりを大量に入力すると、モデルは元々持っていた英語の知識や、論理的思考能力、プログラミング能力などを急速に失っていく傾向があります。
埋め込み層だけでなく、Transformerブロック内部の重みも更新されるため、モデル全体の知識バランスが崩れてしまうのです。
これを防ぐためには、学習データセットの構成（Data Mixture）に細心の注意を払う必要があります。日本語データだけでなく、元のモデルの能力を維持するための高品質な英語データやコードデータも、適切な割合で混ぜて学習させる必要があります。
「日本語処理を効率化したいだけなのに、なぜ英語のデータまで用意して再学習させなければならないのか」と感じるかもしれません。しかし、これがニューラルネットワークの特性です。特定の能力を向上させるためには、システム全体のバランスを再調整するコストが求められるのです。
拡張効果の測定：圧縮率とダウンストリームタスクへの影響
リスクを考慮した上で拡張を実施する場合、その効果を定量的にどう測定し、評価すべきかを解説します。
Fertility Score（トークン化効率）の改善測定
トークナイザーの効率を測る指標として、Fertility Scoreや単純な圧縮率が用いられます。
これは「元のテキストの文字数（またはバイト数）」に対して「トークン数がいくつになったか」の比率を示すものです。
- 指標: 文字数 / トークン数 （数値が高いほど、1トークンあたりの情報量が多いことを示します）
- Llama-3デフォルト: 日本語環境では 0.7〜0.9 程度（1文字が1トークン以上になる傾向）
- 拡張後: 日本語特化の調整により 1.5〜2.0 程度を目指すことが一般的です。
実際に、適切な拡張を行うことで、同じ日本語テキストを表現するのに必要なトークン数を半分以下（約40%〜50%削減）に抑えられる事例が多く報告されています。
日本語テキストの圧縮率と推論速度の相関
トークン数が半分になれば、理論上、生成速度（スループット）は約2倍に向上します。
- Before: 100文字生成するのに150トークン処理 → 15秒かかる
- After: 100文字生成するのに70トークン処理 → 7秒で完了する
これはAPI利用コストの削減に寄与するだけでなく、社内システムや対話型アプリケーションにおいて、ユーザーの体感速度を劇的に向上させます。業務効率化の観点からも、トークン効率の改善は非常に大きな価値を持ちます。
言語理解能力への波及効果
さらに注目すべき点は、トークン化が適切に行われることで、モデルの言語理解能力（JGLUEなどのベンチマークスコア）が向上する可能性があるということです。
バラバラの文字単位で処理するよりも、意味のまとまり（単語）単位で処理した方が、モデルが文脈を構造的に捉えやすくなるためです。「東」「京」「都」と3回に分けて処理するより、「東京都」と1回で処理した方が、アテンションの計算もシンプルになり、離れた文脈との関係性も学習しやすくなります。
ただし、これは十分な継続事前学習が実施された場合に限られます。不十分な学習状態では、逆にスコアが低下するリスクがある点には留意が必要です。
自社LLM構築におけるトークナイザー戦略の決定プロセス
最後に、実際のシステム開発やAI導入の現場において、トークナイザー拡張を行うべきかどうかの判断基準を整理します。
拡張すべきケース vs デフォルトで十分なケース
【拡張を検討すべきケース】
- 大規模な推論基盤を運用する予定がある: 推論コスト（GPU稼働時間など）がビジネスの収益性を圧迫する場合、初期の学習コストを投資してでも、運用時の効率（トークン削減）を優先すべきです。
- 特定のドメインに特化している: 医療、法律、製造業など、専門用語が頻出する業務領域では、それらを1トークンとして登録することで、認識精度と処理速度の両方を大幅に改善できます。
- 十分な計算リソースとデータ基盤がある: 数十億〜数千億トークン規模の継続事前学習を安定して実行できる環境が整っている場合。
【デフォルト（またはLoRA等の軽量チューニング）で十分なケース】
- プロトタイプ開発や小規模な社内ツール: 推論速度に対する要件がそれほど厳格でない場合。
- 学習リソースが限られている: フルパラメータチューニングや大規模な継続学習の実施が難しい場合は、トークナイザーの構造には手を加えず、プロンプトエンジニアリングやRAG（検索拡張生成）の工夫で対応する方が安全かつ確実です。
- 多言語対応や汎用性を維持したい: グローバルな業務環境で使用する場合、過度に日本語へ特化させると本来の汎用性が損なわれる可能性があります。
ドメイン特化（医療・法務等）における専門用語追加の意義
特に、B2Bの業務システムにおいては「専門用語」の扱いがシステム精度の鍵を握ります。
例えば、社内文書に頻出する製品コードや特殊な業界用語。これらがデフォルトのトークナイザーで細切れに分解されていると、検索（RAG）の精度低下を招き、生成時にハルシネーション（幻覚）を引き起こす原因にもなります。
トークナイザー拡張は、単なる速度改善の手段にとどまらず、「自社の業務ドメインの言語体系をモデルに正確に認識させる」ための重要なプロセスと言えます。
フルスクラッチ学習と継続事前学習の分岐点
もし、完全に独自の基盤モデルを構築するという規模のプロジェクトであれば、トークナイザーはゼロから設計（フルスクラッチ）すべきかもしれません。しかし、Llama-3の優れた推論能力の恩恵を受けつつ、自社の業務要件に合わせてカスタマイズしたいのであれば、「Llama-3ベース＋トークナイザー拡張＋継続事前学習」というアプローチが、現在最も現実的で費用対効果の高い戦略と言えるでしょう。
まとめ
Llama-3のトークナイザー拡張は、日本語処理の「重さ」を解消し、業務プロセスを改善するための強力なアプローチです。トークン数を削減し、推論速度を向上させ、コンテキストウィンドウを有効に活用することが可能になります。
しかし、それは無条件に恩恵を得られるわけではありません。埋め込み層の初期化、継続事前学習にかかる計算コスト、そして破滅的忘却のリスク。これらと正面から向き合い、技術的な課題として構造的に解決していく必要があります。
過度な最新技術の押し付けや安易な拡張は、かえってシステムを不安定にします。しかし、導入後の運用までを見据えた戦略的な拡張は、AIプロダクトを真に業務に役立つものへと昇華させる鍵となります。
ぜひ、自社の抱える課題やリソースを俯瞰的に評価し、最適なアーキテクチャを選択してください。もし判断に迷うことがあれば、専門的な知見を持つパートナーに相談するなどして、最新の技術動向や実務的なノウハウを継続的に取り入れることをおすすめします。
理論と実践の両面から技術を正しく活用し、日本語LLMの可能性を実務の現場に広げていきましょう。
コメント