WASI 0.3

2026年6月12日原文(bytecodealliance.org)

概要

WASI 0.3 が公式リリースされ、 WebAssembly Components でasyncがネイティブ対応
WASI Subgroup がWASI 0.3.0を承認、仕様は安定版として確定
Component Model のasyncプリミティブに基づく新しいABI設計
言語バインディング 生成やマイクロサービス連携が大幅に簡素化
今後、各種ツールチェーンやランタイムで WASI 0.3 サポートが拡大予定

WASI 0.3正式リリースとネイティブAsync対応

WASI 0.3.0 が公式リリース、WebAssembly Component Modelの asyncプリミティブ に基づく設計
仕様が 安定版 となり、今後のプログラム互換性が保証
wasi:io （WASI 0.2で利用されていたpollables、input-streams、output-streams）は、Component Modelの 標準ABI に統合
これにより、 インターフェースの記述や署名が簡素化、ほとんどの変更は機械的なもの
asyncプリミティブ （stream<T>、future<T>、async）がComponent Modelの標準ABIとして導入

Component ModelのAsync ABIとイベントループの統合

WASI 0.2では 各コンポーネントが独自のイベントループ/asyncランタイム を必要とした
WASI 0.3では ホスト側が単一イベントループ を管理し、全コンポーネントで共有
stream<T> と future<T> はリソース型のように所有権を持つハンドルとして動作
ランタイムがスケジューリング を制御し、値がfutureに届いた時点で対応タスクを実行
asyncモデルは完了ベース であり、Linuxのio_uringやWindowsのIOCP/IoRingに類似
async関数のエクスポート/インポート が直接可能となり、WASI 0.2のstart/finish/subscribe手順が不要に

WASI 0.2から0.3へのインターフェース変更

0.2でのasync対応のための複雑な記述が、 0.3ではネイティブasync化により大幅に簡素化
例：
- WASI 0.2 ：resource pollable → WASI 0.3 ：future<T>
- WASI 0.2 ：resource input-stream/output-stream → WASI 0.3 ：stream<u8>
- WASI 0.2 ：pollやsubscribe → WASI 0.3 ：futureへのawaitやasync関数の直接返却
ストリームの状態管理 も改善され、エラーとクローズの区別が容易に

言語バインディングの進化

Component Model により、各言語向けの asyncバインディング生成 が容易に
例： wasi:http/handler インターフェースはasync関数としてRustのtraitにマッピング
- Rustでは wit-bindgen クレートでasync fnとして実装可能
Python、JavaScript、C#、C などでもasync対応バインディングが進行中
Go ではgoroutineによる仮想スレッドで非同期/同期呼び出しの変換が可能
- componentize-go を利用し、HTTPサーバの非同期ストリーミング実装が可能

WASI 0.3でのwasi:httpインターフェースの刷新

wasi:http は機械的な変換だけでなく、 コア抽象の再設計 を実施
wasi:http/service と wasi:http/middleware の2つのworldを提供
- service ：HTTPクライアント/ハンドラの基礎
- middleware ：他のハンドラへリクエストを転送できる拡張
サービスチェイニング が可能となり、 マイクロサービス間の連携が高効率化
- 通信遅延がミリ秒単位からナノ秒単位へと大幅短縮

今後の展望とまとめ

WASI 0.3 は WASI Subgroup の承認を経て安定版リリース
Wasmtime 45/46 や jco など主要ランタイム・ツールチェーンが順次対応
Rust、Go、JavaScript、Python など多様な言語でのサポート拡大見込み
WebAssembly Components の学習には「Wasm Component Model book」が推奨
詳細な変更点 はWASI 0.3.0リリースノートを参照
今後のロードマップ や1.0化の情報は「The Road to Component Model 1.0」で確認可能
コミュニティ主導 による開発、ツールチェーン・ランタイム貢献者やユーザーに感謝
ネイティブasync と コンポーザビリティ が標準となり、あらゆる言語で同じプリミティブが利用可能な新時代の到来

Hackerたちの意見

これには愛憎があるなぁ。どうやってこれに従えばよかったんだ？試してみたけど、ほとんどのことが公に見えなかったのが約2年。最後に確認したのは3月で、進展が全くなかったみたい。だから、wasiv3にはすごく疑いを持ってる。面白いことに、もういくつかの約束（意図的じゃないけど）を実装しちゃったし、カスタム統合を持つ独立したwasmが未来の可能性が高いと思ってる。wasiコンポーネントの約束は果たされてない。市場はアーティファクトを動的にホットロードしてリンクしたいんだよ。wasiプロジェクトはその使い方をするには内部の魔法が必要で、提供されるものは出荷前にコンポーネントを静的にリンクすることになってる。これじゃ99%のユースケースが無駄になっちゃう。影で作業されているのが気に入らない。

└

バージョン0.3だね…

└

