WebGPU はなぜ速いのか ― WebGL との違い、GPUDevice、Pipeline、WGSLを読む

WebGPU APIは、Webページから端末のGPUを使って高性能な計算や複雑な描画を行うためのAPIです。MDNは、WebGPUを「基盤となるシステムGPUを使い、高性能計算や複雑な画像描画をブラウザで実行するためのAPI」と説明しています。

ここで重要なのは、WebGPUが単なる描画専用APIではないことです。WebGLは主にグラフィックスAPIとして広まりましたが、WebGPUは最初から render と compute の両方を視野に入れています。

もちろん、WebGPUを使えば何でも速くなるわけではありません。CPUからGPUへデータを送るコスト、Pipeline作成、同期、メモリ使用量、ブラウザの安全性検証などがあります。小さな処理なら、Canvas 2DやWebGL、WASM、普通のJavaScriptのほうが単純で速いこともあります。

WebGLは、OpenGL ESをWeb向けにしたAPIとして広まりました。ブラウザで3Dゲームや可視化を可能にした大きな技術です。一方で、WebGLは古いグラフィックスAPIの設計を引き継いでおり、状態を積み上げながら描画命令を出すスタイルになっています。

WebGPUは、Vulkan、Metal、Direct3D 12のような現代的なGPU APIの考え方に近い設計です。つまり「その場で状態を変えながら描く」のではなく、描画や計算に必要な構成を先にまとめ、Command Encoderで命令を記録し、Queueへ送る流れになります。

WebGLの感覚:
  bindBuffer()
  useProgram()
  enableVertexAttribArray()
  drawArrays()

WebGPUの感覚:
  adapter -> device
  shaderModule -> pipeline
  commandEncoder -> renderPass / computePass
  queue.submit()

この違いは、書き味だけの問題ではありません。WebGPUでは、何をどの形式でGPUに渡すのか、どのShaderを使うのか、どのTextureやBufferを読むのかを、より明示的に構成します。そのぶん初期化コードは長くなりますが、ブラウザやGPUドライバが事前に検証・最適化しやすくなります。

そのため、WebGPUは「WebGLを簡単にしたAPI」ではありません。むしろ低レベル寄りです。Three.jsやBabylon.jsのようなライブラリ、あるいはゲームエンジンや可視化フレームワークがWebGPUをバックエンドとして使う場面が増えると、一般開発者はWebGPUを直接意識せず恩恵を受けることもあります。

WebGPUの入口は navigator.gpu です。対応環境では、ここから GPUAdapter を取得し、さらに GPUDevice を要求します。MDNの基本例でも、navigator.gpu の存在確認、requestAdapter()、requestDevice() の順に進みます。

if (!navigator.gpu) {
  // WebGPU unavailable: fallback to WebGL / Canvas / server rendering
}

const adapter = await navigator.gpu.requestAdapter();
if (!adapter) {
  // No suitable GPU adapter
}

const device = await adapter.requestDevice();

GPUAdapter は、ブラウザが見つけた物理GPUやドライバに近い存在です。統合GPU、ディスクリートGPU、低消費電力GPUなど、環境によって候補は変わります。GPUDevice は、Webアプリが実際に命令やリソースを作るための論理的な入口です。

この分離には意味があります。WebページがGPUを直接裸で握るのではなく、ブラウザが権限、機能、制限、互換性を管理したうえで、安全な論理デバイスを渡します。WebGPUは速さだけでなく、Webの安全モデルに載せるための設計でもあります。

WebGPUで最初につまずきやすい概念が Pipeline です。Pipelineは、GPUがどうデータを処理するかをまとめたレシピです。大きく Render Pipeline と Compute Pipeline があります。

Render Pipelineでは、どの頂点ShaderとフラグメントShaderを使うか、頂点データの形式、色の出力先、Depth設定などを決めます。Compute Pipelineでは、どのCompute Shaderを使うかを決めます。

WebGLでは描画直前に状態変更が積み重なりやすく、意図しない状態漏れに悩むことがありました。WebGPUではPipelineとして構成をまとめるため、見通しは良くなります。ただし、Pipeline作成そのものは重い処理になり得るので、毎フレーム作るのではなく、初期化時や必要なタイミングでキャッシュする設計が基本です。

WebGPUでGPU上に走らせるプログラムは、主に WGSL、WebGPU Shading Languageで書きます。W3CのWGSL仕様は、2026年7月3日時点でCandidate Recommendation Draftとして公開されており、WebGPUのためのShading Languageと説明されています。

WGSLでは、Shaderの入口を属性で示します。代表的な入口は @vertex、@fragment、@compute です。

@vertex
fn vs(@builtin(vertex_index) i: u32) -> @builtin(position) vec4f {
  // vertex shader
}

@fragment
fn fs() -> @location(0) vec4f {
  return vec4f(0.2, 0.7, 1.0, 1.0);
}

@compute @workgroup_size(64)
fn cs(@builtin(global_invocation_id) id: vec3u) {
  // compute shader
}

WGSLは、GLSLよりもWeb向けの検証を強く意識した言語です。型、アドレス空間、Binding、Entry Pointを明示し、ブラウザが静的に検証しやすい構造になっています。これは少し窮屈に見えますが、WebページがユーザーのGPUドライバへ任意の危険な命令を投げ込まないために重要です。

