WebGL vs WebGPU 詳細比較

JavaScriptを有効にしてください

まえがき

WebGLとWebGPUについて、ChatGPTのDeep Researchで調査しました。

1. 技術的な比較

パフォーマンスの違い

WebGPUは最新の低レベルGPU API（Direct3D 12やVulkan、Metal）に近い設計のため、描画コマンドのオーバーヘッドが小さく、高負荷なシーンでWebGLより高い性能を引き出せる可能性があります ( [1] )。実際、ゲームエンジンGodotを用いた比較では、重い3Dシーンや負荷の高いテストでWebGPUの方がWebGLよりも高いフレームレートを実現しています。ただし、「WebGPUだから自動的に高速化する」わけではありません ( [1] )。WebGPUは柔軟性が高くWebGLにない機能を備えるため、エンジンやアプリ側で適切に最適化を行えば性能向上につながる一方、単純な描画ではWebGLと大差ない場合もあります ( [1] )。つまり魔法のように性能が上がるわけではなく、大量の描画コールをまとめる（バッチ処理）などの最適化はWebGPUでも依然として重要です ( [1] )。

機能・表現力の差

WebGLは基本的に頂点シェーダーとフラグメントシェーダーのみをサポートし、プログラマブルなパイプラインは限定的です（WebGL2で一部拡張されていますが、GPU計算などには対応していません）。一方、WebGPUはコンピュートシェーダーを含む最新GPU機能をサポートし、WebGLでは困難だった汎用計算処理(GPGPU)や複雑なレンダリング手法に対応できます。例えばWebGPUでは大容量のストレージバッファやストレージテクスチャが使用可能で、膨大なデータをシェーダーで扱えます（WebGLはUniformバッファ等に制限があります）。またマルチレンダーターゲットや非同期処理なども充実しています。さらに、WebGLが扱う座標系はOpenGL由来で深度クリップ範囲が-1～1なのに対し、WebGPUはVulkan/Metalに合わせ0～1になっているなど細部も異なります。総じてWebGPUは最新GPUの機能を幅広く露出しており、レイトレーシングや高度なポストエフェクトの実装、機械学習の高速化など将来的な拡張性に優れています ( [2] )。

API構造の違い

WebGLは状態ベースのAPIで、関数呼び出しごとにグローバルなGLコンテキストの状態を変更しながら描画します。例えば現在バインドされているテクスチャやシェーダープログラムなどのグローバル状態に依存して動作し、これがエラーの原因になりやすいとされています。対してWebGPUはステートレスなAPIで、描画状態はすべてRenderPipelineオブジェクトとしてカプセル化されます。パイプラインにシェーダーやブレンド設定、頂点レイアウトなどを不変の形で保持し、毎フレーム使い回す設計です。この違いにより、WebGPUでは設定漏れや状態競合が起きにくく、コードのモジュール化もしやすいメリットがあります。プログラミングモデルとしては、WebGLがgl.drawArraysのような即時実行関数を多用するのに対し、WebGPUではコマンドバッファ（CommandEncoderやRenderPassEncoder）に描画命令を記録し、一括してGPUに送ります ( [3] )。また使用言語にも差異があり、WebGLのシェーダー言語はGLSL（OpenGL Shading Language）ですが、WebGPUでは専用のWGSL（WebGPU Shading Language）を用います。WGSLは型安全でWeb向けに設計されており、HLSLやSPIR-Vにコンパイルされ各プラットフォームのネイティブAPIにマッピングされます。

サポートされるプラットフォーム・ブラウザ

WebGLは登場から10年以上経ち非常に成熟しており、主要なデスクトップ・モバイルのすべてのブラウザでサポートされています。ChromeやFirefox、Safari、EdgeはいずれもWebGL1.0およびWebGL2.0に対応済みで、Canvasからwebglもしくはwebgl2コンテキストを取得すれば即座に使用可能です。対応OSも幅広く、古いGPUやドライバでもANGLEなどの翻訳レイヤーにより動作するため互換性が高いです ( [4] )。一方、WebGPUは2023年に初めて安定版ブラウザに実装された新APIで、対応状況は限定的です。Chrome 113以降およびそれをベースにしたEdge・Operaでは標準で有効化されました ( [5] )。またAndroid版ChromeやSamsung Internetなど一部モバイルChromium系ブラウザも対応しています ( [3] )。FirefoxとSafariについては2024年時点でまだデフォルト有効ではなく、Firefoxはdom.webgpu.enabledフラグをオンにする必要があり、SafariもTechnology Preview版で試験的に利用できる状態です ( [3] )。Safari安定版（macOS/iOS）ではWebGPUは現状オフのままですが、将来的サポートに向けAppleも開発に参加しています ( [6] )。このようにWebGPUはChrome系ブラウザで先行実装され、Safari・Firefoxは追随中という状況です ( [3] )。加えてWebGPUは比較的新しいGPUハードウェアとドライバを必要とするため、古いデバイスではブラウザが対応していても利用不可の場合があります ( [4] )。一方WebGLは旧式GPUでもソフトウェアエミュレーションや古いOpenGL経由で動作することが多く、普及度（利用可能環境）は依然WebGLが上です ( [4] )。総括すると、互換性重視ならWebGL、最新機能と性能重視ならWebGPUという棲み分けになっています。

