WebAssembly はブラウザを出た - Component Model と WASI で何が変わったか 2026年版
WebAssembly（Wasm）は長らく「ブラウザで重い処理を速く動かすための技術」でした。Figma や Photoshop の Web 版を支える縁の下の力持ち、という位置づけです。
2026年、その立ち位置が大きく変わりました。Wasm はブラウザの外——サーバ、エッジ、データベース組み込みへと広がり、「安全で可搬な、多言語対応の普遍ランタイム」になりつつあります。「Docker が約束して完全には果たせなかったもの」と評されることもあります。
この記事では、その転換を支える3つの柱——Wasm 3.0・Component Model・WASI——を整理し、2026年の現在地をまとめます。
まず土台: WebAssembly 3.0（2025年9月標準化）
2025年9月17日、WebAssembly 3.0 が標準化されました。数年がかりの大型アップデートで、Wasm を「ブラウザの外でも本気で使える」基盤に押し上げる機能が揃いました。主なものです。
| 機能 | 内容 |
|---|---|
| 64bit アドレス空間（Memory64） | メモリ上限を 4GB から大幅拡張（Web実装では16GBまで） |
| ガベージコレクション（WasmGC） | ランタイム管理のメモリ。構造体・配列の低レベル基盤を提供 |
| 例外処理 | tag ベースの native な例外（throw / 選択的 catch） |
| 末尾呼び出し（Tail Calls） | スタックを消費しない関数呼び出し |
| 型付き参照 / 部分型 | より豊かな型システム。安全な間接呼び出し（call_ref） |
| 複数メモリ | 1モジュールが複数のメモリを宣言・参照 |
| Relaxed SIMD | プラットフォーム固有の最適化を許容する SIMD |
とくに大きいのがWasmGCです。GC がランタイム側に入ったことで、Kotlin・Java・Dart・Scala のような「GC を前提とする言語」が Wasm に素直に乗れるようになりました。これまで Wasm は Rust や C/C++ のような「自前でメモリ管理する言語」が中心でしたが、対応言語の裾野が一気に広がりました。
Component Model: 多言語を「高レベルIF」で合成する
Wasm をブラウザの外で実用にする最大の鍵が Component Model です。
従来の Wasm モジュールは、関数の入出力が基本的に数値とメモリ（生のポインタ）しか扱えず、言語をまたいで部品を組み合わせるのが困難でした。Component Model は、ここに高レベルのインターフェースを導入します。
その記述に使うのが WIT（WebAssembly Interface Types）です。WIT でコンポーネントの API を定義すると、文字列・レコード・リストといった高レベルな型でやり取りでき、生のメモリポインタを介さずに部品同士が会話できます。
これにより、2026年には次のような開発が現実になりました。
ビジネスロジックを Rust で、データ処理モジュールを Python で、グルーコードを JavaScript で書き、それぞれを Wasm コンポーネントとしてコンパイルして、WIT という高レベルIFで合成する。
「言語ごとに得意な部分を書いて、後で部品として組み合わせる」——マイクロサービスを、ネットワーク越しではなく1プロセス内のコンポーネント合成で実現するイメージです。Rust 中心だったエコシステムが、WasmGC と合わせて多言語へ開かれていく流れと噛み合っています（Rust 製の Bun や Go 製の TypeScript コンパイラのように、「ネイティブ言語で速い基盤を作る」潮流とも地続きです）。
WASI: Wasm に「OS の機能」を与える
ブラウザの外で動くには、ファイル・ネットワーク・時刻といったシステムへのアクセスが必要です。それを標準化するのが WASI（WebAssembly System Interface）です。
2026年時点のステータスを正確に整理します。
| バージョン | 状況 |
|---|---|
| WASI Preview 2（0.2系） | 安定。Component Model ベースの WIT 定義群。現行の実用ターゲット |
| WASI 0.3 | ネイティブ非同期I/O を目標に2026年2月ターゲット（言語統合的な並行処理） |
| WASI 1.0 | 2026年末〜2027年初頭が想定 |
NOTE
「WASI が安定した」と語られるとき、その実体は Preview 2（0.2系）です。0.3（非同期I/O）や 1.0 はこれからの段階で、時期は前後し得ます。本記事の時期はあくまで現時点での目標であり、最新は WASI / Bytecode Alliance の公式情報で確認してください。
ランタイムとしては Bytecode Alliance の Wasmtime（2026年5月時点で v45 系）が WASI と Component Model を実装し、リファレンス実装的な役割を担っています。
何に使われているのか（2026年の本番事例）
「ブラウザを出た」と言っても抽象的なので、実際の使われ方を挙げます。
- エッジコンピューティング（ブレイクアウト用途）: Cloudflare Workers が330以上の拠点で Wasm を実行。Akamai は Fermyon を買収しエッジ展開を強化
- サーバーレス関数: Wasm のコールドスタートは約0.5ミリ秒級と、従来型（数百ミリ秒）に比べ桁違いに速い
- ブラウザアプリ（従来からの本丸）: Figma はロード時間を約3分の1に短縮。Google Maps/Sheets、Adobe Photoshop も Wasm を活用
エッジやサーバーレスで効くのは、Wasm の起動の速さとサンドボックスによる安全な隔離です。コンテナより軽く、起動が速く、言語を選ばない——この性質が「多数の小さな処理を、信頼境界をまたいで安全に動かす」エッジの要件にはまっています。
なお、Chrome のページロードのうち約5.5%（2025年）で Wasm が使われているという調査もあります。明示的に .wasm を読む sites はごく一部なので、多くは「気づかないうちに Wasm の恩恵を受けている」状態です。
開発者視点での読みどころ
- 言語の壁が下がった: WasmGC で Kotlin/Java/Dart/Scala 等が乗れるように。Component Model + WIT で多言語の部品合成が現実的に
- デプロイ先が広がった: 同じ Wasm バイナリを、ブラウザ・エッジ・サーバ・DB組み込みで動かせる。「一度書いてどこでも安全に動く」がコンテナより軽量に
- プラグイン基盤として強い: サンドボックス＋言語非依存なので、アプリの拡張機構（プラグイン）を安全に作れる。信頼できないコードを隔離して動かす用途と好相性
- まだ発展途上の部分もある: Component Model や WASI 0.3 / 1.0 は本格普及がこれからの「ウォッチ項目」。本番投入時はランタイムと対応状況を必ず確認する
まとめ
- 2025年9月に WebAssembly 3.0 が標準化。Memory64・WasmGC・例外処理・末尾呼び出しなどで「ブラウザの外」での実用性が一段上がった
- WasmGC により Kotlin/Java/Dart/Scala など GC 前提の言語も Wasm に乗れるように
- Component Model + WIT で、生メモリではなく高レベルIFを介した多言語の部品合成が可能に
- WASI は Preview 2（0.2系）が安定。0.3（非同期I/O）は2026年、1.0は2026末〜2027想定。ランタイムは Wasmtime（v45系）が牽引
- 本番ではエッジ（Cloudflare Workers 等）・サーバーレス（約0.5ms コールドスタート）・ブラウザ（Figma 等）で広く活用
「Wasm はブラウザを速くする技術」という理解は、2026年にはもう古くなりました。いまの Wasm は「言語を選ばず、軽く、安全に、どこでも動かす」ための基盤レイヤーです。エッジやプラグイン基盤を検討するなら、選択肢として一度真剣に評価する価値があります。