WebGPU & WGSL エコシステム 2026 — Chrome / Safari / Firefox 全 GA / wgpu / naga / Tint / Three.js / Babylon / WebLLM / Transformers.js 徹底解説

1. 2026 年の WebGPU マップ — 3 大ブラウザすべて GA

10 年もの間、ブラウザのグラフィックスは WebGL 1.0 (2011) と WebGL 2.0 (2017) で持ちこたえてきた。2026 年、ついに 次世代の標準 が手の中にある。Chrome 113 (2023 年 5 月)、Safari 18 (2024 年 9 月)、Firefox 141 (2025 年 8 月) — すべての evergreen ブラウザが WebGPU を安定版でサポートする。

WebGPU は単なる「より速い WebGL」ではない。

• モダン GPU API の抽象化 — Vulkan / Metal / DirectX 12 を覆う薄いレイヤ
• コンピュートシェーダがファーストクラス — GPGPU (汎用 GPU 計算) がブラウザで可能
• WGSL — GLSL に代わる新しいシェーディング言語 (Rust 風文法、Apple / Google / Mozilla 共同設計)
• 明示的パイプライン — drawcall オーバーヘッドの減少、マルチスレッドに親和的
• バインドグループとバッファ管理 — 現代のグラフィックス API のベストプラクティスをそのまま

2026 年 5 月時点で、「WebGPU を使うべきか?」への答えはシンプルだ。新規プロジェクトなら WebGPU から始め、WebGL をフォールバックに置く。 本稿は、仕様 → ブラウザ → WGSL → コンパイラ → ライブラリ → ML 応用まで、一層ずつ整理する。

この記事のコードはポリフィルを一行も使っていない。すべて 2026 年 5 月時点の evergreen ブラウザ安定機能を前提にしている。

2. WebGPU 仕様 — Working Draft から Candidate Recommendation へ

仕様の位置

WebGPU は W3C の GPU for the Web Working Group が主導する。Apple (WebKit)、Google (Chrome / Dawn)、Mozilla (Firefox / wgpu)、Microsoft、Intel が共同編集者である。

• Working Draft — 2021 〜 2025、活発な変更
• Candidate Recommendation — 2026 年突入、仕様安定化のサイン
• Recommendation — 今後 1 〜 2 年で

CR に到達したということは、WPT (Web Platform Tests) の網羅率が十分で、実装間の interoperability が証明された ことを意味する。「あるブラウザでだけ動く」時代は終わった。

仕様の 2 つの軸

1. WebGPU API — JavaScript から GPU を扱うインターフェース (デバイス / キュー / パイプライン / バインディング)
2. WGSL — シェーディング言語の仕様 (vertex / fragment / compute シェーダ)

両者は別文書として管理されるが、共に進化する。CR 段階の安定機能セットは以下のとおり。

• Render pipeline / compute pipeline
• Bind group / bind group layout
• Buffer / texture / sampler
• Storage buffer / storage texture
• Indirect draw / indirect dispatch
• Timestamp query / occlusion query
• WGSL 1.0 コア (struct / function / control flow / atomic ops)

CR 以降に控える提案

• Subgroups — SIMD グループ (ワープ) 通信、コンピュート性能の加速装置
• Storage texture 拡張 — read-write storage texture
• Mesh shaders — 頂点処理パイプラインの再設計 (Nanite 系)
• Ray-tracing — ハードウェア RT の露出 (Vulkan RT / DXR / Metal RT の抽象化)
• bfloat16 — ML 推論用 16 bit 浮動小数

CR は終わりではなく、始まりだ。これらの拡張が 2026 〜 2027 年に順次入る。

3. ブラウザサポート — Chrome 113 / Safari 18 / Firefox 141

Chrome — 2023 年 5 月 GA

Chrome 113 が初の GA。macOS / Windows / ChromeOS / Android で利用可能。Linux は一時期フラグの裏にあったが、2024 年に段階的に解放された。Chrome のバックエンドは Google 自製の Dawn (C++)。

• レンダーバックエンド
  • Windows → Direct3D 12 (D3D11 fallback)
  • macOS / iOS → Metal
  • Linux / Android → Vulkan
• コンパイラ → Tint (WGSL → SPIR-V / MSL / HLSL)

Safari — 2024 年 9 月 GA