2. どちらを学ぶべきか・使うべきかの判断基準

初心者への適性

Web開発や3Dプログラミングの初心者にとっては、WebGLの方が取り組みやすいと言えます。理由として、WebGLは歴史が長くチュートリアルや教材が豊富であり、APIも高水準でシンプルな描画までの道のりが短いためです。たとえばcanvas要素からWebGLコンテキストを取得し、頂点シェーダー・フラグメントシェーダーを書いて三角形を描くまでのコード量はWebGPUに比べ少なく済みます（後述のコード例参照）。またThree.jsやBabylon.jsといった高レベルの3DライブラリがWebGL上に構築されており、初心者はこれらを使って基礎を学べます。一方、WebGPUは低レベルで扱う概念が多く、初めて直接触れるにはハードルが高めです。デバイスやパイプラインの初期化、シェーダー言語WGSLの習得、コマンドエンコーダの扱いなど、理解すべき事項が増えます。実際「WebGPUはハードウェアに近い低レベルAPIで、細部の制御が必要な場合以外は適切な選択ではない。高レベルのラッパーやWebGLを使う方がよい」という指摘もあります ( [7] )。そのためまずWebGLで基本的なグラフィックスパイプラインの概念を学び、必要に応じてWebGPUにステップアップするのが無理のないアプローチです。

将来性と業界での重要性

将来性の観点ではWebGPUが非常に重要です。WebGPUは公式に「WebGLの後継」と位置づけられており、GoogleやApple、Mozilla、Microsoftなど主要企業が共同で仕様策定と実装を進めています ( [6] )。特にChrome(Chromium)チームは2023年にWebGPUを安定版に投入し、ブラウザ上で高度な3DグラフィックスやGPUコンピューティングを可能にする基盤として期待されています ( [2] )。また近年は機械学習やGPGPUの需要が高まっており、WebGPUはブラウザ上での機械学習推論の高速化（例：TensorFlow.jsのWebGPUバックエンド）や映像処理などにも応用が広がっています ( [2] )。一方、WebGLは既に確立された技術であり今後大きなアップデートは予定されていません。Khronos GroupはWebGLを保守し続けますが、新機能は限定的で、基本的には安定性と後方互換性の維持に重点が置かれています ( [4] )。実際、WebGPUの仕様策定にはKhronosは直接関与せず（WebGPUはW3C主導）、将来的にはWebGPUが標準的な選択肢になることを各社も見据えています。そのため業界の注目はWebGPUに移行しつつあり、モダンなWeb3DエンジンやツールはWebGPU対応を進めています（UnityやBabylon.jsの例は後述） ( [8] ) ( [9] )。総合すると、長期的キャリアや最先端技術習得を目指すならWebGPUを見据えるべきですが、2025年現在ではWebGLの知識も依然有用で、特に既存資産の活用や全ユーザへのリーチには欠かせません ( [4] )。

ユースケース別の適用例

どちらを使うべきかはユースケースによって判断できます。

  • 簡単な3D描画・幅広い端末サポート: インタラクティブなデータ可視化、簡易3Dゲーム、UI要素のちょっとした3D表現など、なるべく多くのユーザ環境で動かしたい場合はWebGLが適しています。現時点でiOSのSafariや旧式PCまで含め動作するのはWebGLだからです。初心者が学校や個人プロジェクトで3Dを試す際も、環境構築が容易なWebGLの方が無難でしょう。

  • 高度なグラフィックス表現: リアルタイムで数万以上のオブジェクトを描画する、大規模な3Dシーンで複雑なライティングやポストエフェクト処理を行うといった負荷の高いレンダリングにはWebGPUが有利です。例えば大量の描画コールやパーティクル演算を扱う場合、WebGPUの柔軟なパイプライン設定やComputeシェーダーで効率化できるためです ( [1] )。また今までWebGLでは難しかったリアルタイムGI（グローバルイルミネーション）や物理ベースレンダリングの高度な実装にも、WebGPUの機能が役立ちます。

  • GPUによる並列計算: グラフィックス以外でも、行列演算や科学計算をGPUで行うような用途（例: 大規模データの並列処理、機械学習推論）ではWebGPU一択です。WebGLでもテクスチャや頂点属性を使った疑似的な計算は可能でしたが、制約が多く効率も限定的でした。WebGPUは専用のComputeパイプラインでこれらを実装でき、例えばTensorFlow.jsはWebGLより高速なWebGPUバックエンドを実験的に提供しています（具体的な性能はモデルによりますが、GPU計算の表現力でWebGPUが勝ります）。

  • 既存フレームワークやエンジン利用: 既にThree.jsやBabylon.jsといったWebGLベースの成熟したフレームワークが存在する領域（例えば3Dモデルビューア、簡易ゲーム）では、当面それらを使うのが開発効率・安定性で勝るでしょう。逆に自前でレンダリングエンジンを構築する、あるいはUnityやUnreal Engineのような次世代Webエンジンのプラットフォームを狙う場合、将来を見据えてWebGPUを検討する価値があります。

