WebGPUとは何か——ブラウザでGPU計算を使う標準APIの仕組みから、WGSL・計算シェーダー・実活用まで

はじめに——ブラウザが「もう1つのGPU実行環境」になる

「GPUの計算パワーを使いたいのに、セットアップの壁で挫折した」——そんな経験はありませんか。ネイティブならSDKやドライバーの準備が重くのしかかります。ならばとWebGLでGPGPU（汎用GPU計算）に挑戦したものの、描画用に設計されたAPIに計算を押し込む複雑さに挫折した開発者も多いのではないでしょうか。MDN Web Docsも、WebGLが描画中心の設計でGPGPUをうまく扱えないことを根本課題の1つに挙げています。

この壁を崩す標準APIが「WebGPU」です。WebGPUはW3Cが策定する、ブラウザでネイティブに近いGPU機能（グラフィックス＋汎用計算）を利用するためのAPIで、Vulkan・Metal・Direct3D 12といったモダンなGPU APIへ効率よくマッピングされるようゼロから設計されました。計算シェーダーによるGPGPUが第一級の機能となり、2026年秋時点ではChrome/EdgeをはじめFirefoxやSafariでも利用可能になりつつあります（対応の詳細は後述します）。

本記事では、WebGPUの仕組み（アダプター/デバイス/パイプラインの階層）、WebGLとの違い、シェーダー言語WGSLと計算シェーダーの書き方の入口、実ユースケースと対応状況、学習ロードマップを順に解説します。記述は、W3CのWebGPU/WGSL仕様、MDN Web Docs、公式のImplementation Status Wikiといった一次情報源に基づいています。インストール不要でGPU計算を始められる「もう1つのGPU実行環境」を、一緒にのぞいてみましょう。

WebGPUとは何か？——WebGLが残した3つの課題

WebGPUを理解する近道は、前身のWebGLが残した課題を整理することです。MDNの説明を要約すると、その背景には次の3点の課題があります（言い回しは筆者による要約です）。

WebGLが革命だった理由

WebGLは2011年ごろに登場した、OpenGL ES 2.0をJavaScriptに移植したAPIです。ブラウザからプラグインなしでGPUの描画能力を引き出す道を開き、Three.jsやBabylon.jsといったライブラリのエコシステムが育ちました。この2つは現在、次世代のWebGPUにも対応しています。

WebGLの3つの根本的課題

MDNが挙げるWebGLの限界を要約すると、次の3点です。

1. 土台のOpenGLに更新の見込みがないこと。 WebGLの登場後、ネイティブの世界ではDirect3D 12・Metal・Vulkanという新世代GPU APIが登場しましたが、OpenGLへの更新はすでに計画されておらず、WebGLが新世代の機能を得る道はありません。
2. GPGPUが不得手なこと。 WebGLはキャンバスへの描画を中心に設計されたため、汎用GPU計算（GPGPU）をうまく扱えません。機械学習モデルのようなGPGPU需要が高まり続けるいま、これは大きな制約です。
3. 描画要求の増大に追いつけないこと。 3Dグラフィックスアプリケーションの要求（同時描画オブジェクト数や新しいレンダリング機能）は増大し続けています。MDNはWebGPUの利点として「CPU側の描画コストが大幅に安い」を挙げており、WebGLではこの負担が大きかったことがうかがえます（この対応関係は筆者の解釈を含みます）。加えて、グローバル状態オブジェクト中心の設計も、呼び出し順序への注意を強いる負荷の一因と指摘されます。

WebGPUの答え

WebGPUは、これらの課題に答えるため、最近のネイティブGPU APIへ効率よくマッピングされるようゼロから設計されました。仕様冒頭では「WebGLとは関連がなく、OpenGL ESを明示的にターゲットにしない」と明言されています。そのアーキテクチャは最近のGPU APIと互換性を保ちつつWebらしく振る舞う（“webby”な）汎用設計で、レンダリングに加えてGPGPUを第一級でサポートし、CPU側の描画コストも大幅に安くなります。計算ベースのパーティクルやポストプロセス、カリング・スキニングをGPUで直接処理できます。WebGPU本体とシェーダー言語WGSLは、2つのW3C標準として整備されています。

WebGPUの仕組み——4層の抽象化とコマンドの流れ

Webアプリから物理GPUまでの抽象化レイヤー