Safari 18、iOS 18 で GA。WebKit のバックエンドは自製実装。macOS / iOS / iPadOS / visionOS すべて Metal ベース。visionOS の空間コンピューティング描画も WebGPU で扱える。

• iOS Safari の WebGPU は、モバイル GPU を活かすゲームと ML 推論にとって大きな意味がある
• WebKit は仕様策定に深く関与し、「JS エンジン上の WebGPU セキュリティ」を強調

Firefox — 2025 年 8 月 GA

Firefox 141 が最終 GA。バックエンドは wgpu (Mozilla / gfx-rs, Rust)。コンパイラは naga (WGSL / SPIR-V / GLSL / MSL / HLSL の相互変換、こちらも Rust)。

• Linux デスクトップでの wgpu + Vulkan の組み合わせはきわめて安定
• Firefox はデスクトップ優先、モバイルは段階的

機能検出

if (!navigator.gpu) {
  throw new Error('WebGPU not supported by this browser')
}

const adapter = await navigator.gpu.requestAdapter()
if (!adapter) {
  throw new Error('No GPU adapter available')
}

const device = await adapter.requestDevice({
  requiredFeatures: ['timestamp-query'],
  requiredLimits: {
    maxStorageBufferBindingSize: 1024 * 1024 * 1024,
  },
})

アダプタが取れないケースは、(a) ブラウザ未対応、(b) GPU ドライバ未対応、(c) ユーザーがポリシーで遮断、のいずれも実環境で頻繁に起きる。フォールバック経路は必ず用意する。

WebGL との共存

WebGPU は WebGL を 完全に置き換えるものではない。2026 年でも WebGL 1 / 2 は、(1) 旧型デバイス、(2) 低電力モバイル、(3) WebView / WKWebView 埋め込み、で必要となる。実運用では両バックエンドを併存させるのが定石である。

4. WGSL — WebGPU シェーディング言語

なぜ GLSL ではないのか

GLSL の文法は OpenGL 時代 (2004) のものだ。現代のグラフィックス API が求める明示性、安全性、ツール親和性とそぐわない。WGSL は Apple / Google / Mozilla が共同設計した Rust 風の新しいシェーディング言語 である。

• 明示的な型と注釈
• Rust / Swift 風の関数宣言
• メモリモデルが明確 (storage, uniform, workgroup, private)
• セキュリティ志向 (out-of-bounds が定義済み、undefined behavior を最小化)

Hello triangle (WGSL)

struct VsIn {
  @location(0) position: vec3<f32>,
  @location(1) color: vec3<f32>,
}

struct VsOut {
  @builtin(position) clip_position: vec4<f32>,
  @location(0) color: vec3<f32>,
}

@vertex
fn vs_main(input: VsIn) -> VsOut {
  var out: VsOut;
  out.clip_position = vec4<f32>(input.position, 1.0);
  out.color = input.color;
  return out;
}

@fragment
fn fs_main(input: VsOut) -> @location(0) vec4<f32> {
  return vec4<f32>(input.color, 1.0);
}

GLSL からの主な変化点。

• 意図は @location、@builtin、@vertex、@fragment といった アトリビュート で表現
• 型は明示的 (vec3 of f32 など)
• let と var の使い分け (Rust の影響)

コンピュートシェーダ — GPGPU はファーストクラス

@group(0) @binding(0) var<storage, read> input: array<f32>;
@group(0) @binding(1) var<storage, read_write> output: array<f32>;

@compute @workgroup_size(64)
fn cs_main(@builtin(global_invocation_id) gid: vec3<u32>) {
  let i = gid.x;
  if (i >= arrayLength(&input)) {
    return;
  }
  output[i] = input[i] * 2.0;
}

この 16 行のコンピュートシェーダこそ、WebGL が最後まで届けられなかった 汎用 GPU 計算を標準 Web で実現する鍵だ。ML 推論、パーティクルシミュレーション、画像処理、ソート、prefix sum — すべてここから始まる。

メモリのアドレス空間

明示的なアドレス空間は GPU のメモリ階層をそのまま露出する。GLSL の uniform キーワードよりはるかに正直である。

5. wgpu (Rust) — Mozilla / gfx-rs の portable WebGPU

wgpu とは

wgpu は Mozilla と gfx-rs コミュニティが Rust で実装した WebGPU の実装 である。役割は 2 つ。

1. Firefox のバックエンド — Firefox の WebGPU は wgpu が支える
2. ネイティブライブラリ — Rust (および C / C++ / Python) から WebGPU API を portable レイヤとして利用できる

