WASMエッジワークロード

コンテナでもVMでもない第三の実行単位

/devops/container-vs-vm/ では、VMはハードウェア層でOSごと隔離し、コンテナはカーネルを共有してプロセス層で隔離する、という二分法を見ました。WASM（WebAssembly）エッジワークロードは、このどちらの系譜にも属しません。実行しているのはOSプロセスではなく、スタックマシン向けに設計されたポータブルなバイトコードです。ホストはforkやclone()でプロセスを起こすのではなく、コンパイル済みモジュールをインスタンス化するだけで実行を開始します。

/devops/oci-runtime-internals/ で見たコンテナ起動は、namespace作成・pivot_root・capability剥奪・execveという重い手順を踏みます。WASMランタイム（Wasmtime、WasmEdge等）はこの手順自体が不要です。バイトコードを検証し、線形メモリ領域を確保し、エントリポイント関数を呼ぶだけ。プロセスもカーネルオブジェクトも新規に作らないため、起動はマイクロ秒〜数ミリ秒に収まります。

隔離の根拠：線形メモリとcapability

WASMの隔離はカーネルのnamespaceではなく、次の2層で成り立ちます。

• 線形メモリのサンドボックス：WASMモジュールが触れるメモリは、ホストが割り当てた連続したバイト配列（線形メモリ）1本だけ。すべてのロード/ストアは実行前に境界チェックされ、範囲外アクセスはトラップで即座に止まります。ポインタは相対オフセットであり、ホストの実アドレス空間を直接指せません。
• WASI（WebAssembly System Interface）によるcapabilityベースの権限：モジュールは既定でファイル・ネットワーク・環境変数に一切アクセスできません。ホスト側が明示的に渡した**capability（ハンドル）**だけを使えます。「このディレクトリだけ」「この1本のソケットだけ」という粒度で権限を絞り込めます。

この2層の効果は、コンテナの隔離モデルと質が異なります。コンテナはカーネルを共有するため、カーネルの脆弱性（権限昇格バグなど）が突かれれば他コンテナやホストに波及し得ます。WASMランタイムは、モジュールが呼べる操作の集合自体をホストが決めるため、攻撃対象領域がホストAPIとして明示的に列挙されるという違いがあります。

エッジで効く三重の制約

CDNエッジやIoTゲートウェイのような場所には、データセンターと違う制約が重なります。

CDNエッジの実行環境（Cloudflare Workers、Fastly Compute等）がWASMを採用してきた理由はこの三重の制約に集約されます。数万テナントのコードを1台の物理ホストに同居させる必要があり、かつリクエストごとの起動遅延を許容できないため、「プロセスを起こさずに済む」実行単位が構造的に有利になります。

何がコンテナ・VMの代替にならないか

WASMが万能の置き換えではない理由も明確です。

• OS依存の機能を前提にしたアプリ：任意のシステムコール、スレッドの完全な制御、既存のネイティブバイナリのそのままの実行は、標準的なWASI環境の対象外です（拡張仕様で徐々に埋まりつつありますが、コンテナと同じ自由度ではありません）。
• 重い計算資源やGPUを長時間占有するワークロード：WASMの利点は軽量な起動と高密度な同居であり、長時間稼働する大規模ジョブでの優位性はコンテナ/VMと大差ありません。
• 既存のLinuxプロセスモデルに強く依存する運用ツール：ログ収集エージェントやカーネルモジュールを前提にした監視は、プロセス／namespaceを前提にしているため、そのままではWASM上に移植できません。

位置づけの整理

VM・コンテナ・WASMは「隔離の強さ」と「起動の軽さ」のトレードオフ上の異なる点に位置します。VMはハードウェア層でOSごと隔離して重く、コンテナはカーネル共有でその中間、WASMはOSプロセスを起こさず線形メモリとcapabilityで隔離してもっとも軽い側に寄ります。三者は置き換え関係ではなく、要求される起動速度・同居密度・隔離モデルに応じて選ぶ選択肢として並立します。エッジのように「多数のテナントを・低遅延で・安全に同居させる」制約が強い場所ほど、WASMが選ばれる理由が具体的に効いてきます。