WASIとは｜WebAssemblyをブラウザ外で動かすシステムインターフェース【2026年版】

WASI（WebAssembly System Interface）は、WebAssembly（Wasm）で作ったプログラムを、ブラウザの外でファイルやネットワーク、時刻、環境変数といったOS機能に触れさせるための標準インターフェース仕様です。Wasm単体には「計算はできるが外部のリソースに手が届かない」という制約があり、その穴を埋めるのがWASIです。この記事で扱うのは、WASI 0.1（Preview 1）から0.2、そして2026年6月にリリースされた0.3までのバージョン差、Wasmtimeやwasi-sdkを使った最小ビルド手順、そしてコンテナやFaaSとどう使い分け、業務システムのどこで採用しどこで見送るかまでを、実装者の視点でたどります。wasm-wasiの関係、wasi-sdkの位置づけ、emscriptenとの違いも合わせて整理します。

まとめ｜WASIはWebAssemblyをブラウザ外へ広げる標準システムIF

WASIは、Wasmバイナリに対して「どのファイルへ、どのネットワーク先へ触ってよいか」をホスト側が明示的に渡す、ケイパビリティベースのシステムインターフェースです。ブラウザのJavaScript連携が担っていた領域を、サーバー・CLI・エッジ・組み込みへ広げます。現時点で押さえるべき軸は3つです。第一に、実務で使われているABIは大きく分けて0.1系（wasi_snapshot_preview1）と0.2系（Component Model採用）で、性格が異なります。第二に、2026年6月にリリースされた0.3系はnative asyncを取り込み、非同期I/Oの書き味が変わりました。第三に、採用の当たり所はプラグイン実行基盤・エッジ/サーバーレス・多言語サンドボックスであり、成熟したコンテナ運用をそのまま置き換える技術ではありません。

まず動かすなら、ランタイムはWasmtime、C系はwasi-sdk、Rustはwasm32-wasip2ターゲットが最短の入口になります。業務システムへの組み込みを検討する段階では、0.2系を土台に据えつつ0.3系の非同期対応をどこまで前提にするかを設計時点で決めておくと、後戻りが小さく済みます。

WASIが埋めるWebAssembly単体では届かないシステム連携の穴

WebAssemblyは、CやRustなどをコンパイルして高速に実行できる可搬なバイナリ形式です。ただしWasmの命令セットそのものには、ファイルを開く・ソケットを張る・時計を読むといったOSへの入口がありません。ブラウザ内ではJavaScript経由でこれを補いますが、ブラウザの外ではその橋渡し役が標準化されていませんでした。WASIは、この「Wasmと外部世界のあいだ」を仕様として定義します。

WASIが標準化するファイル・ソケット・時刻・環境変数のケイパビリティ

WASIが規定するのは、ファイルシステム、ソケット（TCP/UDP）、時刻（モノトニック・実時間）、乱数、環境変数、標準入出力といったリソースへの触り方です。特徴は、これらをグローバルに開放せず、ホストが明示的に渡した範囲だけを見せる設計にあります。たとえばプログラムに特定ディレクトリだけを与え、それ以外のパスには触らせない、という制御が仕様レベルで前提になっています。0.2系以降はこれらのインターフェースがWIT（Wasm Interface Type）で記述され、HTTPクライアント/サーバー（wasi-http）やソケット（wasi-sockets）、キーバリューストアなど、扱える範囲が広がりました。

ブラウザWASMとの役割分担とwasm-bindgenが担う領域

ブラウザ内のWasmは、DOM操作や描画といったWeb APIへJavaScript経由でアクセスします。RustならwasmーbindgenやwasmーpackがそのグルーコードとJS連携を生成し、Wasmとブラウザの間を取り持ちます。WASIはこの領域とは重なりません。担当は「ブラウザの外」で、CLIツール、サーバーサイド関数、エッジワーカー、プラグインといった実行環境です。裏返せば、ブラウザ内で完結するUI処理にWASIは要りません。JavaScriptとの連携でWasmを動かす構成については、WebAssemblyとJavaScriptの連携方法を土台にすると、WASIが受け持つ範囲との線引きが掴みやすくなります。

