株式会社オブライト
Web Development2026-04-24

Three.js 2026年版 完全ガイド — WebGPU対応・TSL・React Three Fiberで変わるWeb3D開発の現在地

Three.jsはWeb上で3Dを描画する最大手のオープンソースライブラリです。2026年は、Apple Safari の WebGPU 正式対応を皮切りに、Three.js の WebGPU レンダラーが本番投入できる成熟期に入りました。本記事では、現在の Three.js でできること、TSL(Three Shading Language)、React Three Fiber エコシステム、業務での活用シーン、最新版での注意点までを実務目線で整理します。


Three.js とは — Web で 3D を扱う事実上の標準ライブラリ

Three.js(https://threejs.org)は、Web ブラウザ上で 3D を描画するための JavaScript ライブラリです。2010年に Ricardo Cabello(mrdoob)氏が公開して以来、Web3D の事実上の標準として、ECサイトの製品ビジュアライザー、不動産・建築のVR内見、教育コンテンツ、データ可視化、ゲーム、アート、メタバース系アプリまで、Web上でグラフィックスを扱うほぼあらゆる場面で採用されています。WebGL を直接書くより圧倒的に短いコードで3D表現を扱え、活発なエコシステムと豊富なサンプルが揃っているのが強みです。

2026年 Three.js の最新トピック

2026年 Q2 時点で押さえておくべき変化点: - WebGPU が全主要ブラウザで利用可能に: 2025年9月に Apple が Safari 26 で WebGPU サポートを出荷し、最後のホールドアウトが解消された - WebGPU レンダラーが「ただ動く」状態に: r171 で WebGPU 対応の取り回しが大きく改善され、特別な設定なしで利用でき、未対応環境ではWebGL 2 に自動フォールバック - Compute Shader による GPU並列計算: 衝突判定・大規模パーティクル・ライティング計算などで100万単位の処理が現実的に - r184(2026年3月)でメモリ管理を改善: 毎フレームの不要オブジェクト生成を抑え、複雑シーンで安定したフレームレートを維持しやすくなった 出典は本記事末尾の参考文献参照。

WebGPU 対応で何が変わるか

WebGPU は WebGL の後継規格で、最新のグラフィックスAPI(Vulkan / Metal / Direct3D 12)の能力を Web に持ち込むものです。Three.js から見たメリット: - Compute Shader: 物理シミュレーション、流体、パーティクル、衝突判定などをGPU側で並列化 - より低いCPUオーバーヘッド: 描画コール準備の負荷が WebGL 比で大幅減 - モダンなシェーダ表現: WGSL(WebGPU Shading Language)が標準 業務観点では「同じハードでより重いシーンを安定して動かせる」「カクつきが起きにくい」という改善が直感的に体感できます。一方、新しいレンダラーゆえにエッジケースのバグ・性能リグレッションが特定バージョンで報告されるケースもあるため、本番投入時はリリースノートの確認とパフォーマンス計測を推奨します。

TSL(Three Shading Language)— GLSL/WGSL の二重管理から解放される

Three.js では、シェーダ(GPU側プログラム)を JavaScript の関数合成として書ける TSL(Three Shading Language)が整備されてきました。TSL の本質はノードベースのシェーダ抽象で、書いた1つのシェーダが内部的に WGSL(WebGPU向け)と GLSL(WebGL向け)の双方にコンパイルされます。これまで「WebGL用にGLSLを書き、WebGPU用にWGSLを書き、両方をメンテナンスする」という重複作業からエンジニアを解放する仕組みです。 さらに、ビジュアルエディタ「TSL Graph」のようなノードベースのGUIも整備されつつあり、デザイナーやノンエンジニアでもシェーダ表現を組みやすい方向に進化しています。

React Three Fiber(R3F)と pmndrs エコシステム

React 環境で Three.js を扱う場合、事実上の標準は React Three Fiber(R3F)です。Poimandres(pmndrs)コミュニティが開発・保守しており、Three.js のシーングラフを React コンポーネントツリーとして宣言的に記述できます。エコシステムには次のような周辺ライブラリがあります: - drei: カメラ・ライティング・ローダなどの便利ヘルパー集 - react-three-rapier: 物理エンジン Rapier の R3F バインディング - react-three-postprocessing: ブルーム・DOF・SSAO などのポストプロセス - leva: シーンパラメータの GUI 調整 WebGPU の R3F 対応は2026年 Q2 時点で発展途上の側面があるものの、`gl` prop に WebGPU レンダラーを渡すパターンで実用的に運用できます(公式 README と参考ブログ参照)。Next.js / Remix などのモダンReactスタックと組み合わせやすいのが採用されている理由です。

Loading diagram...

業務での代表的な活用シーン

Three.js が業務で特に効くユースケースを5つ:

領域具体例効果
EC・製品ビジュアライザー家具・自動車・アパレルの360°ビュー、カラーバリ切替返品率低減・滞在時間向上
不動産・建築VR内見、CADモデルのWeb表示、施工進捗3D共有現地訪問の前さばき、遠隔合意形成
教育・研修機械の構造・人体・分子構造の操作可能3D図印象的な記憶定着
データ可視化大規模ネットワーク図、地理空間、IoT センサーマップ2Dでは伝わらない関係性を直感化
体験・ブランドスクロール連動の3D演出、製品発表サイト印象に残るプロモーション

オブライトでも、ECや不動産系のお客様向けに Three.js / R3F ベースの3Dビュアー実装をご相談いただくケースが増えています。

パフォーマンスの実務指針

Web3D 実装でハマりやすいポイントと指針: - ターゲットデバイスを最初に決める: PC専用か、スマホ含むか、ローエンドAndroidまでカバーするかで設計が大きく変わる - 三角形数とドローコール数を計測する: ドローコールは100以下、頂点数は数十万以下を目安に。InstancedMesh / BatchedMesh でドローコールを減らす - テクスチャは KTX2 / Basis 圧縮: 通信量とVRAMを大幅圧縮 - フレーム時間を計測: r3f-perf や stats.js で「重い」原因を見つける - モバイルでは熱暴走にも注意: 60fpsを取れても発熱で勝手にフレームが落ちることがある

始め方 — 最小構成

Three.js 単体で始めるなら: 1. `npm install three` を導入 2. `<canvas>` を用意し、`THREE.WebGPURenderer`(または `THREE.WebGLRenderer`)でレンダラを生成 3. シーン・カメラ・ジオメトリ・マテリアル・ライトを追加 4. アニメーションループで `renderer.render(scene, camera)` を呼ぶ React プロジェクトなら R3F を使った方が圧倒的に楽: 1. `npm install three @react-three/fiber @react-three/drei` 2. `<Canvas>` の中に `<mesh>`、`<directionalLight>` 等のコンポーネントを宣言的に書く 3. drei の `<OrbitControls>` などを足してカメラ操作を即座に有効化 公式ドキュメント・サンプル集(threejs.org)の数が圧倒的に多いため、近い表現を見つけてコピーする学習スタイルが効率的です。

オブライトでの活用方針

オブライトでは、Web 開発・社内システム構築の中で Three.js / React Three Fiber を採用するケースが増えています。WebGPU と TSL の成熟により、これまで「ネイティブアプリじゃないと厳しい」とされていた重めの3D表現が、Webブラウザだけで現実的なフレームレートで動かせるようになってきました。 Web 開発ソフトウェア開発AI 導入コンサルティング の流れの中で、3Dビジュアライズが効くと判断した場面では Three.js ベースで提案しています。実装は弊社の標準ワークフローである DocDD(Document Driven Development) で設計を先に固めてから、Claude Code 等の AI コーディング支援とあわせて短期間で立ち上げるのが定石です。

よくある質問(FAQ)

Q1: WebGL のままでも問題ないですか? A: 既存の WebGL ベース実装を急いで WebGPU に移す必要はありません。新規プロジェクトは WebGPU レンダラー+WebGL自動フォールバックで設計するのが現代的です。 Q2: Three.js と Babylon.js / PlayCanvas はどう違いますか? A: Three.js はライブラリ(自前で組み立てやすい)、Babylon.js はフレームワーク(機能網羅)、PlayCanvas はエディタ込みプラットフォームと、思想が異なります。Web 3D の表現力では Three.js のエコシステム規模が最大級です。 Q3: モバイル端末で動きますか? A: 動きます。ただしGPU性能の差は大きいため、ターゲット端末でのフレーム時間計測とポリゴン削減・LOD(詳細度切替)設計が前提になります。 Q4: TSL を覚える価値はありますか? A: あります。GLSL と WGSL の二重メンテから解放されることのメリットが大きく、ノードベースのワークフローはデザイナとも協業しやすくなります。 Q5: React Three Fiber を使うべき?素のThree.jsを使うべき? A: Reactプロジェクトなら R3F、それ以外(Vue / Svelte / 素のJS)なら直接 Three.js を使います。R3Fは学習曲線がややありますが、コンポーネント分離の恩恵が大きい中〜大規模プロジェクトで効きます。 Q6: AI と組み合わせた事例はありますか? A: テキストプロンプトから3Dシーン生成、Claude / GPT による TSL シェーダ生成支援、3Dアセットの自動配置など、AI コーディング支援との相性は良好です。

参考文献

お気軽にご相談ください

お問い合わせ