WebGPU実用化の現在地と落とし穴

TL;DR

• 2026-05 時点の到達点: Chrome / Edge は 2023 年から、Safari 26 系は 2025 年中盤から、Firefox は 141（Windows）と 145（macOS Tahoe ARM64）で安定提供。残るのは Linux Firefox 対応（2026 年内予定）の 1 ピースだけ
• 実用が立ち上がった3用途: ブラウザ内 ML inference（Transformers.js v3 で WebGPU vs WebAssembly が 10〜15 倍、ケースによっては 100 倍）／Three.js・Babylon.js の WebGPU バックエンド／汎用 GPU compute
• 採用の決め手は WebNN との棲み分け: NPU を直接叩きたい ML 推論は WebNN、汎用 GPU・3D・コンピュートは WebGPU。fallback と progressive enhancement で 2025 年以前のブラウザも捨てない設計が現実解

はじめに

こんにちは、みねです。

「WebGPU はもう本番で使っていい技術なのか」——2026 年に入って急に聞かれる問いです。Chrome 出荷は 2023 年、Safari は 2025 年中盤、Firefox は 2025 年後半でようやく主要 4 ブラウザがそろいました。

本記事は 2026-05 時点の対応を 公式値で整理 し、ML inference・3D・GPU compute の使いどころ、WebGL / Wasm SIMD / WebNN との棲み分け、段階導入の落とし穴をまとめます。情報は [公式値] と （経験則） を明示分離。

この記事でできるようになること

• 2026-05 時点の標準化と 4 ブラウザ対応を 1 枚で把握
• ML inference / 3D / GPU compute で「いつ WebGPU を選ぶか」を判断
• WebGL / Wasm SIMD / WebNN との使い分けを比較表で説明
• Linux Firefox 待ち・Safari 26 未満・モバイル GPU 差・WGSL 学習コストの落とし穴を回避

対象読者・やらないこと

• 対象: フロントエンド／フルスタックエンジニア（経験 3〜10 年）、ブラウザ内 ML 推論・3D・データ可視化を本番投入検討中
• 扱わない: WGSL シェーダの逐行解説／各ブラウザの個別バグ詳細／WebXR / Vision Pro 特化最適化

1. WebGPU の現在地（2026-05時点）

1.1 標準化の状況

WebGPU は W3C の Candidate Recommendation Draft（最新 2026-03-10 [公式値]、W3C TR/webgpu）。WGSL は 2025-08-18 の Process Document に基づく Draft [公式値]（W3C TR/WGSL）。判断軸は仕様ではなく 対応ブラウザのカバレッジ に変わりました（経験則）。

1.2 4 ブラウザ対応のタイムライン

ソース: Chrome Status / web.dev — WebGPU in major browsers / Mozilla 公表。

2025 年後半に主要 4 ブラウザの安定提供がそろい、残るは Linux Firefox の 1 ピースだけ。ボトルネックは実装側から設計側へ 移り、if ('gpu' in navigator) の一行は簡単でも 2 系統の実装 を回す手間が新しいコストです（経験則）。

2. 主要ユースケース3本

2.1 ML inference（最も伸びた領域）

採用を押し上げた主役は ブラウザ内 ML 推論 です。Transformers.js v3 は ONNX Runtime Web の WebGPU execution provider 経由で device: 'webgpu' を指定するだけで GPU 推論が有効になります [公式値]（Transformers.js v3）。

import { pipeline } from '@huggingface/transformers';
const pipe = await pipeline('text-generation', 'onnx-community/Qwen3.5-0.8B', {
  device: 'webgpu',
});

[公式値] 公式ブログには WebGPU vs WebAssembly で 10〜15 倍、最大 100 倍の事例 が掲載。device: 'webgpu' 指定で有効化 する API も公式提供。（事例） 2026-03 に Qwen 3.5 0.8B のブラウザ内ローカル動作デモが公開され、Microsoft Tech Community でも Phi-3-mini を WebGPU + ONNX Runtime Web でブラウザ内 RAG する事例が紹介されています。

効きどころ（経験則）: オフラインチャット UI、外部送信できないユースケース（医療メモ要約・社内検索）、遅延が致命的なリアルタイム入力支援。クラウドの 300〜800ms 処理をローカル GPU で 30〜80ms に置き換えるシナリオが現実圏です。

2.2 3D 描画（Three.js / Babylon.js の WebGPU バックエンド）