POSIX・CloudABIを源流とするケイパビリティベース設計

WASIの設計はPOSIXの発想を引き継ぎつつ、CloudABIのケイパビリティモデルを強く取り込んでいます。POSIXの多くのシステムコールは、プロセスが暗黙にファイルシステム全体やネットワークへ触れられる前提でした。WASIはこれを反転させ、渡されたハンドル（ケイパビリティ）に紐づく範囲しか操作できない形にしています。この違いが、Wasmを信頼できないコードのサンドボックスとして扱える根拠です。実行時にホストが権限を絞れるため、プラグインやユーザー投稿コードを比較的安全に走らせる土台として機能します。

WASI 0.1から0.2・0.3へと続くバージョン系譜と実装差

WASIは単調に積み上がってきたのではなく、途中でアーキテクチャを組み替えています。実装者がまず知っておくべきは、0.1系と0.2系のあいだに大きな断絶がある点です。この節ではPreview 1（0.1系）、Preview 2（0.2系）、そして2026年に登場した0.3系の性格差を、非断定の時点付きで整理します。

WASI 0.1（wasi_snapshot_preview1）とツールチェーン現況

0.1系はwasi_snapshot_preview1という名前で知られるスナップショットABIです。関数を素朴に並べたフラットなインターフェースで、多くのコンパイラやwasm32-wasip1ターゲットが長く対応してきました。2026年時点でも、既存のツールチェーンや配布物の互換基盤として0.1系は広く残っています。新規に本格採用する土台としては後述の0.2系が中心になりますが、手元でとりあえずビルドが通る状態を作るなら、まだ0.1系のパスに出会う場面は少なくありません。歴史的資産として無視できない層と捉えると扱いを誤りません。

WASI 0.2が導入したComponent Modelとwasi-http

0.2系（Preview 2）は2024年1月にBytecode Allianceがローンチした版で、WASIの土台をComponent Modelへ載せ替えました。ここでインターフェースはWITで型付けされ、言語をまたいだコンポーネント同士を型安全に組み合わせられるようになっています。追加された代表格が、HTTPを扱うwasi-http、TCP/UDPを扱うwasi-sockets、キーバリューストア、そしてWITで書き直されたファイルシステムや時計のインターフェースです。Wasmtime・Spin・wasmCloudといった主要ランタイムが0.2系を実装しており、2026年時点で新規に設計するなら、この0.2系を基準線に置くのが妥当です。

WASI 0.3のnative asyncとstream/futureがもたらす変化

0.3系は2026年6月に0.3.0がリリースされた版で、Component Modelにネイティブの非同期を取り込みました。具体的にはasync func、stream、futureという非同期プリミティブが加わり、0.2系のインターフェースがこれらを前提に組み直されています。0.2系では非同期処理を各ランタイム流儀で回避していましたが、0.3系では並行I/Oを言語のasync構文に寄せて書ける点が変化です。ランタイム側の対応は進行中で、2026年7月時点ではWasmtimeの新しめの系列（43系以降）が0.3系を扱い、既定で有効化する版が続く見込みとして案内されています。本番採用の基準としては、まだ0.2系を土台に、0.3系は前提にできる範囲を見極める段階です。

Wasmtime・jco・wasi-sdk・wasi-libcの対応状況

実装を支える周辺の駒も押さえておくと選定が速くなります。ランタイムの代表はWasmtimeで、0.2系を安定して実行し、0.3系の取り込みも先行する位置づけです。JavaScript側からコンポーネントを扱うjcoは0.3系まで追随しています。C/C++のビルドにはwasi-sdk（Clangとsysrootの一式）を使い、その土台となる標準Cライブラリがwasi-libcです。下の対応関係を目安にすると、どの駒をどの版に合わせるかの見通しが立ちます。

版が混在するため、まず「どのランタイムのどの系列を本番に置くか」を先に固定し、そこからSDKとターゲットを逆算すると、対応表の食い違いに振り回されずに済みます。

