BPE トークナイザー（Byte-Pair Encoding Tokenizer）とは、テキストを頻出パターンに基づいてサブワード単位に分割し、LLM が処理できるトークン列に変換するアルゴリズムである。 英語では高効率に動作する BPE だが、ラオス語・ミャンマー語・クメール語といった低リソース言語では同じ意味内容に対して英語の数倍ものトークンを消費する。この非効率性は API コストの増大だけでなく、翻訳システムのタイムアウトや処理遅延に直結する。

本記事では、LLM を使った多言語翻訳システムを運用するエンジニア・テックリード向けに、BPE トークナイザーが低リソース言語で非効率になるメカニズムを解説し、当社が実際に遭遇したラオス語翻訳のタイムアウト事例をもとに、実践的な設計上の対策を共有する。

BPE トークナイザーの効率は学習コーパスにおける言語の出現頻度に強く依存し、低リソース言語ではバイトレベルの分解が多発してトークン数が膨張する。 このセクションでは、BPE の動作原理から言語間格差が生まれるメカニズムを掘り下げる。

BPE（Byte-Pair Encoding）は、もともとデータ圧縮のために開発されたアルゴリズムを自然言語処理に応用したものだ。動作は以下のステップで進む。

1. テキストを UTF-8 バイト列（または文字列）に分解する
2. コーパス全体で最も頻出する隣接バイトペアを見つける
3. そのペアを 1 つの新しいトークンとして統合する
4. 語彙サイズが上限（たとえば 100,000 トークン）に達するまで 2-3 を繰り返す

英語では "the"、"ing"、"tion" といった頻出パターンが早い段階で統合され、1 単語 = 1〜2 トークンで表現できる。日本語のひらがな・カタカナも一定の統合が進む。しかし、学習コーパスでの出現頻度が低い言語は統合の機会が乏しく、UTF-8 のバイト列がそのまま残る。

たとえば英語の "the" は 1 トークンだが、ラオス語の同等の機能語が 6〜9 トークンに分解される可能性がある。この差がそのまま処理時間とコストの差になる。

ラオス語のトークン効率が低い背景には、4 つの構造的な要因が重なっている。

1. UTF-8 で 1 文字 3 バイト

ラオ文字は Unicode の U+0E80〜U+0EFF に位置し、UTF-8 では 1 文字あたり 3 バイトを消費する。BPE の統合が進んでいなければ、1 文字が最大 3 トークンに分解される。英語の ASCII 文字が 1 バイト = 1 トークン以下で済むのとは対照的だ。

2. 学習コーパスでの出現頻度が極めて低い

BPE の語彙は Common Crawl 等の大規模コーパスから頻度順に構築される。ラオス語のインターネット上のテキスト量は英語と比べて桁違いに少なく、専用のマージ済みトークンがほぼ存在しない可能性が高い。結果として、バイトレベルのフォールバック分解が常態化する。

3. スペースによる単語区切りがない

ラオス語はタイ語と同様に、文中で単語をスペースで区切らない。BPE のプレトークナイゼーション（前処理）はスペースを分割点として利用するため、ラオス語の文全体が 1 つの巨大なプレトークンとして扱われ、効率的な分割が困難になる。

4. 声調記号・結合文字による追加バイト

ラオス語には子音の上下前後に配置される母音記号や声調記号があり、それぞれが独立した Unicode コードポイントを持つ。「1 音節」を表現するのに複数のコードポイント（= 複数の 3 バイト文字）が必要になり、トークン数をさらに押し上げる。

以下は、同じ意味内容を各言語で表現した場合のトークン消費量の目安をまとめたものだ。

学術的な裏付けとして、以下の研究が言語間のトークン効率格差を定量化している。

• Ahia et al. (2023) "Do All Languages Cost the Same? Tokenization in the Era of Commercial Language Models"（EMNLP 2023）: ミャンマー文字・ベンガル語等の低リソース言語で英語比 4〜9 倍のトークン消費を報告
• Petrov et al. (2023) "Language Model Tokenizers Introduce Unfairness Between Languages"（NeurIPS 2023）: 低リソース言語の tokenizer fertility（トークン/単語）が英語の最大 15 倍以上に達するケースを確認。東南アジア・アフリカの言語が最も影響を受ける
• Typhoon プロジェクト: タイ語（ラオス語と同系統の文字体系）で GPT-2 トークナイザーが英語比約 3.8 倍のトークンを消費すると報告