[公式値] Three.js と Babylon.js は WebGPU バックエンドを公式提供。利点は ドローコール削減、コンピュートシェーダ（物理／パーティクル／スキニング）、HDR / 広色域（Safari の HDR images in WebGPU Canvas 対応 [公式値]）の 3 点。自動で速くはなりません（経験則）。効くのは GPU 側がボトルネックで CPU に余裕がある 構成のみで、小規模シーンでは体感差は出ません。

2.3 汎用 GPU compute（compute shader 用途）

画像処理・データ可視化・物理シミュレーション・大規模配列集計など ループを GPU で並列化したい 用途です。WebGL でも GPGPU は可能でしたがフラグメントシェーダに計算を載せるハックが必要でした。WebGPU の compute shader と storage buffer でこの種の処理が素直に書けます（経験則）。

3. 技術選定マトリクス: WebGPU / WebGL / Wasm SIMD

3 つの並列計算手段の使い分け（経験則）:

選び方（経験則）: 計算量が GPU 規模なら WebGPU、互換性最優先なら WebGL、CPU 完結の数値計算は Wasm SIMD。サーバー側 Wasm は Wasmはサーバー実装で本当に効くのか、エッジで ML を動かすかは Edge Functions採用の判断軸とアンチパターン と合わせて読むと、ブラウザ／エッジ／サーバーの推論レイヤ分担が立体的に見えます。

4. WebGPU vs WebNN: NPU との棲み分け

「WebGPU が ML で速いなら WebNN は不要では」という質問をよく受けますが、両者は棲み分け が前提です。

4.1 WebNN の現在地

[公式値] Web Neural Network API（WebNN）は 2026-01-22 に Updated Candidate Recommendation が公開（W3C TR/webnn）。Snapshot 2024-04-11 → 2026-01-22 で 100 件超の重要変更、コメント期限 2026-03-22。強化点は 第 3 波の transformers operator、MLTensor API（buffer sharing）、新しい抽象 device 選択。ブラウザ対応は Chrome / Edge 実装済み、Firefox / Safari は 2026-05 時点では未対応（要追跡）。

4.2 NPU アクセスという最大の差別化

[公式値] WebNN は NPU（Neural Processing Unit）にアクセスできる Web 唯一の API。Apple Silicon の Neural Engine、Qualcomm Hexagon、Intel NPU を叩く正規ルートは WebNN だけ。WebGPU は汎用 GPU compute で NPU は使えず、電力効率重視のモバイルや Neural Engine 適合モデルでは WebNN が原理的に優位（経験則）。

4.3 どちらを選ぶかの決定木

実務軸（経験則）: Chrome/Edge 限定なら WebNN 優先／ONNX 化済みなら execution provider 切替で 1 コード両対応／NPU 効率要件なら WebNN 必須、それ以外は WebGPU で十分。[公式値] MLTensor API の buffer sharing で「WebGPU で前処理 → WebNN で推論 → WebGPU で可視化」の併用も選択肢。ブラウザ内推論の脅威モデル（配布・プロンプト注入・キャッシュ）は AI コーディングのセキュリティ設計 と合わせて。

5. 制約と落とし穴

• Linux Firefox 待ち [公式値]: Mozilla は 2026 年内対応予定。Linux デスクトップ主軸なら fallback 必須。
• Safari 26 未満 [公式値]: 対応は 26 系以降（macOS Tahoe 26 / iOS 26 / iPadOS 26 / visionOS 26）。1〜2 年は WebGL fallback を残す のが安全（経験則）。
• モバイル GPU 性能差: Android 121+ で Android 12 以降対応 [公式値] ですが、廉価帯では WebGL より遅くなる事例も（経験則）。端末 tier 検出 → 動的切替 が現実解。
• WGSL の学習コスト: GLSL と似て非なる言語で、バインディング・ストレージバッファ・コンピュートパイプラインに詰まりがち。1〜2 週間の素振り を見込む（経験則）。
• メモリ制約: PC ブラウザの現実圏は 0.5〜2B パラメータ帯（経験則）。1〜2GB クラスはモバイル不可。
• セキュリティ層の前提変更: モデルがクライアントに配布されるため 知的財産・プロンプト注入・キャッシュ制御 の脅威モデルが増えます（経験則）。

6. 段階導入のロードマップ

本番に載せる順序（経験則）:

