ブラウザAIをモバイルと同じモデルで、Google「LiteRT.js」の狙いと制約

Googleは2026年7月9日、機械学習モデルをブラウザ内で実行する新ランタイム「LiteRT.js」を正式発表した。WebGPUでGPUを使い、CPU経路ではXNNPACKを組み込んだWebAssembly（Wasm）を動かす。将来はWebNNを介してNPUなどの専用回路にもつなぐ構想だ。だが、本当の変化は速度の数字より深い。AndroidやiOS向けに使われてきた.tfliteモデルをWebにも運び、学習フレームワークから配備先まで分断されていた経路を一本に寄せようとしている。

ブラウザ内推論には、カメラ映像や音声をサーバーへ送らずに処理できる利点がある。ネット接続が切れても動き、推論のたびにクラウドGPUへ料金を払う必要もない。一方で、モデル本体は利用者の端末へ配布される。重みを秘匿したいサービスや、端末のメモリに収まらない巨大モデルには向かない。

Webだけ別形式だった時代を終わらせる

LiteRT.jsを理解するには、2024年9月までさかのぼる必要がある。GoogleはTensorFlow Liteを「LiteRT」へ改称した。この時点では名称変更が中心で、.tfliteの拡張子とFlatBuffer形式は維持された。狙いはTensorFlowの小型版という出自から離れ、PyTorchやJAXを含む複数の学習フレームワークと、Android、iOS、組み込み機器を結ぶランタイムへ広げることだった。

LiteRT.jsは、その構想で埋まっていなかったWeb側を担う。これまでPyTorchモデルをTensorFlow.jsで配備するには、Googleの説明によるとPyTorchからONNX、TensorFlow、TensorFlow.jsへと変換を重ねる経路が必要だった。LiteRT.jsを使えば、PyTorchからLiteRTへ直接変換し、生成した.tfliteをブラウザで読み込める。同じモデル成果物をモバイルやデスクトップにも持ち出せるため、Web専用の書き出しと検証を別系統で抱える負担が減る。

これはTensorFlow.jsの終了を意味しない。Googleは2024年の改称時にも、TensorFlow.jsは独立して継続すると明記していた。LiteRT.jsは、そこへ新しい選択肢を加えた。モデル形式を.tfliteへ寄せたい開発者は、ブラウザを例外扱いせずに済む。

Wasm、WebGPU、WebNNの三層構造

LiteRT.jsは、ブラウザが公開する計算APIに応じて実行先を変える。CPU経路では、高速なニューラルネットワーク演算ライブラリXNNPACKをWasm上で動かす。GPU経路には、Direct3D 12、Metal、VulkanのようなネイティブAPIを抽象化するWebGPUを使う。そしてWebNNは、OSの機械学習基盤を通じてCPU、GPU、NPUへ到達するための専用APIだ。

Googleの現行ガイドは、WebGPUの目安としてChromeとEdge 113以降、Safari 17.4以降を挙げ、Firefox 121以降は部分対応としている。WebNNはさらに早い段階だ。Chromium系121以降で実験機能を有効にする必要があり、Googleは一般提供済みのブラウザはまだないと説明する。WindowsではDirectML対応のDirectX 12環境、macOSではApple Silicon、LinuxではOpenVINOの構成も求められる。

WebNNの仕様自体も、2026年6月26日版でW3CのCandidate Recommendation Draftにある。仕様はNPUを含む抽象的なデバイス選択へ進んだが、勧告の完成や複数ブラウザでの相互運用を保証する段階ではない。LiteRT.jsがNPU経路を用意したことと、一般のWebアプリが今日からNPUを安定利用できることは分けて考えるべきだ。

ここでJSPI（JavaScript Promise Integration）が効く。Wasm内の同期的な処理と、WebNNなどの非同期デバイス処理を橋渡しする仕組みで、LiteRT.jsはWebNN利用時にJSPI対応ビルドを求める。ブラウザAIの性能競争はGPUカーネルの速さだけでは決まらず、異なる実行系の境界をどれだけ待たずに越えられるかへ移っている。

TensorFlow.jsを残し、推論器だけを替える

既存のWebアプリを前処理から画面表示まで一度に書き直すのは現実的ではない。Googleは@litertjs/tfjs-interopを用意し、TensorFlow.jsのテンソルをLiteRT.jsへ渡すrunWithTfjsTensorsを提供している。画像のリサイズや正規化、推論後の上位クラス抽出はTensorFlow.jsに残し、モデルの読み込みと実行だけをLiteRT.jsへ差し替えられる。

ただし、接続部分は無料ではない。両ランタイムが別のWebGPUデバイスを使えば、テンソルの変換やメモリコピーが増える。公式手順は同じGPUデバイスを共有するよう求め、WebGPU利用時にTensorFlow.jsの同期読み出しdataSyncを避けるよう警告している。GPUが高速でも、入力をCPUから送り、結果を毎回CPUへ戻して待てば、アプリ全体の遅延は縮まらない。

競合するONNX Runtime Webも、Wasm、WebGPU、WebNNをすでに備える。GPUバッファを保持したまま入出力するI/O bindingや、静的グラフの呼び出しをまとめるgraph captureもある。したがって、WebGPU対応だけでLiteRT.jsの優位は決まらない。差が出るのは、既存モデルが.tfliteとONNXのどちらに近いか、変換後の演算がどこまで対応するか、モバイルとWebで成果物を共用したいかという配備設計である。

LiteRT.jsが強く響くのは、すでにAndroidやiOSでLiteRTを使うチーム、またはPyTorchからGoogleのエッジ向けスタックへ直接流したいチームだ。反対に、ONNXを配備の中心に据え、WebGPU向けの最適化を積み上げている製品なら、ランタイム変更だけで利益が出るとは限らない。比較すべき単位はライブラリ名ではなく、自分のモデルを変換して画面へ結果を返すまでの全工程になる。