ラオス語単体の公開ベンチマークは限られているが、タイ語より不利な条件（さらに少ない学習データ）を考慮すると、タイ語以上のトークン消費倍率になる可能性が高い。

当社の多言語 CMS で、28 セクションの SEO 記事をラオス語に翻訳した際、480 秒のタイムアウトを超過して処理が失敗した。 英語・タイ語では問題なく完了する同じ記事が、ラオス語でだけ制限時間内に収まらなかった。

当社の翻訳 API は以下の構成で動作していた。

翻訳 API（maxDuration: 480 秒）
├── メタ情報翻訳（title, description, keywords）: 3 並列呼び出し
├── 見出し翻訳: 全見出しを 1 回のバッチで処理
└── 本文翻訳: 5 セクション × 6 バッチ → 逐次処理

本文翻訳のパラメータは以下の通りだった。

英語・タイ語では 1 バッチあたり 30〜60 秒で完了し、6 バッチの合計でも 480 秒に十分な余裕があった。しかしラオス語では、出力トークン数の膨張により各バッチの処理時間が大幅に増加し、6 バッチの累積で制限を超過した。

なお、低リソース言語向けの品質改善策として ja→en→lo のピボット翻訳（英語を中間言語として経由する 2 段階翻訳）を導入済みだった。ピボットの第 1 段階（ja→en）は高速に完了するが、第 2 段階（en→lo）でトークン非効率性の影響を受ける。

タイムアウト超過は単一の原因ではなく、以下の 3 つの要因が重なって発生した。

要因 1: 出力トークンの膨張

BPE トークナイザーがラオス語に対して十分な語彙を持たないため、同じ意味内容でも英語より大幅に多いトークン数を生成する。生成トークン数は処理時間にほぼ比例するため、これが最大の遅延要因となる。

要因 2: モデルの生成効率

トークン数の増加に加えて、低リソース言語の生成ではモデル側の内部処理効率も影響しうる。ただしこの要因は、トークン数の増加と独立に切り分けることが難しく、実測ログでの検証が必要だ。

要因 3: 逐次バッチ設計の遅延累積

5 セクションずつの逐次処理では、各バッチのリクエスト初期化・コンテキスト読み込み・ネットワークラウンドトリップといった固定オーバーヘッドが 6 回分累積する。1 バッチあたりの処理時間が長い言語ほど、この構造的な弱点が露呈する。

当社のケースでは、これら 3 要因の重なりにより、英語で合計 3〜4 分の処理がラオス語では 8 分超に膨れ上がった。

対策の核心は「API 呼び出し回数の削減」と「言語特性に応じた動的パラメータ設計」の 2 つだ。 以下に即効性の高い対策から中長期の改善まで、優先度順に解説する。

最も費用対効果が高いのは、低リソース言語のバッチサイズを拡大し、API 呼び出し回数を減らすことだ。

この変更で、28 セクションの記事に対する API 呼び出し回数が 6 回から 2 回に削減される。1 リクエスト内での連続生成は、複数リクエストに分割するよりもオーバーヘッドが小さいため、合計処理時間の短縮が見込める。

ただし、1 リクエストあたりの出力トークン数は増加するため、maxTokens の上限にも注意が必要になる。低リソース言語では maxTokens を上限値（16,000）に固定し、実測データをもとに最適値を導出するアプローチが現実的だ。

翻訳システムのタイムアウトは複数の層で構成されており、すべての層を整合的に設計する必要がある。

maxDuration の延長は暫定対策であり、セクション数が今後さらに増えた場合に再発するリスクがある。根本的にはバッチ設計の改善（呼び出し回数の削減）が主たる対策であり、タイムアウト延長はそれを補完する安全策として位置づけるのが適切だ。

バッチサイズの拡大とタイムアウト調整で当面の問題は解消できるが、セクション数が 40〜50 に達する長大な記事や、さらにトークン効率の悪い言語が追加された場合に備えて、中長期の改善策も検討しておくべきだ。

ストリーミング翻訳（UX 改善として）