このプロジェクトが影で進められているって言うのはちょっと unfair だと思う。俺はCNCFのwasmCloudに関わってるけど、みんながこのコンテンツを提供しようと頑張ってるのを知ってるよ。 - SIGに基づいた定例会議がたくさんあって、全部公開のコミュニティカレンダーに載ってるよ: https://calendar.google.com/calendar/u/0/newembed?src=events... - 専用のZulipもあるし: https://bytecodealliance.zulipchat.com/ - これらのトピックに特化したカンファレンスも開催されてる: Wasm Day、WasmCon、Wasm I/O、Bytecode Alliance Plumbers Summit - CNCFプロジェクト: wasmCloud、Spin - ブログもたくさんあって、録画や要約、トランスクリプトもあるよ: https://bytecodealliance.org/articles/the-road-to-component-..., https://wasmcloud.com/community/, https://spinframework.dev/blog/index もしアーキテクチャの方向性を直接知りたいなら、ルーク・ワグナーの基調講演が一番いいスタート地点だよ: - 「コンポーネントとは何か（そしてなぜ）？」（WasmCon 2023）: https://www.youtube.com/watch?v=tAACYA1Mwv4 - 「コンポーネントへの道」: https://www.youtube.com/watch?v=phodPLY8zNE - 「コンポーネントモデル1.0に向けて」（Wasm I/O 2026）: https://www.youtube.com/watch?v=qq0Auw01tH8 でも、これを言いたいんだ。もっとコンテンツやプロセスをアクセスしやすくするために、他に何を見たい？インスピレーションとして使えるような、うまくやってるコミュニティはある？

└

ランタイムでモジュールをインスタンス化するための問題がオープンになってるよ: https://github.com/WebAssembly/component-model/issues/423

└

WASIコンポーネントの約束は果たされていない。市場はアーティファクトを動的にホットロードしてリンクしたいと思っている。WASIプロジェクトは、そのように使うためには内部の魔法が必要だ：提供されるのは、出荷前にコンポーネントを静的にリンクすることだ。99%のユースケースを無駄にしている。私は、このスペクトルの両端（片方は、モノリシックな単一ソースプロジェクト内でのWASIコンポーネントの完全な静的リンク；もう片方は、ランタイムでの動的コンパイル+リンク+ロード+「ホットインスタンス化」）の両方に対して「ストローマン」だと思う。これらの端に対する「本当の」ユースケースは比較的少ない。誰もがWASIを使いたいと思っているもののほとんどは（私が見たユースケースから判断する限り）、この二つのポイントの中間に近いものだ。やや動的でモジュラーだけど、JITコンパイルやコンポーネントがコンポーネントを取得すること、ホットコンポーネントのインスタンス化、動的リフレクションなどは行われていない。具体的には、WASIの「ポイント」は（私の意見や、私が話したほとんどの人の意見では）、具体的な「プラグイン可能なランタイム」システムがプラグインサポートSDKを実装するためのメタスタンダード（ツールを含む）として機能することなんだ。そういった「プラグインエコシステム」では、すべての「プラグイン」（WASIコンポーネント）は同じ形をしている（つまり、同じエンドポイントを公開し、同じ能力を期待する）。だから、ホストランタイムとそのプラグインは、その形に対して事前にコンパイルできる（別々のプロジェクトで！）。そして、プラグインホストは、ランタイムで任意のWASMコンポーネントを事前に焼き込まれたプラグイン「スロット」にロードできるんだ。なぜなら、動的なものや内省、リフレクション、コンポーネントフレームワークのサポートは必要ないからだ。プラグインホスト自体はコンポーネントではなく、普通のホストランタイムコードなんだ。コンポーネントフレームワークがコンポーネントをロードするのではなく、ホストランタイムがそれを行う。などなど。ある意味で、これはあなたが話していた「カスタムバインディング」だ。でも、それはWASI仕様のターゲットに対するカスタムバインディングなんだ。それが、異なるプラグインがホストの視点から同じプラグイン「スロット」内でランタイムで交換可能になることを可能にするんだ。（従来の「プラグインは特定のシンボルをエクスポートするDLLに過ぎない」というアプローチとは異なり、サンドボックス化を無料で提供することになる。）WASIは、プラグインホストがコンポーネントのコンパイル/リンク時に求めるすべての作業を行うんだ：プラグインが期待されるABIの形であることを確認し、サンドボックス化を保証する（WASIコンポーネントが本質的に抽象マシンの下でアイソレートとして

過去にWASIを使ったことがあるなら、どんなユースケースだったか教えてくれない？他のサンドボックス、例えばコンテナやVMと比べて、何か優位性を感じたかすごく気になる。

└

プラグインシステムでソフトウェアを拡張すること

└

農村のエッジファームシステム

└

https://extism.orgをいじってみたけど、基本的なユースケースは、別のプログラミング言語でソフトウェアを拡張できるけど、クライアントにコンテナやVMをセットアップする必要がないってこと。彼らは「ただ」ブラウザでコードを実行するんだ。もちろんJavaScriptでもいいけど、PythonやGo、何でもあり。かなり特定のことだけど、ブラウザでプログラミングをサポートすることに取り組んでるから。特定のユーザーに拡張させることに深く関わってないなら、たぶんオーバーキルだね。それでも、すごくニッチなもので、同時に以下の条件を満たさなきゃいけない： - プログラミング言語に対して意見が強い人（知識が多すぎる専門家か、逆に少なすぎる初心者） - 既存のシステムの上に何かを作りたいと思うほど熱心な人 - あなたが言ったような解決策に煩わされたくない人

└

VSCodeのようなWASMベースの拡張のマーケットプレイスで自分のRustバイナリを拡張すること

└

WASIのベストな使用例はZigコンパイラだと思う: https://ziglang.org/news/goodbye-cpp/

└

プロセス内でのサンドボックス化されたLLM生成コードの実行。DockerやマイクロVMを立ち上げるよりも、かなり軽量で、起動も速い（事前コンパイルを前提にすれば）。

Hacker Newsで議論の続きを見る

ハクソク