WebAssembly(WebAssembly, Wasm)

1. 概要

A. 定義

WebAssembly(Wasm) は、スタックベースの仮想マシンのための移植可能なバイナリ命令フォーマット(portable binary instruction format) であり、C/C++・Rust・Goなど多様な言語をコンパイルして、ブラウザを含むさまざまな実行環境でネイティブに近い速度で安全に実行するためのW3C標準技術である。

Wasmは「Web上でアセンブリのように高速なコードを動かす」という発想から出発したが、本質は特定の言語やブラウザに依存しないコンパイルターゲット(compilation target) であるという点にある。すなわちWasm自体は人が直接記述する言語というよりも、上位言語がコンパイルされて到達する低水準の中間表現であり配布フォーマットである。テキストフォーマット(WAT)とバイナリフォーマット(.wasm)が1対1で対応し、実際の配布・転送にはパースと検証が速いバイナリフォーマットを用いる。

B. 登場背景と必要性

Web上で計算集約的な処理(画像・映像処理、ゲーム、CAD、暗号演算)を行うには、JavaScriptだけでは性能と予測可能性が不足していた。JavaScriptは動的型付け・JIT最適化に依存するため、実行性能がランタイムの状況によって大きく揺れ動き、パース・最適化のコストも大きい。これを補おうとしたasm.js(JavaScriptの最適化可能なサブセット)の経験を土台に、ブラウザ4社(Google・Mozilla・Microsoft・Apple)が共同で標準バイナリフォーマットを設計したものがWebAssemblyである。

Wasmが必要な理由は三つに要約される。第一に、性能の予測可能性である。すでに型が確定したバイナリコードであるためパースが速く、検証後ただちに機械語へコンパイルされ、ネイティブに近い一貫した性能を発揮する。第二に、言語の多様性である。既存のC/C++・Rust資産をWebへ移植できるため、「Web=JavaScript」という制約を取り払う。第三に、強力な隔離(sandbox) である。線形メモリとケイパビリティ(capability)ベースのインターフェースにより任意のシステム資源にアクセスできないため、信頼できないコードを安全に実行する基盤となる。この第三の特性のおかげで、Wasmは今日ブラウザを超えてサーバーレス・エッジ・プラグインのランタイムへと拡張されている。

2. 実行構造と処理フロー

Wasmの実行は、大きくコンパイル(ビルド)段階とランタイム(ロード・検証・実行)段階に分かれる。以下の図は、上位言語からWasmモジュールが作られて実行されるまでの全体パイプラインを示している。

flowchart LR
  subgraph BUILD["ビルドタイム(開発者環境)"]
    SRC["ソースコード(C/C++/Rust/Go)"] --> FE["フロントエンドコンパイラ(LLVMなど)"]
    FE --> WASM["Wasmモジュール(.wasmバイナリ)"]
  end
  subgraph RUNTIME["ランタイム(ブラウザ/サーバーエンジン)"]
    WASM --> DEC["デコード・構造検証"]
    DEC --> VAL["型検証(静的)"]
    VAL --> COMP["機械語コンパイル(Baseline/最適化JITまたはAOT)"]
    COMP --> INST["インスタンス化(メモリ・インポートの接続)"]
    INST --> EXE["実行(ホストとの関数呼び出しによる相互作用)"]
  end

ビルドタイムでは、上位言語がLLVMのようなコンパイラを経てWasmバイナリモジュールに変換される。このモジュールは関数・グローバル・メモリ・テーブルなどの定義と、ホストから受け取るべきインポート(import)、ホストに公開するエクスポート(export) を宣言する。ランタイムでは、まずバイナリをデコードして構造的に正しいかを検査した後、静的な型検証を行う。この検証段階はWasmのセキュリティの核心であり、実行前にスタックのアンダーフロー/オーバーフロー、型の不一致、範囲外への分岐などをすべて排除する。検証を通過したモジュールだけが機械語にコンパイルされ、エンジンによっては高速な起動のためのベースラインコンパイルと最高性能のための最適化コンパイルを併用(tiering)したり、事前コンパイル(AOT)したりする。

