🧩 WASI 0.3が正式リリース — サーバーサイドWasmは「コンテナの次」になれるのか

2026年6月11日、WASI 0.3.0が正式リリースされた。日本語圏ではほぼ流れてこなかったニュースだが、サーバーサイドWebAssemblyにとっては数年に一度の節目だ。非同期I/Oが、ようやく仕様の一級市民になった。

WASIはブラウザの外——サーバーやエッジ——でWasmを動かすためのシステムインターフェース群だ。「Wasmはブラウザの技術」という認識のまま止まっている人ほど、この半年の動きは見ておいた方がいい。

0.3で何が変わったか

これまでのWASI 0.2では、非同期処理を start/finish のペア呼び出しで擬似的に表現していた。0.3ではこれを廃止して、async func・stream<T>・future<T> がComponent Modelのネイティブ構文になった。ランタイム側もWasmtime 46でasyncが既定で有効になっている(2月にWasmtime 37でプレビューが先行していた)。

地味に聞こえるが、「HTTPを受けてDBを叩いて返す」という普通のサーバー処理が、仕様の標準機能として書ける状態にやっと到達した、という話だ。

Component Modelという本命

WASI 0.3の土台になっているComponent Modelは、個人的にサーバーサイドWasmの本命だと思っている。WIT(WebAssembly Interface Types)という言語で、コンポーネント間の型付きインターフェースを定義する。

interface cache {
  get: func(key: string) -> option<list<u8>>;
  set: func(key: string, value: list<u8>);
}

このインターフェースさえ合っていれば、Rustで書いたコンポーネントとGoで書いたコンポーネントとJSで書いたコンポーネントを、同一プロセス内で型安全に合成できる。マイクロサービスがネットワーク越しにJSONを投げ合っていた部分が、プロセス内の関数呼び出しに潰れる。リリースノートはサービス間呼び出しのオーバーヘッドが「ミリ秒からナノ秒へ」変わると表現している。

「言語の違うチームの成果物を、コンテナではなく型付きコンポーネントで繋ぐ」——マイクロサービスの反省文としてよくできた設計だ。

で、コンテナは捨てられるのか

捨てられない。現在地を正直に書くとこうなる。

強いのはエッジとFaaSだ。Wasmの起動はコンテナのコールドスタートより桁違いに速く(具体的なミリ秒の数字は二次情報が多いので割愛するが、傾向としては確立している)、Cloudflare WorkersのようなエッジではWasmが日常的に動いている。Shopifyも決済カスタマイズのFunctionsをWasmで実行している。

一方で、汎用バックエンドをまるごと移すには穴が残る。ネイティブなマルチスレッドはまだ仕様に無い。Java・KotlinのようなGC言語はWasmGCで進行中(Kotlinのβ対応など)だが、本番事例はこれからだ。そして各言語のツールチェーンは「開発中」のものが多く、WasmtimeとWasmerで方向性が割れているエコシステムの断片化もある。

つまり「コンテナ代替」は看板としては早くて、実態は**「起動が速くて隔離が強い、エッジ/プラグイン実行の標準」が仕様面で完成に近づいた**、が正確なところだ。

Docker登場のときも、最初の数年は「VMの代替には穴が多い」と言われ続けた。WASI 0.3はその「穴が多い時期」の折り返し地点に見える。自分はまず、WFレビューツールのプラグイン実行あたりで小さく試すつもりだ。あなたの手元で「隔離して動かしたい小さなコード」、ありませんか。そこがたぶん入口です。