WASIアプリを最小構成でビルドして実行するツール選定と手順

仕様の話が続いたので、ここからは手を動かす側に寄せます。最小構成でWASIバイナリを作り、ホストから権限を渡して走らせるまでの流れを、言語別の入口とともに示します。コマンドの網羅ではなく、どの駒がどこで効くかの地図として読んでください。

wasi-sdkでC/C++を、wasm32-wasip2でRustをビルドする流れ

C/C++なら、wasiーsdkに同梱のClangでソースをコンパイルし、ターゲットにwasm32ーwasip1またはwasm32ーwasip2を指定します。sysrootにwasiーlibcが入っているため、標準ライブラリ関数もそのまま通る構成です。Rustなら手順はさらに短く、次の順で進みます。

1. rustupでコンポーネント対応ターゲットを追加する（wasm32ーwasip2）。
2. cargo buildで対象ターゲットを指定し、コンポーネント形式の成果物を得る。
3. 生成物をランタイムに渡して実行し、権限の受け渡しを確認する。

0.2系のコンポーネントを出す場合、Rustはwasm32ーwasip2ターゲットが対応します。0.1系止まりで良ければwasm32ーwasip1でも動きますが、新規に組むなら0.2系のp2を起点にするほうが後の拡張が楽です。

Wasmtimeでの実行と–dirによるケイパビリティ付与

できあがったWasmを走らせる最短路がWasmtimeです。素で実行するとファイルにもネットワークにも触れません。触らせたい範囲だけをフラグで明示的に渡します。たとえばホストのディレクトリを見せるなら--dirで対象パスを指定し、環境変数を渡すなら--envで個別に注入します。この「既定は不許可、渡した分だけ許可」という挙動が、WASIのケイパビリティ設計がコマンドラインに現れた姿です。運用では、本番で渡す権限を最小に保ち、必要になった時点で1つずつ足す進め方が安全側に倒せます。

emscripten対WASI：ブラウザ配布かサーバー実行かの分岐

CやC++をWasmにする経路には、emscriptenという長く使われてきた選択肢もあります。両者は競合ではなく、出口の違いです。emscriptenはブラウザ配布を主眼に、JavaScriptのグルーやWeb API連携、既存Cライブラリのブラウザ移植を得意とします。WASIはブラウザ外のCLI・サーバー・エッジで、標準化されたシステムIFに沿って動かすための道です。判断はシンプルで、成果物がブラウザで動くならemscripten、ブラウザの外でOS機能に触れるならWASIが軸になります。同じC資産でも、届け先で選ぶ経路が変わると捉えると迷いません。

業務システム開発でWASIを採用すべき場面と見送るべき境界線

ここは競合解説が手薄な、採用判断の章です。WASIは可搬性とサンドボックス性に強みがある一方、まだ仕様が版ごとに動いています。業務システムに持ち込むなら、当たる場面と外す場面を先に線引きするのが得策です。後の作り直しを避けられます。結論から言い切ります。

採用が効く条件：プラグイン基盤・エッジ・多言語サンドボックス

WASIが効くのは、次の性質が要件に含まれる場面です。第一に、ユーザーやサードパーティのコードを自社基盤で安全に走らせたいプラグイン実行基盤。ケイパビリティで権限を絞れるため、信頼しきれないコードの隔離に向きます。第二に、起動が速く分散配置しやすいエッジ/サーバーレス実行。コンテナより軽い起動が生きます。第三に、複数言語で書いた部品を型付きで組み合わせたい多言語サンドボックス。Component ModelとWITがこの合成を支えます。サーバーレス側でWasmを走らせる発想の下地は、サーバーレスアーキテクチャとWebAssemblyの相乗効果にも通じます。

見送るべき場面：ブラウザ完結・成熟コンテナ運用・0.3全面依存

