ブラウザ上で物体検出などの機械学習モデルを動かす場合、TensorFlow.jsは代表的な選択肢のひとつです。 ただし「ブラウザで動く」ことと「実用的な速度・体験で動く」ことの間には大きなギャップがあります。 本記事では、TensorFlow.jsが提供する3つの主要バックエンド（WebGL / WASM / WebGPU）の特性を比較しながら、 実際のプロダクト開発で直面した課題とその対策を紹介します。

3つのバックエンドの特性

WebGL

最も広くサポートされているバックエンドで、GPUのシェーダを利用して行列演算を高速化します。 多くのブラウザ・デバイスで安定して動作する一方、初回実行時にシェーダのコンパイルが発生するため、 モデルの初回推論（ウォームアップ）に数秒〜数十秒かかることがあります。

WASM（WebAssembly）

CPU上で動作するバックエンドで、SIMD命令に対応している環境では比較的高いスループットを発揮します。 GPUドライバやシェーダコンパイルに依存しないため起動が安定しており、低性能デバイスやGPUが利用できない環境のフォールバックとして有効です。

WebGPU

次世代のGPU APIを利用するバックエンドで、WebGLよりも低レベルな制御が可能です。 対応ブラウザ・デバイスはまだ限定的ですが、対応環境では推論スループットの向上が期待できます。

「初回起動20〜30秒」問題への対策

物体検出モデル（SSD MobileNet V2）をWebGLバックエンドで動かす場合、ページを開いてからモデルが 最初に推論結果を返すまでに、シェーダコンパイルの影響で20〜30秒程度を要するケースがありました。 カメラを起動してすぐに使いたいプロダクトにおいて、この待ち時間はユーザー体験上大きな問題になります。

この課題に対しては、次のようなアプローチで対策を行いました。

1. Web Workerでのモデルプリロード ページ読み込み直後にWeb Worker上でモデルのロードとウォームアップ推論を開始し、 メインスレッドのUI操作をブロックせずにシェーダコンパイルを先行して済ませる。

2. 実行環境に応じたバックエンドのフォールバック設計 WebGPUが利用可能な環境ではWebGPUを優先し、利用できない場合はWebGL、 さらにGPUが不安定な環境ではWASM（SIMD対応）にフォールバックする構成とすることで、 デバイス間のばらつきを吸収する。

3. モデルの量子化による軽量化 モデルサイズと計算量を削減することで、コンパイル・ロード自体のコストも下げる。

これらを組み合わせることで、ユーザーがカメラ画面を操作可能になるまでの待ち時間を大幅に短縮できました。

まとめ

ブラウザ向けML推論の最適化では、「どのバックエンドが速いか」という単純な比較だけでなく、 初回起動時のコストをどう隠すかという観点が非常に重要です。 Web Workerによるプリロードやバックエンドのフォールバック設計は、デバイスやブラウザの多様性が大きい Web環境において、実用的なユーザー体験を実現するための有効なアプローチだと考えています。

今後はWebGPUの普及状況を見ながら、対応バックエンドの選択ロジックを継続的に見直していく予定です。