後者こそ本当のインパクトだ。WebGPU 仕様を ネイティブアプリでも そのまま使えるという意味になる。

wgpu のバックエンド

wgpu (Rust crate)
├─ Vulkan   (Linux / Android / Windows / macOS via MoltenVK)
├─ Metal    (macOS / iOS)
├─ DirectX 12 (Windows)
├─ OpenGL ES 3 (旧型デバイスのフォールバック)
└─ WebGPU (ブラウザ wasm ビルド)

同じコードを Linux / Mac / Windows ネイティブとブラウザ wasm の 5 ターゲットにビルドできる。

小さな wgpu サンプル (Rust)

use wgpu::util::DeviceExt;

async fn run() {
    let instance = wgpu::Instance::default();
    let adapter = instance
        .request_adapter(&wgpu::RequestAdapterOptions::default())
        .await
        .unwrap();
    let (device, queue) = adapter
        .request_device(&wgpu::DeviceDescriptor::default(), None)
        .await
        .unwrap();

    let shader = device.create_shader_module(wgpu::ShaderModuleDescriptor {
        label: Some("triangle.wgsl"),
        source: wgpu::ShaderSource::Wgsl(include_str!("triangle.wgsl").into()),
    });

    // ... pipeline / bind groups / draw
}

Rust 製ゲームエンジン Bevy、GUI フレームワーク iced、組み込みグラフィックス Lyon などが wgpu の上に立っている。WebGPU 仕様は Rust ネイティブアプリの基本ライブラリにもなった。

誰が wgpu を使うか

• Mozilla / Firefox — ブラウザバックエンド
• Deno — サーバサイド GPU として WebGPU を露出
• Bevy — Rust ゲームエンジン標準レンダラ
• gfx-rs コミュニティ — Rust グラフィックスの土壌

6. naga + Tint — WGSL コンパイラの兄弟

naga (Rust, gfx-rs)

naga は wgpu と共に育つシェーダ変換ツール群だ。

• WGSL パーサとライタ
• SPIR-V / WGSL / GLSL / MSL / HLSL の相互変換
• Rust クレートと CLI を提供

# WGSL を Metal Shading Language に変換
cargo install naga-cli
naga shader.wgsl shader.metal

# WGSL を SPIR-V に変換
naga shader.wgsl shader.spv

Rust 系シェーダツールはほぼすべて naga の上に立っている。

Tint (C++, Google Dawn)

Tint は Google が Dawn (Chrome の WebGPU 実装) 向けに作った C++ コンパイラ。

• WGSL → SPIR-V (Vulkan バックエンド)
• WGSL → MSL (Metal バックエンド)
• WGSL → HLSL (D3D12 バックエンド)
• WGSL バリデーション、IR パス、最適化

Tint は Dawn に組み込まれているため、単独 CLI というより Chromium ツリーの内部で動く。WGSL 仕様のリファレンス実装に近い存在だ。

どこでどのコンパイラが動くか

同じ WGSL コードが 3 種類のコンパイラを通り、3 種類の OS グラフィックス API に変換される。仕様適合性 がかつてないほど重要になる理由がここにある。

WGSL バリデーション

naga --validate shader.wgsl

ビルド時にシェーダを検証すればランタイム破綻を防げる。CI に組み込むパターンが増えている。

7. Three.js WebGPU レンダラ (r163+, 2024 年 5 月)

r163 — Three.js WebGPU 正式版

2024 年 5 月にリリースされた Three.js r163 から WebGPU レンダラが正式採用された。r137 (2022) から実験的ではあったが、r163 で production ready が宣言された。

import * as THREE from 'three'
import WebGPURenderer from 'three/addons/renderers/webgpu/WebGPURenderer.js'

const renderer = new WebGPURenderer({ antialias: true })
renderer.setSize(window.innerWidth, window.innerHeight)
document.body.appendChild(renderer.domElement)

const scene = new THREE.Scene()
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000)

const geometry = new THREE.BoxGeometry()
const material = new THREE.MeshStandardMaterial({ color: 0x6699ff })
const cube = new THREE.Mesh(geometry, material)
scene.add(cube)

scene.add(new THREE.AmbientLight(0xffffff, 0.5))
scene.add(new THREE.DirectionalLight(0xffffff, 1))