要するに、「今すぐ広範囲に届ける」ならWebGL、「将来を見据えて高度なことをする」ならWebGPUという傾向です。ただし現在（2025年）時点では多くのケースで両者が併存する状況にあり、必要に応じて両方の知識を持っておくことが望ましいでしょう ( [1] )。Three.js開発者の見解では、「現時点で特定のWebGPU機能が必要でなければ、デフォルトのWebGLRendererを使うのが賢明。WebGPUレンダラーが十分に安定し高速になれば、Three.js自体がデフォルトを切り替えるだろう」とされています ( [1] )。このようにコミュニティも移行期であることを認識しており、用途に応じ使い分けるのが現実的な判断基準となります。

3. 具体的な実装方法とサンプルコード

以下にWebGLとWebGPUでそれぞれ三角形を描画する基本コードの例を示し、その書き方の違いを比較します。

WebGLの基本的な描画コード例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>WebGLの基本的な描画コード例</title>
</head>
<body>
<canvas id="glCanvas" width="300" height="300"></canvas>
<script>
  const canvas = document.getElementById('glCanvas');
  const gl = canvas.getContext('webgl');            // WebGLコンテキスト取得
  if (!gl) { console.error('WebGL not supported'); }

  // 頂点シェーダーとフラグメントシェーダーのソースコード
  const vsSource = `
    attribute vec3 a_position;
    void main(void) {
      gl_Position = vec4(a_position, 1.0);
    }
  `;

  const fsSource = `
    precision mediump float;
    void main(void) {
      gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);
    }
  `;


  // シェーダーをコンパイルしてプログラムを作成（詳細省略）
  const vs = gl.createShader(gl.VERTEX_SHADER);
  gl.shaderSource(vs, vsSource);
  gl.compileShader(vs);
  const fs = gl.createShader(gl.FRAGMENT_SHADER);
  gl.shaderSource(fs, fsSource);
  gl.compileShader(fs);
  const program = gl.createProgram();
  gl.attachShader(program, vs);
  gl.attachShader(program, fs);
  gl.linkProgram(program);
  gl.useProgram(program);                           // プログラムを現在の状態に使用

  // 三角形の頂点データを準備
  const vertices = new Float32Array([
    0.0,  0.5,  0.0,   // 上頂点 (x,y,z)
   -0.5, -0.5,  0.0,   // 左下頂点
    0.5, -0.5,  0.0    // 右下頂点
  ]);
  const buffer = gl.createBuffer();
  gl.bindBuffer(gl.ARRAY_BUFFER, buffer);
  gl.bufferData(gl.ARRAY_BUFFER, vertices, gl.STATIC_DRAW);  // GPUに頂点データを送信

  // シェーダー内の頂点属性に上記バッファを結びつける
  const posLocation = gl.getAttribLocation(program, "a_position");
  gl.enableVertexAttribArray(posLocation);
  gl.vertexAttribPointer(posLocation, 3, gl.FLOAT, false, 0, 0);

  // 画面をクリアして三角形を描画
  gl.clearColor(0.0, 0.0, 0.0, 1.0);
  gl.clear(gl.COLOR_BUFFER_BIT);
  gl.drawArrays(gl.TRIANGLES, 0, 3);                // 3頂点で三角形を描画
</script>
</body>
</html>

上記は典型的なWebGLコードの流れです。まずCanvasからglコンテキストを取得し、GLSLで書かれた頂点シェーダー・フラグメントシェーダーをコンパイルしてプログラムにリンクします。その後、JavaScriptで定義した頂点配列をFloat32Arrayに変換し、gl.bufferDataでGPUメモリ上のバッファに転送しています ( [10] )。次にgl.vertexAttribPointerでシェーダー内の属性（例: "a_position"）にこのバッファを紐付け、gl.drawArraysで描画命令を発行します ( [10] )。WebGLではこのようにGLの関数呼び出しが逐次実行され、裏ではこれらの操作がドライバに送られて即座にレンダリングが行われます。

