LabHub

ブログ

WebGPU & WebGL 2026 完全ガイド - Three.js · React Three Fiber · Babylon.js · PlayCanvas · TresJS · Needle Engine · ネイティブ WebGPU · WGSL 徹底解説

한국어English日本語

プロローグ - 2026年、Web 3D はもう一度生まれ直した

2023年4月、Chrome 113 が WebGPU を既定でオンにしたときは「またひとつの標準争い」に見えた。WebGL 2 は十分に動いていたし、WebGPU は Safari・Firefox ではフラグ越しで、Three.js は「WebGPURenderer」を実験枠で抱えていた。

3年が経った2026年5月、景色は完全に塗り替わった。

本稿では、2026年5月時点の Web グラフィックス・スタックを頭からお尻まで整理する。WebGPU と WebGL の違い、Three.js・R3F・Babylon・PlayCanvas・TresJS・Needle の選び分け、WGSL の要点、コンピュートシェーダーで ML を回す方法、そして韓国・日本コミュニティの資料まで。


1章 · WebGL 2 vs WebGPU - 何が変わったか

一行でまとめると、WebGL は OpenGL ES 3.0 を JavaScript で包んだもの、WebGPU は Vulkan・Metal・DirectX 12 を抽象化した新しい API。両者は思想が違う。

項目WebGL 2WebGPU
リリース2017年に安定化2023年4月の Chrome 113 で既定オン
基盤OpenGL ES 3.0Vulkan/Metal/D3D12 抽象
シェーダー言語GLSL ES 3.00WGSL
コンピュートシェーダーなしファーストクラスで搭載
マルチスレッドキューなしCommand Encoder/Queue
間接ディスパッチ一部(インスタンシングのみ)indirectDraw、indirectDispatch
非同期コールバック型Promise 型(マッピング・サブミット)
パイプライン状態グローバル可変RenderPipeline オブジェクト
テクスチャ圧縮DXT/ETC/ASTC(部分対応)BC/ETC2/ASTC(GPU 別)
デバッグSpector.jsChrome DevTools の WebGPU パネル

要点は一行。WebGL は「描画専用」、WebGPU は「描画 + 計算」。コンピュートシェーダーが入ったことで、ML・シミュレーション・画像後処理・パーティクルがすべて GPU で回るようになった。

性能はどうか。同じシーンを両 API で描画した場合、単純なラスター(ポリゴン描画)は同等だ。CPU オーバーヘッドが下がるぶん、ドローコールが多いほど WebGPU が速い。コンピュート寄り(画像処理・ML 推論)では2〜3倍が一般的。


2章 · ブラウザ対応状況(2026年5月時点)

対応表を整理すると意思決定が早い。

フォールバックはシンプル。

if (navigator.gpu) {
  // WebGPU を使用
  const adapter = await navigator.gpu.requestAdapter()
  const device = await adapter.requestDevice()
} else {
  // WebGL 2 にフォールバック
  const gl = canvas.getContext('webgl2')
}

Three.js の WebGPURenderer はこの分岐を自動でやってくれる。WebGPU が無ければ WebGLRenderer に落ちる。実務ではほぼ意識しなくて済む。


3章 · ネイティブ WebGPU - Dawn と wgpu-rs

ブラウザ内の WebGPU 実装は二択だ。

要点はここ。WebGPU の API はブラウザの中に閉じ込められていない。 Rust なら wgpu-rs、C++ なら Dawn を使えば、同じシェーダー(WGSL)と同じ API でデスクトップ・モバイルのネイティブ・アプリが作れる。WGSL は事実上、SPIR-V の上に乗った標準 GPU シェーダー言語になりつつある。

Bevy(Rust 製ゲームエンジン)は wgpu-rs を基盤に、デスクトップ・モバイル・Web(WASM)を単一コードベースでターゲットする。「Write once, GPU anywhere」はもう冗談ではない。


4章 · WGSL - WebGPU Shading Language

GLSL を知っていれば30分で慣れる。文法が違うだけで、思想は似ている。

最小の頂点シェーダー(WGSL):

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

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

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

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

GLSL との違いを一行ずつ。

最大の差分はコンピュートシェーダーだ。

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

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

64個ずつまとめて1次元配列を2倍にするシェーダー。ML・シミュレーション・画像処理はすべてこのパターンだ。


5章 · Three.js と TSL - 1つのシェーダー、2つのバックエンド