1. フィーチャー検出を 1 箇所に集約（lib/gpu/feature-detect.ts に if ('gpu' in navigator) を閉じ込める）
2. fallback パス（WebGL / Wasm SIMD）を先に動かす
3. WebGPU 専用パスは progressive enhancement に留める
4. ML 推論は ONNX Runtime Web の execution provider 切替に揃え 3 系統を 1 コードで持ち回す
5. 計測を 2 系統で取る（WebGPU と fallback の p95 を両方）

ビルド面は Vite 8 + Rolldown などで WGSL をアセット直インポートできる環境が整い、開発体験のギャップは縮小中（Vite 8 + Rolldown 移行の実務影響）。なお WebGPU 導入で Core Web Vitals は自動改善しません（経験則）。初期化は ファーストビューの遅延要因 になりやすく、遅延ロード／初回描画後の起動と組み合わせが必要です（フロントエンドのパフォーマンス改善はどこから手を付けるか）。

References

1. W3C WebGPU Specification (CR Draft, 2026-03-10) — 仕様正本
2. W3C WGSL Specification — シェーダ言語仕様
3. Chrome Platform Status: WebGPU — Chrome 出荷タイムライン
4. web.dev — WebGPU in major browsers — 4 ブラウザ総括
5. Hugging Face — Transformers.js v3 — device: 'webgpu' 公式データ
6. W3C WebNN (Updated CR 2026-01-22) — WebNN 仕様
7. MDN WebGPU API — API リファレンス

関連記事

• Wasmはサーバー実装で本当に効くのか — Wasm の使いどころを WebGPU と並べて
• Edge Functions採用の判断軸とアンチパターン — エッジで ML 推論を動かす判断軸
• フロントエンドのパフォーマンス改善はどこから手を付けるか — WebGPU 初期化と Core Web Vitals の両立
• Vite 8 + Rolldown 移行の実務影響 — モダンビルドと WGSL アセット統合
• AI コーディングのセキュリティ設計 — ブラウザ内推論の脅威モデル

まとめ

WebGPU は 2025 年後半に主要 4 ブラウザの安定提供がそろい、ボトルネックは実装側から設計側へ移りました。残るピースは Linux Firefox（2026 年内予定）のみ、fallback と progressive enhancement を前提にすれば本番投入は現実的 な段階です。

採用検討では ML 推論／3D／GPU compute のどれが本命か を固め、WebNN（NPU）／WebGL（互換性）／Wasm SIMD（CPU）との棲み分け をセットで設計してください。判断材料は §3 の比較表と §4.3 の決定木を。迷いどころは 記事診断 にご相談ください。

FAQ

Q1. 2026-05 時点で本番に WebGPU を入れていい？

[公式値] 主要 4 ブラウザで安定提供がそろい、残るは Linux Firefox（2026 年内予定）。WebGL / Wasm SIMD の fallback を伴う段階導入 なら本番投入は現実的（経験則）。

Q2. ブラウザ内 ML 推論はクラウド推論の代替？

代替ではなく 棲み分け です（経験則）。オフライン・プライバシー・低遅延 が強みで現実圏は 0.5〜2B パラメータ帯。[公式値] Transformers.js v3 で WebGPU vs WebAssembly が 10〜15 倍、最大 100 倍の事例。7B 超や高精度要件はクラウド推論が現実的。

Q3. WebGPU と WebNN はどう使い分ける？

[公式値] WebNN は NPU にアクセスできる Web 唯一の API（Chrome / Edge 実装済、Firefox / Safari は 2026-05 時点では未対応・要追跡）。汎用 compute・3D は WebGPU、NPU 効率は WebNN、両対応は ONNX Runtime Web の execution provider 切替 が実務軸（経験則）。

Q4. Three.js を WebGPU に切り替えれば速くなる？

シーンが GPU バウンドかで決まります（経験則）。ドローコール多・コンピュートで物理寄せ・HDR なら効き、小規模シーンで CPU に余力があるなら体感差は出ません。[公式値] Three.js / Babylon.js は WebGPU バックエンドを公式提供。

Q5. WGSL の学習コストは？

3D ライブラリ経由なら隠蔽されますが、カスタムシェーダで急に上がります（経験則）。バインディング・ストレージバッファ・コンピュートパイプライン は別概念で 1〜2 週間の素振り を見込みます。正本は W3C TR/WGSL [公式値]。