WebGPU — ブラウザがローカルGPUを直接使う仕組み
WebGLの後継、Vulkan/Metal/DX12レベルの低レベルGPU APIがブラウザに
WebGPUはnavigator.gpuでアクセスするブラウザ内蔵APIだ。インストール不要 — JavaScriptからローカルGPUを直接制御できる。
WebGLと何が違うか
WebGLは2011年に登場した。OpenGL ES 2.0をブラウザにラッピングしたもので、1990年代の設計ベースのためGPUの最新機能を使えなかった。コンピュートシェーダーがなく、暗黙的な状態管理によるドライバオーバーヘッドが大きい。
WebGPUは2023年から登場した次世代API。Vulkan、Metal、DirectX 12のような2015年以降の設計を基盤とする。GPUにより直接的にアクセスでき、コンピュートシェーダーをサポートし、コマンドを複数スレッドで準備できる。
ブラウザ → OS別マッピング
navigator.gpu.requestAdapter()を呼ぶとブラウザが内部的にOS別ネイティブAPIにマッピングする。
Windows → DirectX 12
macOS → Metal
Linux → Vulkan
開発者はこの違いを意識しない。同じJavaScript/WGSLコードが全OSで動く。
どんな作業に使われるか
- 映像編集 — フレームごとにGPUシェーダーでエフェクト合成（Tooscut等）
- 3Dゲーム/レンダリング — Three.jsもWebGPUバックエンドを追加
- AI推論 — ブラウザでモデル実行（ONNX Runtime Web等）
- 科学シミュレーション — 大規模並列演算（流体、パーティクルシミュレーション）
CPUは8〜16コアで順次処理するが、GPUは数千コアで同一演算を一度に回す。全ピクセルに同じ関数を適用する作業がまさにこのパターンで、GPU加速効果が大きい。
WebGLは死んだか
WebGLはほぼ全ブラウザで動く。WebGPUは現時点でChrome/Edge程度。SafariとFirefoxは未完成。3Dグラフィックスだけならwebglが互換性面でまだ安全だ。コンピュートシェーダーや最新GPU機能が必要ならWebGPUが唯一の選択肢。
動作フロー
navigator.gpu.requestAdapter() → GPUアダプター要求（ブラウザがOS別ネイティブAPIにマッピング）
adapter.requestDevice() → GPUデバイス（接続）取得
device.createShaderModule({ code: WGSL }) → WGSLシェーダーコンパイル
device.createRenderPipeline() → バーテックス/フラグメントシェーダー ＋ ブレンディング設定
commandEncoder → renderPass → draw() → GPUが数千コアで並列実行
メリット
- ✓ インストール不要 — navigator.gpu一行でGPUアクセス
- ✓ コンピュートシェーダー対応 — グラフィックスだけでなく汎用GPU計算可能
- ✓ クロスプラットフォーム — 同じWGSLコードがWindows/macOS/Linuxで動作
- ✓ Rust/WASMと組み合わせるとネイティブアプリに近い性能
デメリット
- ✗ Chrome/Edgeのみ完全対応 — Safari非対応、Firefox不安定
- ✗ WebGPU 1.0仕様が最新GPU機能を全てカバーしない
- ✗ WebGL比で学習コストが高い — パイプライン/バインドグループ等の低レベル概念が必要
- ✗ デバイスごとのGPU性能差が大きい — 内蔵GPU vs 外部GPU