필사 모드: WebGPU & WebGL 2026 完全ガイド - Three.js · React Three Fiber · Babylon.js · PlayCanvas · TresJS · Needle Engine · ネイティブ WebGPU · WGSL 徹底解説
日本語プロローグ - 2026年、Web 3D はもう一度生まれ直した
2023年4月、Chrome 113 が WebGPU を既定でオンにしたときは「またひとつの標準争い」に見えた。WebGL 2 は十分に動いていたし、WebGPU は Safari・Firefox ではフラグ越しで、Three.js は「WebGPURenderer」を実験枠で抱えていた。
3年が経った2026年5月、景色は完全に塗り替わった。
- WebGPU は Chrome・Edge・Firefox・Safari 26 で既定オン。グローバルカバレッジは約95%。
- Three.js r182 が `WebGPURenderer` を推奨レンダラーに引き上げた。`WebGLRenderer` はフォールバック。
- Babylon.js 8 は WebGPU をファーストクラスで扱う。Microsoft 後援、IndexedDB シェーダーキャッシュ、自動フォールバック付き。
- PlayCanvas は 2024年6月の Snap 買収後、Snapdragon AR と深く結びつきながらもオープンソース・エンジンの進化を続けている。
- TresJS は Vue 版 R3F、Needle Engine は Unity で組んだシーンを glTF にエクスポートして Web で動かす。
- TSL(Three Shading Language)が GLSL・WGSL を一本化し、WGSL のコンピュートシェーダーが LLM・MediaPipe・Whisper をブラウザ内で回す。
本稿では、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 2 | WebGPU |
| --- | --- | --- |
| リリース | 2017年に安定化 | 2023年4月の Chrome 113 で既定オン |
| 基盤 | OpenGL ES 3.0 | Vulkan/Metal/D3D12 抽象 |
| シェーダー言語 | GLSL ES 3.00 | WGSL |
| コンピュートシェーダー | なし | ファーストクラスで搭載 |
| マルチスレッドキュー | なし | Command Encoder/Queue |
| 間接ディスパッチ | 一部(インスタンシングのみ) | indirectDraw、indirectDispatch |
| 非同期 | コールバック型 | Promise 型(マッピング・サブミット) |
| パイプライン状態 | グローバル可変 | RenderPipeline オブジェクト |
| テクスチャ圧縮 | DXT/ETC/ASTC(部分対応) | BC/ETC2/ASTC(GPU 別) |
| デバッグ | Spector.js | Chrome DevTools の WebGPU パネル |
要点は一行。**WebGL は「描画専用」、WebGPU は「描画 + 計算」**。コンピュートシェーダーが入ったことで、ML・シミュレーション・画像後処理・パーティクルがすべて GPU で回るようになった。
性能はどうか。同じシーンを両 API で描画した場合、単純なラスター(ポリゴン描画)は同等だ。CPU オーバーヘッドが下がるぶん、ドローコールが多いほど WebGPU が速い。コンピュート寄り(画像処理・ML 推論)では2〜3倍が一般的。
2章 · ブラウザ対応状況(2026年5月時点)
対応表を整理すると意思決定が早い。
- **Chrome/Edge** - 113+ 安定(2023年4月)。Android でも同様。
- **Firefox** - 121 でデスクトップ既定オン、2025年中に安定化完了。
- **Safari** - 17.4 で macOS・iOS ベータ開始、26(2025年9月 macOS Tahoe と同時)で正式リリース。
- **モバイル** - Chrome Android、Safari iOS 26 ともに既定オン。
フォールバックはシンプル。
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 実装は二択だ。
- **Dawn** - Google 製の C++ ライブラリ。Chromium の WebGPU 実装本体。デスクトップアプリでも同じコードが使える(Skia や Flutter が採用)。
- **wgpu-rs** - Mozilla 製の Rust ライブラリ。Firefox・Servo・Bevy・Veloren などが採用。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 との違いを一行ずつ。
- `@vertex`・`@fragment`・`@compute` - 関数単位でエントリーポイントを示す。1ファイルに頂点とフラグメントを同居させられる。
- `vec3<f32>` - ジェネリック型。整数・浮動小数・符号無し整数を明示する。GLSL の `vec3` のような暗黙の浮動小数は無い。
- `@location(N)` - 入出力スロット。頂点バッファとフラグメント出力の両方で使う。
- `@builtin(position)` - `gl_Position` 相当。
最大の差分は**コンピュートシェーダー**だ。
@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` が推奨レンダラーに昇格した。
最小シーン:
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 の両方にコンパイルする。
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 ツリーとして整理できる。
function Cube() {
return (
)
}
export default function Scene() {
return (
)
}
JSX タグ `mesh`・`boxGeometry` は Three.js のクラス名に対応する。`OrbitControls`・`Environment` は **drei**(Poimandres チームのヘルパー)から来る。drei が無いと R3F は半分の価値だ。
R3F v9 の WebGPU - 非同期 `gl` prop
gl={async (props) => {
const r = new WebGPURenderer(props)
await r.init()
return r
}}
>
{/* ...シーン... */}
R3F v9 が非同期ファクトリを受けるようになったので、WebGPU 初期化が React のライフサイクルに自然に収まる。2026年5月現在、Poimandres チームが積極的に磨き込み中。
R3F エコシステムのヘルパー
- **leva** - GUI(dat.gui の React 版)。
- **zustand** - シーンの状態管理(Redux の代替)。
- **valtio** - もう一つの状態管理。
- **maath** - 3D 数学ヘルパー。
- **react-spring** - アニメーション。
- **drei** - `OrbitControls`・`useGLTF`・`Html`・`Text`・`Sky`・`Sparkles` など。
これらすべてが Poimandres という単一の OSS コレクティブから出ている。個人ではなくチームで作っていることが R3F の大きな強みだ。
7章 · Babylon.js 8 - Microsoft が後援するフルスタック・エンジン
Babylon.js は Three.js と思想が違う。Three.js が「ライブラリ(部品)」なら、Babylon は「エンジン(完成品)」だ。
違いを見ると選択基準が明確になる。
- **インスペクター** - Babylon は最初からビジュアル・インスペクターを内蔵。`scene.debugLayer.show()` の一行でシーングラフ・ライト・マテリアルを GUI で編集できる。
- **物理** - Havok・Cannon・Ammo の統合が標準。
- **WebGPU** - Babylon は2020年から WebGPU をファーストクラスで扱ってきた。シェーダーキャッシュ・自動フォールバック・コンピュートシェーダー API がよく整っている。
- **PBR** - 物理ベース・レンダリングのマテリアルが非常に精密(Unreal や Unity 水準)。
- **Playground** - `playground.babylonjs.com` で即座にコード実行可能。
最小の Babylon シーン:
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` を使う。
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 コンポーネントとして表現する。
R3F の `mesh` の代わりに `TresMesh`、`boxGeometry` の代わりに `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
Three.js の上に Unity のコンポーネント・システムを載せたもの。Unity 側の C# コンポーネント(`Transform`・`MeshRenderer`・`Light`)が glTF 拡張としてシリアライズされ、クライアントの JS コンポーネント(`@needle-tools/engine`)がそれを復元する。
長所: Unity の巨大なアセット・エコシステム(アニメーション・シェーダーグラフ・物理)がそのまま Web に来る。WebXR も込み。短所: Unity が必須(エディタのビルドは約10GB)。
商用ライセンスが切り分けられているので、インディーや小規模チームならほぼ無料。コカ・コーラや LG といった大手のマーケティングサイトでも見かける。
11章 · Wonderland Engine - WebXR 専用
Wonderland はさらに特化型のケース。**WebXR(VR/AR)を最もよく回せるエンジン**だ。
- 独自のビジュアル・エディタ(デスクトップアプリ)。
- 非常に軽量(エンジンコア約500KB)。
- WebXR チューニング: 90fps を目標値とする。
- Meta Quest・Vision Pro のブラウザでほぼネイティブ並みの性能。
VR ゲーム・トレーニング・シミュレータを作るときには Three.js や Babylon より遥かに速い。短所は、一般 3D サイトに使うにはオーバースペック。
12章 · Spline - デザイナー向けの Figma-for-3D
Spline はノーコード陣営。ブラウザ内のデザインツールで 3D シーンを作り、それを React コンポーネントや iframe で埋め込む。
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)付き。
- 2D スプライト・UI・インタラクティブ広告。
- ゲーム UI・HUD オーバーレイ。
- チャート・データ可視化の一部。
`deck.gl`(地理可視化)と PixiJS は両方 Uber の影響圏で始まったが、PixiJS は英国 OSS コミュニティ主導。
14章 · Cesium - 3D 地球・地理情報
地球を描くような巨大シーンを作るときは Cesium。**3D Tiles** 標準(OGC で標準化)を作った当事者でもある。
- Sentinel・NASA・OpenStreetMap データの直接ロード。
- 衛星・ドローン・LiDAR メッシュのストリーミング。
- WebGL 2 ベース、WebGPU バックエンドは作業中。
NVIDIA Omniverse・Unreal Engine と連携する産業向けツール。政府 GIS・国防・都市デジタルツインで標準的に使われる。
15章 · コンピュートシェーダー + ブラウザ ML
WebGPU がもたらした最大の変化は**コンピュート**だ。ブラウザで GPU 計算ができるようになり、ML 推論がクライアントに降りてきた。
TensorFlow.js + 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)が安定化した。
const session = await ort.InferenceSession.create('model.onnx', {
executionProviders: ['webgpu'],
})
const output = await session.run({ input: inputTensor })
Hugging Face のモデルはほとんど ONNX にエクスポートできる。**`transformers.js`**(HF 公式)がこれをラップする。
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 で回す。
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 テクスチャの構成。
- `.gltf` - JSON、分離されたアセットへの参照。
- `.glb` - 単一バイナリ。Web 向け推奨。
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 のシェーダーをゼロから書くのは難しい。次の資源が答えになる。
- **Three.js Shading Language(TSL)** - 上で扱った JS DSL。
- **patapom WGSL collection** - GitHub の WGSL サンプル集。
- **Shadertoy** - GLSL フラグメントシェーダーの本拠地。WGSL ポートも増えている。
- **The Book of Shaders** - Patricio Gonzalez Vivo による無料書籍。
- **WebGPU Samples** - Google 公式。`webgpu.github.io/webgpu-samples`
デバッグツール
- **Chrome DevTools の WebGPU パネル** - Chrome 119 から内蔵。シェーダーソース・パイプライン状態・メモリ使用量を見られる。
- **Spector.js** - WebGL 専用。フレームキャプチャ・ドローコールごとの分析。
- **RenderDoc** - ネイティブ GPU デバッガ。wgpu-rs/Dawn のワークフローで有用。
18章 · ユースケース - どこに何を使うか
- **ポートフォリオサイト / ヒーローセクション** - R3F + drei。Spline も良い。
- **製品コンフィギュレーター(車・家具)** - Three.js または PlayCanvas。PBR が重視されるなら Babylon もよく選ばれる。
- **データ可視化** - deck.gl(地理)、Three.js + カスタムシェーダー(抽象可視化)。
- **ブラウザゲーム** - PlayCanvas、Babylon.js。重ければ Wonderland。
- **AR/VR(WebXR)** - Wonderland Engine、Needle Engine。
- **8thWall 空間 AR** - Niantic 8th Wall プラットフォーム。
- **Unity 資産の再活用** - Needle Engine。
- **2D ゲーム・インタラクティブ広告** - PixiJS 8。
- **地球・地図 3D** - Cesium。
- **ブラウザ ML** - transformers.js + WebGPU、WebLLM。
19章 · クロスプラットフォーム 3D エンジンの Web ターゲット
Web 専用ではない、デスクトップ・モバイルも対象とする大型エンジンも Web をターゲットする。
- **Unity WebGL** - 古いオプション。ビルドサイズが大きい(20MB+)。**Unity WebGPU** が実験的に追加された(2024年)。
- **Unreal Engine - Pixel Streaming** - サーバーでレンダリングして動画でストリーミング。WebRTC ベース。重いシーンをモバイルで見せるとき向き。
- **Godot 4 - Web Export** - WebAssembly + WebGL 2。WebGPU は 4.4 から。
Web ネイティブのエンジン(Three.js・Babylon・PlayCanvas)と比べるとビルドサイズと起動時間が短所。ただし Unity・Unreal にすでに資産があるなら Pixel Streaming が最短経路だ。
20章 · 韓国・日本コミュニティ
Web 3D は英語圏のリソースが圧倒的だが、韓国と日本のコミュニティも急速に育っている。
**韓国**:
- 韓国 WebGL/WebGPU ユーザー会 - Facebook・Discord のグループ。
- Three.js 韓国語翻訳 - `threejs.kr` の非公式翻訳(コミュニティ主導)。
- Toss Frontend - `tossface` と 3D インタラクション、SLASH カンファレンスでの発表多数。
- NAVER FE Talk - Three.js・R3F セッションが定期開催。
**日本**:
- **ICS.media** - 日本最大のフロントエンドマガジン。Three.js・WebGPU チュートリアルが圧倒的に充実。
- **Three.js Tokyo / three.js Japan** - 定期ミートアップ。
- **池田 泰延(Yasunobu Ikeda)** - ICS.media 編集者。Three.js 本の著作多数。
- **WebGL Total** - 日本語の WebGL 入門サイト。
ICS.media は英訳しても遜色ない水準の記事が多い。日本語が苦でなければ頻繁に立ち寄ることを勧める。
21章 · 有名な Three.js サイト
インスピレーションが欲しいなら次のサイトを巡るといい。
- **bruno-simon.com** - Three.js Journey 講師 Bruno Simon のポートフォリオ。サイトを車で運転できる。
- **active-theory.com** - インタラクティブ広告エージェンシー。自社サイトそのものがショーケース。
- **lusion.co** - 英国エージェンシー。Three.js マーケティングサイトの真髄。
- **rafa-marsala / igor-bachelard.com** - 個人ポートフォリオ。
- **threejs.org/examples** - 200+ の公式サンプル。新機能はまずここに入る。
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 になる。
参考資料
- WebGPU 仕様 - `https://www.w3.org/TR/webgpu/`
- WGSL 仕様 - `https://www.w3.org/TR/WGSL/`
- Can I Use WebGPU - `https://caniuse.com/webgpu`
- Three.js - `https://threejs.org/`
- Three.js Journey(Bruno Simon)- `https://threejs-journey.com/`
- TSL ドキュメント - `https://github.com/mrdoob/three.js/wiki/Three.js-Shading-Language`
- React Three Fiber - `https://r3f.docs.pmnd.rs/`
- drei - `https://github.com/pmndrs/drei`
- Poimandres コレクティブ - `https://pmnd.rs/`
- Babylon.js - `https://www.babylonjs.com/`
- Babylon.js Playground - `https://playground.babylonjs.com/`
- PlayCanvas - `https://playcanvas.com/`
- PlayCanvas Engine GitHub - `https://github.com/playcanvas/engine`
- TresJS - `https://tresjs.org/`
- Needle Engine - `https://needle.tools/`
- Wonderland Engine - `https://wonderlandengine.com/`
- Spline - `https://spline.design/`
- PixiJS - `https://pixijs.com/`
- Cesium - `https://cesium.com/`
- glTF 2.0 - `https://www.khronos.org/gltf/`
- gltf-transform - `https://gltf-transform.dev/`
- Basis Universal - `https://github.com/BinomialLLC/basis_universal`
- KTX 2.0 - `https://www.khronos.org/ktx/`
- Dawn(Chromium WebGPU)- `https://dawn.googlesource.com/dawn`
- wgpu-rs - `https://wgpu.rs/`
- TensorFlow.js - `https://www.tensorflow.org/js`
- ONNX Runtime Web - `https://onnxruntime.ai/docs/tutorials/web/`
- transformers.js - `https://huggingface.co/docs/transformers.js/`
- WebLLM(MLC)- `https://webllm.mlc.ai/`
- MediaPipe - `https://developers.google.com/mediapipe`
- WebGPU Samples - `https://webgpu.github.io/webgpu-samples/`
- The Book of Shaders - `https://thebookofshaders.com/`
- Shadertoy - `https://www.shadertoy.com/`
- ICS.media(日本)- `https://ics.media/`
- Khronos glTF Sample Models - `https://github.com/KhronosGroup/glTF-Sample-Assets`
현재 단락 (1/346)
2023年4月、Chrome 113 が WebGPU を既定でオンにしたときは「またひとつの標準争い」に見えた。WebGL 2 は十分に動いていたし、WebGPU は Safari・Firefox ...