camera.position.z = 5

renderer.setAnimationLoop(() => {
  cube.rotation.x += 0.01
  cube.rotation.y += 0.01
  renderer.render(scene, camera)
})

WebGL レンダラとほぼ同じコードで動作する。

TSL — Three.js Shading Language

Three.js のもう一つの賭けは TSL (Three Shading Language) だ。WGSL や GLSL を直接書かず、JavaScript 関数の合成でシェーダを記述する。

import { color, uniform, mul, sin, time, attribute } from 'three/tsl'

const baseColor = uniform(color(0xff6633))
const wave = sin(mul(attribute('position').x, 2.0).add(time))
const finalColor = baseColor.mul(wave.add(1.0).mul(0.5))

material.colorNode = finalColor

TSL は WGSL と GLSL を自動生成する。ひとつのシェーダコードで WebGPU と WebGL の両方をターゲット にできるのが要点だ。

Three.js のマイグレーション戦略

1. WebGLRenderer → WebGPURenderer に import を差し替える
2. 動作確認後、手書きシェーダ部分があれば TSL へ段階的に移行
3. コンピュートシェーダ (パーティクル、GPGPU) は新機能として活用

誰が使っているか

• Vercel — マーケティングページの一部 3D
• トス — データ可視化の一部 (WebGPU コンピュートシェーダ)
• カカオゲームズ — 一部のウェブプロトタイプ
• Three.js Journey (Bruno Simon) の講座が WebGPU / TSL 対応に更新

8. Babylon.js WebGPU (5.x, 6.x)

Babylon.js の WebGPU への賭け

Microsoft が支援する Babylon.js は WebGPU に早くから賭けた。2021 年の 5.0 で実験的 WebGPU エンジンを投入し、2023 年の 6.0 で安定化させた。ゲームエンジン級の機能と共に進むのが強みだ。

import { Engine, WebGPUEngine, Scene, FreeCamera, Vector3, HemisphericLight, MeshBuilder } from '@babylonjs/core'

const canvas = document.getElementById('renderCanvas')
const engine = await WebGPUEngine.IsSupportedAsync
  ? await new WebGPUEngine(canvas).initAsync().then((e) => e ?? null) || new Engine(canvas, true)
  : new Engine(canvas, true)

const scene = new Scene(engine)
const camera = new FreeCamera('cam', new Vector3(0, 5, -10), scene)
camera.setTarget(Vector3.Zero())
camera.attachControl(canvas, true)

new HemisphericLight('light', new Vector3(0, 1, 0), scene)
const box = MeshBuilder.CreateBox('box', { size: 2 }, scene)

engine.runRenderLoop(() => scene.render())

WebGPUEngine.IsSupportedAsync でサポートを判定し、フォールバックする。

Babylon.js の強み

• PBR + IBL — 映画級のシェーディング
• Node Material Editor — ノードベースのシェーダ GUI
• Physics — Cannon / Havok 連携
• GUI — ゲーム UI / デモウィジェット
• glTF インポート — 標準モデルフォーマット

ゲーム、シミュレーション、デジタルツインに強い。Three.js が「グラフィックスのビルディングブロック」なら、Babylon.js は「エンジン」に近い。

Babylon.js + WebGPU コンピュート

import { ComputeShader, StorageBuffer } from '@babylonjs/core'

const cs = new ComputeShader('add', engine, {
  computeSource: `
    @group(0) @binding(0) var<storage, read_write> data: array<f32>;
    @compute @workgroup_size(64)
    fn main(@builtin(global_invocation_id) gid: vec3<u32>) {
      data[gid.x] = data[gid.x] * 2.0;
    }
  `,
})

const buffer = new StorageBuffer(engine, 1024 * 4)
cs.setStorageBuffer('data', buffer)
cs.dispatch(16, 1, 1)

ゲームエンジンの中でそのまま GPGPU を実行できる。

9. Filament Web / regl / gpu.js / PlayCanvas

Filament Web — Google の PBR エンジン

Google が作った Filament (C++) は Android の sceneform 時代からモバイル PBR の標準を提示してきたエンジンだ。WebAssembly + WebGPU/WebGL ビルドを提供し Filament Web として動く。

• 映画級の PBR + IBL (Image-Based Lighting)
• 精密なトーンマッピング / ホワイトバランス
• glTF 標準インポート

