ステータス：草案（2026-10-16）、主にドキュメント基準。 スマホやブラウザ内で私たちのモデルを実行した測定は ありません（未実測）。標準とブラウザのサポートについては、W3Cおよびブラウザベンダの公式記事を2026-10-16時点に閲覧して確認しました。JPEGのサイズとモデルのパラメータ数は、本シリーズのサーバー実測値から取得しています。 シリーズ「ビジョンモデルを読む3」第7編。モデルを持ち運ぶ形式（ONNX）については 第3編にあります。
目次
- 1. 直感：どこで計算すべきか
- 2. ブラウザで計算を行う方法
- 3. アプリにおける実装：Core ML
- 4. すでにスマートフォンで動作しているモデル
- 5. 私たちのモデルをスマートフォンに移行する場合：サイズと帯域
- 6. 制限事項
- 7. 私たちのプロジェクトとの関連性
- 参考文献
1. 直感：どこで計算すべきか
カメラはスマートフォンにあります。結果（スコアボード）もスマートフォンの画面に表示されます。その間の処理を行うモデルだけがサーバーにある場合、フレームごとに「スマートフォン ⇄ サーバー ⇄ スマートフォン」の往復が発生します。モデルをスマートフォンに移行すれば、この往復がなくなります。しかし、スマートフォンはGPUが小型で、長時間実行すると発熱し、機種によって性能が10倍も異なります。
| デバイス内 | サーバー | |
|---|---|---|
| 遅延 | ネットワークの往復なし | ネットワークの往復 ＋ 中継 |
| プライバシー | 映像がデバイスの外に出ない | フレームがサーバーに送信される（保存されなくても） |
| コスト | ユーザーのデバイスで計算 | サーバーのGPUコスト、同時ユーザー数の制限 |
| モデル | 小型である必要性（ダウンロード・メモリ） | 大きくても問題ない |
| 一貫性 | 機種によって速度や結果が異なる可能性がある | 全員に同じ結果 |
| 修正 | 新しいモデルを再取得する必要がある | サーバーを変更するだけで全員に適用される |
2. ブラウザで計算を行う方法
WebGL → WebGPU
TensorFlow.js（Smilkov他、2019）は、ブラウザのグラフィックスAPI（WebGL）を使用してニューラルネットワークを動作させていました。テンソルをテクスチャに格納し、出力要素ごとにグラフィックスシェーダーを1回ずつ実行するという迂回路でした。それでもパフォーマンスの差は大きかったのです。
| MobileNet v1、224×224で1回（論文の表1） | 時間 |
|---|---|
| 純粋なJavaScript（2014年のノートPC） | 3,426ms |
| WebGL、同じノートPCの内蔵GPU | 49ms（71倍） |
| WebGL、デスクトップ級GPU | 5ms（685倍） |
| Node.js, 같은 데스크톱급 GPU 의 CUDA | 3ms |
WebGPU は、グラフィックスAPIを介さずにGPUでの計算を直接呼び出す新しい標準です。シェーダー言語にはWGSLを使用します。2026-10-16時点において、W3CではWebGPUおよびWGSLの双方が「候補勧告草案（Candidate Recommendation Draft）」の段階にあります（それぞれ2026-09-15、2026-09-21版）。ブラウザベンダの公式記事で確認されたリリース状況は以下の通りです。
| ブラウザ | WebGPUのデフォルト有効化 |
|---|---|
| Chrome 113 | ChromeOS・macOS・Windows |
| Chrome 121 | Android 12以降（Qualcomm・ARM GPU搭載デバイス） |
| Safari 26.0 | macOS・iOS・iPadOS・visionOS |
| Firefox 141 | Windowsのみ（2025-07の記事に基づく。その後、他のオペレーティングシステムについては確認できていない） |
MDNでは未だに「制限付き利用可能（Limited availability）」と表示されており、HTTPSなどのセキュアコンテキストでのみ使用可能です。16ビット浮動小数点（f16）は、Chrome 120以降のシェーダー機能を持つデバイスで使用されます。第2編で取り上げたFP16が、ブラウザでも利用できるようになったと言えます。
WebAssembly（WASM）：CPUを最大限に活用する
GPUへデータを送信するには固定のオーバーヘッドがかかるため、 小規模なモデルであればCPUの方が優れている場合があります。 ブラウザでCPUを高速化する手段がWebAssemblyであり、SIMD（1つの命令で複数の数値を処理）とスレッドを有効にするとパフォーマンスが大きく向上します。これはTensorFlow.js公式リポジトリのWASMバックエンドの表（Chrome 79、2020年頃のデバイスのため古い数値）です。
| MobileNet V2、2019年のノートPC | 時間 |
|---|---|
| 純粋なJavaScript | 893.5ms |
| WASM | 98.4ms |
| WASM + SIMD | 30.2ms |
| WASM + SIMD + スレッド | 10.3ms |
| WebGL | 19.6ms |
同じドキュメントには、積和演算が2,000万〜6,000万回程度の軽量なモデルであればWASMはWebGLと同等であり、1億〜5億回になるとWASMが数倍遅くなると記載されています。第3編で見た「呼び出しコスト対計算量」のトレードオフが、ブラウザでもそのまま当てはまります。
WebNN：デバイスのニューラルネットワークアクセラレータ
近年のスマートフォンやノートPCには、ニューラルネットワーク専用のアクセラレータ（NPU）が搭載されています。WebGPUではこれを利用できません。 WebNN は、「畳み込み」や「行列積」といったニューラルネットワークの演算単位でグラフを渡すことにより、ブラウザがCPU・GPU・NPUの中から最適なものを選んで実行させることができるW3C標準です。2026-10-10版が候補勧告草案となっており、現在のバージョンでは開発者が直接デバイスを選択するのではなく、「低電力」や「高性能」といった選好（プレファレンス）のみを指定します。ブラウザごとのデフォルトのリリース状況は、一次資料では確認できませんでした。
ONNX Runtime Web：ひとつのファイル、複数のバックエンド
第3編のONNXファイルをブラウザで実行するためのランタイムです。実行プロバイダとして wasm（CPU）やwebgpu·webgl·webnn がありますが、 すべての演算子をサポートしているのはWASMだけであるため、他のプロバイダがサポートしていない演算はWASMにフォールバックされます。WebGLプロバイダはメンテナンスのみが行われており、パフォーマンスの面ではWebGPUが推奨されています（公式ドキュメント）。このドキュメントのブラウザサポート表は、上記のベンダの記事よりも古く見えました。「ランタイムがそのブラウザでテストを行ったこと」と「ブラウザがWebGPUをリリースしたこと」は別の話です。
3. アプリにおける実装：Core ML
Apple製デバイスのCore MLは、CPU、GPU、Neural Engineを組み合わせて使用します。 computeUnits を「すべて」に設定するとオペレーティングシステムがデバイスを選択し、開発者がCPUのみ、CPU+GPU、CPU+Neural Engineに絞り込むことも可能です。モデル圧縮ツール（coremltools）では、重みのパレット化（1・2・3・4・6・8ビットのルックアップテーブル）、重みのINT4・INT8およびアクティベーションのINT8線形量子化、プルーニング（枝刈り）が提供されています。公式ドキュメントには、圧縮によってサイズは確実に小さくなるものの、 レイテンシの改善が保証されるわけではない（バックエンドによっては計算のために重みを再展開するため）と記載されており、自身のモデルとデバイスで実際に測定するよう推奨しています。第2編や第4編と同じ結論です。
4. すでにスマートフォンで動作しているモデル
- BlazePose（Bazarevsky他、2020）：人の関節33点を、2017年のスマートフォン用CPUコア1つでLiteモデルにより約30 FPSで処理。検出器は最初のフレームとロストした時のみ実行し、残りは前回の関節位置で切り抜いた領域内を追跡する（第5編）。
- EfficientTAM（Xiong他、2024）：2023年のハイスペック・スマートフォンにおいて、1024×1024の入力でフレームあたり261〜1,011ms、512×512の入力で80.6ms（論文の表1・5、精度は未記載）。
- MobileNetV2（2018）：スマートフォンの大型CPUコア1つで75ms（第4編）。
共通しているのは、 「小規模なモデル ＋ 実行頻度を減らす」 ということです。スマートフォンにおけるリアルタイム処理は、単一のモデルを高速化することよりも、パイプライン全体を設計する問題に近いです。
5. 私たちのモデルをスマートフォンに移行する場合：サイズと帯域
| モデル | パラメータ数 | FP32 | FP16 | INT8 |
|---|---|---|---|---|
| ボールモデル（BlurBall） | 149万 | 6.0MB | 3.0MB | 1.5MB |
| 卓球台検出（EfficientTAM-S） | 3,406万 | 136MB | 68MB | 34MB |
（パラメータ数 × 4・2・1バイト。実際のファイルには構造情報が追加されます。）
ボールモデルは、ウェブページと一緒にダウンロードしても負担にならないサイズです。問題は計算量です。このモデルは512×288の解像度を最後まで維持するため、サーバー側のノートPC級GPUでもFP16で1推論あたり約10msかかりました（第1編）。スマートフォンのGPUで30fpsを達成できるかどうかは測定していません（未実測）。卓球台の検出は試合開始時に1回行えばよいため、スマートフォン上で数百msかかっても問題ありませんが、34〜136MBのデータをダウンロードする必要があります。
逆に、現在のようにサーバーで実行する場合は、フレームをアップロードする必要があります。本シリーズのサーバー実測における、同じ試合映像のJPEGサイズは以下の通りでした。
| 送信する画面 | 品質 50 | 品質 70 | 品質 90 | 30fpsで送信する場合（品質 70） |
|---|---|---|---|---|
| 512×288 | 9.1KB | 12.3KB | 24.7KB | 約 2.9Mbit/s |
| 1280×720 | 37.7KB | 52.4KB | 111.5KB | 約 12.6Mbit/s |
（サーバー側CPUのOpenCVエンコーダ基準。ブラウザのJPEGエンコーダでは、同じ品質数値でもサイズが異なる場合があります — 運用設計に関するドキュメントでは、試合映像において12〜18KBで計測されています。）512×288に縮小して送信するだけで、帯域幅は4分の1になります。アップロードが遅い卓球場のWi-Fi環境では、この違いが「動作するかどうか」の分かれ目になります。
6. 制限事項
- スマートフォンやブラウザで私たちのモデルを実行した実測値はありません。本記事におけるスマートフォン側の判断は、ドキュメントや他のモデルの公開数値に依存しています。
- ブラウザのサポート状況は急速に変化します。上記の表は2026-10-16時点に閲覧したベンダの記事に基づいたものであり、Firefoxの他のオペレーティングシステムにおけるリリース状況や、WebNNのデフォルトリリース状況については確認できていません。
- 公開されているベンチマークの数値（TensorFlow.jsの表など）は、数年前のデバイスやブラウザの値です。傾向（バックエンドによって数十倍変わるという点）のみを参考にし、絶対値をそのまま移行してはなりません。
7. 私たちのプロジェクトとの関連性
- 現在の役割分担：スマートフォン（ブラウザ）がカメラ映像を取得して中央揃えで512×288に縮小し、JPEG（品質0.7）で最大30fpsで送信し、返却されたボールの位置と判定を描画します。サーバー側では、JPEGのデコード、ボールモデルの実行、バウンダリおよび審判ルールの処理、卓球台の検出を行います。これは、モデルとルールを一箇所で修正し、全員に対して一貫した判定を提供するためです。
- スマホから先に移行する候補は卓球台探しです。試合開始時に1回だけなので遅延の重要性が低く、成功すれば「卓球台を探している間のサーバー往復」がなくなります。ボールモデルは毎フレームなのでスマホGPUの実測が先決です。
- 移行するには第3回のONNXエクスポートと第2回の精度確認（FP16でボールの位置が同じか）を経る必要があります。その実測は次の課題として残しておきます。
次の記事は、このシリーズのすべてのピースをTT Scoreのリアルタイムなパスに載せた実際の予算表です。
TTの一言。 私のボールモデルは6MBなのでスマホにすっぽり収まります。しかし、スマホの中で1秒間に30回推論できるかどうかは、まだ誰も測定していません。測定するまでは「できる」とは言いませんよ！
参考文献
- Smilkov, D. et al. (2019). TensorFlow.js: Machine Learning for the Web and Beyond. SysML 2019. https://arxiv.org/abs/1901.05350
- TensorFlow.js WASMバックエンド README. https://github.com/tensorflow/tfjs/blob/master/tfjs-backend-wasm/README.md
- W3C WebGPU. https://www.w3.org/TR/webgpu/ · WGSL. https://www.w3.org/TR/WGSL/ · WebNN. https://www.w3.org/TR/webnn/
- Chrome Developer Blog — WebGPUリリース(113)、Android(121)、f16(120). https://developer.chrome.com/blog/webgpu-release
- WebKit Blog — Safari 26.0. https://webkit.org/blog/17333/webkit-features-in-safari-26-0/
- Mozilla Gfx Blog — Firefox 141 WebGPU. https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-on-windows-in-firefox-141/
- MDN WebGPU API. https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
- ONNX Runtime Web. https://onnxruntime.ai/docs/tutorials/web/
- Apple Core ML(MLComputeUnits), coremltools圧縮ガイド. https://developer.apple.com/documentation/coreml · https://apple.github.io/coremltools/docs-guides/source/opt-overview.html
- Bazarevsky, V. et al. (2020). BlazePose. CVPR Workshop. https://arxiv.org/abs/2006.10204
- Xiong, Y. et al. (2024). Efficient Track Anything. arXiv. https://arxiv.org/abs/2411.18933