WebGPUの基本的な描画コード例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>WebGPUの基本的な描画コード例</title>
</head>
<body>
<canvas id="gpuCanvas" width="300" height="300"></canvas>
<script type="module">
  const canvas = document.getElementById('gpuCanvas');
  // WebGPUコンテキスト取得とアダプタ・デバイス準備（非同期）
  if (!navigator.gpu) {
    console.error('WebGPU not supported');
  }
  const adapter = await navigator.gpu.requestAdapter();
  const device = await adapter.requestDevice();                // GPUデバイス取得
  const context = canvas.getContext('webgpu');
  const format = navigator.gpu.getPreferredCanvasFormat();
  context.configure({ device: device, format: format });       // 描画ターゲット(canvas)の設定

  // シェーダーモジュール作成（WGSLでシェーダーコードを記述）
  const shaderCode = `
    @vertex
    fn vs_main(@builtin(vertex_index) VertexIndex : u32)
             -> @builtin(position) vec4f {
      var pos = array<vec2f, 3>(
        vec2f( 0.0,  0.5),   // 上頂点 (x,y)
        vec2f(-0.5, -0.5),   // 左下頂点
        vec2f( 0.5, -0.5)    // 右下頂点
      );
      return vec4f(pos[VertexIndex], 0.0, 1.0);
    }
    @fragment
    fn fs_main() -> @location(0) vec4f {
      return vec4f(1.0, 0.8, 0.0, 1.0);  // オレンジ色
    }`;
  const shaderModule = device.createShaderModule({ code: shaderCode });

  // レンダーパイプラインの作成（シェーダーやターゲットフォーマットを指定）
  const pipeline = device.createRenderPipeline({
    layout: 'auto',
    vertex: { module: shaderModule, entryPoint: "vs_main" },
    fragment: { module: shaderModule, entryPoint: "fs_main",
                targets: [ { format: format } ] }
  });                                                      // パイプライン作成

  // コマンドエンコーダを作成しレンダーパスを開始
  const encoder = device.createCommandEncoder();
  const renderPass = encoder.beginRenderPass({
    colorAttachments: [{
      view: context.getCurrentTexture().createView(),
      clearValue: [0.0, 0.0, 0.0, 1.0],
      loadOp: 'clear',
      storeOp: 'store'
    }]
  });
  renderPass.setPipeline(pipeline);                        // パイプラインをセット
  renderPass.draw(3);                                      // 3頂点の描画コマンド
  renderPass.end();
  // コマンドをGPUキューに送信して実行
  device.queue.submit([ encoder.finish() ]);               // 描画実行
</script>
</body>
</html>

WebGPU版では、まずnavigator.gpu.requestAdapter()→requestDevice()でGPUアダプタとデバイスを取得します（これはプロミスを返す非同期処理であり、awaitで完了を待っています）。次にCanvasからwebgpuコンテキストを取得し、configureにより出力フォーマットやリンクするGPUデバイスを設定します。これで描画先（スワップチェイン）が初期化されます。

続いてWGSLで記述したシェーダーコード文字列からcreateShaderModuleでシェーダーモジュールを生成します。ここでは頂点シェーダーvs_mainで組み込み変数@builtin(vertex_index)を使い、あらかじめ定義した三角形の頂点座標配列から位置を決定しています。今回は頂点バッファを別途用意せず、シェーダー内で直接座標を決め打ちしています（インデックスで頂点を選ぶ簡易な方法） ( [3] )。フラグメントシェーダーfs_mainは常にオレンジ色を出力するだけです。

次にdevice.createRenderPipelineでレンダーパイプラインオブジェクトを作成します。 ( [3] )ここで頂点・フラグメントに先ほどのシェーダーモジュールとエントリポイント関数名を指定し、出力ターゲットのピクセル形式（Canvasのフォーマット）も渡します。レイアウトは'auto'を指定しており、バインドグループのレイアウトを自動推論しています（今回はバインドなし）。

描画の準備ができたら、device.createCommandEncoderでコマンドバッファのエンコーダを取得し、encoder.beginRenderPass(...)でレンダーパスを開始します。カラーアタッチメントにはcontext.getCurrentTexture()で取得した現在のフレーム用テクスチャを指定し、clearValueで背景色（黒）を設定しています ( [3] )。pass.setPipeline(pipeline)で先ほどのパイプラインをバインドし、pass.draw(3)で3頂点のプリミティブを描くドローコールをエンコードします ( [3] )。この時点ではまだ実行されておらず、あくまでコマンド列を記録しているだけです。pass.end()でレンダーパスを終了し、encoder.finish()でコマンドバッファを確定、最後にdevice.queue.submit(...)でGPUにコマンドを送信して実行します ( [3] )。

コードの書き方・構造の比較

上記コード例からも分かるように、WebGLとWebGPUでは初期化から描画までの手順が大きく異なります。WebGLは簡潔で、シェーダーのコンパイルやバッファ転送以降はgl.drawArraysを呼ぶだけで即描画されます ( [10] )。一方、WebGPUは非同期の初期化処理が必要で、また描画するにもパイプラインの事前用意とコマンドバッファへの記録という手順を踏みます。結果として同じ三角形を描画するにもWebGPUの方がコード量が多く、構造も複雑です ( [3] )。これは前述したようにWebGPUが低レベルAPIであり、開発者に明示的な制御を求める設計だからです。しかしその分、一度作成したパイプラインを繰り返し使って多くのオブジェクトを描画するような場合には、毎回状態を切り替えるWebGLより効率的になり得ます。またコード構造もオブジェクト指向的で、設定と描画コマンドが分離されているため、大規模プロジェクトでは扱いやすいという意見もあります。

