ブラウザ上でLLM（大規模言語モデル）を動かす、あるいはトークナイザー（テキストを数値化する前処理）をフロントエンドに組み込む案件が増えています。この記事は、そうした実装をJavaScript側で作るかWebAssembly（以下Wasm。ブラウザ内で高速にコードを実行する仕組み）に任せるかを迷っているフロントエンドエンジニアに向けた内容です。
LLMのパイプラインでは、入力文字列がまずトークナイザーによってトークン（単語や部分語の単位）に分割され、それぞれがToken ID（語彙表の番号）に変換されます。GPT系のモデルではBPE（Byte Pair Encoding、頻出するペアを繰り返し結合してトークンを作るアルゴリズム）が使われ、GPT-4の語彙数はおよそ10万です。この処理自体は数値計算というより文字列処理ですが、埋め込みベクトルの生成やAttention計算に入ると、行列演算が大量に発生します。
この数値処理をどこで実行するかが、Web上でAI機能を提供する際の重要な設計判断になります。プロンプトの前処理をサーバーに投げるだけなら悩む必要はありませんが、オフライン動作やレイテンシ削減を狙ってクライアント側で完結させたい場合、選択肢の比較が必要です。
どんな場面で判断が必要になるか
代表的なのは、ブラウザ上でトークン数をリアルタイム表示するチャットUI、あるいはWebGPU経由で小型モデルの推論まで完結させるプロダクトです。
トークナイザーだけをフロントエンドに持ちたいケースと、埋め込み生成やAttention計算まで含めた推論全体をブラウザに持ちたいケースでは、要求される処理速度がまったく異なります。まずは自分がどちらのレイヤーを実装しようとしているのかを切り分けることが出発点です。
判断軸
処理密度が1つ目の軸です。BPEのようなトークン化処理は文字列の走査とハッシュ的なルックアップが中心で、JavaScriptのままでも十分高速に動きます。一方でTransformer層の行列演算（Section 6で扱われる線形代数の計算）は、単純なループ処理に対してJavaScript実行エンジンの最適化が効きにくく、Wasmや専用ランタイムの恩恵が大きくなります。
バンドルサイズが2つ目の軸です。Wasmモジュールは事前コンパイル済みバイナリのため、V8（ChromeのJSエンジン）のJITコンパイル待ちがなく初回実行が安定します。ただし語彙表データ（10万トークン分のマッピング）自体のサイズはJSでもWasmでも変わらないため、モデルの語彙サイズが大きいほど転送量の削減はCDNキャッシュや圧縮方式の工夫に依存します。
開発・保守コストが3つ目の軸です。JavaScriptで書けば既存のNode.jsツールチェーンやテストフレームワークがそのまま使えます。RustやC++でWasmモジュールを書く場合、別言語のビルドパイプラインが増え、デバッグ時のスタックトレースも読みにくくなります。
ブラウザ互換性が4つ目の軸です。WebAssemblyは主要ブラウザで広くサポートされていますが、WebGPU（GPU計算をブラウザから使う新しいAPI）はSafariでの対応がChromeやEdgeに比べて遅れている状況があり、推論全体をクライアントで完結させる場合はフォールバック設計が必須になります。
選択肢の比較
| 実装方式 | 向いている処理 | 強み | 弱み |
|---|---|---|---|
| JavaScriptのみ | トークン化・軽量な前処理 | 実装が速い・デバッグしやすい | 大規模な行列演算は遅い |
| Wasm（tiktoken系など） | BPEトークン化の高速化 | JS比で処理が安定・高速 | ビルドチェーンが増える |
| WebGPU推論 | 小型モデルのブラウザ内推論 | サーバー不要・オフライン動作 | ブラウザ間の対応差が大きい |
ケース別の推奨
チャット入力欄でトークン数の目安を表示するだけなら、JavaScript実装のトークナイザーで十分です。BPEのアルゴリズム自体は文字列処理が主体のため、Wasm化による恩恵は限定的です。まず素のJSで実装し、実際にプロファイリングして処理時間がボトルネックになってから移行を検討する順序で問題ありません。
多言語対応や絵文字を含む長文を高頻度でトークン化するプロダクトなら、Wasm版のトークナイザーライブラリを検討する価値があります。UTF-8のマルチバイト処理（英語1バイト、日中韓や絵文字は最大4バイト）が絡む場面では、文字列操作の最適化余地が大きく、Wasmの効果が出やすい領域です。
埋め込み生成やAttention計算まで含めた推論そのものをブラウザで完結させたいなら、WebGPUを使う実装を検討する段階です。ただしSafari対応が必要なプロダクトでは、サーバーサイド推論へのフォールバックを最初から設計に組み込む判断が欠かせません。
あえて見送るべき条件
対応ブラウザをSafari込みで広く保証する必要があるプロダクトで、WebGPU推論をメイン経路に据えるのは時期尚早です。フォールバックの実装コストがWasm化のメリットを上回るケースが少なくありません。
また、トークン数が少ない単発フォーム入力のような用途では、Wasmモジュールの読み込みコスト自体がオーバーヘッドになります。処理量に対してモジュールサイズが見合わない場合は、素のJSに留める判断が妥当です。
判断の締めくくりとして確認すること
まずは自分の実装がトークン化レイヤーなのか推論レイヤーなのかを切り分けてください。
トークン化だけならJSで開始し、Chrome DevToolsのPerformanceタブで実際のボトルネックを計測してからWasm移行を判断するのが現実的な進め方です。
推論まで含める場合は、対象ブラウザのWebGPU対応状況をcaniuse.comで確認し、フォールバック設計の有無を最初に決めておくと後戻りが少なくなります。
最終的には、処理密度・バンドルサイズ・保守コスト・ブラウザ互換性の4軸を自分のプロダクト要件に当てはめて優先順位をつけることが、遠回りをしない近道になります。