Three.js は週次 npm ダウンロードが270万を超える、Web 3D の事実上の標準だ。r182(2025年12月)で WebGPURenderer が推奨レンダラーに昇格した。

最小シーン:

import * as THREE from 'three'
import { WebGPURenderer } from 'three/webgpu'

const scene = new THREE.Scene()
const camera = new THREE.PerspectiveCamera(75, w / h, 0.1, 1000)
camera.position.z = 5

const renderer = new WebGPURenderer({ antialias: true })
await renderer.init()
renderer.setSize(w, h)
document.body.appendChild(renderer.domElement)

const cube = new THREE.Mesh(
  new THREE.BoxGeometry(1, 1, 1),
  new THREE.MeshStandardMaterial({ color: 0x44aa88 })
)
scene.add(cube)
scene.add(new THREE.AmbientLight(0xffffff, 0.4))
const dir = new THREE.DirectionalLight(0xffffff, 1.0)
dir.position.set(5, 10, 7.5)
scene.add(dir)

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

WebGL との違いは2つ。

  1. await renderer.init() - WebGPU は非同期初期化が必須。
  2. setAnimationLoop - requestAnimationFrame の代わりに推奨。WebXR もここで一緒に拾える。

TSL - Three Shading Language

Three.js 0.158 から入った JS DSL。1度書いたシェーダーを GLSL と WGSL の両方にコンパイルする。

import { Fn, vec3, sin, time, uv } from 'three/tsl'

const myColor = Fn(() => {
  const t = sin(time.mul(2.0))
  return vec3(uv().x, t, uv().y)
})

material.colorNode = myColor()

GLSL を手書きしなくてもシェーダーグラフが組まれる。WebGPU では WGSL に、WebGL では GLSL に自動変換される。2026年現在、新規に書くシェーダーは TSL で書くことを推奨する。


6章 · React Three Fiber + drei - React ツリーに 3D を載せる

R3F は Three.js を React コンポーネントとして表現する。命令型コードは50ノードを超えると一気にぐちゃぐちゃになるが、R3F なら React ツリーとして整理できる。

import { Canvas } from '@react-three/fiber'
import { OrbitControls, Environment } from '@react-three/drei'

function Cube() {
  return (
    <mesh rotation={[0, 0.4, 0]}>
      <boxGeometry args={[1, 1, 1]} />
      <meshStandardMaterial color="hotpink" />
    </mesh>
  )
}

export default function Scene() {
  return (
    <Canvas camera={{ position: [0, 0, 5], fov: 75 }}>
      <ambientLight intensity={0.4} />
      <directionalLight position={[5, 10, 7.5]} intensity={1} />
      <Cube />
      <OrbitControls />
      <Environment preset="city" />
    </Canvas>
  )
}

JSX タグ meshboxGeometry は Three.js のクラス名に対応する。OrbitControlsEnvironmentdrei(Poimandres チームのヘルパー)から来る。drei が無いと R3F は半分の価値だ。

R3F v9 の WebGPU - 非同期 gl prop

import { Canvas } from '@react-three/fiber'
import { WebGPURenderer } from 'three/webgpu'

<Canvas
  gl={async (props) => {
    const r = new WebGPURenderer(props)
    await r.init()
    return r
  }}
>
  {/* ...シーン... */}
</Canvas>

R3F v9 が非同期ファクトリを受けるようになったので、WebGPU 初期化が React のライフサイクルに自然に収まる。2026年5月現在、Poimandres チームが積極的に磨き込み中。

R3F エコシステムのヘルパー

これらすべてが Poimandres という単一の OSS コレクティブから出ている。個人ではなくチームで作っていることが R3F の大きな強みだ。


7章 · Babylon.js 8 - Microsoft が後援するフルスタック・エンジン

Babylon.js は Three.js と思想が違う。Three.js が「ライブラリ(部品)」なら、Babylon は「エンジン(完成品)」だ。

違いを見ると選択基準が明確になる。

最小の Babylon シーン:

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

const canvas = document.getElementById('renderCanvas')
const engine = new Engine(canvas, true, { preserveDrawingBuffer: true })

const scene = new Scene(engine)
const camera = new ArcRotateCamera('camera', -Math.PI / 2, Math.PI / 2.5, 5, Vector3.Zero(), scene)
camera.attachControl(canvas, true)

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

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

コードは少し明示的で、カメラが最初から ArcRotateCamera(軌道カメラ)として用意される。Three.js なら OrbitControls を別で取り付ける必要があった部分。

Babylon の WebGPUEngine

