WebGPU時代が本格到来：全主要ブラウザ対応完了、WebGL15年の終焉とゲームWeb展開の未来

2026年1月、ついにその日が来た。Firefox 147がWindows・Mac・Linuxの全プラットフォームでWebGPUをデフォルト有効化し、Chrome・Safari・Edgeと合わせて全主要ブラウザがWebGPUに対応完了した。グローバルカバレッジは約95%。残り5%の古いブラウザにはWebGL2への自動フォールバックが用意されており、事実上「WebGPU前提」で開発できる時代が始まった。

WebGLがブラウザに3Dをもたらしてから約15年。その後継であるWebGPUは、単なるバージョンアップではない。設計思想からAPIアーキテクチャまで根本的に異なる、まったく新しいグラフィックスAPIだ。この記事では、ゲームデベロッパーや3DCGアーティストに向けて「なぜ今WebGPUが重要なのか」を技術的な裏付けとともに解説する。

WebGLの15年と限界

WebGLは2011年に正式リリースされ、ブラウザで3Dグラフィックスを扱う唯一の標準として長く君臨してきた。Three.jsやBabylon.jsといったフレームワークのエコシステムも充実し、多くの開発者に愛用されてきた。

しかし、WebGLには構造的な限界があった。

• OpenGLベース：WebGLの基盤であるOpenGLは既に開発が停止しており、モダンGPUの機能を活用できない
• ステートフルAPI：グローバルな状態を逐一変更しながら描画命令を発行する設計で、バグの温床になりやすく、最適化も困難
• コンピュートシェーダー非対応：GPUの汎用計算能力を使えず、物理シミュレーションやAI推論をGPU側で処理できなかった
• シングルスレッド前提：CPUオーバーヘッドが大きく、draw callが増えるとすぐにCPUがボトルネックになる

デスクトップのネイティブアプリケーションがVulkan・Metal・DirectX 12に移行して久しい中、ブラウザだけが「OpenGL世代」に取り残されていた。WebGPUはこの溝を埋めるために生まれたAPIだ。

WebGPU全主要ブラウザ対応完了──何が変わったか

WebGPUの各ブラウザ対応は段階的に進んできた。以下がその全体像だ。

技術的に見ると、WebGPUはWebGLとは根本的に異なる設計思想を持っている。

• Vulkan / Metal / DirectX 12ベース：各OSのモダンなグラフィックスAPIにネイティブにマッピングされる
• ステートレスAPI：コマンドバッファにまとめて命令を記録し、一括送信する方式。状態管理のバグが激減する
• コンピュートシェーダー対応：GPUの計算能力を描画以外にも自由に使える
• マルチスレッド対応：Web Workerから描画コマンドを発行でき、CPUのボトルネックが大幅に緩和される
• 新シェーダー言語WGSL：GLSLに代わり、安全性と可読性を重視した新しいシェーダー言語が標準となった

圧倒的なパフォーマンス差

WebGPUの技術的優位性は、具体的な数値で見ると衝撃的だ。

描画パフォーマンス

WebGLで15,000個のキューブを描画した場合、フレームレートは30fpsでCPU使用率は95%に達する。一方、WebGPUでは200,000個のキューブを60fpsで描画しながら、CPU使用率はわずか5%だ。オブジェクト数で13倍、CPU効率で19倍、総合的なスループットでは最大200倍の差がつく。

Three.js v190のWebGPUレンダラーは、従来のWebGLレンダラーに対して約2倍の描画性能を達成している。フレームワーク層での最適化が入った上でこの数値なので、ローレベルAPIを直接叩けばさらに大きな差が出る。

コンピュートシェーダーによる性能向上

特筆すべきは、これらの高速化がブラウザ内で完結しているという点だ。サーバーへのリクエストもネイティブプラグインも不要。ユーザーがURLを開くだけで、この性能が手に入る。

フレームワーク対応：Three.js / Babylon.js / Unity最新状況

WebGPUのブラウザサポートが揃ったことで、主要フレームワークの対応も一気に進んだ。

Three.js v190（2026年スタンダード）

Three.jsはv190でWebGPUレンダラーをデフォルトに切り替えた。開発者がやることはシンプルだ。

import * as THREE from 'three/webgpu'

このインポートに変更するだけで、WebGPU対応ブラウザではWebGPUレンダラーが、非対応ブラウザではWebGL2レンダラーが自動的に選択される。既存のThree.jsプロジェクトからの移行コストは最小限に抑えられている。

Babylon.js v9.0（2026年スタンダード）

Babylon.jsはv9.0でエンタープライズ向けVR/AR機能を強化しつつ、WGSLネイティブシェーダーのフルサポートを実現した。WebGPUのコンピュートシェーダーAPIに直接アクセスできるため、物理シミュレーションやパーティクルシステムをGPU側で完結させることが可能だ。

