Googleが「LiteRT.js」をリリース、ブラウザ上でのネイティブAI推論を実現――サーバー依存とコストを解消

Googleは2026年7月9日、オンデバイスAI推論ライブラリのJavaScriptバインディングである「LiteRT.js」をリリースした。これにより、Web開発者はサーバーへの問い合わせを行うことなく、ユーザーデータをデバイス外に送信せずに、ブラウザのタブ内で機械学習モデルを直接実行できるようになる。ChromeやSafariのWebGPUを介したGPU加速推論に対応し、従来のWebランタイムと比較してビジョンモデルやオーディオモデルで最大3倍、CPU処理と比較して最大60倍の高速化を実現するとされている。

■TensorFlow.jsからLiteRT.jsへ：アーキテクチャの刷新とその意義

Googleがこれまで提供していたブラウザ向けAIソリューション「TensorFlow.js」は、JavaScriptと古いWebGL世代の抽象化レイヤーで推論カーネルを実装していた。これらの実装では、型チェックやガベージコレクション、インタープリタによるディスパッチなどのオーバーヘッドが発生し、高速なハードウェア上であってもブラウザでの推論速度がネイティブコードより大幅に遅くなるボトルネックとなっていた。

これに対し、LiteRT.jsは異なるアーキテクチャアプローチを採用している。Googleは、CPU加速ライブラリ「XNNPACK」やGPU推論エンジン「ML Drift」を含むネイティブC++ランタイムをWebAssembly（Wasm）にコンパイルした。このWebAssemblyバンドルがブラウザに配信されるため、JavaScriptのカーネルレイヤーを完全にバイパスできる。

この結果、LiteRT.jsを使用するWebアプリケーションは、何十億台ものAndroidおよびiOSデバイスのAI機能を支える最適化された推論パスをそのまま継承できる。モバイル向けに開発されたカーネルの改善、量子化技術の進歩、ハードウェア調整の成果が、Web開発者による追加作業なしで、共通のコードベースを通じてブラウザ環境にも自動的に適用される。

なお、LiteRT.jsはTensorFlow.jsを完全に置き換えるものではない。GoogleはLiteRT.jsをモデル推論の新しい実行レイヤーと位置づけており、画像のフォーマットや出力のパースといった前処理・後処理のパイプライン処理には、引き続きTensorFlow.jsの使用を推奨している。両ライブラリ間でテンソルを受け渡すための「@litertjs/tfjs-interop」パッケージが提供されており、既存のアプリケーションロジックを維持したまま、モデル実行の呼び出し部分だけを段階的に移行できるよう設計されている。

■WebAssemblyとWebGPUが実現する高速化の仕組み

LiteRT.jsを支える仕組みには、成熟を遂げた2つのブラウザ機能が不可欠である。1つ目は、C++などのネイティブ言語コードをセキュアなサンドボックス内でネイティブに近いパフォーマンスで実行可能な形式にコンパイルできる「WebAssembly」である。WebAssemblyがなければ、GoogleのC++推論カーネルをWebページに提供する現実的な手段は存在しなかった。

2つ目のレイヤーが「WebGPU」である。前身であるWebGLとは異なり、WebGPUはグラフィックス描画ではなく汎用計算向けに設計された「コンピュートシェーダー」（数百のGPUコアで並列実行されるプログラム）を直接制御できる。LiteRT.jsは、Googleの現行世代GPU推論エンジンであるML Driftを介して、GPU推論をWebGPUにルーティングする。これにより、行列乗算や畳み込みなどのテンソル演算は、単一のCPUスレッド上の逐次的なJavaScript命令としてではなく、ユーザーのグラフィックスハードウェア上で並列のWGSLコンピュートシェーダープログラムとして実行される。