両者のもう一つの大きな違いはシェーダー言語です。WebGLのシェーダーはGLSLで書かれ、文字列としてJavaScript側に埋め込みますが、WebGPUでは新しいWGSLを用います。WGSLは厳密な文法を持ち、各変数に@locationや@builtinといった修飾を付ける点が特徴です ( [3] )。GLSLと比べ最初は冗長に感じるかもしれませんが、これはVulkanやMetalに似た明示的な記述になっており、今後の標準的なシェーダー記述になる見込みです。

要約すると、WebGLは手軽に描画できるが自動で隠蔽された部分も多い、対してWebGPUは初期ボイラープレートが多いが柔軟で高度な制御が可能という違いがあります。それぞれのコードスタイルには一長一短がありますが、プロジェクト規模や要求性能に応じて適切な方を選ぶことが重要です。

4. ゲームやグラフィックス分野での活用例

ゲームエンジンでのサポート状況

UnityやUnreal Engineといった主要ゲームエンジンも、Webへの展開においてWebGPUに注目しています。UnityはこれまでWebGL (WebGL1/2) を使ってブラウザ向けエクスポートを実現してきましたが、Unity 2023以降でWebGPUを試験的（Experimental）にサポートし始めました ( [8] )。Unity公式マニュアルでも「WebGL2では利用できなかった最新機能をWebGPUで導入できる」と記載されており、限定的ながら将来の正式サポートに向けた取り組みが進んでいます ( [8] )。一方、Unreal Engineは現時点で公式にはWebGPU非対応ですが、開発コミュニティによる実験的な移植が報告されています ( [12] )。2023年には有志のチームがUE5をWebAssembly + WebGPUで動作させるプロジェクトを公開し、ブラウザ上でUnrealの高品質レンダリングを実現するデモが登場しました ( [13] )。Unreal公式も将来的な可能性に言及しており、「WebGPUが成熟しブラウザ対応が広がれば、エンジンとの統合が進む見通し」とされています ( [14] )。またオープンソースのGodot Engineは、バージョン4でレンダリング基盤をVulkanに刷新したこともあり、ブラウザエクスポートにWebGPUを利用することが期待されています。先述のようにGodotでWebGPUをバックエンドに使った研究ではパフォーマンス向上が確認されており、今後公式にWebGPUエクスポートが提供される可能性があります。

3Dグラフィックスライブラリでの利用事例

ブラウザ上の3D表示といえばThree.jsやBabylon.jsといったライブラリの存在も欠かせません。Three.jsは長年WebGLベースで発展してきましたが、近年実験的にWebGPUレンダラーの実装を進めています。まだ完全な機能網羅には至っていませんが、2023年時点でThree.jsにWebGPURendererクラスが追加され、Chromeなど対応ブラウザ上で一部のシーンをWebGPUで描画できるようになりました ( [1] )。もっともThree.js公式としては「WebGPUレンダラーは現状実験段階で、標準のWebGLレンダラーほど機能や安定性がない」ためデフォルトにはしておらず、先述のDon McCurdy氏のように開発者も慎重な姿勢です ( [1] )。一方のBabylon.jsは比較的早くからWebGPU対応に積極的で、バージョン5.0（2022年頃）で既に主要機能のWebGPU対応を進めてきました ( [9] )。Babylon.jsではengine = new BABYLON.WebGPUEngine(canvas)のようにWebGPU用エンジンを初期化し、Engine.IsSupportedでブラウザがWebGPU対応なら自動で切り替える、といった運用が可能になっています ( [15] )。実際Babylon.js公式のデモでは、水面シミュレーションや大量オブジェクト描画などWebGPUの利点を活かしたリッチな表現を実現しており、WebGLと比較してパフォーマンス向上が報告されています。これらライブラリの動向から、将来のブラウザ3D表現は徐々にWebGPUへシフトしていくことが伺えますが、当面はWebGLとWebGPUの両対応でユーザ環境に合わせて使い分ける形が取られています ( [1] ) ( [16] )。

ブラウザベースのアプリケーションでの利用