Webアプリが直接扱うのはGPUDevice（論理デバイス）で、GPUAdapterから取得します。GPUAdapterは物理GPUとドライバーをコード上で表現したもので、その下ではブラウザのWebGPU実装がネイティブGPU API（Metal／Vulkan／D3D 12）と通信し、ドライバーを経由して物理GPUへ届きます（MDN）。

graph TD
    A[Webアプリ] --> B[GPUDevice（論理デバイス）]
    B --> C[GPUAdapter]
    C --> D[ブラウザのWebGPU実装]
    D --> E[ネイティブGPU API（Metal / Vulkan / D3D12）]
    E --> F[ドライバー]
    F --> G[物理GPU]

なぜ物理GPUを直接扱わせず、論理デバイスを挟むのでしょうか。物理GPUは多数のアプリやプロセス（多くのWebアプリを含む）で同時利用されるため、各Webアプリはセキュリティとロジック上の理由から隔離された形でアクセスする必要があります。この多重化（マルチプレキシング）の提供こそ、論理デバイスの役割です（MDN）。

デバイス取得の3ステップ

デバイスの取得はnavigator.gpuから始まる3ステップです。MDN掲載の機能検出つき基本形がこちらです。

async function init() {
  if (!navigator.gpu) throw Error("WebGPU not supported.");
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) throw Error("Couldn't request WebGPU adapter.");
  const device = await adapter.requestDevice();
}

requestAdapter()ではhigh-performance（高性能優先）／low-energy（省電力優先）の方針を指定でき、requestDevice()ではfeaturesとlimitsを要求できます。未指定なら、汎用的なデフォルト設定のデバイスが返されます。

パイプラインは2種類

パイプラインは、プログラム可能なステージを含む論理構造です。レンダーパイプラインはグラフィックス描画用で、頂点とフラグメントのステージを含み、結果をcanvasへ出力します。コンピュートパイプラインはGPGPU用で、単一の計算ステージを持ち、計算シェーダーがワークグループ（スレッドの小集団）単位で並列実行されます。

コマンドの流れ

WebGPUでは、GPUへの命令を記録してまとめて送ります。CommandEncoderを作成し、PassEncoder（レンダーパスまたはコンピュートパス）でパイプライン設定やバッファ操作、計算の発行（dispatchWorkgroups）を記録します。命令列はCommandBufferにまとめられ、queue.submit()でキュー経由でGPUへ送られ、実行されます。

graph LR
    A[CommandEncoder] --> B[PassEncoder（レンダー／コンピュートパス）]
    B --> C[CommandBuffer]
    C --> D[Queue.submit]
    D --> E[GPU実行]

計算結果は、実行後にmapAsyncで非同期にマッピングして読み戻します。記録して一括送信し、結果は非同期で受け取る——これがWebGPUコーディングの基本リズムです。

WebGLとの比較——何が変わり、何を気をつけるか

WebGLとWebGPUの比較表

（出典: MDN、ics.media、webgpu.org）

実測データから見る差

ics.mediaの実測記事によると、同一の3Dシーンでモデル数を増やす検証（MacBook Air M1 2020・Chrome 113）では、ドローコール1万回でWebGLは約30FPSに低下し、WebGPUは約50FPSを維持したといいます。

差の主因はCPU負荷です。WebGLはドローコールのたびにステート検証が走るのに対し、WebGPUはパイプライン作成時に検証を済ませるため、ドローコール時の負荷が小さく、切替も1回のAPI呼び出しで完結します。なお、このデモは負荷比較のためインスタンシングをあえて未使用です（出典: ics.media）。

気をつける点

高速になった一方で、設計上の注意点もあります。

第一に、GPUバッファーはホスト（JavaScript）から直接アクセスできません。書き込みはwriteBuffer()、読み戻しはマッピング（mapAsync）です。直接マップできないストレージバッファーは、コピー可能なバッファー経由で読み出します。（出典: webgpufundamentals）

第二に、パイプラインの生成コストです。ステート検証を作成時に行う裏返しで、生成にはある程度のコストが伴います。都度作り直さず、生成済みパイプラインを使い回す構成が基本です。

第三に、データサイズです。ics.mediaのバイトニックソート検証では、要素数が少ないうちは転送と命令のオーバーヘッドのためCPUが有利で、増えると逆転すると報告されています。GPUに渡せば必ず速いわけではなく、転送コストを勘案した使い分けが大切です（出典: ics.media）。

互換モードという移行の橋