WebGPU で動かすには Engine の代わりに WebGPUEngine を使う。

import { WebGPUEngine } from '@babylonjs/core'

const engine = new WebGPUEngine(canvas)
await engine.initAsync()

文法は Three.js の await renderer.init() とほぼ同じ。WebGPU シェーダーキャッシュ(IndexedDB)は Babylon の方がよく扱う。大きなシーンでの初回ロードが速い。

選択を一行で。レファレンスサイト・R3F・小さなコンポーネント中心なら Three.js。ゲーム・インスペクター・完成度中心なら Babylon.js。


8章 · PlayCanvas - ブラウザ・エディタを持つゲームエンジン

PlayCanvas は他の2エンジンと毛色が違う。ブラウザの中で動くビジュアル・エディタを備える。まるで Unity Editor の Web 版だ。

[ブラウザ・エディタ: playcanvas.com]
       | (ドラッグ&ドロップ)
       v
[シーン・prefab・マテリアル・スクリプト]
       |
       v
[ビルド -> CDN ホスティング -> <iframe> 埋め込み]

PlayCanvas Editor でシーンを作れば、それがそのまま Web ゲームになる。別途のビルド段階が無い。だから広告用インタラクティブ 3D や車両コンフィギュレーターのような、デザイナーの手数が多い案件で圧倒的に強い。

エンジン本体もオープンソース(MIT)。playcanvas npm パッケージでコードだけ書くのもアリ。

2024年6月、Snap が PlayCanvas を買収した。Snapdragon Spaces・Snap Lens のような AR プラットフォームと結びついたことで、モバイル AR を Web で動かす標準エンジンになりつつある。買収後もオープンソース・エンジンは進化を続けている。


9章 · TresJS - Vue 陣営の R3F

Vue.js 開発者が R3F をうらやんだなら、答えは TresJS だ。Three.js を Vue コンポーネントとして表現する。

<script setup>
import { TresCanvas } from '@tresjs/core'
import { OrbitControls } from '@tresjs/cientos'
</script>

<template>
  <TresCanvas>
    <TresPerspectiveCamera :position="[3, 3, 3]" />
    <TresMesh>
      <TresBoxGeometry />
      <TresMeshStandardMaterial color="hotpink" />
    </TresMesh>
    <TresAmbientLight :intensity="0.5" />
    <OrbitControls />
  </TresCanvas>
</template>

R3F の mesh の代わりに TresMeshboxGeometry の代わりに TresBoxGeometry - Vue は PascalCase + 接頭辞が好み。@tresjs/cientos が R3F の drei に相当する。

エコシステム規模は R3F の10分の1ほどだが、コアな機能は全部ある。Nuxt モジュールも用意され、Vue 3 の Composition API と相性がいい。


10章 · Needle Engine - Unity で作って Web で動かす

Needle の思想は独特だ。Unity Editor でシーンを組み、glTF にエクスポートして Web で動かす。

[Unity Editor]
   | (Needle パッケージをインストール)
   | (Export glTF)
   v
[scene.glb] + [scripts.js]
   |
   v
<needle-engine> -> WebGL/WebGPU レンダリング

Three.js の上に Unity のコンポーネント・システムを載せたもの。Unity 側の C# コンポーネント(TransformMeshRendererLight)が glTF 拡張としてシリアライズされ、クライアントの JS コンポーネント(@needle-tools/engine)がそれを復元する。

長所: Unity の巨大なアセット・エコシステム(アニメーション・シェーダーグラフ・物理)がそのまま Web に来る。WebXR も込み。短所: Unity が必須(エディタのビルドは約10GB)。

商用ライセンスが切り分けられているので、インディーや小規模チームならほぼ無料。コカ・コーラや LG といった大手のマーケティングサイトでも見かける。


11章 · Wonderland Engine - WebXR 専用

Wonderland はさらに特化型のケース。WebXR(VR/AR)を最もよく回せるエンジンだ。

VR ゲーム・トレーニング・シミュレータを作るときには Three.js や Babylon より遥かに速い。短所は、一般 3D サイトに使うにはオーバースペック。


12章 · Spline - デザイナー向けの Figma-for-3D

Spline はノーコード陣営。ブラウザ内のデザインツールで 3D シーンを作り、それを React コンポーネントや iframe で埋め込む。

import Spline from '@splinetool/react-spline'

export default function App() {
  return <Spline scene="https://prod.spline.design/abc/scene.splinecode" />
}