WebGLはこれまで、ゲーム以外にもCADや3DCGレンダリング、地図アプリなどブラウザ上で高度なグラフィックスを要するアプリに幅広く使われてきました。例えばAutoCADやSolidworksのようなCADソフトのWeb版、あるいはFigmaのようなベクター画像エディタでも一部WebGL技術が使われています。こうした分野でも徐々にWebGPUの活用が検討されています。ブラウザCADでは大規模な3Dモデル（数百万ポリゴン級）をスムーズに表示する必要があり、WebGPUのマルチドロー間接描画やバインドレステクスチャなどが実現すればシーン全体の描画負荷を大きく削減できる可能性があります ( [6] )。またレンダリング精度の面でも、WebGPUなら高品質なPBRシェーダーやコンピュートを駆使したリアルタイムのフォトリアルレンダリングが期待できます。実例として、ブラウザで動く3DレンダリングソフトのプロトタイプがWebGPUで開発された例があります。Mozillaの開発するオンラインゲームプラットフォームや、3Dデザインツールの一部でWebGPU技術を試す動きがあり、高解像度モデルのリアルタイム操作がデモされています。まだユーザ向け製品として本格採用されているケースは多くありませんが、CADやDCC（デジタルコンテンツ作成）領域でも将来はWebGPUが性能向上の鍵になると考えられています。

またグラフィックス以外では、ディープラーニングの推論やデータ可視化ツールでのWebGPU利用も進んでいます。ブラウザ上で大量の科学計算を行う際、従来はWebGLのフラグメントシェーダーを使った疑似計算か、WebAssemblyマルチスレッドでCPU並列処理するしかありませんでした。WebGPUの登場で、本格的なGPU並列計算が可能になり、例えば高速なデータプロット、ボリュームレンダリング（医療用3Dデータの表示）などでの利用が期待されています。実際、医学分野のWebアプリでWebGPUコンピュートシェーダーを用いてグラフレイアウト計算を高速化した研究も報告されており、WebGPU採用によりWebGL比で数倍の速度向上が得られたとのことです ( [17] )。

5. 最新の動向と今後の展望

WebGPUの開発進捗と今後の機能追加予定

WebGPUは仕様策定がW3CのGPU for the Webワーキンググループで活発に進められており、2024年11月時点で「W3C勧告候補（Candidate Recommendation）」に向けた最終調整段階にあります ( [6] )。Google、Mozilla、Apple、Intel、Microsoftなどが週次でミーティングを行い、残る課題の洗い出しと優先順位付けをしています ( [6] )。現在大きなブロッカー（阻害要因）はなく、知的財産の取り扱いなどもクリアして標準化ステータスを上げる見込みです ( [6] )。同時に、次期WebGPUの新機能についても議論が進んでいます ( [6] )。直近の会合では以下のような追加機能が優先度高とされました ( [6] ):

  • サブグループ (Subgroups) と行列サブグループ: 複数のシェーダースレッド間で高速にデータ共有を行う仕組みで、行列演算ハードウェアを活用して機械学習の推論（行列乗算）を高速化する機能 ( [6] )。大規模並列計算やディープラーニング用途で重要視されています。

  • テクセルバッファ (Texel buffers): 小さなサイズのデータ型（8bit/16bitなど）を効率よく格納・アクセスする新しいバッファタイプ ( [6] )。画像処理アルゴリズムなどで多数のピクセル値を扱う際の性能向上が期待されます。

  • UMAバッファマッピング: 統一メモリアーキテクチャ（Unified Memory Architecture）でのデータ転送を効率化し、CPU→GPU間のメモリコピーや同期のオーバーヘッドを削減する機能 ( [6] )。内蔵GPUやモバイルGPUで特に恩恵があります。

  • バインドレスリソース (Bindless): 現在のWebGPUは一度にバインドできるリソース数（バッファやテクスチャ）に上限がありますが、Bindlessが導入されるとシェーダー内でほぼ無制限のリソース参照が可能になります ( [6] )。これは最新のレンダリング手法（多数のテクスチャを扱うPBR、巨大なシーンの描画など）に必要不可欠で、業界が強く求めている機能です。

  • マルチドローインダイレクト (Multi-Draw Indirect): GPU上の計算結果に基づいて複数の描画コマンドを一度に発行できる機能 ( [6] )。現在はdrawIndirectで1つの描画しかできませんが、これが拡張されるとGPU駆動のレンダリング（例: GPUでカリングして可視オブジェクトだけまとめて描画）が容易になります。

  • 64ビットアトミック演算: シェーダー内で64-bit整数の原子操作を可能にする拡張 ( [6] )。特にバッファやテクスチャへの高精度な積算や、ソフトウェアラスタライザ（深度テストと値書き込みを組み合わせたような処理）を実装するのに必要で、これも高度なアルゴリズム実現につながります。

さらに互換モード (Compatibility mode)やWebXR連携といったトピックも議論されています ( [6] )。互換モードとはOpenGL ES 3.1しかサポートしない古いデバイス上でもWebGPUを動かすため、WebGPUコマンドを内部でOpenGLに翻訳する仕組みで、対応範囲の拡大を狙っています ( [6] )。WebXR連携は、VR/AR表示のためのレイヤーをWebGPUのスワップチェインとして扱えるようにし、VRコンテンツでもWebGPUが使えるようにする取り組みです ( [6] )。

以上のように、WebGPUは今後1～2年で正式勧告に至り、さらなる機能拡充が予定されています。これら新機能が実装されれば、より先進的なレンダリングや計算がブラウザで可能になり、WebGPUの価値が一層高まるでしょう。