また、WGSLを書いたからといって、ブラウザがそのままGPUへ文字列を渡すわけではありません。ブラウザ実装は、環境に応じてMetal、D3D12、Vulkanなどの下層APIへ変換・検証して実行します。開発者が見るのはWebGPUとWGSLの抽象化された世界です。

WebGPUでは、描画命令や計算命令を直接すぐ実行するのではなく、GPUCommandEncoder に記録し、完成したCommand Bufferを GPUQueue に送ります。

const encoder = device.createCommandEncoder();

const pass = encoder.beginRenderPass(renderPassDescriptor);
pass.setPipeline(renderPipeline);
pass.draw(3);
pass.end();

device.queue.submit([encoder.finish()]);

この形は、最初は遠回りに見えます。しかしGPUはCPUとは別の実行装置です。CPU側が命令を組み立て、GPU側へまとめて送ることで、ブラウザやドライバは処理順序やリソース状態を管理しやすくなります。

つまりWebGPUでは、CPUで1命令ずつ結果を待つのではなく、GPUに渡す仕事をまとめる意識が重要です。これがWebGPUらしい設計であり、単純なAPI呼び出しの置き換えではない理由です。

WebGPUがWebGLと大きく違う点の一つが、Compute Shaderを第一級の機能として扱うことです。Compute Shaderは、画面に直接描くためのShaderではなく、GPU上で並列計算を行うためのShaderです。

画像処理で考えると分かりやすいです。1000万ピクセルの画像に同じフィルタをかける場合、各ピクセルの処理はかなり独立しています。CPUでも並列化できますが、GPUは同じような計算を大量に並べるのが得意です。

• 画像のぼかし、シャープ化、色変換
• 粒子シミュレーションや物理演算
• 大量の頂点・インスタンスデータの前処理
• ニューラルネットワークの行列演算やテンソル処理

ただし、Compute Shaderを使えば自動的に高速になるわけではありません。GPUへデータを転送するコスト、Workgroupの粒度、メモリ配置、Pipelineの再利用、結果をCPUへ戻す必要があるかどうかで性能は変わります。

ブラウザ内AI推論でも、WebGPUは注目されています。とはいえ、すべてのモデルがWebGPUで快適に動くわけではありません。モデルサイズ、量子化形式、メモリ上限、ブラウザ実装、端末GPUの性能に大きく左右されます。

GPUは本来、Webページのためだけに作られた装置ではありません。OS、ブラウザ、他のアプリ、別のタブが同じGPUを共有することがあります。そのため、WebGPUは「低レベルで速いAPI」でありながら、Webの安全モデルに入る必要があります。

WebGPUでは、BufferやTextureの使い方、Shaderの型、Binding、Pipeline設定などが細かく検証されます。MDNにも、WebGPUのエラーにはValidation Errorがあり、操作がAPIの検証制約を通らなかったことを示すと説明されています。

これは開発者にとっては面倒に見えることがあります。WebGPUのエラーは、最初は「なぜ描画されないのか」が分かりにくいです。しかし、この検証は、Webページが不正なGPUメモリアクセスや未定義動作に依存しないための重要な仕組みです。

また、WebGPUはHTTPSなどのsecure contextで提供されます。ローカル開発では動いても、本番の配信条件やブラウザ設定によって使えないことがあります。WebGPUを使う機能では、対応判定と代替表示を必ず設計に入れるべきです。

2026年7月時点で、WebGPUは期待値が高い一方、記事や製品紹介で「もうWebGLは不要」と言い切るのは危険です。MDNはWebGPU APIをLimited availabilityと表示しており、広く使われるブラウザの一部では動かない可能性があると説明しています。

実務では、次のような分岐が必要です。

if (navigator.gpu) {
  // WebGPU path
} else if (canvas.getContext("webgl2")) {
  // WebGL2 fallback
} else {
  // Canvas 2D / static image / server-side fallback
}

特に、教育コンテンツ、行政・医療・業務システム、ECサイトの重要導線などでは、WebGPUだけに依存する設計は避けるべきです。WebGPUは体験を良くする強力な選択肢ですが、基本機能を完全に握らせるには、まだ対応環境の確認が必要です。

一方、Studio系ツール、3Dビューア、ゲーム、画像編集、生成AIの補助処理など、対応ブラウザを案内できる用途では、WebGPUを積極的に使う価値があります。ユーザーの環境が合えば、Webだけでかなりリッチな処理ができます。

WebGPUは強力ですが、採用判断は冷静に行うべきです。

WebGPUは、Canvas 2DやCSSアニメーションの代わりに何でも使うものではありません。GPUを使うだけでなく、GPUに向いた形へデータと処理を設計できるときに強くなります。

WebGPUの本質は、「ブラウザからGPUを使えるようになった」という一文よりも、GPU利用を明示的な設計に変えるところにあります。

• WebGLはWebの3Dを広げたが、古いOpenGL ES由来の状態管理を引き継いでいる
• WebGPUはGPUAdapter、GPUDevice、Pipeline、CommandEncoder、Queueで処理を明示する
• WGSLはWebGPU向けのShader言語で、vertex / fragment / compute の入口を持つ
• RenderだけでなくComputeを扱えるため、画像処理やAI推論にも使われる
• Limited availabilityなので、実務では対応判定とフォールバックが必須

WebGPUは、WebGLを今すぐ消す技術ではありません。むしろ、WebGLが切り開いた「ブラウザでGPUを使う」世界を、現代的なGPU設計へ進めるための次の土台です。Webで重い描画や計算を扱うなら、今後ますます避けて通れない技術になります。