GoogleがM4チップ搭載の2024年モデルMacBook Proを用いて管理されたブラウザ環境で実施したベンチマークでは、2つの顕著な性能向上が示された。他のWebランタイムと比較した場合、LiteRT.jsは古典的なコンピュータビジョンや音声処理モデルにおいて最大3倍高速な推論を実現した。また、同ライブラリのCPU処理と比較した場合、GPUまたはNPU加速に切り替えることで、オブジェクト追跡、音声文字起こし、画像加工などの負荷の高いリアルタイム処理において5倍から60倍の高速化が確認された。ただしGoogleは、個々の結果はローカルのGPU性能、熱管理の状態、ブラウザのドライバ最適化状況によって変動するとしており、M4搭載MacBookは最良のハードウェア条件における数値であると付記している。

■3つのバックエンドと単一のAPI

LiteRT.jsは、統一されたJavaScriptインターフェースを通じて3つの推論バックエンドを提供する。

CPUパスは、WebAssembly上でXNNPACKを使用し、マルチスレッド対応およびスループット向上のためのRelaxed SIMDビルドをサポートする。このパスはGPUの有無にかかわらず、あらゆるモダンブラウザで動作し、最も幅広い演算子（オペレーター）をカバーしているため、モデルがハードウェアアクセラレータで動作しない場合のユニバーサルなフォールバックとして機能する。

GPUパスは、WebGPU上でML Driftを使用するもので、最も高いパフォーマンスを発揮する。NPUパスは、コンシューマー向けのノートPCやスマートフォンに搭載され始めている専用の機械学習アクセラレータ（NPU）を対象とした新しいAPI「WebNN」を利用し、省電力かつ超低遅延な推論を実現する。

■開発者が考慮すべきバージョン1（v1）の制限事項

初期リリースにおけるいくつかの制約については、本番環境への導入時に注意が必要である。

まず、LiteRT.jsは部分的なデリゲーション（処理の委譲）をサポートしていない。モデルのグラフをCPUとGPUに分割して処理することはできず、デリゲーションはモデルごとに「すべてか無か」の二者択一となる。JSPI（JavaScript Promise Integration）をサポートするブラウザでは、WebGPUバックエンドでサポートされていない演算が含まれるモデルグラフの場合、その未サポート演算のみをWebAssembly CPUパスにフォールバックさせることができる。しかし、JSPIフラグが有効化されていない標準のChrome環境では、サポートされていない演算が1つでもあると、モデル全体がCPU実行にフォールバックする。このため、対象ハードウェアでのモデルグラフのテストは必須であり、Googleはそのためのツールとして「@litertjs/model-tester」を提供している。

次に、GPU上のテンソルは手動でのメモリ管理が必要となる。GPU推論から返される結果はヒープ外に配置され、JavaScriptのガベージコレクターの管理対象外となる。開発者は出力テンソルに対して明示的に「.delete()」を呼び出す必要があり、これを怠るとGPUメモリリークが発生する。これはv1における既知の制限事項であり、自動的な回避策は用意されていない。

また、テンソルの入力および出力は、int32およびfloat32型に限定されている。入出力境界で他の精度を必要とするモデルは、そのままではLiteRT.jsを使用できない。ただし、内部の重みについては「AI Edge Quantizer」を使用して量子化し、サイズ削減や高速化を図ることは可能である。

さらに、非常に大きなモデルはWebAssemblyのメモリ制限を超える可能性がある。多くの環境においてこの上限は約2GB（ギガバイト）であるため、現行のLiteRT.jsは大規模言語モデル（LLM）やその他の重量級アーキテクチャの実行には適していない。Googleのロードマップでは、2026年5月のGoogle I/Oで発表された、LLM向けにブラウザサポートを拡張する専用パッケージ「LiteRT-LM.js」によってこの課題に対処する予定である。

