WebAssemblyの仕組み ― ブラウザでネイティブ級の速度が出るワケ

代わりというより「補完」だね。JavaScriptは柔軟で書きやすいけど、インタプリタで動くから重い処理は苦手。WebAssembly（略してWasm）はブラウザ上で動くバイナリ命令形式で、ネイティブに近い速度が出るんだ。画像処理や3D、動画編集みたいなCPU集約型の処理に向いているよ。

C、C++、Rustなどのプログラミング言語で書いたコードを、LLVMなどのコンパイラが.wasmファイルに変換するんだ。たとえばRustなら「cargo build --target wasm32-unknown-unknown」でWasmバイナリが生成される。Emscriptenというツールチェーンを使えばC/C++のコードもWasmにコンパイルできるよ。

ブラウザのWasmエンジンが.wasmバイナリを受け取って、まずバリデーション（型チェックなど）を行い、次にネイティブのマシンコードにコンパイルするんだ。このコンパイルが非常に高速なのがポイントで、JavaScriptのように「まずインタプリタで実行→ホットパスだけJITコンパイル」という段階を踏まなくていい。ストリーミングコンパイルといって、ダウンロードしながら同時にコンパイルすることもできるよ。

もちろん！Wasmモジュールはimport/exportの仕組みを持っていて、JavaScriptからWasmの関数を呼んだり、逆にWasmからJavaScriptの関数を呼んだりできるんだ。たとえばFigmaはUI部分をJavaScript（React）で作って、レンダリングエンジンをC++からWasmにコンパイルして使っている。Google EarthもWasmのおかげでプラグインなしでブラウザから3D地球儀が見られるようになったんだよ。

実はWasmはセキュリティにかなり気を使った設計なんだ。サンドボックス内で動作して、直接OSのファイルやネットワークにはアクセスできない。メモリも線形メモリという独立した領域を使うから、ブラウザ本体や他のタブのメモリを覗くこともできないよ。JavaScriptと同じオリジンポリシーも適用されるんだ。

それがWASI（WebAssembly System Interface）だね。ブラウザの外でもWasmを動かすための標準インターフェースで、ファイル読み書きやネットワーク通信などのOS機能に「能力ベース」のセキュリティモデルでアクセスできる。WasmtimeやWasmerといったランタイムを使えば、サーバーサイドでもWasmが動く。Dockerの共同創設者が「もし2008年にWasmとWASIがあったら、Dockerを作る必要はなかった」と言ったのは有名な話だよ。

コンテナより起動が速くてサイズも小さいからね。Cloudflare WorkersやFastly Compute@EdgeではすでにWasmをエッジコンピューティングに使っているよ。さらに最近は「コンポーネントモデル」という仕様が進んでいて、異なる言語で書いたWasmモジュールを型安全に組み合わせられるようになる。GC（ガベージコレクション）プロポーザルも進行中で、これが入るとGoやKotlinのようなGC言語からのコンパイルも効率的になるんだ。

まさにそうだね。Wasmは「ブラウザのための技術」から「ユニバーサルランタイム」に進化しつつある。ブラウザ、サーバー、エッジ、IoTデバイス…どこでも同じバイナリが安全に高速に動く世界を目指しているんだ。「一度コンパイルすればどこでも動く」というJavaの夢を、別の形で実現しようとしているとも言えるね。