AWS Bedrock の InvokeModelWithResponseStreamCommand を使用すると、生成途中のテキストをチャンクで受信できる。ただし、Vercel ではストリーミング中の経過時間も maxDuration に含まれるため、タイムアウト回避策にはならない。あくまでクライアントへの進捗フィードバック（「翻訳中: 12/28 セクション完了」等の表示）やユーザー体験の改善として活用するのが正しい位置づけだ。

全セクション一括翻訳

28 セクションを 1 回の API 呼び出しで翻訳するアプローチ。セクション区切りのデリミタ（===SECTION_N===）を使い、出力をパースする。API 呼び出しが 1 回になるため固定オーバーヘッドは最小化されるが、maxTokens の上限（16,000）で出力が切れるリスクがある。出力切れ検知 → 残りセクションを 2 回目のバッチで翻訳するフォールバック設計が必要になる。

ラオス語と同様の問題は、ミャンマー語・クメール語・チベット語でも発生する可能性が高い。 タイ語は中リスクだが、現行のタイムアウト設定では問題が顕在化していない。

多言語展開を計画する際は、対象言語を LOW_RESOURCE_LANGS セットに追加するだけで対策が一括適用される設計にしておくことが望ましい。新しい言語を追加する前に、テスト用テキストでトークン消費量を実測し、バッチサイズと maxTokens の適正値を事前に検証すべきだ。

完全には解決しない。SentencePiece（Unigram）や WordPiece など BPE 以外のアルゴリズムも存在するが、いずれも学習コーパスの頻度分布に依存する点は同じだ。低リソース言語のテキストが学習データに少なければ、どのアルゴリズムでも語彙の偏りは生じる。

改善が期待できるのは、対象言語のコーパスを追加して独自のトークナイザーを再学習する手法（Typhoon がタイ語で採用）だが、これは LLM プロバイダー側の対応が必要であり、API ユーザーが直接コントロールできる領域ではない。API ユーザーとしては、トークン効率の差を前提とした設計（バッチ調整・タイムアウト設計）で対応するのが現実的だ。

入力側のトークン効率は改善する。ja→lo の直接翻訳では、日本語のソーステキストの読み取りにもトークンを消費する。ja→en→lo のピボット翻訳を使うと、第 2 段階の入力が英語（最もトークン効率が良い言語）になるため、入力トークンは削減される。

ただし、出力側（ラオス語テキストの生成）のトークン非効率性はピボット翻訳でも変わらない。出力トークン数が処理時間の主因であるため、ピボット翻訳だけではタイムアウト問題の根本解決にはならない。品質面ではピボット翻訳のメリットが大きい（低リソース言語への直接翻訳より、英語経由のほうが品質が安定する傾向がある）ため、品質と速度のバランスでピボットを採用しつつ、バッチ設計で処理時間を制御するのが推奨される。

上がる。多くの LLM API は入力・出力トークン数に基づく従量課金であり、同じ意味内容でも言語によってトークン数が異なれば、コストもそれに比例する。

Petrov et al. (2023) はこの問題を「言語間の不公平性」として指摘している。たとえばラオス語のユーザーが英語のユーザーと同じ量の情報を処理するのに数倍の料金を支払う構造になる。

API ユーザーとしてできる対策は限られるが、以下は検討に値する。

• 必要な部分だけ翻訳する: 全セクションを一括翻訳するのではなく、変更があったセクションのみ差分翻訳する
• キャッシュの活用: 同一テキストの再翻訳を避ける
• ピボット翻訳: 入力トークンを英語で抑えることで、入力コストを削減する

BPE トークナイザーは英語を中心とする高リソース言語で高い効率を発揮する一方、ラオス語をはじめとする低リソース言語では構造的な非効率が避けられない。この非効率性は LLM の翻訳システムにおいて、タイムアウト・コスト増大・処理遅延という形で顕在化する。

対策の要点は 3 つだ。

• 言語別の動的バッチ設計: 低リソース言語ではバッチサイズを拡大し、API 呼び出し回数を削減する
• タイムアウトの多層設計: Vercel Function と Bedrock HTTP の両方のタイムアウトを整合的に調整する
• 実測データに基づくチューニング: トークン消費量と処理時間を言語別に計測し、パラメータを継続的に最適化する

多言語対応を進める際は、対象言語のトークン効率を事前に検証し、低リソース言語向けのパラメータセット（LOW_RESOURCE_LANGS）に追加する運用フローを組み込むことを推奨する。