古いGPU環境が心配な場合は、互換（コンパティビリティ）モードが橋渡しになります。requestAdapter()のオプションに featureLevel: "compatibility" を指定すると、OpenGL ES 3.1やDirect3D 11級の古いAPI上でも制限付きサブセットとして動作させられます。制限付きアプリはコアWebGPUのサブセットとして設計されているため幅広い環境での動作が意図されていますが、実装状況は流動的なため対象環境での動作確認が必要です（出典: MDN）。

計算シェーダー入門——WGSLで並列計算を書く

WebGPUがWebGLと決定的に違うのが、画像描画とは独立した「計算シェーダー」を第一級機能として持つ点です。このセクションでは、専用言語WGSLの概要、最小のコード例、そしてGPUとCPUの間のデータの流れを順に見ていきます。

WGSLとは

WGSL（WebGPU Shading Language）は、WebGPU専用に策定されたシェーディング言語です。WebGLで使ってきたGLSL ESとは別物で、Rustを思い起こさせる低レベルな文法を持ち、仕様はシェーダー言語としてW3Cの独立文書（https://www.w3.org/TR/WGSL/）で管理されています。ブラウザ実装内部でのシェーダーコンパイル経路が考慮された設計とされます。GPUに渡すコードのMIMEタイプはtext/wgslと定められています。文法をブラウザ上で逐次試しながら学べる「Tour of WGSL」（https://google.github.io/tour-of-wgsl/）が入門の定番です。

最小の計算シェーダー

計算シェーダーは、@compute属性と@workgroup_size属性を付与した関数として書きます。配列の各要素を2倍する最小例は次のとおりです（webgpufundamentals.org掲載のコード）。

@group(0) @binding(0) var<storage, read_write> data: array<f32>;

@compute @workgroup_size(1)
fn computeSomething(
  @builtin(global_invocation_id) id: vec3<u32>
) {
  let i = id.x;
  data[i] = data[i] * 2.0;
}

※この例はdispatch回数と配列長が一致する前提の最小例です。実用では配列長をuniform等で渡し、範囲外アクセスを避ける境界チェックを入れるのが定石です。

並列実行の様子は「巨大な格子」でイメージすると分かりやすいです。GPUは3次元の格子状にスレッドを敷き、@workgroup_size(x, y, z)で指定したサイズの小ブロック＝ワークグループごとに実行します。たとえば@workgroup_size(3, 4, 2)なら1ワークグループは3×4×2で24スレッド。JavaScript側でdispatchWorkgroups(4, 3, 2)を呼ぶと、この24スレッドのブロックが4×3×2＝24個ディスパッチされ、合計576スレッドが一斉に動きます。個々のスレッド（invocation）はglobal_invocation_idという一意のIDから、自分が担当する升目を知る仕組みです。

GPUとCPUの間のデータフロー

JavaScriptからGPUで計算させる典型的な流れは、次の4段階です。

1. device.createBuffer()でGPUBufferを作る。usageフラグ（GPUBufferUsage.STORAGE | COPY_SRCなど）で用途を宣言
2. device.queue.writeBuffer()で入力データを書き込む
3. コマンドエンコーダーでコンピュートパスを組み、dispatchWorkgroups()で実行を指示し、queue.submit()でGPUへ送出
4. 結果の読み戻しはmapAsync()。ただしストレージバッファは直接mapできないため、MAP_READ可能なステージングバッファへcopyBufferToBuffer()でコピーしてからmapAsync(GPUMapMode.READ)で受け取る

計算そのものより、最初に戸惑うのはこの「データの往来の設計」であることが多いです。

GPGPUが効く場面

計算シェーダーが力を発揮するのは、ソート・画像処理・数値計算など、同じ操作を大量のデータへ一括適用する処理です（パーティクルのような3Dオブジェクトの座標・状態計算にも使われます）。検証記事（ics.media）の実測によると、バイトニックソートをCPU（JS標準のsort()）と比較した場合、要素数が少ないうちはGPUへの転送と命令オーバーヘッドの分だけCPUが有利ですが、要素数4,096前後を境に優劣が逆転します。以降は差が拡大し、同検証ではCPUの処理時間が急激に増えるのに対し、WebGPUは30ミリ秒以下の緩やかな増加で収束しました（Chrome 113 / MacBook Air M1 2020での検証であり、環境により結果は変わります。なおバイトニックソートは要素数が2の累乗でないと適用できないため、実測ではダミーデータの追加で調整しています）。「GPUなら常に速い」ではなく、データサイズと転送コストの兼ね合いを見極めるのが実務のポイントです。

ハローワールドの次の一歩

