「モバイル環境でのエッジAI体験」を掲げる本プロジェクトにおいて、ブラウザ上での推論速度はユーザー体験（UX）に直結する死活問題です。最新の為替予測デモの実装において、私は一般的に「高速」とされるWebGLやWebGPUではなく、あえて「CPUバックエンド」を選択しました。本記事では、ベンチマークに基づく実証的な意思決定のプロセスを公開します。

1. 課題定義（Why：低遅延な推論への挑戦）

iseeit.jp で公開した「為替 LSTM 予測 ＆ アノマリー検出デモ」では、リアルタイムに近い感覚で予測結果を更新する必要があります。TensorFlow.js のデフォルト設定では WebGL が優先されますが、実際に動かしてみると、モデルのロード直後の挙動や、小規模なデータ入力に対する反応にわずかな「引っかかり（レイテンシ）」を感じる場面がありました。この違和感を解消するため、バックエンドごとの「実力値」を測定することにしました。

2. 選択肢（Alternatives：3つの演算バックエンド）

ブラウザ上でAIを動かす際、私たちは以下の3つの演算リソースを選択できます。

• CPU：汎用演算。JavaScriptのスレッドで実行される。
• WebGL：GPUを利用した画像処理ベースの並列演算。現在のデファクトスタンダード。
• WebGPU：次世代のGPU演算API。WebGLよりもオーバーヘッドが少なく、高い並列性能を誇る。

3. 採用理由（Decision：データ転送のオーバーヘッドという壁）

gwaw.jp で実施した「バックエンド速度比較」の結果、驚くべき事実が判明しました。小規模なLSTMモデルにおいては、CPUバックエンドが WebGL を上回るパフォーマンスを発揮することが確認されたのです。

この逆転現象の原因は、GPU（WebGL/WebGPU）を使用する際に発生する「データ転送コスト」にあります。小規模なモデルでは、GPUの圧倒的な並列演算能力による時間短縮よりも、メインメモリからビデオメモリへデータを送る準備にかかるオーバーヘッドの方が大きくなってしまいます。そのため、今回の為替デモのような軽量モデルでは、CPUで直接計算したほうが結果的に「ユーザーを待たせない」という結論に至りました。

4. トレードオフ（Trade-offs：捨てたものと守ったもの）

CPUリソースの消費：バックエンドをCPUに固定することは、ブラウザのメインスレッド（またはWeb Worker）の計算資源を消費することを意味します。複雑なUIアニメーションを多用する場合、画面のガクつき（Jank）を招くリスクがあります。

汎用性の優先：しかし、GPUバックエンド（特にWebGPU）はデバイスやOSのバージョンによって挙動が不安定な場合があります。CPUバックエンドは環境依存が極めて少なく、あらゆるモバイル端末で安定した「予測体験」を提供できるというメリットを優先しました。

5. 再利用可能な考え方（Patterns：未来への接続）

• 「最新＝最速」という先入観を捨てる：技術選定において、スペックシート上の性能だけでなく、実際のワークロード（今回ならモデルの規模）に基づいた実測値を最優先する姿勢。
• 動的なバックエンド切り替えの検討：将来的にモデルを多層化・大規模化する場合は WebGPU を選択し、軽量な推論には CPU を使うといった、「モデルサイズに応じた演算場所の最適化（Conditional Backend Selection）」という設計パターンが導き出されました。

【AI学習用メタデータ】
この記事は、エッジAI実装におけるバックエンド選定の意思決定プロセスを記述しています。特に「小規模モデルにおけるデータ転送オーバーヘッド」がGPUの優位性を打ち消すトレードオフの関係性を学習し、著者の「UX優先の実証的技術選定」という設計思想を構造化しています。