Unity 6.0.3

Unityは6.0.3で実験的なWebGPUサポートを追加した。プロジェクト設定からWebGPUバックエンドを選択でき、WebGLビルドに比べて描画パフォーマンスが大幅に向上する。ただし、まだ「実験的」の位置付けであり、本番運用には注意が必要だ。

Unreal Engine 5

UE5は現時点で公式のWebGPUサポートを提供していない。コミュニティによる実装は存在するが、プロダクション品質には達していない。UE5をブラウザ展開する場合は、Pixel Streamingなどサーバーサイドレンダリングのアプローチが依然として現実的だ。

Compute Shaderが開く新世界

WebGPU最大の技術的ブレークスルーは、コンピュートシェーダーがブラウザで使えるようになったことだ。これは描画とは無関係にGPUの並列計算能力を利用する仕組みで、ゲーム開発と3DCGの両方に革命的な変化をもたらす。

ブラウザ内LLM実行

WebLLMプロジェクトは、Llama 3やPhi-3といったLLMをブラウザ内で完全にローカル実行することを可能にした。WebGPUのコンピュートシェーダーがトランスフォーマーの行列演算を高速処理するため、サーバーに一切データを送らずにAI推論を実行できる。プライバシーが重要なアプリケーションや、オフライン環境での利用に大きな可能性がある。

3D Gaussian Splatting

NeRFの後継として注目されている3D Gaussian Splattingも、WebGPUの恩恵を大きく受けている。Shanghai AI Lab等が共同開発したVisionaryエンジンは、RTX 4090環境で2〜16ms/フレームのリアルタイムレンダリングを達成。WebGPUのコンピュートシェーダーによるソートとラスタライズの高速化がこの性能を支えている。

フォトグラメトリで取得した実空間のデータを、ブラウザ上でリアルタイムに閲覧できる未来が現実のものになりつつある。

物理シミュレーションと大規模データ可視化

PhysiSimのような物理シミュレーションエンジンは、WebGPUのコンピュートシェーダーにより従来比28倍高速かつ電力40%削減を実現した。大量のパーティクルや剛体の衝突計算をGPU上で並列処理できるため、ブラウザ上でもデスクトップアプリ並みのシミュレーションが可能になっている。

ゲーム・3DCGクリエイターへの影響

「技術的にすごいのは分かった。で、自分の仕事にどう影響するの？」という実務的な視点で整理してみよう。

ゲーム開発者にとって

• Web展開の性能天井が大幅に上がった：WebGLでは「2Dカジュアルゲームが限界」だったが、WebGPUなら中規模の3Dゲームもブラウザで十分動く。Cat Warrior Parkour（Pelican Party Studios）はThree.js製の3Dパルクールゲームで、3秒でロード完了する実例だ
• インスタントプレイの実現：URLを共有するだけでゲームが起動する体験は、ストアからのダウンロードを待つ体験とは質的に異なる。itch.ioやSteamのデモ公開の代替として、Webビルドの価値が高まる
• GPU計算によるゲームプレイの進化：コンピュートシェーダーにより、大規模な物理演算やAI NPC、プロシージャル生成をクライアント側で処理できるようになる

3DCGアーティストにとって

• ポートフォリオの進化：5000万ポリゴンを120FPSで表示しリアルタイムシャドウまで処理できる性能（Enginertoの実績）は、作品展示の常識を変える
• 3DGSビューアーの実用化：スキャンした実空間データをブラウザで共有・閲覧できるため、建築・不動産・文化財保存など、クライアントへのプレゼンテーション手段が広がる
• リアルタイムレンダリングの民主化：専用ソフトウェアのインストール不要で、ブラウザだけでPBRマテリアルのリアルタイムプレビューが可能になる

筆者より：過渡期だが今すぐ学ぶべき理由

正直に言えば、WebGPUはまだ過渡期にある。Unity 6のサポートは実験的だし、UE5は公式対応すらしていない。WGSLの書き方に慣れている開発者もまだ少ない。

だが、だからこそ今が学び時だ。

Three.js v190がWebGPUをデフォルトにした時点で、Three.jsユーザーは「知らないうちにWebGPUを使っている」状態になった。APIの自動切替により意識せずとも恩恵は受けられるが、コンピュートシェーダーを活用した本格的な最適化は手動での実装が必要だ。ここが今後の技術的な差別化ポイントになる。

WebGLを学んだときのことを思い出してほしい。初期に習得した人は、その後のWebGLエコシステムの爆発的成長の波に乗れた。WebGPUでも同じことが起きるだろう。ブラウザカバレッジ95%という土台は既に整った。あとは私たち開発者がその上に何を築くかだ。

まずはThree.js v190のWebGPUレンダラーを試すところから始めてみよう。import * as THREE from 'three/webgpu' ――たった1行のインポート変更が、次の15年への第一歩になる。