WebGPU バックエンドは 2025 年から段階的に移行中。C++ グラフィックスエンジンの本気がそのまま運ばれてきた印象だ。

regl — 関数型 WebGL / WebGPU

regl (Mikola Lysenko) は命令型の WebGL を関数型にラップする。小さく、速く、学習コストが低い。

import regl from 'regl'

const draw = regl({
  vert: `
    precision mediump float;
    attribute vec2 position;
    void main() {
      gl_Position = vec4(position, 0, 1);
    }
  `,
  frag: `
    precision mediump float;
    uniform vec4 color;
    void main() { gl_FragColor = color; }
  `,
  attributes: { position: [[-1, 0], [0, -1], [1, 1]] },
  uniforms: { color: [1, 0, 0, 1] },
  count: 3,
})

regl.frame(() => draw())

WebGPU バックエンド (regl-gpu など) も登場している。グラフィックス学習やデータ可視化で重宝される。

gpu.js — JavaScript で GPU コンピュート

gpu.js は JavaScript 関数を GPU シェーダに変換して実行する GPGPU ヘルパー。長らく WebGL ベースだったが WebGPU バックエンドが導入されつつある。

import { GPU } from 'gpu.js'

const gpu = new GPU()
const multiplyMatrix = gpu
  .createKernel(function (a, b) {
    let sum = 0
    for (let i = 0; i < 512; i++) {
      sum += a[this.thread.y][i] * b[i][this.thread.x]
    }
    return sum
  })
  .setOutput([512, 512])

const c = multiplyMatrix(matA, matB)

ML や画像処理の高速なプロトタイピングに向いている。

PlayCanvas — ブラウザゲームエンジン

PlayCanvas は英国発のブラウザゲームエンジン。ECS 構造とホスト型エディタを備え、WebGPU バックエンドを正式サポートする。広告/マーケティングの 3D インタラクティブによく登場する。

• ECS コンポーネントモデル
• クラウドエディタ (ブラウザ上でシーン編集)
• glTF / 物理 / サウンド / アニメーション
• WebGL2 + WebGPU の二重バックエンド

Disney や BMW など、大手ブランドの 3D 広告事例が多い。

10. WebLLM (MLC LLM) — ブラウザでの LLM 推論

WebLLM とは

CMU / MLC チームの MLC LLM プロジェクトが構築した WebLLM は、LLM (Llama, Mistral, Phi など) を ブラウザ内部 で WebGPU 推論するライブラリだ。サーバなし、データをブラウザの外に出さずに応答を受け取る。

<script type="module">
  import * as webllm from 'https://esm.run/@mlc-ai/web-llm'

  const engine = await webllm.CreateMLCEngine('Llama-3-8B-Instruct-q4f32_1-MLC')

  const reply = await engine.chat.completions.create({
    messages: [
      { role: 'system', content: 'You are a helpful assistant.' },
      { role: 'user', content: 'WebGPU の未来について簡潔に教えて。' },
    ],
  })

  console.log(reply.choices[0].message.content)
</script>

API は OpenAI 互換 (chat.completions.create) だ。

技術スタック

• MLC LLM コンパイラ — PyTorch モデルを TVM ベースで WebGPU シェーダにコンパイル
• WGSL コンピュートシェーダ — Matmul / Attention / RMSNorm などのコア演算
• FP16 / INT4 量子化 — モデルサイズを縮小してブラウザに収める

パフォーマンス (2026 年基準)

• M3 MacBook Pro で Llama-3 8B (q4 量子化) 毎秒 30 〜 60 トークン
• M2 iPad で Phi-3.5-mini (3.8B) 毎秒 20 〜 30 トークン
• デスクトップ RTX 4070 + Chrome WebGPU で毎秒 80 〜 120 トークン

サーバ推論の 50 〜 70 % 程度。しかし 推論コストがゼロ という点が圧倒的だ。

誰が使うか

• チャットボットデモ — ローカル LLM の体験
• プライバシー重視サービス — 医療 / 法務 / 学校 (データがブラウザの外に出ない)
• オフライン PWA — 機内モードでも動く
• オンデバイスエージェント — ブラウザ拡張機能

11. Transformers.js (Xenova) — WebGPU アクセラレーション

Transformers.js とは

Hugging Face の Transformers をブラウザに移植した Transformers.js (作者 Xenova) は、ほぼすべての小型モデル (BERT, DistilBERT, Whisper, CLIP, ViT, SAM など) をブラウザで推論する。2024 年から WebGPU バックエンド が正式採用。

