はじめに
WebAssembly は当初、ブラウザ上で高パフォーマンスなコードを安全に実行するための技術として登場しました。しかし、近年はサーバーサイドやエッジコンピューティング、IoTなどの領域でも注目され、「Write Once, Run Anywhere」を真に実現する汎用プラットフォームへと進化を遂げつつあります。
2024年にW3Cが発表し、現在ドラフト段階の WebAssembly Version 2.0の規格 は、その進化をさらに加速させる重要なマイルストーンです。コンポーネントモデルやWASI（WebAssembly System Interface）の強化、GCやSIMDの正式サポートなど、多数の新機能が追加され、今やWebAssemblyはコンテナ技術を補完・代替しうる「軽量かつ高性能」な実行環境としても注目されています。
本記事では、WebAssembly 2.0の主要な新機能と、これから訪れる活用分野、そして注目すべき事例を分かりやすくまとめます。Web開発者はもちろん、サーバーレスやエッジ、IoT、AI分野に関わるすべてのエンジニアにとって、WebAssembly 2.0は見逃せないトピックです。
WebAssembly Version 2.0の規格 は、2022年4月にW3Cから最初のパブリックワーキングドラフトとして公開されました。 その後、2024年10月には、W3Cの技術アーキテクチャグループ（TAG）に対して、バージョン2.0の仕様を勧告候補（CR）に移行するためのレビューが依頼されています(2025/1/15に締切済み)。 この進展から、WebAssembly Version 2.0の規格は、2025年内には正式に確定する可能性が高いと考えられます。
WebAssembly 2.0の概要
なぜWebAssembly 2.0が重要なのか
-
普遍性（Write Once, Run Anywhere）の実現
OSやハードウェアアーキテクチャに依存せず、どんな環境でも同じバイナリを実行できるのがWasm最大の強みです。2.0ではこの理念がさらに徹底され、複数の言語・プラットフォームがシームレスに連携しやすくなりました。 -
軽量性・高速性
コンテナと比較しても起動時間が非常に短く、リソース消費も少ないのが特徴です。数千〜数万程度の同時実行単位を容易に扱えるため、サーバーレス環境やエッジ環境で効果を発揮します。 -
セキュリティ（サンドボックス）
Webブラウザ由来のサンドボックスモデルを継承しており、OSレベルから隔離された安全な実行環境を提供します。これにより、プラグインやマイクロサービスなどを安全に動作させられます。 -
2.0での主な追加機能
- コンポーネントモデル: 複数のWasmモジュールを柔軟に組み合わせ、再利用性を高めるモデル
- WASIの強化: ブラウザ外でのファイルシステム、ネットワークアクセスなどを標準化
- GC・SIMDの正式サポート: GC言語のランタイム移植が容易になり、並列演算が高速化
- 例外処理の強化: C++やRustなどのネイティブ言語と同等の例外ハンドリングが可能
主な新機能と改善
1. SIMD（Single Instruction, Multiple Data）の完全統合
SIMDのサポートによって並列演算の性能が飛躍的に向上します。特に画像処理や機械学習推論など、大量のデータを扱う計算に効果的です。また、IoTやエッジ環境でのセンサー情報のリアルタイム解析などでも、高速化が期待されます。
2. 新しい例外処理モデル
従来のWasmには例外処理が限定的でしたが、2.0ではC++やRustのような高レベル言語の例外機構を活かした開発が可能になりました。ランタイム環境の安全性と開発効率が大きく向上します。
3. GC（Garbage Collection）の正式サポート
JavaやC#、Python、RubyなどGCを前提とする言語にとって、Wasm上でネイティブに近い形で動作できる道が開かれました。これにより、従来は困難だった各種言語ランタイムのWasm移植が一層加速すると考えられます。
4. WASI（WebAssembly System Interface）の正式採用
ブラウザ外での利用を可能にする標準インターフェイスです。ファイルシステム、ネットワーク、環境変数などのOSレベル機能が標準化され、サーバーレスやエッジでのWasm活用が現実的になりました。
5. モジュールの再利用を促進するコンポーネントモデル
複数のWasmモジュールを効率的に組み合わせ、アプリケーションを段階的に構築できるようになります。規模の大きなプロジェクトでも、モジュール単位の開発・デプロイが容易になります。
WebAssembly 2.0の活用分野
ここからは、2.0によってどのような分野でどのように活用されるかを、具体的な例や技術要素を交えて解説します。
1. サーバーレス環境での高パフォーマンス実行
- 軽量・高速な起動: ほぼ瞬時に起動し、リクエスト単位でスケーラブルに処理できる
- 強固なセキュリティモデル: 隔離された環境でのコード実行が容易
- 柔軟な言語サポート: C/C++やRustだけでなく、Java/C#などの言語も対応が進行中
事例：Cloudflare Workers、Fastly Compute@Edge、Fermyon Spin、Vercel Edge Functions
- Cloudflare Workers: V8 Isolateベースのエッジランタイムだが、Wasmモジュールにも積極的
- Fastly Compute@Edge: Wasmtimeを活用し、高速なエッジ処理を提供
- Fermyon Spin: サーバーレスのWasmプラットフォーム。簡単にWasmアプリをデプロイ可能
- Vercel Edge Functions: Next.jsなどのフレームワークと連携し、エッジでWasmを活用
こうしたサーバーレスプラットフォームでは、「コンテナなし」の超軽量なマイクロサービスを構築でき、スケーリングコストの削減や開発の迅速化が可能になります。
2. エッジコンピューティング・IoTへの拡大
- リアルタイム分析: 大量のセンサーデータをエッジ側で即座に解析し、クラウドへの負荷を軽減
- SIMDによる高速化: 画像/動画解析やマルチメディア処理でも並列演算が大きく寄与
- 軽量GC: メモリの限られたIoTデバイスでも安全にプログラムを実行
具体的な活用シーン例
- 工場内のセンサーデータ分析: 不良品の早期検知や設備故障の予測
- スマートシティのリアルタイム交通情報処理: 渋滞予測や緊急車両優先制御
- ビデオ監視システム: エッジでの人物検出・トラッキングにより、クラウドへの送信データを削減
3. AI・機械学習分野のさらなる最適化
- 一度ビルドすればどこでも動く: ブラウザ、サーバー、エッジなど環境を問わず共通バイナリを利用
- SIMD活用: 行列演算をはじめとする機械学習の基本処理を高速化
- GCサポート: PythonやRubyなど、動的言語ベースのMLライブラリの移植も容易に
具体的なライブラリ・プロジェクト例
- TensorFlow.js: ブラウザ上での推論に加え、Wasmバックエンドを強化
- ONNX Runtime Web: 多様なプラットフォームでONNXモデルを実行可能
-
異なる環境での推論シナリオ:
- ブラウザでインタラクティブなデモ
- サーバーでのバッチ推論
- エッジでのリアルタイム異常検知
4. ゲームエンジン・VR/ARアプリケーション
- UnityやUnreal Engineなど、多くのゲームエンジンがWasmビルドをサポート
- 複雑なゲームロジックやマルチプレイ処理をWasmモジュールで実装可能
- WebXRやThree.jsと連携したVR/ARコンテンツの高速化も期待大
具体的な展望
- ブラウザベースのオンラインゲーム: アセット配信を効率化し、ロード時間を短縮
- AR/VR学習コンテンツ: スマホやブラウザだけで没入型学習が可能に
5. プラグインエコシステムの拡張
- 安全なサンドボックス: アプリケーション本体を壊さずにプラグインを動作
- WASIを利用したファイルアクセスやネットワーク: ブラウザ外でもプラグインが機能
具体的なアプリケーション例
- サーバーアプリケーション: NGINXやEnvoyなどの拡張モジュールをWasmプラグイン化
- デスクトップアプリケーション: テキストエディタや画像編集ソフトのプラグイン機能をWasmで実装
- CI/CDツール: パイプライン内の一部ステップをWasmモジュールで安全に実行
6. 既存言語ランタイム・仮想マシンの移植
- GC対応により、Java、C#だけでなく、Go、Python、Rubyなどのランタイム実行が容易に
- GraalVM Native Imageや.NET BlazorなどのプロジェクトでのWasm活用も進行中
- 豊富なライブラリ資産の活用: 既存のエコシステムをそのままWasmへ移行できる可能性
WebAssembly 2.0の招待実装について
W3Cは、2024年12月にWebAssembly 2.0の候補勧告スナップショットに対する実装招待を開始。次世代仕様の早期フィードバックを集める重要なフェーズに入っています。
招待実装（Implementation Call）とは？
招待実装（Implementation Call） とは、標準化団体（例：W3C）がドラフト段階の仕様を広く実装者（ブラウザベンダーやランタイム開発者など）に試してもらい、実際の実装を通じて早期にフィードバックを得るための呼びかけを指します。まだ正式版ではありませんが、「技術コミュニティ全体で仕様を育てる」 という目的で非常に重要なプロセスです。
-
候補勧告（CR）段階で呼びかけられる
- ドラフト仕様がある程度固まると、実装者に対して「この仕様を実装し、問題や改善点を報告してほしい」とアナウンスされます。
-
標準化の合意形成を進める
- 同時に複数の実装が行われることで、互換性のある標準仕様へと仕上げるための意見交換が活発化します。
-
正式勧告への布石
- 仕様と実装の不整合やパフォーマンス課題が洗い出され、解消されれば、最終的に正式版（Recommendation）へ近づきます。
実装招待の対象仕様
- WebAssemblyコア仕様2.0：安全かつポータブルな低レベルコードフォーマット
- JavaScriptインターフェース2.0：WebAssemblyとJavaScriptの相互運用API
- Web API 2.0：Webプラットフォームとの統合仕様
現在の状況
- フィードバック期間：2025年1月15日までGitHubで意見募集（既に締切済み）
-
主な改善点：
- SIMDに関連する命令追加
- 新しいv128データ型のサポート
- 関数の機能拡張
WASI（WebAssembly System Interface）の進展
- WASI Preview 2が承認され、WASI 0.2.0として正式ローンチ。
- ライブラリ実装者による利用が可能。
- ブラウザ外でのWasm利用が一層現実的になり、サーバーやIoTデバイスでの応用が期待される。
この招待実装フェーズは、WebAssembly 2.0の実用化を目指すうえで非常に重要な段階であり、WASIを含む周辺エコシステムの拡充にも拍車がかかると見られています。
複数のブラウザベンダーやランタイムが互換性を持って2.0機能を実装し、問題点を洗い出すことで、正式勧告へ近づくことが期待されます。
WebAssemblyを応用したプロジェクト
WebAssemblyは「ブラウザで高速コードを動かすための技術」を超え、サーバーレスやデータベース、ブロックチェーン、レガシー資産再生など多方面に応用が広がっています。ここでは、その中でも面白い／ユニークなプロジェクトをいくつか取り上げます。
| プロジェクト名 | 概要・特徴 | 関連リンク |
|---|---|---|
| Pyodide | CPythonインタープリタをWebAssemblyに移植。ブラウザ上でPythonコードを実行できる | Pyodide公式リポジトリ |
| Blazor WebAssembly | Microsoftが開発するC#フレームワーク。.NETランタイムをWasm上で動かし、ブラウザでC#コードを実行 | Blazor公式ドキュメント |
| Suborbital | サーバーレス／マイクロサービス開発向けのWasmプラットフォーム。ホスト言語を問わずWasmモジュールを関数として実行 | Suborbital.dev |
| Lunatic | Erlang/ElixirのようなプロセスモデルをWasmで再現し、高並列＆分散実行を可能にする実験的ランタイム | Lunatic公式サイト |
| Ruffle | FlashコンテンツをWasm経由で再生するオープンソースプロジェクト。Flashサポート終了後のレガシーコンテンツ再生を目指す | Ruffle公式サイト |
| Proxy-Wasm | EnvoyやNGINXなどのプロキシ／サービスメッシュでWasmプラグインを実行する仕組み。プラグインを安全に拡張可能 | Proxy-Wasm |
| Polkadot / NEAR | WebAssemblyをスマートコントラクトの実行環境として利用するブロックチェーン。高速処理と高い移植性が特徴 |
Polkadot NEAR |
| Wasm UDF in Databases | データベースでユーザー定義関数（UDF）をWasmとして実行。セキュアかつ言語非依存で柔軟な拡張が可能 | Ex: Extism, pgwasm |
| CheerpX for Flash | Ruffleと同様、FlashをWebAssemblyで動かすソリューション。企業内システムなどFlash依存資産の延命に活用 | CheerpX |
1. Pyodide
- Pythonをブラウザ上で実行するプロジェクト
- 科学技術計算やデータ解析系のライブラリ（NumPy, Pandasなど）の一部も利用可能
- 「インストール不要のPython環境」をPWAやWebアプリとして提供できる
2. Blazor WebAssembly
- Microsoft製フレームワークで、C#コードをブラウザ上で直接実行
- サーバー通信を減らし、リッチなインタラクティブWebアプリが作りやすい
- ASP.NET Coreとの連携もスムーズ
3. Suborbital
- サーバーレス／マイクロサービス向けプラットフォーム。任意の言語をWasmにコンパイルして軽量関数を実行
- 多言語モジュールを組み合わせ、軽量かつ安全にサービスを提供できる
4. Lunatic
- ErlangやElixirの特徴であるActorモデルをWasmで実装し、高並列＆分散実行を目指す
- まだ実験的だが、**「Wasm × Actorモデル」**の可能性を切り開くランタイム
5. Ruffle
- FlashコンテンツをWebAssembly上で再生するオープンソースプロジェクト
- Flash Player終了後のレガシーコンテンツを安全にブラウザで動かせる
- 教育サイトや企業内システムのFlash依存を救う
6. Proxy-Wasm
- EnvoyやNGINXなどプロキシ／サービスメッシュ上でWasmプラグインを動かす仕組み
- サンドボックス化による安全性とホットリロード可能な拡張性を両立
- トラフィック制御や認証、監査ログなどを柔軟に実装できる
7. Polkadot / NEAR（ブロックチェーン領域）
- ブロックチェーンのスマートコントラクト実行環境としてWasmを採用
- 高速＆高移植性・安全性を活かし、契約ロジックの柔軟な拡張が可能
- CosmWasmなど他のチェーンでもWasm活用が広がる
8. Wasm UDF in Databases
- データベースで**ユーザー定義関数（UDF）**をWasmとして実行
- SQLクエリにカスタムロジックを安全に組み込みやすい
- Extismやpg-wasmなど、DB内でサンドボックス化したUDFを実行する試みが進行中
9. CheerpX for Flash
- FlashをWasmでエミュレートするソリューション
- Ruffle同様、Flash依存のレガシー資産を延命
- 安全なサンドボックス内でFlashを動かし、企業向けシステムの維持に寄与
WebAssemblyをベースとした実験的な軽量OSプロジェクトも進行中
代表的なプロジェクト
| プロジェクト | 特徴 | アーキテクチャ | 主要ターゲット |
|---|---|---|---|
| Walos | WebAssembly Language based OS。プロセスやドライバもWasm。 | ハードウェア保護を使わないシンプル設計 | 研究・実験 |
| Kwast | Rust製のWebAssembly対応OS。マイクロカーネル | 同一アドレス空間で複数プロセス実行 | 研究・実験 |
| Wasmachine | IoT向けWasm OS。AOTコンパイルでカーネルモード動作 | システムコールのオーバーヘッド最適化 | 小型デバイス |
Linuxベースではないのか？
既存のLinuxカーネルを流用しているわけではなく、独自のOSコア＋WebAssemblyランタイムで構築される実験的プロジェクトが中心です。
Rustなどの安全な言語を用いてブートローダやプロセス管理を一から作り込み、Wasmバイナリをサンドボックス実行することを前提に設計されています。
なぜLinuxを使わずにゼロから？
- 軽量化・シンプル化：大規模なLinuxカーネルを排し、最小限に特化
- 研究的アプローチ：UNIX哲学に縛られない新アーキテクチャの探究
- メモリ安全性・サンドボックス：Rust＋Wasmで攻撃面を狭めたセキュアOSを目指す
実用面の現状
- 多くはまだ研究段階で、ブートローダや小規模ホストOSを併用するケースも多い。
- WASIがハードウェアアクセス等を標準化すれば、将来的に「Linux不要の純Wasm OS」が登場する可能性はあるが、現時点では実験的プロジェクトが主流。
図解：WebAssemblyベースOSの概念
上記のように、従来のLinuxカーネルを使用せず、最小限のカーネルやブートローダの上でWebAssemblyランタイムを中核に据え、OSレベルのサービスやユーザープロセス（WASM Modules）を動かすという構造を想定しているのがWasmベースOSの特徴です。
WebAssemblyはアプリプラットフォームを不要にするのか？
WasmがApple Storeのようなアプリプラットフォームを不要にするか、という疑問が度々取り上げられます。ここでは、その可能性と制約を整理します。
1. WebAssembly v2の可能性
- ブラウザ外でも動作が進むWasm v2
- モジュールリンキングやコンポーネントモデルによる大規模アプリ対応
- 高い移植性・セキュリティと性能向上が見込まれ、ネイティブアプリに迫る
2. Apple Storeの役割とWasmの課題
- アプリ審査と安全性：Appleの厳格なポリシーと審査体制
- 課金システム：アプリ内課金やサブスク管理が強固
- OSとの統合：iOSネイティブAPIや深いシステムアクセス
- Wasmはサンドボックスが強みな一方、ネイティブ機能利用には制約が多く、Appleがこれを積極的に容認する可能性は低い。
3. 将来的なシナリオ
- WASIの進化：ネイティブ機能へのアクセス拡充で、Apple Storeを介さないアプリ配布の可能性が広がるかもしれない
- PWA（プログレッシブウェブアプリ）の進化：Wasmと組み合わせ、ブラウザ上でネイティブ級機能を実現
- Appleのポリシー変化：独占禁止や競争法の観点で政府や規制当局の指導が入り、App Store以外での配布を認めざるを得なくなるケースも、可能性は否定できない
もっとも、現時点ではApple Storeの役割（審査・課金・OS連携）が依然として大きく、Wasmがすぐにこれを完全代替するのは難しいと考えられます。
よくある質問（Q&A）
Q1: WebAssemblyは本当に安全なのでしょうか？ サンドボックスの脆弱性は？
A1: Wasmは当初ブラウザでの実行を想定して設計されたため、サンドボックスによる強固なセキュリティモデルを備えています。OSのシステムコールやメモリアクセスも制限され、WASIを介してのみ許可された操作が可能です。ただし、サンドボックスの実装には各ランタイムやブラウザベンダーが深く関わるため、ゼロデイ脆弱性が完全にないとは言い切れません。常に最新の実装を追い、セキュリティアップデートを適用することが重要です。
Q2: WebAssemblyのパフォーマンスはネイティブコードと比較してどうですか？
A2: ネイティブコード（C/C++など）と比べると若干のオーバーヘッドはありますが、JITコンパイル等により非常に高速に動作します。特に、起動時間やメモリ使用量の面で有利です。一方、I/Oがボトルネックになるケースや、GCのある言語では最適化によって結果が異なるため、ユースケースに応じたベンチマークが必要です。
Q3: 開発の難易度は高いでしょうか？ 既存のWeb開発技術との違いは？
A3: C/C++やRustなどのWasm対応ツールチェーンを使えば、比較的スムーズにWasmバイナリを生成できます。また、AssemblyScriptやTinyGoなど、JavaScriptやGoエンジニアに馴染みやすい選択肢もあります。ただし、ブラウザ外で使う場合はWASIの知識やランタイム選択など、従来のWeb開発とは異なる点があるため、学習コストは多少発生します。
Q4: WASIは今後どのように進化していくのでしょうか？
A4: 現在はファイルシステムアクセスやネットワークなど基礎的な機能が標準化されています。今後はより広範なシステムコール（スレッド管理やGPUアクセスなど）も検討されており、OSのAPIに近いレベルの標準化が進む可能性があります。これにより、Wasmがより多様なユースケースに対応できると期待されています。
Q5: WebAssemblyとDockerのようなコンテナ技術は、どう使い分ければよいですか？
A5: コンテナはOSレベルの仮想化を提供し、包括的なパッケージングやネットワーク管理を行えます。一方、Wasmはアプリケーションコード単位での極めて軽量なサンドボックスを提供します。迅速な起動や大規模スケールが必要な場合はWasmが適しており、既存のインフラやCI/CDとの互換性を重視する場合はコンテナが向いています。両者を組み合わせるハイブリッドアプローチも一般的です。
Q6: Apple Storeを経由せずiOS上でWasmアプリを配布できる可能性はありますか？
A6: 現状では難しいですが、将来的にWASIの進化や独占禁止法的な規制の影響などで、何らかの形で容認されるシナリオもゼロではありません。とはいえ、Appleの方針次第なので、現時点で確実とは言えません。
Q7: WebAssemblyを応用した面白いプロジェクトはどこがポイントですか？
A7: ブラウザ内だけでなく、サーバーレス・AI/ML・ブロックチェーン・データベースUDF・レガシー資産の再生など多分野に広がっており、Wasmサンドボックスの安全性や移植性が大きく寄与しています。RustやC++、C#、Pythonなど、多様な言語で同じバイナリを生成できる点も魅力です。
Q8: LinuxカーネルとWasmベースOSを組み合わせたハイブリッドは考えられますか？
A8: 実際に、WasmベースOSを仮想マシンとしてLinux上で動かす例もあります。今後はWASI拡張やハードウェアへの直接アクセスが実現すれば、Linuxを完全に排除して“純粋なWasm OS”を構築する道も模索されるでしょう。
Q9: 研究段階のWasm OSは実用性が低いのでは？
A9: 現時点では実験要素が大きいですが、RustやWasmによるメモリ安全とサンドボックスの結合には大きな意義があります。将来のIoTやセキュアな軽量OSとして芽があると見る研究者や開発者は少なくありません。
Q10: 招待実装と正式版の違いは何ですか？
A10: 招待実装（Implementation Call）は、まだ正式標準になる前の候補勧告段階で実装者に広く呼びかけ、早期フィードバックを得るためのフェーズです。複数のベンダーが互換性をもって実装し、問題点が解消されれば最終勧告（Recommendation）へと進みます。
Q11: 2.0はいつ正式リリースされる予定ですか？
A11: 2 2024年12月に候補勧告スナップショットが提示され、2025年1月15日までフィードバックを受け付けました。正式リリース時期は未定ですが、実装招待フェーズを経て2025年中〜後半に標準化がまとまる可能性があります。
まとめ
WebAssembly 2.0は、ブラウザからクラウド、エッジ、そしてIoTデバイスまでを繋ぐ汎用実行プラットフォームとして、これからますます存在感を高めていくでしょう。ブラウザのサンドボックスという強固な安全性をベースに持ちながら、高パフォーマンスと軽量性、そしてマルチプラットフォーム対応という魅力を兼ね備えています。
- SIMD、GC、例外処理などで性能と柔軟性が格段に向上
- WASIの標準化により、ブラウザ外での利用が大きく拡張
- ゲーム、AI、IoT、エッジなど多岐にわたる分野で事例が増加
- **W3Cの実装招待（2024年12月〜2025年1月）**を通じて、2.0仕様とWASI周辺がさらに発展
- PWAやOSプロジェクトとの連携により、新たなアプリ配布モデルも期待される
すでに、WebAssemblyは「ブラウザで高速コードを動かすための技術」を超え、サーバーレスやデータベース、ブロックチェーン、レガシー資産再生など多方面に応用が広がっており、version 2 の正式デビューによって今後もさらに加速しそうです。
さらに、WasmをベースとしたOSプロジェクトにおいては、Linuxカーネルを流用せず、独自のミニマルなカーネル部＋WebAssemblyランタイムを中核として構築しようという試みが進行中です。これらはまだ実験段階にとどまりますが、メモリ安全性やサンドボックスを最大限活かした新種のOSを生み出す可能性もあると思っており、個人的に期待しています。
一方、Apple Storeのように審査・課金・OS連携の面で強固なエコシステムをもつプラットフォームを、現状のWasmがすぐに置き換えることは困難ですが、独占禁止や競争法の観点からの規制や、WASIのさらなる進化、そしてApple自身のポリシー転換など、様々な要素が絡み合うことで、今後のアプリ配布のあり方が変化する可能性もあるかもしれません。
参考文献・リンク
-
WebAssembly公式サイト
WebAssemblyの概要や仕様、最新ニュースがまとまっています。 -
W3C WebAssembly Working Group
WebAssemblyの標準化プロセスやドラフト仕様の詳細を追う際に役立ちます。 -
各ブラウザで実装された機能を確認
各ブラウザで実装されている機能を確認する際に役立ちます。 -
Cloudflare Workers公式ドキュメント
EdgeでのWasm活用事例や開発方法について詳しく紹介。 -
Fastly Compute@Edge
Wasmtimeを使った高性能なエッジ実行環境。サーバーレス活用の参考に。 -
Fermyon Spin
Wasmベースのサーバーレスフレームワークで、簡単にアプリケーションをデプロイ可能。 -
WASI (WebAssembly System Interface)
ブラウザ外でWasmがシステムリソースへアクセスするための標準API群。 -
Wasmtime
Bytecode Allianceによる高速ランタイム。サーバーサイドやエッジでの利用に最適。 -
WasmEdge
サーバーレスやエッジ向けの軽量ランタイム。低メモリで高速な実行が特徴。
以上