WebGPU vs WebGL: 業界が移行する理由

WebGLやThree.jsなどのライブラリで3D体験を構築したことがあれば、おなじみの壁に直面したことがあるでしょう。GPUが十分に活用されていないにもかかわらずCPUがボトルネックになる、コンピュートシェーダーにアクセスできない、デバイスによって異なる不可解なGLSLエラーなどです。WebGPUは、これらの制限に直接対処します。これはWebGL 3.0ではなく、現代のGPUが実際にどのように動作するかを中心に設計された、根本的に異なるAPIモデルです。

この記事では、実践において重要なアーキテクチャの違い、WebGPU APIがレンダリングとコンピュートワークフローにもたらす変化、そしてプロジェクトへの採用タイミングを評価する方法について説明します。

2つの異なるAPIモデル

WebGLレンダリングは、OpenGL ES 2.0から継承されたステートマシン設計に従います。グローバルステート(バインドされたテクスチャ、アクティブなシェーダー、ブレンドモード)を設定すると、そのステートは変更するまで持続します。このモデルは2011年には理にかなっていましたが、スケールすると問題が発生します。忘れられたステート変更が微妙なバグを引き起こし、シングルスレッドのコマンド送信がCPUバウンドなシーンのボトルネックになります。

WebGPUは、Vulkan、Metal、Direct3D 12で使用される明示的なアプローチを採用しています。可変的なグローバルステートの代わりに、すべてのレンダリング設定を事前にカプセル化した不変のパイプラインオブジェクトを作成します。リソースは個別にバインドされるのではなく、バインドグループに整理されます。コマンドはコマンドバッファに記録され、バッチで送信されます。

この明示的なモデルは、より多くの事前作業を必要としますが、バグのカテゴリ全体を排除します。さらに重要なのは、GPUドライバが開発者の意図を推測することなくコマンド実行を最適化できることです。

パイプライン、バインドグループ、コマンドバッファ

WebGLからWebGPUへの実践的な移行は、3つの概念を中心に展開されます。

パイプラインは、シェーダーモジュール、頂点レイアウト、ブレンドステート、レンダーターゲットを不変のオブジェクトにバンドルします。初期化時にパイプラインを作成し、レンダリング時にそれらを参照します。設定を変更するには新しいパイプラインを作成する必要があります。これは高コストに聞こえますが、積極的なドライバ最適化を可能にします。

バインドグループは、WebGLの個別のユニフォームとテクスチャバインディングを置き換えます。gl.uniform*やgl.bindTextureを繰り返し呼び出す代わりに、バインドグループレイアウトを定義し、そのレイアウトに一致するバインドグループを作成し、単一の呼び出しでグループ全体をスワップします。これにより、フレームごとのAPIオーバーヘッドが大幅に削減されます。

コマンドバッファは、コマンドの記録と送信を分離します。複数のスレッドでコマンドを記録し、完成したバッファをGPUキューに送信できます。これがWebGPUのマルチスレッド潜在能力が存在する場所ですが、ほとんどのフレームワークユーザーはこれに直接対話することはありません。

WGSLがGLSLを置き換える

WebGPUは、GLSLの代わりにWGSL(WebGPU Shading Language)を使用します。構文は異なりますが、基本的な概念(頂点シェーダー、フラグメントシェーダー、ユニフォーム、varying)は馴染みのあるものです。

意味のある変化はツーリングです。WGSLはWebのセキュリティモデル向けに設計され、デバイス間でより一貫性のあるコンパイル動作を提供します。エラーメッセージには、GLSLがしばしば生成する不可解なベンダー固有の出力ではなく、ソースの場所と実行可能な説明が含まれます。

Three.jsを使用している場合、TSL(Three.js Shading Language)抽象化により、GLSLとWGSLの両方にコンパイルされるJavaScriptでシェーダーを記述でき、移行が容易になります。

コンピュートシェーダーが可能性を変える

WebGLはGPU使用をグラフィックスに制限します。物理演算、パーティクルシステム、プロシージャル生成はCPU上で実行され、コンピュート集約型アプリケーションのパフォーマンス上限を作り出します。

WebGPU APIには、GPU上で任意の並列計算を実行するプログラムであるコンピュートシェーダーが含まれています。有利な場合、CPUでフレームあたり数十ミリ秒かかる大規模パーティクルシステムなどのワークロードが、GPUコンピュートを使用すると数ミリ秒に短縮できます。同じことが流体シミュレーション、AI推論、リアルタイムデータ処理にも当てはまります。

これは段階的な改善ではありません。コンピュートシェーダーは、Webグラフィックスでは以前は実現不可能だったワークロードを可能にします。

フレームワークの現実: WebGLフォールバックを備えたWebGPUバックエンド

ほとんどの開発者は、生のWebGPUコードを書くことはありません。Three.js、Babylon.js、PlayCanvas、UnityのWeb出力はすべて、WebGPUバックエンドをサポートしているか、追加中です。典型的なパターンは、サポートされていないブラウザ向けの自動WebGLフォールバックを備えた、プライマリレンダラーとしてのWebGPUです。

Three.jsではこれが簡単です:

// WebGPU with automatic fallback
import * as THREE from 'three';
import WebGPURenderer from 'three/addons/renderers/webgpu/WebGPURenderer.js';

const renderer = new WebGPURenderer();
await renderer.init();

基本的なシーンでは、このスワップはすぐに機能します。コンピュートシェーダーや高度な機能を活用するには追加のコードが必要ですが、移行パスは段階的です。

ブラウザサポートと残るギャップ

2026年1月現在、WebGPUはデスクトッププラットフォーム全体でChrome、Edge、Operaで出荷されています。SafariはWebGPUをサポートし、macOS 26(Tahoe)以降ではデフォルトで有効になっていますが、古いmacOSバージョンでは機能フラグが必要です。FirefoxはWindowsとmacOS 26+でデフォルトでWebGPUを出荷していますが、他のプラットフォームはまだフラグの背後にあります。モバイルサポートは改善していますが、デバイスとOSバージョン間でまだ不均一です。ターゲットオーディエンスの現在のステータスはcaniuse.com/webgpuで確認してください。

WebGLは非推奨ではありません。普遍的な互換性を必要とするプロジェクトや、既存のコードベースがうまく機能している場合には、依然として正しい選択です。しかし、新しいグラフィックスとコンピュートへの投資はWebGPUに向かっています。機能、最適化、フレームワーク開発の焦点は今そこにあります。

移行のタイミング

6ヶ月以上のタイムライン、コンピュート集約型ワークロード、またはGPUに余裕があるにもかかわらずCPUボトルネックに直面しているシーンを持つ新規プロジェクトでは、WebGPUを評価してください。今日普遍的なブラウザサポートを必要とする本番アプリケーション、またはWebGPUが解決する特定のパフォーマンス問題がない既存のコードベースでは、WebGLを使い続けてください。

結論

WebGLからWebGPUへの移行は緩やかであり、緊急ではありません。WebGPUの明示的なAPIモデル、コンピュートシェーダーサポート、改善されたツーリングは、Webグラフィックスにとって意味のある前進を表していますが、WebGLは多くのユースケースで依然として実行可能です。今WebGPUのアーキテクチャモデルを理解することで、プロジェクトが低レベルのGPUアクセスと並列コンピュート機能から恩恵を受けるときに、それを活用できる立場に立つことができます。

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.