WebGLの今後のサポート状況

WebGL自体は前述の通り大きな仕様拡張は予定されていません。WebGL 2.0（OpenGL ES 3.0相当）までが策定済みで、それ以上の機能追加はWebGPUに委ねる形です。Khronos Groupおよび各ブラウザベンダーは、WebGLを“保守モード”で維持していく方針を示しています ( [4] )。保守モードとは、重大な不具合修正やセキュリティ対応、必要に応じたごく小さな拡張（例えば新しい圧縮テクスチャ形式のサポートなど）は行うが、本質的なAPI変更や大規模機能追加はしないという意味です ( [4] )。実際、「WebGLは広く使われポータブルであり、今後も長い将来がある」という見解がワーキンググループのメンバーから表明されています ( [4] )。ブラウザからWebGLが排除されることはまずなく、Flashのように廃止される懸念も現在はありません ( [4] )。したがって、現在WebGLで開発された膨大な既存資産は今後も問題なく動き続けると見てよいでしょう。

ただし新しいGPU技術への対応という点では、WebGLでは限界があります。例えばレイトレーシングやコンピュートシェーダーはWebGLでは仕様上扱えません。このためKhronosも次世代としてWebGPUに注力しており、OpenGL自体もモバイルではVulkanへの移行が進んでいます。WebGLとWebGPUは「OpenGLとVulkanの関係」に近いとも言われ、今後は徐々にWebGPUがWebGLを代替していく流れです ( [18] )（もっとも完全に置き換わるには数年単位の時間がかかるでしょう）。2025年現在、WebGLは安定稼働するレガシー兼現役技術、WebGPUはエキサイティングな新技術という位置づけで、両者が並行して利用される状況が続く見込みです。

企業や開発者の動向・採用状況

企業レベルでもWebGPUへの期待から採用検討が進んでいます。GoogleはChromeでいち早くWebGPUを提供しただけでなく、先述のように機械学習ライブラリ（TensorFlow.js）やグラフィックスデモなどで積極的にWebGPUを活用し始めています ( [2] )。MicrosoftもEdge（Chromiumベース）で同時に対応し、自社のBabylon.jsエンジン開発を通じてWebGPUエコシステム形成に関与しています。Appleは当初は消極的とも言われましたが、WebGPUワーキンググループに参加しSafariへの実装も進めており、特に自社のMetal APIと相性が良いことから長期的には自社プラットフォーム上でも推進する姿勢を見せています ( [6] )。Mozilla（Firefox）はWebGPU実装「wgpu」をRustで主導開発し、将来的な標準化を後押ししています（Firefox本体への組み込みは遅れていますが、技術スタックは揃えている状況です）。

ゲーム業界では、Unity・Unrealの動きのほか、大型ゲームプラットフォーム（例えばPlayCanvasやFacebook Instant Gamesなど）がWebGPU対応を視野に入れています。特にUnityはWebGPU対応を表明したことで、WebGPUがゲーム開発者にも無視できない存在になりました ( [19] )。今後Unity製ゲームがWebGPUで動作すれば、グラフィック表現やパフォーマンスが飛躍する可能性があります。

開発者コミュニティでは、WebGPU関連のライブラリやツールが増加しています。例えばRustのwgpuやDawn（ChromiumのWebGPU実装）のようにネイティブ環境でWebGPU相当のAPIを使うプロジェクト、あるいはシェーダー開発を容易にするShadeDSLのような試みも出てきました ( [20] )。またブログやカンファレンスでのWebGPU話題も増え、「今からWebGPUを学ぼう」という動きが活発になっています ( [21] )。Hacker Newsなどでも「WebGPUを使うべきか」「学習リソースは？」といった議論が散見され、関心の高さがうかがえます ( [7] )。

総合すると、企業も開発者もWebGPUを次世代の基盤として注目・準備している段階です。ただし実運用ではまだWebGLが主役であり、「まずは両対応、将来WebGPUシフト」が現実的なラインとなっています。今後SafariやFirefoxでの正式サポートが出揃えば、一気にWebGPU採用が加速する可能性があります。

6. WebGPUの普及率

現在のブラウザ対応状況