import { pipeline } from '@xenova/transformers'

// WebGPU バックエンドを強制
const pipe = await pipeline('sentiment-analysis', 'Xenova/distilbert-base-uncased-finetuned-sst-2-english', {
  device: 'webgpu',
})

const result = await pipe('I love WebGPU in 2026.')
console.log(result)
// [{ label: 'POSITIVE', score: 0.9998 }]

サポートタスク

• NLP — sentiment-analysis、fill-mask、summarization、translation、question-answering
• 音声 — Whisper (自動音声認識)、VAD
• ビジョン — CLIP、SAM、DINO、ViT、OWL-ViT
• マルチモーダル — LLaVA-Phi、Florence-2

ほとんどの Hugging Face 小型モデルが ONNX → WebGPU 変換で動く。

応用事例

• 検索 UI に意味検索を追加 — sentence-transformers をブラウザで
• 録音 → 字幕 — Whisper-tiny / base
• 画像分類 / 埋め込み — CLIP をブラウザで

パフォーマンス

大型モデル (70B 級) は難しいが、小型モデル (500M 未満) はきわめて速い。distilbert-base の推論がデスクトップ WebGPU で 5 〜 10 ms 程度だ。

12. React Three Fiber WebGPU / ONNX Runtime WebGPU

React Three Fiber (R3F) WebGPU

React Three Fiber は Three.js を React コンポーネントでラップしたライブラリ。2025 年から WebGPU レンダラを正式サポート。

import { Canvas } from '@react-three/fiber'
import { WebGPURenderer } from 'three/addons/renderers/webgpu/WebGPURenderer.js'

export default function Scene() {
  return (
    <Canvas
      gl={(canvas) => {
        const renderer = new WebGPURenderer({ canvas, antialias: true })
        return renderer
      }}
    >
      <ambientLight intensity={0.5} />
      <directionalLight position={[5, 5, 5]} />
      <mesh>
        <boxGeometry args={[1, 1, 1]} />
        <meshStandardMaterial color="#6699ff" />
      </mesh>
    </Canvas>
  )
}

宣言的な React API + WebGPU アクセラレーション。マーケティング / プロダクトページの 3D インタラクティブに最適だ。

ONNX Runtime Web — WebGPU バックエンド

Microsoft の ONNX Runtime Web は ONNX モデルをブラウザで動かすライブラリ。バックエンドとして WebGL / WASM / WebGPU を選べる。

import * as ort from 'onnxruntime-web/webgpu'

const session = await ort.InferenceSession.create('./model.onnx', {
  executionProviders: ['webgpu'],
})

const feeds = { input: new ort.Tensor('float32', new Float32Array(224 * 224 * 3), [1, 3, 224, 224]) }
const results = await session.run(feeds)
console.log(results.output.data)

PyTorch / TensorFlow で学習したモデルを ONNX へエクスポート → ブラウザで WebGPU 推論。エンタープライズ案件で最も無難な選択肢である。

どのシナリオにどのライブラリ?

13. Web Stable Diffusion — ブラウザでの SD

Web Stable Diffusion

CMU / MLC チームがさらに作り上げた Web Stable Diffusion は、Stable Diffusion 1.5 / 2.1 を ブラウザ内部 で WebGPU 推論する。テキスト → 画像をサーバ呼び出しなしで生成する。

• モデルサイズはおよそ 2.1 GB (量子化)
• 初回ロード後はキャッシュ (IndexedDB)
• M2 MacBook で 1 枚あたり 20 〜 40 秒
• RTX 4070 + Chrome WebGPU で 8 〜 15 秒

動作の流れ

1. UNet / VAE / Text Encoder を ONNX / MLC でコンパイル
2. 重みを IndexedDB にキャッシュ
3. テキスト → CLIP → UNet 拡散ループ → VAE デコード
4. キャンバスに描画

全プロセスがブラウザ内部で完結する。サーバ費用はかからない。

応用

• 個人向け画像生成ツール — 登録やカード不要で即時利用
• 教育デモ — 拡散モデルの実演
• クリエイティブツール — オフライン対応の PWA

限界

• 初回 2 〜 3 GB のダウンロードは確かな参入障壁
• 巨大な SDXL (7 GB+) モデルはまだ現実的でない
• モバイルは NPU サポートがなくデスクトップ中心