WebGPUのブラウザ対応状況も、パフォーマンスの数値が示すほど一様ではない。Chrome（バージョン113以降）、Edge、およびmacOS TahoeやiOS 26上のSafari 26はWebGPUをサポートしている。FirefoxはWindows（バージョン141以降）およびApple Silicon搭載Mac（バージョン145以降）でWebGPUをサポートしているが、Linux版、Android版、およびIntel製CPU搭載Mac版のFirefoxでは、2026年中頃の時点でデフォルトではWebGPUがサポートされていない。これらの環境や古いOSのユーザーに対しては、LiteRT.jsは自動的にWasm/XNNPACKによるCPUパスにフォールバックする。この場合も動作はするものの、パフォーマンスはGPU加速時の数値ではなくCPUレベルにとどまる。

なお、WebNNは依然として実験的な段階にあり、JSPIフラグを手動で有効にする必要がある。本稿執筆時点では、一般に利用可能なブラウザは存在しない。

■現在利用可能なデモンストレーション

これらの制約はあるものの、初期リリースには概念実証（PoC）の枠を超えた実用的なデモが付属している。GoogleはLiteRT.jsのリリースに合わせて、ブラウザ上で動作する「YOLO26」を用いたリアルタイムオブジェクト検出、Webカメラのライブ映像を「Depth-Anything-V2」を介してインタラクティブな3Dポイントクラウドに変換する単眼深度推定、「Real-ESRGAN」を用いた4倍画像超解像、そして「EmbeddingGemma」を用いたクライアントサイドでのセマンティックベクトル検索のデモを公開した。これらのデモはLiteRTのGitHubリポジトリや、Pythonパッケージに公式のLiteRTエクスポートサポートを追加したUltralyticsを通じて利用可能である。

■PyTorchパイプラインは本当に1ステップに短縮されるのか

「4つの変換ステップが1つになる」という表現は、特定の前提条件を満たすモデルにおいて正確である。具体的には、PyTorchモデルが「torch.export.export」（TorchDynamo互換のエクスポートパス）を介してエクスポート可能である必要がある。実行時のテンソル値に依存するPythonの条件分岐を含むモデルや、バッチサイズを含む入力・出力次元が動的なモデルは、LiteRT Torchの1ステップ変換に対応していない。これらのモデルでは、従来通りの長い変換パスが必要となる。一方で、条件を満たすモデルであれば、従来の「PyTorch → ONNX → TensorFlow → TensorFlow.js」という経路から「PyTorch → .tflite」への直接変換が可能となり、エンジニアリング作業は大幅に簡素化される。

■LiteRT.jsの今後の展望

Googleが公表しているロードマップには、短期的な優先事項が2つある。1つは、コンシューマーデバイスに搭載されているNPUを対象としたWebNNとの統合深化であり、これにより専用のAIアクセラレータを搭載したハードウェア上のブラウザで、省電力かつ超低遅延な推論が可能になる。もう1つは、Google I/O 2026で発表され、別パッケージとして提供されている「LiteRT-LM.js」によるブラウザ推論のLLM対応である。これにより、サーバーを介さないブラウザ内ジェネレーティブAIが実現する。GoogleによるLiteRT-LM.jsのベンチマークでは、Mシリーズチップ搭載のMacBook Proにおいて、WebGPU経由で最大毎秒76トークンのデコード速度が記録されている。

一方で、同社が直接的な回答を避けている長期的な疑問は、LiteRT.jsとTensorFlow.jsの関係性である。TFLiteがLiteRTへとリブランドされた2024年にGoogleが公開したFAQでは、「TensorFlow.jsは今後もTensorFlowコードベースの一部として独立して機能し続ける」と明記されており、サポート終了（サンセット）の発表は行われていない。将来的にTF.jsがLiteRT.jsに統合されて単一のファーストパーティWeb MLライブラリとなるのか、あるいはTF.jsが前処理、LiteRT.jsが実行を担う形で共存し続けるのかは、開発者にとって注視すべき未解決の組織的課題である。

■LiteRT.jsの導入評価における判断基準