ランディングページ・ヒーローセクションのインタラクティブ 3D イラストが主用途。2025年から WebGPU レンダリングのオプションが追加された。デザイナーが Figma を使う感覚で 3D を作れるのがキモ。


13章 · PixiJS 8 - 2D ならこれ

3D ばかり扱っていて急に 2D が必要になったら? Canvas 2D API は遅いし、Three.js で 2D を描くのは過剰。PixiJS がその席に座る。

PixiJS 8(2024年リリース)が WebGPU をファーストクラスで扱う。Three.js と同様、自動フォールバック(WebGL)付き。

deck.gl(地理可視化)と PixiJS は両方 Uber の影響圏で始まったが、PixiJS は英国 OSS コミュニティ主導。


14章 · Cesium - 3D 地球・地理情報

地球を描くような巨大シーンを作るときは Cesium。3D Tiles 標準(OGC で標準化)を作った当事者でもある。

NVIDIA Omniverse・Unreal Engine と連携する産業向けツール。政府 GIS・国防・都市デジタルツインで標準的に使われる。


15章 · コンピュートシェーダー + ブラウザ ML

WebGPU がもたらした最大の変化はコンピュートだ。ブラウザで GPU 計算ができるようになり、ML 推論がクライアントに降りてきた。

TensorFlow.js + WebGPU バックエンド

import * as tf from '@tensorflow/tfjs'
import '@tensorflow/tfjs-backend-webgpu'

await tf.setBackend('webgpu')
await tf.ready()
const model = await tf.loadGraphModel('/model/model.json')
const output = model.predict(input)

WebGL バックエンド比1.5〜3倍速い。小型モデル(MobileNet・BlazePose)の推論はほぼネイティブ近似。

ONNX Runtime Web + WebGPU

Microsoft 製 ONNX ランタイムの Web ビルド。WebGPU EP(Execution Provider)が安定化した。

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

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

Hugging Face のモデルはほとんど ONNX にエクスポートできる。transformers.js(HF 公式)がこれをラップする。

import { pipeline } from '@xenova/transformers'

const generator = await pipeline('text-generation', 'Xenova/gpt2', {
  device: 'webgpu',
})
const out = await generator('Once upon a time', { max_new_tokens: 50 })

ブラウザの中で GPT-2 級のモデルが動く。小型 LLM ならサーバー無しのクライアント推論が現実的に。

WebLLM - 本物の LLM をブラウザで

Carnegie Mellon の MLC チームが作るプロジェクト。Llama・Phi・Gemma のような本物の LLM を WebGPU で回す。

import * as webllm from '@mlc-ai/web-llm'

const engine = await webllm.CreateMLCEngine('Llama-3.2-3B-Instruct-q4f16_1-MLC')
const reply = await engine.chat.completions.create({
  messages: [{ role: 'user', content: 'こんにちは' }],
})

3B〜8B モデルなら M2/M3 Mac でトークンあたり20〜40ms 程度。爆速ではないが、サーバー呼び出し無しで動く LLM という事実そのものが意味を持つ。医療・法務など、データを絶対サーバーに送れない領域で出番がある。

MediaPipe + WebGPU

Google の MediaPipe(画像・動画 ML)にも WebGPU バックエンドがある。顔認識・手のトラッキング・ポーズ推定がブラウザ内で60fps で回る。

whisper.cpp + WebGPU

OpenAI Whisper を C++ に移植した whisper.cpp にも WebAssembly + WebGPU ビルドがある。ブラウザ内の音声認識。


16章 · glTF - 3D の PNG・JPG

3D モデルをやり取りする標準は glTF 2.0(Khronos)。JSON + バイナリバッファ + PNG/JPG/KTX2 テクスチャの構成。

Three.js の GLTFLoader、R3F の useGLTF、Babylon の SceneLoader.Append - 全部同じフォーマットを扱う。

glTF 最適化ツールチェーン

# gltf-transform - 最も強力な CLI
npx gltf-transform optimize input.glb output.glb

# テクスチャ圧縮
npx gltf-transform ktx2 input.glb output.glb

# Draco/Meshopt メッシュ圧縮
npx gltf-transform draco input.glb output.glb

gltf-transform は事実上の標準。1GB の Blender エクスポートが50MB まで縮む。

Basis Universal + KTX2

JPG/PNG は CPU で展開してから GPU に上げる。KTX2(Basis Universal) は GPU 圧縮フォーマット(BC7・ETC2・ASTC)のまま直接アップロードする。GPU メモリと読み込み速度の両方が縮む。