これを解くのが、2026 〜 2027 年に控える WebGPU 拡張 (bfloat16、mesh shaders、ray-tracing) の宿題だ。

14. コンピュートシェーダ + Storage Texture + Subgroups + mesh shaders の未来

コンピュートシェーダが変えたこと

WebGPU の真の革命はグラフィックスではなく GPGPU だ。

• パーティクルシステム — CPU → GPU へ (百万粒子)
• 物理シミュレーション — 位置ベース動力学 (PBD)、MLS-MPM
• 画像 / 動画処理 — リアルタイムフィルタ、OpenCV 代替
• ML 推論 — Matmul、Attention、Conv2D
• データ可視化 — 数百万点のクラスタリング / KDE

韓国ではトスのデータ可視化チームが頻繁に引用される事例だ。数十万点のインタラクティブチャートが 60 fps で動作する。

Storage Texture

@group(0) @binding(0) var<storage, read_write> output: texture_storage_2d<rgba8unorm, write>;

@compute @workgroup_size(8, 8)
fn cs_main(@builtin(global_invocation_id) gid: vec3<u32>) {
  let coord = vec2<i32>(i32(gid.x), i32(gid.y));
  let color = vec4<f32>(0.5, 0.7, 1.0, 1.0);
  textureStore(output, coord, color);
}

現在は読み取り専用または書き込み専用の storage texture。2026 年後半に read-write storage texture 拡張が入る予定だ。

Subgroups (ワープ通信)

enable subgroups;

@compute @workgroup_size(64)
fn cs_main(@builtin(subgroup_invocation_id) sid: u32) {
  let value = some_input[sid];
  let sum = subgroupAdd(value);
  // ワープ内部で 32 〜 64 倍速いリダクション
}

CUDA の warp shuffle、Metal の SIMD-group メッセージに相当。ソート / scan / Matmul / Attention の最適化の要だ。

Mesh shaders

伝統的な「頂点バッファ → インデックスバッファ → 頂点シェーダ → ラスタライザ」のパイプラインに代わり、メッシュシェーダが小さなメッシュ (meshlet) を直接吐く。Unreal Engine の Nanite 風の仮想化マイクロポリゴンが可能になる。

2026 年時点で W3C 提案段階。安定化は 2027 〜 2028 年と見られる。

Ray-tracing

DXR / Vulkan RT / Metal RT のブラウザ抽象化。グローバルイルミネーション、反射、屈折をシェーダから直接扱える。提案段階ではあるが、実現すればゲーム / 可視化に大きな変革をもたらす。

15. 韓国 / 日本 — トス、カカオゲームズ、ピクシブ、CyberAgent

韓国

トス (Toss)

トスのデータ可視化チームは 2024 年から WebGPU コンピュートシェーダを採用。数十万件のトランザクションを扱うインタラクティブチャートと、クラスタリングアルゴリズムがブラウザの GPU 上で動く。SLASH カンファレンスでの発表が韓国エンジニアコミュニティを刺激した。

• 大規模データ可視化 (数十万点)
• リアルタイムフィルタリング / ズーム
• WebGL フォールバックも維持

カカオゲームズ

PlayCanvas + WebGPU の組み合わせで一部ウェブゲームのプロトタイプを実験中。モバイルブラウザ (iOS Safari 18, Android Chrome) 対応がゲームの参入障壁を下げる。

NAVER D2 / CLOVA

NAVER LABS と D2 は WebGPU 関連の記事を定期的に発信する。CLOVA チームは Transformers.js と ONNX Runtime Web を用いた ML 推論デモを公開している。

日本

ピクシブ (pixiv)

クリエイタープラットフォーム pixiv では、一部のインタラクティブコンポーネント (スタンプ、エフェクト) に WebGPU を適用しつつある。JavaScript の限界で実装できなかったリアルタイムエフェクトが、WebGPU コンピュートで解決される。

CyberAgent

広告 / ゲーム領域での WebGPU 採用が活発だ。3D 広告、シミュレーション、ライブ配信のエフェクト — すべて WebGPU へ移行中。AbemaTV の一部インタラクティブコンテンツもこの流れにある。

LINE / Yahoo Japan

大規模データ可視化に WebGPU コンピュートシェーダを試験導入中。トスと同じ動機だ。

グローバル