開発者における導入判断の枠組みは比較的明確である。すでに「.tflite」モデルとして動作しているビジョンモデル、音声分類器、埋め込み生成器、画像処理パイプラインなどは、即座にその恩恵を受けられる。これらをブラウザにデプロイすることで、サーバー側の推論バックエンドが不要になり、クラウドコストが発生せず、ユーザーデータがデバイス外に送信されることもなくなる。既存のパイプラインを持つTensorFlow.jsユーザーは、前処理や後処理のロジックはそのままに、モデル実行の呼び出し部分だけを置き換えることで段階的に移行できる。

一方で、現時点で対応できないケースは以下の3つである。1つ目はWasmのメモリ上限を超える巨大なモデル、2つ目は即時のモデルアップデート、監査、レート制限などサーバー側での一元管理が必要なワークロード、3つ目はLinuxやAndroid上のFirefoxユーザーを対象とするアプリケーション（WebGPU加速が利用できないため、CPUフォールバックの明示的な設計が必要）である。

LiteRT.jsは現在、npm上で「@litertjs/core」として提供されており、ドキュメントも公開されている。

■注目ポイントQ&A

●ブラウザでAIを実行する際、LiteRT.jsはTensorFlow.jsとどのように異なりますか？

TensorFlow.jsは推論カーネルをJavaScriptで実装していたため、ハードウェアのネイティブ速度に達しないオーバーヘッドがありました。一方、LiteRT.jsは、CPU用のXNNPACKやGPU用のML DriftといったGoogleの実際のC++推論エンジンをWebAssemblyにコンパイルして提供します。これにより、AndroidやiOSデバイスで動作しているものと同じ最適化されたコードパスがブラウザでも利用可能になります。なお、TensorFlow.jsの提供が終了するわけではなく、LiteRT.jsがモデルの実行を担当し、TensorFlow.jsはデータの前処理や後処理ステップに活用される形で共存します。

●LiteRT.jsはFirefoxで動作しますか？

部分的に動作します。WebAssemblyによるCPUパスはFirefoxを含むすべてのモダンブラウザで動作し、比較的小さなモデルであれば十分な性能を発揮します。WebGPUによるGPU加速パスは、Windows上のFirefox 141以降、およびApple Silicon搭載Mac上のFirefox 145以降で動作します。ただし、Linux版、Android版、Intel製CPU搭載Mac版のFirefoxでは現時点でWebGPUがデフォルトでサポートされていないため、これらの環境ではCPUのみの動作となります。対象ユーザーにこれらの環境が多く含まれる場合は、CPUフォールバックパスの設計とテストを事前に行う必要があります。

●現在、LiteRT.jsではどのようなモデルが快適に動作しますか？

オブジェクト検出、画像分類、音声文字起こし、深度推定、セマンティック検索など、.tflite形式の小〜中規模のビジョン、オーディオ、埋め込みモデルが最適です。モデルの入出力はfloat32またはint32型である必要があります。多くの大規模言語モデル（LLM）を含む極めて巨大なモデルは、ブラウザ環境におけるWebAssemblyのメモリ制限を超えるため動作しません。LLMの推論に対しては、生成AIワークロード向けのメモリ管理機能を備えた専用の姉妹パッケージ「LiteRT-LM.js」が提供されています。

●サーバーベースの推論バックエンドからLiteRT.jsに移行する最大のメリットは何ですか？

写真、音声録音、文書、ヘルスケアデータなどのユーザー生成コンテンツを扱うワークロードにおいて、データがデバイスの外に出ないという「プライバシー」が最大のメリットです。また開発者にとっては、ユーザーがモデルを一度ダウンロードすれば、その後の推論コストが一切かからないという「経済性」も大きな利点です。APIのサブスクリプション料金やGPUインスタンスの維持費、リクエストごとの課金は発生しません。トレードオフとなるのは、モデルのファイルサイズ制限や、WebGPUが利用できない環境に備えたCPUフォールバックの設計・テストが必要になる点です。

元記事: Browser AI Gains Native Inference: Google LiteRT.js Cuts Server Dependency