最大3倍をどう読むか

GoogleはLiteRT.jsの発表で、既存Webランタイムを上回る最大3倍の性能を掲げた。比較図はONNX Runtimeを1とし、2024年型M4搭載MacBook Proの「制御されたブラウザ環境」で測った値である。ただし、ブラウザ名とバージョンは開示されていない。結果は一律でもない。

図の最大値はCPUのinception_v3で3.33倍、WebGPUではefficientnetの3.15倍だった。一方、inception_v3のWebGPU差は1.11倍、whisper_baseのCPU差は1.12倍に収まる。Google本文の「最大3倍」は丸めた表現で、図には3倍を少し超える値もある。ランタイムを入れ替えれば常に同じ差が出るわけではない。

もう一つの図は、画像分類のEfficientnetと物体検出のYolo11nを比較している。音声系はASRのDeepspeechとText EncoderのWhisper Base、画像セグメンテーションはIsnetだ。Google本文はWebGPUまたはWebNNがCPU比5〜60倍に達したと説明するが、図のWhisper BaseはWebNNで67.2倍と記載されている。ここでも本文は丸めている。

さらに図のEfficientnet行は、CPU 23.86ms、WebGPU 3.96ms、WebNN 3.07msであるのに、速度向上を7.9倍と7.1倍としている。表示されたレイテンシを単純に割った結果とは一致しない。測定条件にはブラウザ名とOSがない。反復回数やウォームアップ、入力形状も不明で、量子化精度も示されていない。WebNNはApple CoreML経由とされるが、図からAppleのNPUで実行されたとは断定できない。

Googleが2026年1月に示したLiteRT GPUの平均1.4倍は、旧TensorFlow Lite GPU delegateとの比較だった。これもLiteRT.js対ONNX Runtime Webの数字ではない。最大3倍、CPU比5〜60倍、平均1.4倍は、対象モデルと比較相手がそれぞれ異なるため、混ぜて性能の代表値にはできない。

ブラウザ推論では、モデル本体の演算時間だけを測っても利用者の待ち時間は分からない。初回にはWasmの読み込み、モデルのダウンロード、グラフのコンパイル、GPUシェーダーの準備が入る。実行時には前処理、CPUとGPU間の転送、後処理が続く。短いモデルでは固定費が支配し、重い畳み込みや行列演算ではGPUの並列性が効きやすい。

Googleが@litertjs/model-testerを案内している理由はここにある。このツールはランダム入力を使い、WebNN、WebGPU、CPUでモデルが完走するかを調べ、指定回数のベンチマークを実行する。採用前には少なくとも、初回起動とウォームアップ後のレイテンシ、ピークメモリ、CPUへのフォールバック有無を対象端末ごとに測る必要がある。

LiteRT.jsのテンソルは開発者が明示的に解放する。結果をWasm側へ移してJavaScript配列として読む操作にも転送が伴う。推論ループで削除を忘れれば、短いベンチマークは速くても長時間動作でメモリが増える。速度の評価は、数十回の推論値と同じくらい、カメラを数分動かした後の安定性がものをいう。

本番投入を阻む四つの境界

第一の境界はモデル変換だ。GoogleのPyTorch向け手順は、モデルがtorch.export.export、つまりTorchDynamoで書き出せることを前提にする。テンソルの実行時値に依存するPythonの条件分岐は使えず、現行ガイドではバッチを含む入出力テンソルの動的次元も認めていない。学習済みモデルをそのままブラウザへ置けば動くわけではなく、モデルの書き換えが必要になる場合がある。

第二は演算カバレッジである。ここはGoogle自身の公開情報が一致していない。2026年6月12日更新のGet startedは部分委譲を非対応とする一方、OverviewはWebGPUやWebNNで扱えない演算をCPUへ自動フォールバックすると説明する。GitHubのmainブランチにあるcore READMEはさらに細かく、JSPI対応ブラウザではWebGPU非対応演算をWasmへ演算単位で分け、非対応ブラウザではモデル全体をWasmへ戻すとしている。

この食い違いから、安定配布版2.5.xの挙動を文書だけで一つに決めることはできない。使うnpmバージョンを固定し、JSPIの有無を分け、モデルテスターと実アプリのログでどこへフォールバックしたかを確認する必要がある。演算の一部がCPUへ移るか、モデル全体がCPUへ戻るかで、レイテンシの意味は大きく変わる。

第三はデータ形式とメモリだ。現行ガイドが認めるモデルの入出力はint32とfloat32に限られる。Wasmのメモリ上限やバッファ配置のため、大きなモデルは読み込み時に失敗し得る。重みの量子化でファイルを縮められても、計算型と入出力型には別の制約が残る。

第四はブラウザ標準の成熟度になる。WebGPUは実用域へ入ったが、WebNNは実験段階にある。企業が不特定多数の端末へ配るWebアプリなら、当面の基準線はWasmとWebGPUであり、WebNNは対応機で上積みを狙う経路だろう。GoogleがLiteRT.jsで完成させたのは、NPU性能そのものより、CPUからGPU、将来のNPUまで同じモデルを運ぶための入口である。

LiteRT.jsを採るかどうかは、宣伝上の倍率では決められない。判断材料は明確だ。同じ.tfliteをWebとモバイルへ配れる価値が変換コストを上回り、対象ブラウザのWebGPUで演算が完走し、初回起動を含む実測が既存ランタイムを超えるか。その三条件が揃ったとき、ブラウザはLiteRTにとって例外の配備先ではなくなる。