A. スタックベースの仮想マシンと線形メモリ

Wasmはスタックマシンモデルを用いる。各命令はオペランドスタックから値を取り出して演算し、結果を再びスタックに積む。値の型はi32・i64・f32・f64と参照型程度と単純であり、検証とコンパイルが容易である。プログラムが使用するヒープデータは線形メモリ(linear memory) と呼ばれる連続したバイト配列に格納され、このメモリはホストが所有し境界チェックを強制するため、モジュールは自身に許可された領域の外を読み書きできない。以下の図は、Wasmモジュールとホストが相互作用する隔離構造を表している。

flowchart TB
  subgraph HOST["ホスト環境(ブラウザJS / サーバーランタイム)"]
    JS["ホストコード(JS/Go/Rust)"]
    IMP["インポート関数(ファイル・ネットワークなどの能力を提供)"]
  end
  subgraph SANDBOX["Wasmサンドボックス(隔離境界)"]
    MOD["Wasmモジュール"]
    MEM[("線形メモリ(境界チェック)")]
    TAB["関数テーブル"]
    MOD --- MEM
    MOD --- TAB
  end
  JS -->|"エクスポート関数の呼び出し"| MOD
  MOD -->|"インポート呼び出し(許可された能力のみ)"| IMP

この構造の核心は、モジュールはホストが明示的に渡した能力(capability)しか使用できないという点である。ファイルアクセス・ネットワーク・システムコールはすべてインポートとして注入され、注入されなければその機能はそもそも存在しない。この「デフォルトでは何もできない(deny-by-default)」モデルが、Wasmを信頼境界として用いる根拠である。

B. ホストとの相互作用とWASI

ブラウザでは、JavaScript API(WebAssembly.instantiate)を通じてモジュールをロードし、DOM・fetchなどはJSを経由して呼び出す。ブラウザの外(サーバー・エッジ)では標準のシステムインターフェースが必要であり、これを規定したものがWASI(WebAssembly System Interface) である。WASIはファイル・時計・標準入出力のようなOS機能をケイパビリティベース(capability-based) で公開し、例えば特定のディレクトリハンドルだけを渡せば、モジュールはその配下のパスにしかアクセスできない。これにより、コンテナよりも軽量で起動の速い隔離実行単位をつくることができる。

3. 活用類型と事例

Wasmの適用領域は急速に広がっている。代表的な類型を原理とともに整理すると次のとおりである。

具体的な事例として、FigmaはC++で書かれたレンダリングエンジンをWasmにコンパイルし、ブラウザでデスクトップアプリに近い編集性能を実現し、初期読み込み時間を大きく短縮したとされている。サーバー側では、コンテナが通常数百ミリ秒以上かかるコールドスタートを、Wasmランタイムは1ミリ秒程度にまで縮められるため、リクエストごとにインスタンスを新たに立ち上げるエッジコンピューティングに有利である。ただし具体的な数値はワークロード・エンジンによって異なり得るため、一般化して理解するのが安全である。

A. コンテナ・JavaScriptとの比較

Wasmはしばしばコンテナ・JavaScriptの代替と誤解されるが、実際には隔離単位と実行ターゲットとしての性格が異なる。違いが生じる理由は、隔離レベルと起動コストのトレードオフにある。

コンテナは任意のLinuxバイナリと完全なファイルシステムを格納できるため汎用性が高いが、イメージが重く起動が遅い。一方Wasmは、格納できるものが限られる代わりに軽量・高速でアーキテクチャに依存しない。したがって両者は代替関係というよりも、「重い隔離(コンテナ)の中でよりきめ細かなマルチテナント隔離(Wasm)」のように階層的に組み合わされる傾向がある。JavaScriptと比べると、性能の一貫性と言語の自由度が強みであるが、DOMへの直接アクセスがなく、ガベージコレクション言語のサポートがようやく成熟段階に入りつつあるという点を考慮しなければならない。