• WebGPU Samples（https://webgpu.github.io/webgpu-samples/）——実際に動く公式サンプル集。まずcompute basicを動かしてみましょう
• compute.toys（https://compute.toys/）——ブラウザだけで計算シェーダーを書いて共有できる遊び場
• Chrome Developersの行列乗算チュートリアル——GPGPUらしい実践課題として定番

実ユースケース——画像処理からブラウザ内ML推論まで

WebGPUの実用化はどこまで進んでいるのでしょうか。

グラフィックス/3Dエンジンの対応

公式ポータルwebgpu.orgでは、Three.js、Babylon.js、Unity、PlayCanvasといった主要エンジンの対応が列挙されています。Three.jsはWebGPURendererが実験的機能として利用可能、Babylon.jsは一部機能を除き対応済みです（ics.media）。

機械学習: ブラウザ内推論

計算シェーダーの本領を発揮するのがML推論です。

• TensorFlow.js: WebGPUバックエンドで高速化
• ONNX Runtime Web: WebGPU実行プロバイダ（EP）によるGPU加速
• Transformers.js v3（Hugging Face、2024年リリース）: device: 'webgpu'指定だけで有効化。WASM比「最大100倍高速」はHugging Faceの発表値であり、対象モデル・環境・処理による特定条件での値です
• WebLLM（MLC AI）: ブラウザ内で直接LLM推論を実行

推論データを端末内で処理する構成を取れば、データを外部サーバーへ送らないプライバシー面と、通信往復がないレイテンシ面で有利です（モデル取得時の通信やアプリの実装内容には依存します）。

ネイティブ/サーバーでもWebGPU

Web向け標準は、ネイティブ世界へも逆輸入されています。Rust実装のwgpuはFirefox、Servo、Denoで採用され、C++実装のDawnはChromiumのWebGPU実装として使われます。共通ヘッダーwebgpu.hで、同じAPIのままネイティブやサーバー側のGPU処理が書けます。「Webの標準がそのままネイティブAPIになる」逆転現象です。

ユースケースの向き不向き

「とりあえずGPU」ではなく、データ量と並列性で判断するのが実践的です。

対応状況と移行戦略——2026年秋時点の実務ガイド

ブラウザ対応表（2026年9月時点）

以下はImplementation Status Wiki等の公開情報を2026年9月時点で整理したものです（OS・バージョン・安定版/開発版により扱いが異なるため、最新状況は各公式情報およびcaniuseで確認してください）。

ただしcaniuseではSafari 26を「部分対応」、Firefox安定版を「無効」と表記するなど表記ズレがあります。実運用では機能検出が必須です。

実務の移行戦略（ステップバイステップ）

1. 機能検出 — navigator.gpu の有無と、requestAdapter() の失敗（null返却）をチェックします（MDNのイディオム）。
2. WebGLフォールバック — 非対応環境では既存のWebGLパスへ切り替えます。
3. 互換モードの検討 — featureLevel: "compatibility" を指定するとOpenGL ES 3.1 / Direct3D 11級でも制限サブセットが動きます。幅広い環境での動作が意図された設計ですが、実装状況は要確認です。
4. ターゲット環境の確認 — WebGPU Report で対象環境のfeatures / limitsを確認します。

エラーハンドリングとデバッグ

パイプラインは生成時点で検証される設計で、ミスは早期に捕捉できます。実行時エラーはエラースコープ（pushErrorScope / popErrorScope）で区間を囲んで切り分けます。GPUは他のアプリと共有されるためデバイスは失われる（device lost）可能性があり、ロスト時はアダプター再取得とリソース再構築が必要です。初期化を再実行できる設計が安心です。デバッグにはChromeのDevTools向けWebGPU Dev Extensionが役立ちます。ストレージバッファは直接mapできないため、読み戻しはステージングバッファ経由とmapAsyncの完了待ち（複数なら全完了待ち）の確認がコツです。

よくある質問（FAQ）

Q: WebGPUはWebGLを完全に置き換えるの？

いいえ、すぐにではありません。WebGLは巨大な資産（ライブラリ、 educationalコンテンツ、業務システム）の上に成り立っており、広く使われ続けています。WebGPUはあくまで「次世代の標準」として設計されたAPIで、MDNも「OpenGL/WebGLに今後機能追加はなく、WebGPUは今後も新機能が追加されていく」と説明しています。両者は長い並行運用期間を経て移行が進むと考えるのが現実的です。

Q: SafariやFirefoxでもWebGPUは使えるの？