# basisu CLI
basisu -ktx2 -uastc texture.png
# gltf-transform でも自動で KTX2 化できる
npx gltf-transform uastc input.glb output.glb

KTX2 は WebGL 2 と WebGPU の両方で対応。Three.js の KTX2Loader でロードする。


17章 · シェーダーライブラリとツール

GLSL/WGSL のシェーダーをゼロから書くのは難しい。次の資源が答えになる。

デバッグツール


18章 · ユースケース - どこに何を使うか


19章 · クロスプラットフォーム 3D エンジンの Web ターゲット

Web 専用ではない、デスクトップ・モバイルも対象とする大型エンジンも Web をターゲットする。

Web ネイティブのエンジン(Three.js・Babylon・PlayCanvas)と比べるとビルドサイズと起動時間が短所。ただし Unity・Unreal にすでに資産があるなら Pixel Streaming が最短経路だ。


20章 · 韓国・日本コミュニティ

Web 3D は英語圏のリソースが圧倒的だが、韓国と日本のコミュニティも急速に育っている。

韓国:

日本:

ICS.media は英訳しても遜色ない水準の記事が多い。日本語が苦でなければ頻繁に立ち寄ることを勧める。


21章 · 有名な Three.js サイト

インスピレーションが欲しいなら次のサイトを巡るといい。

Bruno Simon の Three.js Journey コース(threejs-journey.com)は事実上の標準教材。95章、合計100時間+。新しく始めるなら無条件にお勧め。


22章 · 学習ロードマップ(実用版)

ゼロから始めるなら次の順番。

  1. JS・Web の基礎 - DOM・Canvas・requestAnimationFrame に慣れていること。
  2. Three.js 基礎 - threejs.org/manual または Three.js Journey 1〜30章。
  3. 最初のシーン - キューブ・ライト・OrbitControls・glTF ロードまで。
  4. R3F 入門 - Three.js を理解した後で R3F に移ると速い。
  5. シェーダー(GLSL/TSL) - 無料書籍 The Book of Shaders と Shadertoy。
  6. WebGPU - webgpu.github.io の公式チュートリアル。
  7. WGSL - Google の WebGPU Samples。
  8. 特殊トピック - WebXR・glTF 最適化・コンピュートシェーダーのうち必要なものを選ぶ。

平均3〜6ヶ月でプロダクションサイトを書ける水準に達する。


23章 · よくある質問5つ

Q1. WebGL 2 はまだ学ぶべき?

フォールバックコードが要るなら基礎は知っておくべき。ただし新規シェーダーは TSL か WGSL に寄せた方が将来性は高い。

Q2. R3F vs 純 Three.js?

React プロジェクトなら R3F。静的サイト・Vanilla JS なら Three.js。同じエンジンを違う使い方で回しているだけ。

Q3. Babylon は Three.js より優れている?

長短が違う。Babylon は完成度・インスペクター・物理・WebGPU 成熟度が強み。Three.js はエコシステム・ドキュメント・サンプル数・採用市場が強み。

Q4. PlayCanvas のビジュアルエディタは本当に使える?

マーケティングサイトや車両コンフィギュレーターのようにデザイナーの手数が多い案件では圧倒的。コード中心の案件なら無理に使う必要は無い。

Q5. ブラウザで本当に LLM を動かせる?

3B〜8B までは実用的。70B はメモリ・速度的に厳しい。小さなアシスタント・コード補助・翻訳あたりが適正サイズ。


24章 · 結び - 「一度書けばどこでも GPU」の時代

2026年の Web 3D は3つの流れが合流した。

  1. WebGPU の定着 - ユーザーの95%がコンピュートシェーダーを使える。
  2. TSL の登場 - 1本のシェーダーで GLSL と WGSL の両方が作れる。
  3. ブラウザ ML の日常化 - transformers.js・WebLLM・MediaPipe がサーバー無しの ML を可能にした。

これらが重なると、サーバー無しのインタラクティブ 3D + AI サイトが現実になる。ユーザーの GPU を借りて LLM・画像生成・リアルタイム 3D を同時に回す。サーバーコストもレイテンシもプライバシー懸念もほぼゼロ。

道具は十分に揃った。残るのは作ることだけだ。良いシェーダー1本、シーン1つ、実験1ページ。それが積み上がると次の時代の Web になる。


参考資料

コメント

まだコメントはありません。

ログインするとコメントできます