FigmaやPhotoshopが、なぜブラウザの中でネイティブアプリ並みの速度で動くのか。答えの多くはWebAssembly(WASM)にある。ブラウザの高速化技術としてひっそり標準化されたこの仕組みは、いまや設計ツールから暗号処理、サーバーサイドのプラグインシステムまで、静かに広い範囲を支えている。
WASMとは何か#
WebAssemblyは、スタックベースの仮想マシン向けに設計されたバイナリ命令フォーマットだ。C・C++・Rust・Go(TinyGo)・AssemblyScriptなど様々な言語のコンパイル先として使え、コンパイル済みのバイナリをほぼネイティブに近い速度で実行できる。2017年に主要ブラウザが足並みを揃えて対応し、その後W3Cの標準として仕様が固まった。JavaScriptを置き換える技術ではなく、JavaScriptから呼び出して使う「もう一つの実行エンジン」という位置づけだ。
サンドボックスという設計#
WASMの核心は、サンドボックス化された実行環境という設計にある。WASMモジュールは自分専用の線形メモリ(linear memory)領域だけにアクセスでき、ホスト環境の任意のメモリ番地やファイルシステムに直接触れることはできない。ホスト側(JavaScriptなど)が明示的に許可した関数だけを呼び出せる仕組みになっており、この制約のおかげで、出所の分からないコードであっても安全に実行できる。ネイティブアプリなら致命的なメモリ破壊バグも、WASMのサンドボックスの外には影響しない。
実際に採用されている場所#
WASMの採用事例は、ブラウザの外にも広がっている。
- Figma: デザインツールの描画エンジンをC++からWASMにコンパイルして提供しており、大規模なファイルでもブラウザ上でネイティブアプリに近い操作感を実現している
- Adobe Photoshop(Web版): 数十年分のC++コードベースをWASMへ移植し、ブラウザだけでレイヤー編集やフィルタ処理を動かしている
- 1Password: ブラウザ拡張の暗号処理コアをRustで書き、WASMとしてブラウザ内で動かしている
- Envoy Proxy: プロキシの拡張機能(WASMフィルタ)としてWASMプラグインシステムを採用しており、Istioのようなサービスメッシュ基盤にも広がっている
- wasmCloud / Wasmtime: コンテナに代わる軽量な実行単位として、サーバーサイドでもWASMランタイムを使う動きが出てきている
いずれも「重い処理をブラウザやサンドボックスの中で安全に、かつ高速に動かしたい」という同じ動機から採用されている点が共通している。仕様そのものはWebAssembly公式サイトで公開されている。
得意なこと、向かないこと#
WASMが力を発揮するのは、CPU負荷の高い計算処理だ。画像・動画のエンコード/デコード、暗号処理、パーサー、圧縮・展開、数値計算といった処理は、JavaScriptのJITコンパイルよりも安定して高速に動く傾向がある。JITは実行時にホットパスを最適化するため実行のたびに速度がばらつくが、WASMは事前にコンパイルされたバイナリを実行するだけなので速度が安定しやすい。
一方で向かない場面もある。ホスト言語側とWASM側でデータをやり取りする際、文字列やオブジェクトのような複雑な構造はそのまま渡せず、線形メモリ上にシリアライズしてコピーする必要がある。小さな処理を頻繁に呼び出すような使い方だと、このコピーのオーバーヘッドが処理本体の速度向上を打ち消してしまうことがある。WASMは「大きな処理を一括で渡して、一括で結果を受け取る」ような使い方と相性が良く、細かい関数呼び出しを何度も行うような使い方には向かない。
まとめ#
WASMは「ブラウザの中だけの高速化技術」ではない。FigmaやPhotoshopのような大規模アプリケーションの移植先として、あるいはEnvoyのようなプラグインシステムの基盤として、静かに実用の範囲を広げている。サンドボックス化された線形メモリモデルのおかげで安全に異言語のコードを持ち込め、CPU負荷の高い処理では安定した速度が出やすい一方、データのやり取りにはコストがかかる——「何でも速くなる魔法」ではなく、向いている処理を見極めて使う技術だと理解しておきたい。