使える環境が広がっています。Safariは2025年9月リリースのSafari 26.0から、Firefoxは2025年7月リリースのFirefox 141（Windows）から利用可能です。ただしプラットフォームによる差（Linux未対応、FirefoxはWindowsのみ等）が残るため、実運用では navigator.gpu の機能検出とWebGLへのフォールバックが必須です。

Q: 計算シェーダーを使うのにCUDAの知識は必要？

不要です。WebGPUのシェーダー言語WGSLは、CUDAとは独立の、Rust風の文法を持つW3C標準言語です。GPU並列計算の概念（ワークグループ、スレッドID）さえ掴めば、Web開発者の延長線で学習できます。Tour of WGSLなどのインタラクティブな学習リソースも充実しています。

Q: ブラウザのWebGPUで本格的な機械学習推論は可能？

可能性が急速に広がっています。Transformers.js v3はHugging Faceの発表で「WASM比最大100倍」の高速化を謳い、WebLLMはブラウザ内でLLM推論を直接実行できます。ただしモデルサイズとブラウザのメモリ制約があるため、現実には埋め込みモデルや小型LLMのような、メモリに収まる規模の推論に向いています。

Q: どうやって学び始めればいい？

公式のWebGPU Samplesで動くコードを見る → compute.toysでWGSLをブラウザ内でいじる → WebGPU Fundamentalsで体系学習、という順序がおすすめです。日本語ならics.mediaの入門記事が網羅的です。

まとめ——今日から始める3つのアクション

本記事の要点を3行でまとめます。

• WebGPUはW3C標準のGPU APIで、Vulkan/Metal/D3D12を基盤に、計算シェーダーによるGPGPUを第一級サポートする
• WGSLで書く計算シェーダーにより、データ転送オーバーヘッドが許容できる規模の処理なら、ブラウザ内でCPUを大きく上回る並列計算ができる
• 2026年秋時点でChrome/Edge/Firefox/Safariの主要ブラウザが対応を揃え、ブラウザ内ML推論（Transformers.js、WebLLM）も実用化しつつある

今日から始める3つのアクション:

1. 自分の環境を確認する: WebGPU Report にアクセスして、自分のブラウザ・GPUのWebGPU対応と機能制限（limits）を確認しましょう
2. 計算シェーダーを動かす: WebGPU Samples のcompute basicをローカルでcloneして動かし、データフロー（buffer作成 → dispatch → 結果の読み戻し）を追いかけましょう
3. 小さなユースケースで1本書く: 画像フィルターのような小さな題材で、WGSLの計算シェーダーを1本書いてみましょう。学んだ概念がすべて繋がります

学習ロードマップ

• MDN WebGPU API — https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
• WebGPU Fundamentals — https://webgpufundamentals.org/
• ics.media WebGPU入門（日本語） — https://ics.media/entry/230426/
• Tour of WGSL — https://google.github.io/tour-of-wgsl/
• Transformers.js v3 — https://huggingface.co/blog/transformersjs-v3
• WebLLM — https://github.com/mlc-ai/web-llm

参考文献

本記事の記述は、以下の一次情報源・検証記事に基づいています（2026年9月30日時点で確認）。

• MDN WebGPU API — https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
• W3C WebGPU仕様 — https://www.w3.org/TR/webgpu/
• W3C WGSL仕様 — https://www.w3.org/TR/WGSL/
• webgpu.org（公式ポータル） — https://webgpu.org/
• WebGPU Implementation Status Wiki — https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
• ics.media「WebGPUがついに利用可能に」（実測・対応表の出典） — https://ics.media/entry/230426/
• webgpufundamentals.org — https://webgpufundamentals.org/
• Hugging Face「Transformers.js v3」 — https://huggingface.co/blog/transformersjs-v3
• WebLLM — https://github.com/mlc-ai/web-llm
• ONNX Runtime WebGPU Execution Provider — https://onnxruntime.ai/docs/execution-providers/WebGPU-ExecutionProvider.html
• WebGPU Explainer — https://gpuweb.github.io/gpuweb/explainer/
• caniuse WebGPU — https://caniuse.com/webgpu

関連記事

• WebGPUでブラウザ内AI推論はどこまでできる？——インストール不要のオンデバイスAIが開く新しいかたち

GPU計算への入門壁を大きく下げるWebGPU。ネイティブSDKのインストール不要で、ブラウザという誰もが持つ実行環境から並列計算の世界に入れるのは、間違いなくこの標準の大きな価値です。