逆に、次の場面では今のWASIを主役に据えません。ブラウザ内で完結するUI処理は、WASIの担当外です。ここで無理にWASIを持ち込むと、JS連携で済む話を複雑にするだけに終わります。すでにコンテナで安定運用が回っている基盤を、WASIへ全面移行するのも見送りが妥当です。エコシステムの厚みは成熟したコンテナ側が上で、置き換えの利得より移行コストが勝ちます。そして、0.3系のnative asyncを前提にした設計を今すぐ本番の必須要件にするのも早計です。ランタイム対応が広がりきる前に依存を固めると、運用開始後に足をすくわれます。サーバーレスの向き不向きそのものを比較したい場合は、概念側のサーバーレスとはを先に押さえると、WASIを持ち込む前提が整理できます。

コンテナ・FaaSとの使い分けと段階的に移行するときの判断軸

コンテナ、FaaS、WASIは対立ではなく層が違います。判断軸は「隔離の粒度」と「起動の速さ」、そして「エコシステムの成熟度」です。長時間動くステートフルなサービスや、既存資産の厚みが要るワークロードはコンテナが手堅い。イベント駆動の短命処理はFaaSが噛み合い、そこへ軽量サンドボックスとしてWASIを差し込む余地があります。移行するなら、まず1つのプラグイン境界やエッジ関数をWASI化し、権限付与と可搬性の手応えを測ってから範囲を広げる進め方が安全です。こうしたWasmランタイムの内製導入や、既存システムへの組み込み設計を具体化する段階では、Webシステム開発の受託として要件整理から一緒に踏み込めます。

よくある質問

WASIの版差やツール選定でつまずきやすい点を、実装者が実際に検索する疑問の形でまとめます。

WASIとWebAssemblyは何が違いますか？

WebAssemblyは可搬な実行バイナリの形式そのものを指し、計算を高速に走らせる器です。WASIはそのWasmが、ブラウザの外でファイルやネットワーク、時刻といったシステム機能に触れるための標準インターフェース仕様を指します。器がWasm、器の外との触り方の取り決めがWASI、という関係です。

WASIのPreview 1とPreview 2はどちらを使うべきですか？

新規に設計するなら0.2系（Preview 2）を土台にするのが妥当です。0.2系はComponent ModelとWITで型付けされ、wasi-httpやwasi-socketsなど扱える範囲が広がっています。0.1系（wasi_snapshot_preview1）は既存ツールチェーンや配布物の互換基盤として残っており、手元でビルドを通す際に出会う場面はまだあります。

WASI 0.3では何が変わりましたか？

2026年6月にリリースされた0.3系は、Component Modelにネイティブの非同期を取り込みました。async funcやstream、futureといった非同期プリミティブが加わり、並行I/Oを言語のasync構文に寄せて書けます。ランタイム対応は進行中のため、本番では0.2系を基準に、0.3系を前提にできる範囲を見極める段階です。

WASIとDockerコンテナは競合しますか？

全面的な競合ではなく、隔離の粒度と起動の軽さで層が分かれます。長時間動くサービスや既存資産の厚みが要る処理はコンテナが手堅く、プラグイン隔離やエッジの短命処理では軽量なWASIが噛み合います。成熟したコンテナ運用をそのまま置き換える技術ではない、と捉えると判断を誤りません。

WASIアプリを動かすランタイムは何を選べばよいですか？

入口としてはWasmtimeが扱いやすく、0.2系を安定して実行し0.3系の取り込みも先行しています。C/C++のビルドにはwasi-sdk、標準ライブラリの土台はwasi-libc、JavaScriptからコンポーネントを扱うならjcoという対応です。まず本番に置くランタイムの系列を固定し、そこからSDKとターゲットを逆算すると選定が安定します。

関連記事

• クラウドネイティブとは：WASIが噛み合うエッジ/サーバーレス実行を含む、クラウド前提の開発全体像を掴めます。
• FaaSとは：短命なイベント駆動処理の実行モデル。WASIを軽量サンドボックスとして差し込む文脈の理解に役立ちます。
• コンテナとは：WASIと層が分かれるコンテナの基礎。使い分けの前提として押さえておけます。