Skip to main content
約 1 分Aedifex Team

WebGPU がブラウザベース 3D 設計を高速にする仕組み

WebGPU がコンピュートシェーダー、JavaScript オーバーヘッドの削減、最新 GPU へのアクセス、リアルタイムな部屋レンダリングによってブラウザでの 3D 設計をどう向上させるかを解説します。

ブラウザはもはや軽量な 3D プレビューを表示するだけのものではありません。WebGPU によって、デスクトップのレンダリング API にかなり近い形で最新のグラフィックスハードウェアとやり取りできるようになりました。Aedifex がシーンをインタラクティブに保ったまま素材・家具・照明を更新できるのは、このためです。

簡単な歴史

かつてブラウザでの 3D といえば WebGL のことでした。WebGL は 2011 年頃に Chrome に搭載された OpenGL ES の JavaScript バインディングで、Google Maps の 3D ビューや Tinkercad、SketchUp Free などを実現してきました。しかし、これは常に妥協の産物でした。古い API の上に作られており、その API 自体もベンダー固有のデスクトップ GPU API に対する妥協だったのです。

WebGL の最大の課題は次のとおりです。

  1. シングルスレッドの JS ボトルネック。ほとんどのグラフィックス呼び出しがメインの JS スレッドを経由します。数千個のオブジェクトを含むシーンでは、GPU が本格的に動き出す前にドローコールのオーバーヘッドで処理が詰まってしまいます。
  2. コンピュートシェーダーがない。WebGL 2 でコンピュートに近い機能がいくつか追加されましたが、最新の GPU プログラミングには遠く及びません。
  3. 古いシェーディング言語。GLSL ES 3.0 は 2010 年代のエフェクトには十分でしたが、最新の PBR や複雑な照明を扱うには苦しいものでした。

WebGPU は、Vulkan・Metal・Direct3D 12 から得られた知見を取り入れ、それをブラウザにもたらした再設計の成果です。ブラウザやデバイスによって対応状況が異なるため、MDN では依然として完全な Baseline ではないとされていますが、方向性は明確です。最新の GPU へのアクセスは、もはやウェブプラットフォームの一部なのです。

WebGL にはできなかった WebGPU の 3 つの強み

1. 本物のコンピュートシェーダー

レンダリングだけでなく、汎用的な GPU コードを実行できます。設計エディタにとっては、ライトカリングや空間的なチェック、シーンデータのバッチ処理といったタスクで効いてきます。これまで JavaScript のメインスレッドを圧迫していた処理を、GPU 側に寄せられるのです。

2. マルチスレッドでのコマンド記録

WebGPU は、コマンドバッファやリソースバインディングに対して、レンダリングコードからより明示的に制御できる仕組みを提供します。多数の壁セグメントや家具インスタンスを含む複雑なシーンも、従来の WebGL ループより少ないオブジェクト単位のオーバーヘッドで準備できます。

3. 最新のシェーディング言語(WGSL)

WGSL はウェブのために専用設計された言語です。型安全で検証もしやすく、ドライバレベルの未定義動作(UB)もありません。Aedifex は PBR(物理ベースレンダリング)シェーダーに WGSL を採用しており、これこそが素材プレビューを 2002 年のテレビゲームのようにではなく、本物の素材そっくりに見せている理由です。

Aedifex は WebGPU をどう活用しているか

リアルタイム PBR レンダリング

Aedifex のカタログに収録されたすべての素材には、PBR マップが付属しています。albedo(色)、normal(表面のディテール)、roughness(粗さ=光沢の度合い)、metalness(金属か非金属か)の各マップです。シェーダーはこれらをすべてピクセルごとに Cook-Torrance BRDF を使って評価します。これは V-Ray や Cycles と同じ計算ですが、ワークステーションで 1 フレームに 60 分かけるのではなく、ブラウザ上で毎秒 60 フレームで動いている点が違います。

技術的に興味のある方へ。この種のレンダラーは通常、クラスタード方式やタイルド方式のライト管理、スクリーンスペースエフェクト、テンポラルアンチエイリアシング、そして WGSL で書かれた素材シェーダーを組み合わせています。ただ、ユーザーにとって大事な結果はもっとシンプルです。照明を動かしたり床の素材を変えたりしたときに、即座に反映されたと感じられること、それが重要なのです。

家具のインスタンシング

よくあるリビングルームには、同じモデルの椅子がいくつも置かれています。これらを 1 つずつ別々のオブジェクトとしてレンダリングすると、椅子だけで 4〜8 回のドローコールが発生します。インスタンシングを使えば、4 脚の椅子をまとめて 1 回のコールでレンダリングできます。WebGPU のストレージバッファのおかげでこれをすっきりと実装でき、インスタンスデータを頂点属性にエンコードする必要もありません。

動的なライティング

Aedifex で太陽位置のスライダーをドラッグすると、ライティングがリアルタイムに再計算されます。太陽は、カスケードシャドウマップを備えた指向性ライトとして扱われます。室内のランプも同じくシャドウマップ付きのポイントライトです。各ライトの寄与は、フラグメントシェーダーでピクセルごとに計算されます。WebGL でも基本的なシャドウマップは扱えましたが、数十個ものライトを実用的に管理できるようにしているのは、WebGPU の改良されたバインディングモデルです。

ブラウザに求められること

2026 年時点での WebGPU の対応状況は、本格的なブラウザ 3D に取り組むには十分なほど広がっていますが、それでも機能検出(feature detection)は欠かせません。

  • Chromium 系ブラウザ:現時点で WebGPU が最も成熟している環境です
  • Firefox と Safari:対応は進んでいますが、バージョンやデバイスによる違いは引き続き想定しておくべきです
  • 古いデバイスや管理対象のブラウザ:WebGL へのフォールバックが必要になる場合があります

Aedifex は、まず機能を検出してからレンダラーを選びます。WebGPU が使えないブラウザでも、ユーザーには真っ白なキャンバスではなく、品質を抑えたフォールバックを通してエディタが表示されるようになっています。

ブラウザファーストのツールにとって、なぜこれが重要なのか

5 年前は、ブラウザで本格的な 3D 設計アプリを作るとなれば、WebGL に合わせてビジュアルを妥協するしかありませんでした。今日では、ブラウザベースのツールでも、多くのユーザーが実際に重視するイテレーション規模において、デスクトップツールに匹敵するレンダリング品質を実現できます。

Aedifex がブラウザファーストである理由は、まさにここにあります。Aedifex は、2D のウェブアプリにくっついた静的な 3D ビューアではありません。「インストール不要」と「URL で共有」を、ライブレンダリングを犠牲にせずに両立させた、インタラクティブな設計エディタなのです。

試してみる

お使いのモダンなブラウザでデモを開いてみてください。時間帯を変えると、照明がリアルタイムに更新される様子を確認できます。これが WebGPU の実際に動いている姿です。

ツールの比較はこちら:Aedifex と SketchUp の比較。利用できるツールの一覧はこちら:2026 年版・無料で使える 3D 建築ツール