• Vercel — マーケティングページの 3D
• Figma — レンダリングパイプラインの一部を評価中
• Adobe — Photoshop Web の GPU アクセラレーション
• Google Earth Web — WebGPU バックエンドを試験
• Unreal Engine Pixel Streaming — WebGPU クライアントを検討

16. 誰が WebGPU を学ぶべきか — ゲーム / データ可視化 / ブラウザ ML

シナリオ別の推奨

ゲーム / インタラクティブ 3D

• Three.js (低い参入障壁、大きなコミュニティ) または Babylon.js (エンジン級機能)
• シェーダは TSL か WGSL を直接記述
• モバイル対応には WebGL2 フォールバックを必ず

データ可視化 (数十万 〜 数百万点)

• regl または Three.js BufferGeometry + コンピュートシェーダ
• トスのパターン — クラスタリング / KDE / ヒートマップを GPU 上で
• Observable / D3 との併用も可能

ブラウザ ML 推論

• 小型モデル (BERT, Whisper-tiny, CLIP) → Transformers.js
• 社内 ONNX モデル → ONNX Runtime Web
• LLM チャットデモ → WebLLM
• SD / 画像生成 → Web Stable Diffusion

ネイティブ + ウェブ統合

• Rust で wgpu の上にコアを記述
• 同じコードを wasm にビルドしてブラウザへ
• Bevy / iced など Rust グラフィックス系を活用

学習パス

1. WGSL 基礎 — @vertex / @fragment / @compute の小さなサンプルから
2. WebGPU を直接呼ぶ — pipeline / bind group / buffer を手で書いてみる
3. Three.js / Babylon.js — 高水準ライブラリで素早く成果を出す
4. コンピュートシェーダ — GPGPU パターン (reduce / scan / matmul)
5. ML 推論統合 — Transformers.js や ONNX Runtime Web の応用

よくある落とし穴

• ブラウザは同じではない — Chrome / Safari / Firefox 全てでテスト
• WGSL コンパイラ差異 — Tint / WebKit / naga の挙動差が時折出る
• WebGL フォールバック必須 — 旧型デバイス / WebView 用
• 初回ロードコスト — シェーダコンパイル時間と重みダウンロード時間を計測
• メモリ制限 — モバイル GPU はメモリが小さい (2 〜 4 GB)、モデルサイズに注意

結論 — 2026 年の GPU ウェブ

WebGPU はもはや「もうすぐ来る」ものではない。すでに来ている。 Chrome / Safari / Firefox の 3 大ブラウザは GA。仕様も CR。ライブラリ生態系も成熟した。2026 年の答えはシンプルだ。

新規のグラフィックス / GPGPU プロジェクトは WebGPU から始め、WebGL を安全網として置く。ブラウザ ML は WebGPU なしには成り立たない時代だ。

参考 / References

• W3C — WebGPU Specification
• W3C — WGSL Specification
• W3C — GPU for the Web Working Group
• MDN Web Docs — WebGPU API
• Chrome Developers — WebGPU を始める
• WebKit blog — WebGPU in Safari
• Mozilla Hacks — WebGPU in Firefox
• wgpu — wgpu.rs
• gfx-rs — github.com/gfx-rs/wgpu
• naga — github.com/gfx-rs/naga
• Google Dawn — dawn.googlesource.com
• Three.js — threejs.org
• Three.js WebGPU examples — threejs.org/examples/?q=webgpu
• Babylon.js — babylonjs.com
• Babylon.js WebGPU docs — doc.babylonjs.com/setup/support/webGPU
• Filament — google.github.io/filament
• regl — regl.party
• gpu.js — gpu.rocks
• PlayCanvas — playcanvas.com
• React Three Fiber — r3f.docs.pmnd.rs
• WebLLM (MLC LLM) — webllm.mlc.ai
• Transformers.js (Xenova) — huggingface.co/docs/transformers.js
• ONNX Runtime Web — onnxruntime.ai/docs/tutorials/web
• Web Stable Diffusion — mlc.ai/web-stable-diffusion
• Bevy ゲームエンジン — bevyengine.org
• NAVER D2 — d2.naver.com
• Toss SLASH カンファレンス — toss.tech/slash
• pixiv inside — inside.pixiv.blog
• CyberAgent developer blog — developers.cyberagent.co.jp
• Can I Use — WebGPU — caniuse.com/webgpu
• WebGPU Samples — webgpu.github.io/webgpu-samples