2024年時点でのWebGPUブラウザ対応率はおよそ全体の73%と推定されています ( [5] )。これはChrome/Edge/OperaなどChromium系ブラウザがデスクトップ・Android問わずWebGPUをデフォルトサポートしたためで、これらのシェア合計が約7割強に達するためです ( [5] )。一方、FirefoxとSafariは依然として標準サポートに至っておらず、この2つ（特にiOSのSafari）は無視できないシェアを持っています ( [5] )。Safariについては技術プレビュー版で実装が進み、Safari 17以降で機能フラグ付きながら利用可能な状態です ( [5] )。しかしiPhoneやiPadのSafariではまだ一般ユーザは使えないため、モバイルWebGPUはAndroidが主という状況です ( [3] )。Firefoxも開発版では機能フラグで動作しますが、安定版有効化はもう少し先と見られます ( [5] )。このように主要ブラウザ4種のうち3種（Chrome系 + 開発中のSafari/Firefox）でWebGPU実装自体は出揃っており、残る課題はデフォルト有効化とプラットフォーム固有の最適化です。たとえばChromeでは当初Linuxサポートが遅れましたが現在は改善され、SafariもmacOSで動作確認が取れてきています ( [5] )。ブラウザ対応という観点では、「Chromium系は対応済み、Firefox・Safariはもうすぐ」という段階にあります。よって普及率73%という数字は「機能が存在するブラウザ」のシェアであり、実際にWebGPUコンテンツを誰でも利用できる環境という意味ではまだ5割未満とも言えます（SafariユーザやFirefoxユーザでは動作しないため）。しかしSafariとFirefoxが正式対応すれば、一気に95%以上の環境でWebGPUが利用可能になる見込みです。

企業や開発者の導入状況

企業によるWebGPU導入はまだ初期段階ですが、着実に増えています。前述のUnityのように商用ゲームエンジンが実験導入を始めたケースや、Googleのサービス（例えばGoogle Earthなど一部機能での採用検討）も取り沙汰されています。Microsoftは自社のOfficeスイートWeb版でのグラフィックス高速化などにWebGPUを応用する可能性が指摘されています（例えばExcelの大量セル描画やPowerPointのトランジション描画など）。Adobeもブラウザ版Creative Cloudで3DやGPUアクセラレーション機能を強化しており、将来的にWebGPU活用が考えられます。開発者コミュニティでは、個人プロジェクトやスタートアップがWebGPUを使ったゲームやデモを公開し始めています。2024年初頭には「WebGPUの注目デモ」紹介記事が出るなど ( [22] )、徐々に作品数が増えてきました。例えば高精細なフラクタルレンダリングデモや、物理シミュレーションをブラウザで実行する技術デモなどが登場しており、「WebGLでは実現困難だった表現が可能になっている」と話題になりました。TensorFlow.jsも公式にWebGPUバックエンドをリリース（実験段階）し、ブラウザでのAIモデル実行に革命をもたらそうとしています。これらから、先進的な開発者層は既にWebGPUに触れ始めていることが読み取れます。

市場シェアや成長率

WebGPU自体の市場シェア（実利用率）を正確に計測するデータはまだありませんが、関連指標からその傾向を推測できます。Chromeチームによれば、Chrome 113リリース以降にWebGPUを使用したページビューの割合が徐々に増えているとのことです。特に開発者向けプレビュー版だったChrome CanaryではWebGPU有効化直後から試験利用が活発で、GitHub上のWebGPUリポジトリも多くのスターを集めました。Can I useのデータでは、対応ブラウザベースでの理論普及率は2023年5月時点で約50%から、2024年初頭に70%を超えています ( [5] )。これはChromium系ブラウザのシェア拡大と、各ベンダーがWebGPUを有効化していったことによります。成長率という点では、WebGPUは他の新APIと比べても速いペースで普及が進むと見られます。なぜなら、WebXRやWebAssemblyと異なり既存WebGLコンテンツからの置き換え需要が見込まれるからです。開発者はWebGLの性能限界に直面したとき、従来はネイティブアプリに頼るしかありませんでしたが、今後はWebGPUに移行する選択肢があります。そのため、高性能を求めるWebサービスほどWebGPU採用に積極的になるでしょう。

もっとも現時点では、一般ユーザから見て「WebGPU対応コンテンツ」は限定的で、市場シェアという意味ではこれからです。例えば主要なWebGLゲームプラットフォーム（FacebookのInstant GamesやTencentのミニゲームなど）は依然WebGLで運用されています。しかしブラウザ対応が整い開発者の知見が蓄積されれば、数年内にWebGPU対応ゲームやアプリが当たり前にリリースされ、市場シェアが急伸する可能性があります。ある調査では、2025年末までに新規Web3Dコンテンツの半数近くがWebGPUを利用するとの予測もあります。実際Babylon.jsチームは「2023年はWebGPU元年」と位置づけており、以降は指数関数的な成長を見込んでいます。

総括すると、WebGPUの普及率は現時点では対応ブラウザシェアベースで約70%、実利用ベースではそれ以下ですが、Safari/Firefoxの追随とともに環境カバー率はほぼ100%に近づき、実際の利用も今後急激に拡大する見通しです ( [3] ) ( [5] )。Web開発者にとっても、ここ数年がWebGPU習熟とコンテンツ移行の重要なタイミングとなるでしょう。既存のWebGLも併存しつつ、将来的にはWebGPUがウェブグラフィックスの主流として定着すると期待されています。

参考資料

スポンサーリンク
共有
もふもふ

プロフィール

著者
もふもふ
プログラマ。汎用系→ゲームエンジニア→Webエンジニア→QAエンジニア