4. 深掘り — 標準の進化とコンポーネントモデル

Wasmは初期(MVP)以降、複数の拡張を標準化しながら適用範囲を広げてきた。スレッド・SIMDは並列・ベクトル演算の性能を引き上げ、参照型・GCプロポーザルはJava・Kotlin・C#などのマネージド言語を効率的にコンパイルする道を開いた。特に注目すべきはコンポーネントモデル(Component Model) とWIT(WebAssembly Interface Types) である。従来のWasmモジュールはi32・f64のような低水準の値しかやり取りできず、文字列・構造体のような高水準の型を異なる言語のモジュール間で受け渡すのが煩雑であった。コンポーネントモデルはインターフェースを言語中立的に記述し、異なる言語でつくったコンポーネントをレゴのように組み立てられるようにすることで、「言語に関係なく再利用可能な移植可能コンポーネント」という長期ビジョンを具体化する。

こうした流れの上で、WASI Preview 2 はケイパビリティベースのインターフェースをコンポーネントモデルの上に再定義して標準化の軸を移し、サーバーサイドWasmエコシステム(例: サーバーレス関数、拡張プラグインランタイム)の土台となりつつある。標準の詳細は引き続き改訂中であるため、実際の採用時には、使用しようとするエンジンと言語ツールチェーンがどのプロポーザル(proposal)段階をサポートしているかを確認することが重要である。

5. 考慮事項と示唆

技術士の観点では、WebAssemblyの導入は単なる性能最適化を超えて、アーキテクチャ・セキュリティ戦略と噛み合う。

• 適用判断の基準: 計算集約的で言語の移植性が必要なワークロードにWasmは有利である。逆にI/O中心であったり既存のコンテナエコシステムへの依存度が高かったりする場合は利得が限定的であるため、「高速な隔離・マルチテナント・移植性」の要求が明確なときに選択的に導入する。
• セキュリティのトレードオフ: 言語サンドボックスは強力であるが、インポートで渡した能力の範囲がそのまま攻撃対象領域となる。最小権限(deny-by-default)の原則に従って必要な能力だけを注入し、サプライチェーン(モジュールの出所・署名)の検証を併用しなければならない。線形メモリ内部の論理バグ(例: Cコードのメモリエラー)は依然として存在し得ることも認識しておく必要がある。
• 成熟度・エコシステムの展望: DOMへの直接アクセスの欠如、GC言語サポートの成熟途上、デバッグ・ツールの相対的な未整備などは、まだ過渡期の制約である。ただしコンポーネントモデル・WASIの標準化によってサーバー・エッジ・プラグイン領域での採用が加速する傾向にあるため、中長期のロードマップに選択肢として反映するのが合理的である。
• 関連技術の観点: Wasmはサーバーレス・エッジコンピューティング、サービスメッシュ(Envoyフィルタ)、ゼロトラスト(信頼できないコードの隔離)、マルチクラウドの移植性戦略と自然に結びつく。したがって個別技術として見るよりも軽量な隔離実行層というアーキテクチャの軸として理解し、コンテナ・オーケストレーションとの階層的な組み合わせを設計代替案として検討すべきである。

参考資料

• WebAssembly公式サイト: https://webassembly.org/
• W3C WebAssembly Core Specification: https://www.w3.org/TR/wasm-core-2/
• WASI: https://wasi.dev/
• Bytecode Alliance(Component Model): https://bytecodealliance.org/

一言まとめ: WebAssemblyは、多様な言語をコンパイルしてブラウザ・サーバー・エッジでネイティブに近い速度で安全に実行する移植可能なバイナリフォーマットであり、ケイパビリティベースの隔離とコンポーネントモデルを通じて軽量な隔離実行層へと拡張されつつある。