WebGPUのシェーダーの文法がほぼRustな理由
WebGPUの初学者が最初にぶつかる壁はWGSL（WebGPU Shading Language）の文法の異質さだと思います。
GLSLやHLSLを書いてきた人間からすると、こういうコードを見た瞬間に「なんだこれは」となる。
@vertex
fn vs_main(@location(0) pos: vec3<f32>) -> @builtin(position) vec4<f32> {
return vec4<f32>(pos, 1.0);
}
まんま Rust じゃん。
なぜWebのシェーダー言語がRustの構文を踏襲しているのか。調べれば調べるほど、技術的合理性だけでは説明できない闇が見えてきました。
すべての元凶 -> AppleとKhronosのIP戦争
WGSLは誰も望んでなかった
ここが一番大事なポイントです。
WGSLという言語が存在する最大の理由は、Appleが既存のSPIR-Vを拒否したからです。
SPIR-V（Standard Portable Intermediate Representation）はKhronos Groupが策定したシェーダーのバイナリ中間表現で、Vulkanのエコシステムで広く使われています。
WebGPUの策定初期、GoogleもMozillaも「SPIR-Vのサブセットをそのまま使えばいいのでは？」という立場でした。
ところが、2019年12月9日のW3Cの会議で、Apple WebKitチームのMaciej Stachowiakがこう発言します。
Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can't talk about the substance of this dispute.
（AppleはKhronosのIP枠組みの下で作業することに同意できない。Apple法務とKhronosの間に非公開の紛争があるためだ。紛争の内容について話すことはできない。）
非公開の法的紛争の存在だけで、SPIR-Vの採用は白紙になりました。
Khronos IP フレームワークとは
Khronosの知的財産フレームワークは、仕様を実装する人同士で特許訴訟をしない、という相互不可侵条約のようなものです。
Appleがこれを拒否したということは、Lobste.rsのあるコメンターが指摘したように、「自分たちが望む相手に対して特許訴訟を起こす権利を留保する」ということに他なりません。
紛争の具体的な中身は今も公開されていません。ただ、以下の状況証拠は存在します。
- Appleは2018年にmacOSでOpenGLとOpenCL（いずれもKhronos標準）を非推奨にし、独自のMetal APIへの移行を推進
- AppleはmacOS上でOpenGLのバージョンを4.1で止めており、それ以降のアップデートを一切行っていない
- AppleはどのプラットフォームでもVulkanを実装していない
このAppleの法的ポジションにより、WebGPUのシェーダー言語には3つの制約が課されました。
- テキストベースであること（SPIR-Vのようなバイナリは不可）
- W3Cが所有する単一の仕様書で定義されること（Khronosの仕様を参照不可）
- KhronosのIPに一切依存しないこと
つまり、「新しい言語を作るしかない」状況に追い込まれたわけです。
WHLSL - Appleの失敗した代替案
Metal由来のシェーダー言語
Appleは単にSPIR-Vを拒否しただけでなく、自ら代替案を提示しています。2018年11月、AppleのMyles Maxfieldが WHLSL（Web High-Level Shading Language、通称「ホイッスル」） を提案しました。
WHLSLはMicrosoftのHLSLとのソースレベル互換性を目指した言語で、既存のシェーダーを最小限の変更で移植できることを売りにしていました。加えて、ゼロ初期化や生ポインタの排除など、Web安全性のための機能も盛り込まれていました。
Google・Mozillaからの技術的反論
Googleの反論の核心は ポータビリティ でした。
Appleは出荷するGPUファミリーが数種類しかありません。一方、Chromeはデスクトップ、モバイル、組み込みを含む何千ものハードウェアSKUで動作します。GoogleのCorentin Wallezはこう主張しました。
「このグループが、世界中のすべてのGPUをカバーするセマンティクスを新たに定義できるとは考えていない。SPIR-Vのセマンティクスを基盤にすることが、すべてのGPUアーキテクチャでポータブルに動作する言語を確保する唯一の現実的な方法だ。」
Mozillaも基本的にGoogleと同じ立場でした。
業界からの悲鳴
2019年9月24日、IHV（ハードウェアベンダー）やISV（ソフトウェアベンダー）を交えた会議で、業界側の声はもっと直截でした。
AdobeのEric B.はこう言い放ちました。
「新しい高水準言語を作るのは大罪（cardinal sin）だ。やるな。シェーダーを全部また書き直すなんてまっぴらごめんだ。」
UnityのJesse B.も警告しています。
「HLSLから必要なものにトランスコードできるなら素晴らしい。できないなら、我々はあなたたちのプラットフォームを一切サポートしないかもしれない。」
これらの警告は 結局無視されました。
Tint - Google による打開案
レドモンドでの転換点
WHLSLをめぐる膠着状態は、2020年2月12〜13日、レドモンドでの対面会議でようやく打破されました。GoogleのDan Sinclairが Tint という新しい提案を発表したのです。
Tintの核心的なアイデアはSPIR-Vと全単射（bijective）な関係にあるテキスト言語でした。つまり、すべての有効なプログラムがSPIR-Vとの間で忠実に変換可能であることを保証する。
これは絶妙な落としどころでした。
- Appleが得たもの: W3Cグループが所有するテキスト形式。Khronos IPへの依存なし
- Google・Mozillaが得たもの: SPIR-Vのセマンティクスを基盤とし、全GPUアーキテクチャでのポータビリティを確保
反応は劇的でした。AppleのMyles Maxfieldは「Appleの3つの目標のうち1つを完全に解決する。この言語をこのグループで設計しWebGPUで使うことを提案する。とても嬉しい」と述べました。
MozillaのDzmitry Malyshau（kvark）に至っては「この激しい合意（violent agreement）にショックを受けている」と言っています。
2020年2月24日、この言語は正式に WGSL と命名されました。
TintはGoogleのコンパイラ実装の名前として残りました。
長続きしなかった全単射構想
問題なのは、kvarkが後に書いたように、「言語デザイナーの手が解かれると、彼らは第一原理に突き動かされるようになる」 ことです。
WGSLは厳密なSPIR-Vミラーリングから次第に離れていき、批判者が言うところの「GLSLとRustの奇妙な混合物」へ、支持者が言うところの「モダンで安全でよく定義されたシェーダー言語」へと進化しました。
WGSL に残る Rust の指紋
構文比較：WGSL vs Rust
WGSLのRust影響は広範かつ具体的です。fnキーワード、->による戻り値型の指定、let/varによる不変/可変バインディング、name: Typeの後置型注釈、i32/u32/f32のスカラー型名——すべてRustからの直接的な借用です。
| Feature | WGSL | Rust |
|---|---|---|
| 関数宣言 | fn add(a: f32, b: f32) -> f32 |
fn add(a: f32, b: f32) -> f32 |
| 可変変数 | var x: f32 = 1.0; |
let mut x: f32 = 1.0; |
| 不変バインディング | let x = 5; |
let x = 5; |
| 整数型 |
i32 u32
|
i32 u32
|
| 浮動小数点型 | f32 |
f32 |
| ベクトル型 | vec4<f32> |
N/A |
関数宣言に関しては、WGSLとRustの構文が完全に一致しています。
各構文選択の技術的正当化
それぞれの選択には、一応の技術的理由が付けられています。
fn キーワード: MozillaのJeff Gilbertは会議議事録で「次の文字を見るときに、今見ているものが何であるかが分かっていると、パースが楽になる。コンピュータのパーサーにとっても人間の可読性にとっても」と述べています。C系言語の関数宣言は戻り値型が先頭に来るため、宣言とは関数呼び出しの区別にコンテキストが必要です。fnがあれば曖昧さがない。
後置型注釈（x: f32）: オプショナルな型宣言が可能になり、Cの悪名高い宣言パース問題を回避できます。
明示的ビット幅（f32 vs float）: ハードウェアごとにfloatの意味が異なるクロスプラットフォームのポータビリティバグを防ぎます。
問題は、これらの理由はどれも「Rustの構文を採用する」理由にはなるが、「Rustの構文を採用しなければならない」理由ではないことです。 funcでもfunctionでもfnでも、曖昧さの排除という目的は達成できます。f32という命名も、float32でも同じことです。
個々の判断は合理的だが、それらが集まった結果がRustに酷似するのは、設計者のバックグラウンドの反映に他なりません。
MozillaのRust-WebGPU二重ポジション問題
Rustの生みの親がWebGPU実装も主導
WGSLの設計において、Mozillaは極めてユニークな位置を占めていました。
MozillaはRustの生みの親であり、同時にWebGPUの最重要Rustツールである wgpu（Firefox、Servo、Denoで使用される純RustのWebGPU実装）と Naga（WGSL、GLSL、SPIR-Vを相互変換するシェーダー翻訳ライブラリ）の開発を主導していました。
両プロジェクトのリードエンジニアである Dzmitry Malyshau（kvark） は、Google以外で最もWGSL議論に積極的に参加した人物です。事実上すべてのWGSL会議議事録に名前が登場し、WebGPUのエディターも務めています。
重要なのは、彼がNagaの中間表現をWGSLに非常に近いものとして設計したことです。これにより、WGSLからNagaへの変換は極めて軽量になりました。Mozillaの実装投資は、構造的にWGSLの設計方向と整合するようになっていたのです。
MozillaのJeff Gilbertは、2020年4月14日のWGSL会議で明確に好みを表明しています。
「Cのバックグラウンドがあり、Rustは初心者だが、Rustの型構文の方が好きだ。」
彼はWGSL設計プロセス全体を通じて、後置型注釈、fnキーワード、その他のRust的選択を推進しました。
しかし「Mozillaが単独で操縦」は言い過ぎかも
公平を期すと、Googleの初期Tint提案も最初からRust的構文を使っていました。
Rustの推進者とは考えにくい人物であるAppleのMyles Maxfieldも、WGSLが「モダンな言語」と整合することを認めています。収束は本物でしたが、Mozillaのエコシステムにおけるポジションがそれを増幅したのも確かです。
実装者の怒りを感じる3つのIssue
開発者コミュニティの反発は、gpuweb/gpuwebリポジトリのいくつかのIssueに結晶化しました。
Issue #566 - WGSL is terrible!
2020年2月28日にmisyltoadが起票した、最も炎上したIssueです。
「まるで誰かがRustを見てクールだと思い、SPIR-Vの表現をRust構文で作ろうとしたようだ。」
「vec4<f32>はすぐに古くなる」という冗長さへの攻撃と、「continuingブロックって何だよ。聞いたこともない造語を押し付けるな」という見慣れない構文への困惑が主な論点でした。
核心的な主張は、もし誰もWGSLを手書きしないなら、バイトコード（SPIR-V）の方が厳密に優れている、ということでした。
Issue #593 - Reasoning behind inheriting rust-like syntax
2020年3月5日にYenが起票した、より冷静ながら同様に鋭いIssueです。WGSLとGLSLで同等のフラグメントシェーダーを並べて比較し、WGSLが同一機能により多くのトークンと不慣れな構文を必要とすることを示しました。
起票者はこう指摘しています。
「Rustから継承された構文の冗長さは、WGSLがRust自体の複雑さを持たない以上、明確な目的を果たしていないように見える。」
W3Cグループはこれを2020年3月10日の会議で議論しましたが、最終的にトークン数が最小であることは優先事項ではないと結論づけました。
Issue #570 - SPIR-V support
2020年2月28日にL-asが起票。一言で要約すると「SPIR-Vがあるのに新しい言語を作る必要が分からない」。UnityやAdobeの代表者が数ヶ月前に述べたのと同じ立場です。
Issue #847 - Possibility of SPIR-V and/or GLSL as a WebGPU extension?
SPIR-VやGLSLをWebGPU拡張としてサポートする可能性を求めたこのIssueには、50以上の👍リアクションが付きました。これはコミュニティ感情の最も強い定量的シグナルでした。
さらに2023年1月のIssue #3786では、経験豊富なシェーダー開発者がこう断言しています。
「WGSLは実際の開発者のいかなる実際のニーズも満たすことに失敗する... Unity、Robloxなどは、WGSLを実行可能な提案とは見なしていない。」
SPIR-V論争の全体像
賛成派 vs 反対派の論点整理
SPIR-V問題はW3Cで2年以上にわたり議論されました。Dzmitry Malyshau（kvark）は webgpu-debateリポジトリ でArgdown記法を使い、論証グラフ全体を形式化しています。
SPIR-V賛成派の主要論点（主にGoogle・コミュニティ）：
- 実装対象が小さい（パーサーが不要）
- WebGLを何年も悩ませたパーサーバグを排除できる
- 成熟したバリデーターやオプティマイザのエコシステムが使える
- また別のシェーダー言語を作る必要がない
SPIR-V反対派の主要論点（主にApple）：
- SPIR-Vは低レベルすぎる（制御フローグラフ表現がHLSL/MSLへの変換を困難にする）
- 未定義動作がありWebセキュリティと相容れない
- W3CグループがKhronosの仕様変更に依存してしまう
- Webではテキスト形式が慣例（「ソースを見る」文化）
kvark自身の立場の変遷
面白いのは、kvark自身の立場が時間とともに変化したことです。
NagaのSPIR-Vサポートを何年も実装した後、2021年5月に 「Horrors of SPIR-V」 というブログ記事を公開し、具体的な実装上の悪夢を列挙しました。紛らわしいストレージクラス、壊れたバリデーション、扱いにくい整数符号処理、断片化された仕様……。
彼の結論は、SPIR-V擁護派のコミュニティに反するものでした。
「SPIR-Vフォーマットの擁護者の大半（WGSLを批判するのが好きな人たち）は、SPIRV-Crossに通す以外にSPIR-Vで実際に何かをした経験がほとんどないのではないかと確信するようになった。」
しかし同時に、2021年7月の 「Problems with decision making at W3C」 では標準化プロセス自体を批判し、不明確な目標、偏った調査、Google・Microsoft・Intel間の内部相関が事実上の多数派を形成していること、実装者の賛同の喪失を指摘しています。
WGSLの物語は、彼自身がその解決に貢献しながらも、彼を悩ませ続けました。
仕様を書いたのは？
エディターの顔ぶれ
WGSL仕様の現在のエディターは
- David Neto（Google）
- Alan Baker（Google）
- Mehmet Oguz Derin（独立/Mozilla）
です。過去のエディターには Dan Sinclair（Google）と Myles C. Maxfield（Apple）がいます。
5人中3人がGoogleの所属です。この偏りは注目に値します。
David Neto は間違いなく最も重要な人物です。元KhronosのSPIR-Vワーキンググループ議長であり、シェーダー言語仕様の深い専門知識をWGSLに持ち込みました。SPIR-Vへの貢献を維持しつつWGSLの設計を主導するという二重の役割は、まさにこの妥協——SPIR-Vのセマンティクスを、W3Cが所有するテキスト形式で表現する——を体現しています。
Dan Sinclair は膠着を打破したTint提案を発表した人物。Corentin Wallez（Google）はChromeのWebGPU実装を率い、SPIR-Vセマンティクスに関するGoogleの立場を明確にしました。
Apple側では Myles Maxfield がWHLSLの推進者からWGSLのエディターへ転身し、Robin Morisset がメモリモデルと均一性分析に貢献しました。
構文比較が本当に明らかにすること
頂点シェーダーを並べてみる
修辞を剥ぎ取り、WGSLがどこで伝統から逸脱しているか正確に示すには、コードを並べるのが一番です。
GLSL（従来）：
#version 450
layout(location=0) in vec3 pos;
layout(set=0, binding=0) uniform UBO { mat4 mvp; };
void main() {
gl_Position = mvp * vec4(pos, 1.0);
}
WGSL（現在）：
struct VertexOutput {
@builtin(position) pos: vec4<f32>,
}
@group(0) @binding(0) var<uniform> mvp: mat4x4<f32>;
@vertex
fn vs_main(@location(0) pos: vec3<f32>) -> VertexOutput {
var out: VertexOutput;
out.pos = mvp * vec4<f32>(pos, 1.0);
return out;
}
WGSLバージョンはおよそ2倍の長さで、GLSL、HLSL、Metalのいずれから来た開発者にも馴染みのない構文を使っています。
ジェネリクス型構文という地雷
特に怒りを買ったのが ジェネリクス型構文 です。GLSLがvec4、HLSLがfloat4と書くところを、WGSLはvec4<f32>を要求します。型のパラメータ化を明示的にするという選択ですが、山括弧でコードが散乱します。
執拗な苦情を受けて、委員会は最終的にショートハンドエイリアス（vec4<f32>の代わりにvec4f）を追加しましたが、仕様のカノニカルな表現はジェネリクス形式のままです。
プリプロセッサの不在
#ifdef、#include がない。シェーダー開発者がバリアント管理、機能トグル、コード構成に日常的に使うCプリプロセッサに相当するものが、WGSLには存在しません。
開発者は外部ビルドツールを使うか、コミュニティ主導の WESL（WGSL Enhanced Shading Language） プロジェクト——import、条件付きコンパイル、パッケージングを追加する——を採用するしかありません。
なぜコミュニティはここまで激怒したのか
怒りの深さは、開発者の信頼に対する裏切りという認識に起因しています。
グラフィックスコミュニティは、非公開で、説明もなく、AppleとKhronosの間で行われる企業間の法的紛争が、誰も要求していない言語の創設を強制し、主要な業界プレイヤーの明示的な反対を覆す過程を、リアルタイムで目撃しました。
あるHacker Newsのコメンターが要約したように、「WGSLを望んだ人は誰もいない。これはWebGPUの開発中にAppleを宥めなければならなかったことのアーティファクトに過ぎない。」
皮肉の上塗り
この状況の皮肉は、後の展開でさらに深まります。
2024年、MicrosoftがDirectXにSPIR-Vをインターチェンジフォーマットとして採用すると発表しました。
これにより、SPIR-VはVulkan、DirectX、Metal（SPIRV-Cross経由）——つまり Web以外のあらゆる場所 で普遍的なシェーダーIRとなりました。
さらに、WGSLの創設を強制したApple自身のSafariがWebGPUを出荷したのは 2025年9月のSafari 26 で、Chrome（2023年4月）やFirefox（2025年7月）よりも大幅に遅れました。WGSLの存在理由を作った当事者が、WGSLを使うプラットフォームを最後に出荷したのです。
Web標準の構造的な問題
WGSLの物語は、Web標準の構造的特徴を照らし出しています。
十分な市場支配力を持つ単一のブラウザベンダーは、非技術的な理由で技術的に好ましい解決策を事実上拒否でき、委員会プロセスは合意なしに出荷するのではなく、障害を迂回して新しいものを作る方向に進む。
その結果として生まれるのは、すべての制度的制約を満たす言語です——Webにとって安全で、すべてのブラウザで実装可能で、W3Cが所有する——しかし、実際にそれを書かなければならない開発者をほとんど満足させない言語です。
まとめ：WGSLがRustすぎる原因
WGSLは絶対的な意味では悪い言語ではありません。
安全性の保証は本物で、仕様は厳密であり、wgsl-analyzerのようなツールがオーサリング体験を徐々に改善しています。
- Raph Levienは自身のGPUアクセラレーテッド2DレンダラーVelloをWGSLに移植し、「移植作業は順調に進んだ」と報告しています。
- Bevyゲームエンジンは排他的にWGSLを採用し、RustエコシステムはwgpuとNagaを通じてWGSLを受け入れました。
- Nagaのベンチマークでは、競合するシェーダー翻訳器に比べて 4〜80倍高速 という結果が出ています。
しかし、WGSLを生み出したプロセスは、標準化団体のダイナミクスに関する教訓です。
AppleとKhronosの非公開の企業法的紛争が、より広い開発者コミュニティの好み、UnityやAdobeといった主要プレイヤーの明示的な要求、確立されたエコシステムの技術的優位性を覆しました。そこから生まれたRust的構文は、パーシングと安全性の観点からは擁護可能でしたが、設計プロセスを支配したブラウザベンダー（特にMozillaとGoogle）のエンジニアの制度的嗜好も反映しています。
WGSLと共に生きなければならない開発者たちは、その創造に対して驚くほど少ない影響力しか持ちませんでした。そして、数十の👍リアクションが付いたGitHub Issueとして提出された彼らの抗議は、認知はされましたが、受け入れられはしませんでした。
中心的な教訓はこうです。
Web標準は、そのユーザーの技術的嗜好よりも、その作成者の法的・制度的制約によって形成される。
Discussion
おそらくTypoかと思うのですが、Safari 26のリリースは2025年の9月ではないでしょうか？
ご指摘に感謝です。修正しました。ありがとうございます。
Rustだという指摘は先入観強すぎではと思いました。
Rustのように型推論があるなら、
vec4<f32>(pos, 1.0)ではなくvec4(pos, 1.0)と書くだろうし、return out;はoutと書くでしょう。Rust風に書くなら、vs_main()の中身はで済みます。3行も要りません。
WebGPUは詳しくないですが、どの言語に似ているという議論は全く本質的ではなく、GLSLとWGSLの比較を見るに、WGSLでは
mvpやposなどの変数をグローバルスコープに定義したり、gl_Positionなどの出処不明な変数に書き込む仕様を嫌い、入出力の関係を明確にしたかったのではないですか？