- Authors

- Name
- Youngju Kim
- @fjvbn20031
- はじめに
- 1. WebAssembly 101 — <ruby>基礎<rp>(</rp><rt>きそ</rt><rp>)</rp></ruby><ruby>概念<rp>(</rp><rt>がいねん</rt><rp>)</rp></ruby>の<ruby>完全<rp>(</rp><rt>かんぜん</rt><rp>)</rp></ruby><ruby>整理<rp>(</rp><rt>せいり</rt><rp>)</rp></ruby>
- 2. WASIの<ruby>進化<rp>(</rp><rt>しんか</rt><rp>)</rp></ruby> — システムインターフェースの<ruby>標準化<rp>(</rp><rt>ひょうじゅんか</rt><rp>)</rp></ruby>
- 2.1 WASIが<ruby>必要<rp>(</rp><rt>ひつよう</rt><rp>)</rp></ruby>な<ruby>理由<rp>(</rp><rt>りゆう</rt><rp>)</rp></ruby>
- 2.2 Preview 1 — <ruby>最初<rp>(</rp><rt>さいしょ</rt><rp>)</rp></ruby>の<ruby>試<rp>(</rp><rt>こころ</rt><rp>)</rp></ruby>み(2019〜2023)
- 2.3 WASI 0.2 — コンポーネントモデルの<ruby>登場<rp>(</rp><rt>とうじょう</rt><rp>)</rp></ruby>(2024)
- 2.4 WASI 0.3 — ネイティブasyncの<ruby>革命<rp>(</rp><rt>かくめい</rt><rp>)</rp></ruby>(2025)
- 3. 2025年<ruby>主要<rp>(</rp><rt>しゅよう</rt><rp>)</rp></ruby>マイルストーン — Wasmエコシステムの<ruby>大転換<rp>(</rp><rt>だいてんかん</rt><rp>)</rp></ruby>
- 3.1 AkamaiによるFermyon<ruby>買収<rp>(</rp><rt>ばいしゅう</rt><rp>)</rp></ruby>
- 3.2 プロダクションデプロイ<ruby>事例<rp>(</rp><rt>じれい</rt><rp>)</rp></ruby>の<ruby>拡大<rp>(</rp><rt>かくだい</rt><rp>)</rp></ruby>
- 3.3 WASI 0.3<ruby>公式<rp>(</rp><rt>こうしき</rt><rp>)</rp></ruby><ruby>発表<rp>(</rp><rt>はっぴょう</rt><rp>)</rp></ruby>
- 3.4 コンポーネントモデルの<ruby>成熟<rp>(</rp><rt>せいじゅく</rt><rp>)</rp></ruby>
- 4. サーバーサイドWasm — フレームワークとプラットフォーム
- 5. Wasmランタイム<ruby>比較<rp>(</rp><rt>ひかく</rt><rp>)</rp></ruby> — どれを<ruby>選<rp>(</rp><rt>えら</rt><rp>)</rp></ruby>ぶべきか
- 5.1 <ruby>主要<rp>(</rp><rt>しゅよう</rt><rp>)</rp></ruby>ランタイム<ruby>概要<rp>(</rp><rt>がいよう</rt><rp>)</rp></ruby>
- 5.2 <ruby>詳細<rp>(</rp><rt>しょうさい</rt><rp>)</rp></ruby><ruby>比較<rp>(</rp><rt>ひかく</rt><rp>)</rp></ruby>テーブル
- 5.3 <ruby>選択<rp>(</rp><rt>せんたく</rt><rp>)</rp></ruby>ガイド
- 5.4 パフォーマンスベンチマーク(2025年<ruby>基準<rp>(</rp><rt>きじゅん</rt><rp>)</rp></ruby>)
- 6. Wasm + AI — エッジでのAI<ruby>推論<rp>(</rp><rt>すいろん</rt><rp>)</rp></ruby>
- 6.1 なぜWasmでAIを<ruby>実行<rp>(</rp><rt>じっこう</rt><rp>)</rp></ruby>するのか
- 6.2 ONNX Runtime + Wasm
- 6.3 WasmEdge + LLM<ruby>推論<rp>(</rp><rt>すいろん</rt><rp>)</rp></ruby>
- 6.4 Spin + AI<ruby>推論<rp>(</rp><rt>すいろん</rt><rp>)</rp></ruby>
- 6.5 AI<ruby>推論<rp>(</rp><rt>すいろん</rt><rp>)</rp></ruby>パフォーマンス<ruby>比較<rp>(</rp><rt>ひかく</rt><rp>)</rp></ruby>
- 7. Wasm vs コンテナ vs サーバーレス — <ruby>比較<rp>(</rp><rt>ひかく</rt><rp>)</rp></ruby><ruby>分析<rp>(</rp><rt>ぶんせき</rt><rp>)</rp></ruby>
- 8. ハンズオン:RustでWasmアプリをビルド・デプロイ
- 8.1 <ruby>事前<rp>(</rp><rt>じぜん</rt><rp>)</rp></ruby><ruby>準備<rp>(</rp><rt>じゅんび</rt><rp>)</rp></ruby>
- 8.2 <ruby>新規<rp>(</rp><rt>しんき</rt><rp>)</rp></ruby>Spinプロジェクトの<ruby>作成<rp>(</rp><rt>さくせい</rt><rp>)</rp></ruby>
- 8.3 ビジネスロジックの<ruby>実装<rp>(</rp><rt>じっそう</rt><rp>)</rp></ruby>
- 8.4 ビルドとローカルテスト
- 8.5 Fermyon Cloudにデプロイ
- 8.6 バイナリサイズ<ruby>比較<rp>(</rp><rt>ひかく</rt><rp>)</rp></ruby>
- 9. <ruby>言語<rp>(</rp><rt>げんご</rt><rp>)</rp></ruby>サポート<ruby>状況<rp>(</rp><rt>じょうきょう</rt><rp>)</rp></ruby>
- 9.1 Tier 1 — プロダクションレディ
- 9.2 Tier 2 — プロダクション<ruby>可能<rp>(</rp><rt>かのう</rt><rp>)</rp></ruby>(一部<ruby>制約<rp>(</rp><rt>せいやく</rt><rp>)</rp></ruby>あり)
- 9.3 Tier 3 — <ruby>実験的<rp>(</rp><rt>じっけんてき</rt><rp>)</rp></ruby> / <ruby>開発<rp>(</rp><rt>かいはつ</rt><rp>)</rp></ruby><ruby>中<rp>(</rp><rt>ちゅう</rt><rp>)</rp></ruby>
- 9.4 <ruby>言語<rp>(</rp><rt>げんご</rt><rp>)</rp></ruby>サポート<ruby>要約<rp>(</rp><rt>ようやく</rt><rp>)</rp></ruby>
- 10. <ruby>開発者<rp>(</rp><rt>かいはつしゃ</rt><rp>)</rp></ruby><ruby>採用<rp>(</rp><rt>さいよう</rt><rp>)</rp></ruby>ロードマップ
- 10.1 2025年の<ruby>現在<rp>(</rp><rt>げんざい</rt><rp>)</rp></ruby><ruby>地<rp>(</rp><rt>ち</rt><rp>)</rp></ruby>
- 10.2 <ruby>開発者<rp>(</rp><rt>かいはつしゃ</rt><rp>)</rp></ruby>のための<ruby>学習<rp>(</rp><rt>がくしゅう</rt><rp>)</rp></ruby>パス
- 10.3 2026年<ruby>以降<rp>(</rp><rt>いこう</rt><rp>)</rp></ruby>の<ruby>展望<rp>(</rp><rt>てんぼう</rt><rp>)</rp></ruby>
- 11. クイズ
- 12. まとめ — Wasmの<ruby>現在<rp>(</rp><rt>げんざい</rt><rp>)</rp></ruby>と<ruby>未来<rp>(</rp><rt>みらい</rt><rp>)</rp></ruby>
- <ruby>参考<rp>(</rp><rt>さんこう</rt><rp>)</rp></ruby><ruby>資料<rp>(</rp><rt>しりょう</rt><rp>)</rp></ruby>
はじめに
Docker創始者のSolomon Hykesが2019年に残した有名なツイートがあります。「もし2008年にWASMとWASIがあったなら、Dockerを作る必要はなかっただろう。」あれから6年、2025年にその予言が現実になりつつあります。
WebAssembly(Wasm)は元々、ブラウザでC/C++コードをネイティブに近い速度で実行するために誕生しました。しかし2025年現在、Wasmはブラウザという枠を完全に超えました。サーバーレスコンピューティング、エッジデプロイ、AI推論、プラグインシステム、さらにはブロックチェーンスマートコントラクトまで — Wasmが届かない領域はありません。
この記事では、WebAssemblyの基礎概念から2025年の主要マイルストーン、サーバーサイド活用、ランタイム比較、AI統合、そしてハンズオンまで包括的に解説します。Wasmがなぜ「一度コンパイルすればどこでも実行」される真のユニバーサルランタイムなのかを確認しましょう。
1. WebAssembly 101 — 基礎概念の完全整理
1.1 Wasmとは何か
WebAssemblyはスタックベース(stack-based)の仮想マシンのためのバイナリ命令形式(binary instruction format)です。核心的な特性は以下の通りです。
バイナリ形式: 人間が読めるテキスト形式(WAT)とコンパクトなバイナリ形式(.wasm)の2つで存在します。
;; WAT(WebAssembly Text Format)例 - 2つの数を足す関数
(module
(func $add (param $a i32) (param $b i32) (result i32)
local.get $a
local.get $b
i32.add
)
(export "add" (func $add))
)
スタックマシン: Wasmはレジスタではなくスタックベースで動作します。すべての演算はスタックから値を取り出し(pop)、結果を再びスタックに積む(push)方式です。
型安全性: 4つの基本型(i32、i64、f32、f64)と参照型(funcref、externref)をサポートし、すべての演算で型チェックが行われます。
1.2 サンドボックス保安モデル
Wasmの最も強力な特徴の一つは**サンドボックス実行**です。
- メモリ隔離: 各Wasmモジュールは自分だけの線形メモリ(linear memory)を持ちます。ホストのメモリに直接アクセスすることはできません。
- Capability-based Security: Wasmモジュールはホストが明示的に付与した機能(capability)のみを使用できます。ファイルシステム、ネットワーク、環境変数などへのアクセスはホストが許可した範囲でのみ可能です。
- 実行隔離: 無限ループ防止のためのfuelメカニズム、スタックオーバーフロー検出など、ランタイム安全装置が内蔵されています。
┌──────────────────────────────────────────┐
│ ホスト環境(Host) │
│ ┌────────────┐ ┌────────────┐ │
│ │ Wasmモジュール │ │ Wasmモジュール │ │
│ │ A │ │ B │ │
│ │ ┌────────┐ │ │ ┌────────┐ │ │
│ │ │ 線形 │ │ │ │ 線形 │ │ │
│ │ │ メモリ │ │ │ │ メモリ │ │ │
│ │ └────────┘ │ │ └────────┘ │ │
│ └────────────┘ └────────────┘ │
│ 互いに完全に隔離されている │
└──────────────────────────────────────────┘
1.3 移植性(Portability)の真の意味
Javaの「Write Once, Run Anywhere」を覚えていますか?Wasmはこれをさらに一歩進めました。
| 特性 | Java/JVM | Docker/コンテナ | WebAssembly |
|---|---|---|---|
| サイズ | 数十MB(JRE) | 数十〜数百MB | 数KB〜数MB |
| 起動時間 | 数百ms | 数秒 | マイクロ秒 |
| セキュリティモデル | SecurityManager(非推奨) | namespaces/cgroups | 内蔵サンドボックス |
| CPUアーキテクチャ | JVM依存 | イメージ別ビルド | 真のクロスプラットフォーム |
| 言語サポート | JVM言語 | すべての言語 | 30以上 |
2. WASIの進化 — システムインターフェースの標準化
2.1 WASIが必要な理由
ブラウザ内のWasmはJavaScriptと相互作用すれば十分です。しかしサーバーで実行するには、ファイルシステム、ネットワーク、時計、乱数生成器などのシステムリソースにアクセスする必要があります。
WASI(WebAssembly System Interface)はこの問題を解決する標準インターフェースです。POSIXのWasm版と考えるとわかりやすいでしょう。
2.2 Preview 1 — 最初の試み(2019〜2023)
WASI Preview 1はPOSIXスタイルのシンプルなAPIを提供しました。
// WASI Preview 1スタイル - ファイル読み込み
use std::fs;
fn main() {
let content = fs::read_to_string("/data/config.toml")
.expect("ファイルを読み込めません");
println!("設定: {}", content);
}
制限事項:
-
非同期
(async)未
サポート - ソケットネットワーキングが不完全
- コンポーネント間統合メカニズムの欠如
- HTTPリクエストの標準化不備
2.3 WASI 0.2 — コンポーネントモデルの登場(2024)
2024年にリリースされたWASI 0.2は、革新的な**コンポーネントモデル(Component Model)**という概念を導入しました。
// WIT(Wasm Interface Type)定義例
package my-app:backend;
interface http-handler {
handle-request: func(req: request) -> response;
}
world my-server {
import wasi:http/outgoing-handler;
export http-handler;
}
コンポーネントモデルの要点:
- WIT(Wasm Interface Type): 言語中立のインターフェース定義言語
- コンポーネント合成: 異なる言語で書かれたWasmコンポーネントをリンクタイムで結合
- リッチ型: 文字列、リスト、オプション、Result、レコードなど高レベル型をサポート
- 仮想化: ファイルシステム、ネットワークなどを仮想的に置換可能
2.4 WASI 0.3 — ネイティブasyncの革命(2025)
2025年の最も重要な技術的マイルストーンは間違いなくWASI 0.3です。最大の変化は**ネイティブ非同期(async)**サポートです。
// WASI 0.3 - ネイティブasync HTTPハンドラー
use wasi::http::handler;
async fn handle(request: handler::Request) -> handler::Response {
// 非同期データベースクエリ
let user = db::query("SELECT * FROM users WHERE id = ?", &[request.user_id]).await;
// 非同期外部APIコール
let enriched = external_api::enrich(user).await;
handler::Response::new(200, serde_json::to_string(&enriched).unwrap())
}
WASI 0.3の主要革新:
| 機能 | WASI 0.2 | WASI 0.3 |
|---|---|---|
| 非同期 | pollベース(非効率) | ネイティブasync/await |
| 並行性 | 単一リクエスト処理 | マルチリクエスト同時処理 |
| ストリーミング | 制限的 | 完全なストリーミングI/O |
| HTTP | 同期ハンドラー | 非同期ハンドラー |
| パフォーマンス | オーバーヘッドあり | ネイティブ水準 |
3. 2025年主要マイルストーン — Wasmエコシステムの大転換
3.1 AkamaiによるFermyon買収
2025年3月、CDNおよびクラウドセキュリティ企業のAkamaiがFermyonを買収しました。これはWasmエコシステムのゲームチェンジャーです。
Fermyonとは?
- Spinフレームワークの開発元
- Fermyon Cloud(Wasm専用サーバーレスプラットフォーム)を運営
- Matt Butcher(Helm創始者)などクラウドネイティブのベテランが設立
買収の意味:
- Akamaiの世界4,200以上のPoP(Point of Presence)でWasm実行が可能に
- エッジコンピューティング + Wasmの本格的なエンタープライズ採用シグナル
- Cloudflare Workersとの直接競争構図を形成
- Wasmがもはや実験的技術ではなくプロダクション技術であることを証明
3.2 プロダクションデプロイ事例の拡大
2025年、大規模プロダクション環境でのWasm採用が急速に拡大しました。
Shopify: サードパーティアプリの拡張システムをWasmベースに移行。数万のアプリがWasmサンドボックス内で安全に実行されています。
Figma: ブラウザベースのデザインツールのコアレンダリングエンジンをC++からWasmにコンパイルし、ネイティブアプリに匹敵するパフォーマンスを達成しました。
Fastly: Computeプラットフォームで毎日数十億件のリクエストをWasmで処理。コールドスタート時間は35マイクロ秒未満です。
Cloudflare: Workersプラットフォームが世界300以上のデータセンターでWasmを実行しています。
3.3 WASI 0.3公式発表
Bytecode Allianceが2025年上半期にWASI 0.3の最初の公式マイルストーンを達成しました。ネイティブasyncが最も重要な機能であり、サーバーサイドWasmの実用性が大幅に向上しました。
3.4 コンポーネントモデルの成熟
2025年はコンポーネントモデルが実質的に使用可能になった年です。wasm-tools composeコマンドにより、異なる言語で書かれたコンポーネントを一つに組み合わせることが可能になりました。
# Rustで書かれたビジネスロジックとPythonで書かれたMLモジュールを合成
wasm-tools compose business-logic.wasm -d ml-module.wasm -o combined-app.wasm
4. サーバーサイドWasm — フレームワークとプラットフォーム
4.1 Spin Framework(Fermyon)
SpinはWasmネイティブのサーバーレスフレームワークの代表格です。
# spin.toml - Spinアプリケーション設定
spin_manifest_version = 2
[application]
name = "my-api"
version = "1.0.0"
[[trigger.http]]
route = "/api/hello"
component = "hello-handler"
[component.hello-handler]
source = "target/wasm32-wasip2/release/hello_handler.wasm"
allowed_outbound_hosts = ["https://api.example.com"]
// Spin HTTPハンドラー(Rust)
use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;
#[http_component]
fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {
let name = req
.query()
.get("name")
.unwrap_or(&"World".to_string())
.clone();
Ok(Response::builder()
.status(200)
.header("content-type", "application/json")
.body(format!(r#"{{"message": "Hello, {}!"}}"#, name))
.build())
}
Spinの特徴:
- マイクロ秒レベルのコールドスタート
-
内蔵
キーバリューストア、SQLite、Redisサポート - Rust、Go、Python、JavaScript、C#など多言語サポート
spin deployでFermyon Cloudに即時デプロイ
4.2 Cloudflare Workers
Cloudflare Workersはエッジ上でWasmを実行する最も成熟したプラットフォームです。
// Cloudflare Worker - Wasmモジュールの使用
export default {
async fetch(request, env) {
// Rustでコンパイルされたwasmモジュールで画像処理
const wasmModule = await import('./image-processor.wasm')
const imageData = await request.arrayBuffer()
const processed = wasmModule.resize(
new Uint8Array(imageData),
800, // width
600 // height
)
return new Response(processed, {
headers: { 'Content-Type': 'image/webp' },
})
},
}
Workersの強み:
-
世界
300以上のデータセンター - V8 isolateベース + Wasmハイブリッド実行
- Workers KV、Durable Objects、D1(SQLite)、R2(Object Storage)統合
-
無料
ティア:1日10万リクエスト
4.3 Fastly Compute
Fastly Computeは純粋なWasmベースのエッジコンピューティングプラットフォームです。
// Fastly Computeハンドラー
use fastly::{Error, Request, Response};
#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
// 地理情報ベースのルーティング
let geo = req.get_client_geo().unwrap();
let country = geo.country_code().unwrap_or("US");
let backend = match country {
"KR" | "JP" => "origin-apac",
"DE" | "FR" | "GB" => "origin-eu",
_ => "origin-us",
};
// オリジンにリクエスト転送
let mut beresp = req.send(backend)?;
beresp.set_header("X-Served-By", "fastly-compute-wasm");
Ok(beresp)
}
Fastly Computeの差別化ポイント:
- 35マイクロ秒未満のコールドスタート
-
純粋
Wasm実行
(V8なし) - Viceroyによるローカル開発環境
-
帯域幅
課金
なし(リクエスト数ベース)
4.4 プラットフォーム比較
| 特性 | Spin/Fermyon | Cloudflare Workers | Fastly Compute |
|---|---|---|---|
| ランタイム | Wasmtime | V8 + Wasm | Wasmtime(カスタム) |
| コールドスタート | マイクロ秒 | ミリ秒 | 35us未満 |
| 言語サポート | Rust, Go, JS, Python, C# | JS, Rust, C, C++ | Rust, Go, JS |
| ストレージ | KV, SQLite, Redis | KV, D1, R2, DO | KV Store, Object Store |
| エッジノード | 4,200+(Akamai) | 300+ | 主要POP |
| 無料ティア | あり | 1日10万件 | あり |
| オープンソース | Spin(Apache 2.0) | wrangler(MIT) | SDK(Apache 2.0) |
5. Wasmランタイム比較 — どれを選ぶべきか
5.1 主要ランタイム概要
サーバーサイドWasmを実行するランタイムには複数の選択肢があり、それぞれ設計哲学と最適化ポイントが異なります。
5.2 詳細比較テーブル
| 特性 | Wasmtime | WasmEdge | Wasmer | wazero |
|---|---|---|---|---|
| 開発元 | Bytecode Alliance | CNCF | Wasmer Inc. | Tetratelabs |
| 言語 | Rust | C++ / Rust | Rust | Go(純粋) |
| コンパイル戦略 | Cranelift AOT/JIT | LLVM AOT + インタプリタ | Cranelift/LLVM/Singlepass | インタプリタ + コンパイラ |
| WASIサポート | 0.2 + 0.3(先導) | 0.2 | 0.2 | Preview 1 |
| コンポーネントモデル | 完全サポート | 部分的 | 部分的 | 未サポート |
| 埋め込み | Rust, C, Python, Go, .NET | Rust, C, Go, Python | Rust, C, Python, Go, JS | Goネイティブ |
| 強み | 標準準拠、安定性 | AI/ML最適化、軽量 | パッケージマネージャー | 外部依存ゼロ、Go統合 |
| 弱み | 比較的大きいバイナリ | コンポーネントモデル遅延 | 標準準拠遅延 | 機能制限的 |
| 代表的用途 | Spin, Fastly | 自動車, IoT, SaaS | 汎用、パッケージ配布 | Goベースプラットフォーム |
5.3 選択ガイド
質問1: 主要言語がGoですか?
|-- YES -> wazero(外部依存ゼロ、CGoが不要)
|-- NO
|-- 質問2: 最新のWASI標準準拠が重要ですか?
| |-- YES -> Wasmtime(Bytecode Alliance、標準を先導)
| |-- NO
| |-- 質問3: AI/MLワークロードが主目的ですか?
| | |-- YES -> WasmEdge(GGML、TensorFlow Lite統合)
| | |-- NO -> Wasmer(汎用、wapmパッケージマネージャー)
5.4 パフォーマンスベンチマーク(2025年基準)
HTTP "Hello World" レスポンスタイム(p99、マイクロ秒):
Wasmtime: ████████░░░░░░░░ 45us
WasmEdge: ████████░░░░░░░░ 48us
Wasmer: █████████░░░░░░░ 52us
wazero: ██████████░░░░░░ 62us
Node.js: ████████████████ 120us
Docker+Node: スケール外(ms単位)
6. Wasm + AI — エッジでのAI推論
6.1 なぜWasmでAIを実行するのか
AI推論をエッジで実行すると、以下の利点があります。
- 遅延時間の削減: クラウドへの往復が不要なため、数十〜数百ms節約
- データプライバシー: ユーザーデータがローカル/エッジで処理され外部に出ない
- コスト削減: GPUサーバーの代わりにCPUベースのエッジで軽量モデルを実行
- オフラインサポート: ネットワークなしでもAI機能が動作
6.2 ONNX Runtime + Wasm
ONNX RuntimeはWasmバックエンドを公式サポートしています。
// ONNX Runtime Web(Wasmバックエンド)例
import * as ort from 'onnxruntime-web'
// Wasmバックエンド設定
ort.env.wasm.numThreads = 4
ort.env.wasm.simd = true
async function classifyImage(imageData) {
const session = await ort.InferenceSession.create('mobilenet-v2.onnx', {
executionProviders: ['wasm'],
})
const tensor = new ort.Tensor('float32', preprocessImage(imageData), [1, 3, 224, 224])
const results = await session.run({ input: tensor })
return postprocess(results.output)
}
6.3 WasmEdge + LLM推論
WasmEdgeはGGML/llama.cpp統合により、大規模言語モデル(LLM)をWasm内で実行できます。
# WasmEdgeでLLMを実行
wasmedge --dir .:. \
--nn-preload default:GGML:AUTO:llama-2-7b-chat.Q4_K_M.gguf \
llm-chat.wasm
サポートモデル:
- Llama 2 / 3(Meta)
- Mistral / Mixtral
- Phi-2 / Phi-3(Microsoft)
- Gemma(Google)
-
量子化
モデル(Q4、Q5、Q8)
6.4 Spin + AI推論
Fermyon Spinはサーバーレス推論のためのspin-llmインターフェースを提供します。
// SpinでのLLM推論
use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::llm;
#[spin_sdk::http_component]
fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {
let prompt = req.body().as_str()?;
let result = llm::infer(
llm::InferencingModel::Llama2Chat,
prompt,
)?;
Ok(Response::builder()
.status(200)
.header("content-type", "text/plain")
.body(result.text)
.build())
}
6.5 AI推論パフォーマンス比較
| 環境 | モデル | トークン/秒 | 初回トークン遅延 | メモリ |
|---|---|---|---|---|
| WasmEdge + GGML | Llama-2-7B Q4 | 約12 | 約500ms | 約4GB |
| ネイティブllama.cpp | Llama-2-7B Q4 | 約15 | 約400ms | 約4GB |
| Spin AI | Llama-2-7B Q4 | 約10 | 約600ms | 約4GB |
| ONNX Wasm | MobileNet-V2 | 約30 FPS | 約50ms | 約20MB |
Wasm環境でのAI推論はネイティブの約70〜85%の性能を発揮し、セキュリティと移植性を考慮すれば十分実用的です。
7. Wasm vs コンテナ vs サーバーレス — 比較分析
7.1 総合比較テーブル
| 特性 | Dockerコンテナ | AWS Lambda | Wasm(Spin/Wasmtime) |
|---|---|---|---|
| コールドスタート | 1〜10秒 | 100ms〜数秒 | マイクロ秒 |
| イメージ/バイナリサイズ | 数十〜数百MB | 50MB(zip) | 数KB〜数MB |
| メモリオーバーヘッド | 数十MB | 128MB最小 | 数MB |
| セキュリティ隔離 | カーネルnamespaces | Firecracker VM | 内蔵サンドボックス |
| 移植性 | CPUアーキテクチャ依存 | クラウド依存 | どこでも実行 |
| ネットワーキング | 完全サポート | VPC設定必要 | WASIベース |
| ファイルシステム | 完全サポート | 一時的/tmp | WASI仮想FS |
| エコシステム成熟度 | 非常に高い | 高い | 成長中 |
| デバッグツール | 豊富 | CloudWatch | 改善中 |
| プロダクション実績 | 10年以上 | 9年以上 | 2〜3年 |
7.2 いつ何を選ぶべきか
Dockerコンテナが適切な場合:
-
複雑
なシステム依存関係
が必要
なレガシーアプリケーション -
長時間
実行
されるステートフルサービス -
完全
なファイルシステム/ネットワークアクセスが必要
な場合
サーバーレス(Lambda)が適切な場合:
- イベントドリブンアーキテクチャ
-
不規則
なトラフィックパターン - AWSサービスとの深い統合が必要な場合
Wasmが適切な場合:
- マイクロ秒レベルのコールドスタートが必要なエッジデプロイ
- マルチテナント環境で強力な隔離が必要な場合
- プラグイン/拡張システム(ユーザーコードの安全な実行)
- クロスプラットフォームCLIツールの配布
7.3 ハイブリッドアプローチ
現実
では一つだけを
選
ぶのではなく、
組
み
合
わせて
使用
します。
┌──────────────────────────────────────────────────┐
│ ユーザーリクエスト │
└─────────────┬────────────────────────────────────┘
v
┌─────────────────────────┐
│ エッジ(Wasm/Spin) │ 認証、キャッシュ、A/Bテスト
│ - マイクロ秒応答 │ ジオベースルーティング
└─────────────┬───────────┘
v
┌─────────────────────────┐
│ サーバーレス(Lambda) │ ビジネスロジック、API
│ - イベント処理 │ DBクエリ、外部API
└─────────────┬───────────┘
v
┌─────────────────────────┐
│ コンテナ(ECS/K8s) │ ML学習、バッチ処理
│ - 長時間タスク │ ステートフルサービス
└─────────────────────────┘
8. ハンズオン:RustでWasmアプリをビルド・デプロイ
8.1 事前準備
# Rustのインストール(既にインストール済みならスキップ)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Wasmターゲットの追加
rustup target add wasm32-wasip2
# Spin CLIのインストール
curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash
sudo mv spin /usr/local/bin/
8.2 新規Spinプロジェクトの作成
# HTTPハンドラーテンプレートでプロジェクト作成
spin new -t http-rust my-wasm-api
cd my-wasm-api
8.3 ビジネスロジックの実装
// src/lib.rs
use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;
use spin_sdk::key_value::Store;
use serde::{Deserialize, Serialize};
#[derive(Serialize, Deserialize)]
struct VisitorCount {
path: String,
count: u64,
last_visited: String,
}
#[http_component]
fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {
let path = req.path().to_string();
let method = req.method().to_string();
match (method.as_str(), path.as_str()) {
("GET", "/api/health") => health_check(),
("GET", "/api/visitors") => get_visitor_count(&path),
("POST", "/api/visitors") => increment_visitor(&path),
_ => Ok(Response::builder()
.status(404)
.body("Not Found")
.build()),
}
}
fn health_check() -> anyhow::Result<impl IntoResponse> {
Ok(Response::builder()
.status(200)
.header("content-type", "application/json")
.body(r#"{"status": "healthy", "runtime": "wasm"}"#)
.build())
}
fn get_visitor_count(path: &str) -> anyhow::Result<impl IntoResponse> {
let store = Store::open_default()?;
let count = store
.get(path)
.map(|bytes| String::from_utf8(bytes).unwrap_or_default())
.unwrap_or_else(|| "0".to_string());
Ok(Response::builder()
.status(200)
.header("content-type", "application/json")
.body(format!(r#"{{"path": "{}", "count": {}}}"#, path, count))
.build())
}
fn increment_visitor(path: &str) -> anyhow::Result<impl IntoResponse> {
let store = Store::open_default()?;
let current: u64 = store
.get(path)
.map(|bytes| String::from_utf8(bytes).unwrap_or_default())
.unwrap_or_else(|| "0".to_string())
.parse()
.unwrap_or(0);
let new_count = current + 1;
store.set(path, new_count.to_string().as_bytes())?;
Ok(Response::builder()
.status(200)
.header("content-type", "application/json")
.body(format!(r#"{{"path": "{}", "count": {}}}"#, path, new_count))
.build())
}
8.4 ビルドとローカルテスト
# ビルド
spin build
# ローカル実行
spin up
# 別のターミナルでテスト
curl http://localhost:3000/api/health
# 出力: {"status": "healthy", "runtime": "wasm"}
curl -X POST http://localhost:3000/api/visitors
# 出力: {"path": "/api/visitors", "count": 1}
curl http://localhost:3000/api/visitors
# 出力: {"path": "/api/visitors", "count": 1}
8.5 Fermyon Cloudにデプロイ
# Fermyon Cloudにログイン
spin cloud login
# デプロイ
spin cloud deploy
# 出力例:
# Uploading my-wasm-api version 1.0.0...
# Deploying...
# Application deployed!
# URL: https://my-wasm-api-xyz123.fermyon.app
8.6 バイナリサイズ比較
ビルド成果物サイズ:
Wasmバイナリ: 247 KB
Node.js (node_modules): 45 MB
Goバイナリ: 8.2 MB
Dockerイメージ (Node): 145 MB
Dockerイメージ (Alpine): 52 MB
9. 言語サポート状況
9.1 Tier 1 — プロダクションレディ
Rust
RustはWasm開発の第一級市民(first-class citizen)です。
// Rust - 完全なWASI 0.2サポート
use std::io::Write;
fn main() {
let mut stdout = std::io::stdout();
writeln!(stdout, "Hello from Rust + Wasm!").unwrap();
}
# コンパイル
cargo build --target wasm32-wasip2 --release
# 実行
wasmtime target/wasm32-wasip2/release/my-app.wasm
利点: ゼロランタイムオーバーヘッド、最小バイナリサイズ、最高のツールサポート 欠点: 学習曲線が急
C / C++
// C - EmscriptenまたはWASI-SDKでコンパイル
#include <stdio.h>
int main() {
printf("Hello from C + Wasm!\n");
return 0;
}
# wasi-sdkでコンパイル
/opt/wasi-sdk/bin/clang hello.c -o hello.wasm
wasmtime hello.wasm
利点: 既存のC/C++コードベースを再利用、豊富なライブラリ 欠点: メモリ安全性は開発者の責任
9.2 Tier 2 — プロダクション可能(一部制約あり)
Go
// Go - TinyGoを使用したWasmコンパイル
package main
import "fmt"
func main() {
fmt.Println("Hello from Go + Wasm!")
}
# TinyGoでコンパイル(標準GoもWASIサポート追加中)
tinygo build -target=wasip2 -o hello.wasm main.go
wasmtime hello.wasm
利点: 簡潔な文法、並行処理モデル 欠点: TinyGo使用時に標準ライブラリの一部が未サポート、バイナリサイズがRustより大きい
.NET / C#
// C# - .NET 8+のWasmサポート
using System;
class Program {
static void Main() {
Console.WriteLine("Hello from C# + Wasm!");
}
}
# .NET 8 WASIワークロードでビルド
dotnet workload install wasi-experimental
dotnet build -c Release
wasmtime bin/Release/net8.0/wasi-wasm/my-app.wasm
9.3 Tier 3 — 実験的 / 開発中
Python
# Python - componentize-pyによるWasm変換
# まだ実験的だが急速に発展中
def handle_request(request):
return {
"status": 200,
"body": f"Hello from Python + Wasm!"
}
# componentize-pyでWasmコンポーネントを生成
componentize-py -d wit/ -w my-world componentize app -o app.wasm
JavaScript / TypeScript
// JavaScript - StarlingMonkey(SpiderMonkeyベース)またはjavy
export function handleRequest(request) {
return {
status: 200,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ message: 'Hello from JS + Wasm!' }),
}
}
9.4 言語サポート要約
| 言語 | ツールチェーン | WASIバージョン | バイナリサイズ | 成熟度 | 備考 |
|---|---|---|---|---|---|
| Rust | cargo + wasm32-wasip2 | 0.2 / 0.3 | 数十〜数百KB | プロダクション | 第一級 |
| C/C++ | wasi-sdk / Emscripten | 0.2 | 数十〜数百KB | プロダクション | 既存コード活用 |
| Go | TinyGo / 標準Go | 0.2 | 数百KB〜数MB | プロダクション可能 | TinyGo推奨 |
| C# | .NET 8 WASI | 0.2 | 数MB | プロダクション可能 | AOTコンパイル |
| Python | componentize-py | 0.2 | 数十MB | 実験的 | CPython含む |
| JS/TS | StarlingMonkey / javy | 0.2 | 数MB | 実験的 | ランタイム含む |
| Kotlin | Kotlin/Wasm | ブラウザ | 数MB | 実験的 | サーバーサポート予定 |
| Swift | SwiftWasm | Preview 1 | 数MB | 実験的 | 活発な開発 |
10. 開発者採用ロードマップ
10.1 2025年の現在地
採用曲線:
イノベーター アーリーアダプター アーリーマジョリティ レイトマジョリティ ラガード
(2019) (2022) (2025) (2027?) (2030?)
| | <<<ここ>>> | |
v v v v v
+--+ +--------+ +----------+
| | | | | |
| | | | | ここ! |
+--+ +--------+ +----------+
Wasm MVP WASI P1 WASI 0.2/0.3
ブラウザ サーバー実験 プロダクションデプロイ
10.2 開発者のための学習パス
Phase 1: 基礎(1〜2週間)
- Wasmの概念理解(バイナリ形式、スタックマシン、サンドボックス)
- WAT(テキスト形式)の読み練習
- お好みの言語で簡単なWasmモジュールをコンパイル
Phase 2: サーバーサイド(2〜4週間)
- WASIの概念理解(ファイル、ネットワーク、環境変数)
- SpinまたはCloudflare Workersで最初のエッジアプリをデプロイ
- KVストア、データベースとの連携
Phase 3: プロダクション(4〜8週間)
- コンポーネントモデルとWITインターフェースの学習
-
既存
サービスの一部をWasmにマイグレーション - モニタリング、ロギング、エラーハンドリングの構築
Phase 4: 上級(8週間以上)
- マルチコンポーネントアーキテクチャの設計
- AI推論ワークロードの統合
- カスタムランタイムの埋め込み
10.3 2026年以降の展望
- WASI 1.0安定化: 2026年末〜2027年初めの見込み
- コンポーネントレジストリ: npm/crates.ioのようなWasmコンポーネントパッケージマネージャー
- デバッグツールの成熟: ブレークポイント、プロファイリング、メモリ分析ツール
- 言語サポートの拡大: Python、Rubyなどの Tier 1サポート
- 標準化されたAIインターフェース: wasi-nnの安定化によるランタイム間AIモデル互換性
11. クイズ
以下
のクイズでWebAssemblyの
理解度
を
確認
しましょう。
Q1. WebAssemblyのセキュリティモデルにおける「Capability-based Security」とは何ですか?
正解: Wasmモジュールはホストが明示的に付与した機能(capability)のみを使用できるセキュリティモデルです。ファイルシステム、ネットワーク、環境変数などへのアクセスはホストが許可した範囲でのみ可能です。これは従来のOSの「デフォルト許可、必要に応じて遮断」とは逆の「デフォルト遮断、必要に応じて許可」方式です。
Q2. WASI 0.3の最も重要な革新とは何で、それがサーバーサイドWasmにとってなぜ重要ですか?
正解: WASI 0.3の最も重要な革新は**ネイティブ非同期(async)**サポートです。WASI 0.2ではpollベースの非効率な方式で非同期を模倣する必要がありました。ネイティブasyncにより、サーバーで複数のリクエストを効率的に同時処理できるようになり、実際のプロダクションワークロードに対応できるようになりました。
Q3. AkamaiによるFermyon買収はWasmエコシステムにどのような意味を持ちますか?
正解: この買収には複数の意味があります。第一に、Akamaiの世界4,200以上のPoP(Point of Presence)でWasmアプリを実行できるようになります。第二に、エッジコンピューティング市場でCloudflare Workersとの本格的な競争構図が形成されます。第三に、Wasmがもはや実験的技術ではなく、エンタープライズ級のプロダクション技術として認められたことを意味します。
Q4. Wasm、Dockerコンテナ、AWS Lambdaをコールドスタート時間で比較してください。
正解: コールドスタート時間の比較:Wasmはマイクロ秒(us)レベルで最速です。AWS Lambdaは100ミリ秒から数秒。Dockerコンテナは1秒から10秒以上かかることがあります。Wasmがこれほど高速な理由は、バイナリサイズが小さく(数KB〜数MB)、VMやOSを起動する必要なくランタイムがWasmモジュールを直接ロードするためです。
Q5. サーバーサイドWasm開発に最適な言語は何で、その理由は?
正解: 現在、サーバーサイドWasm開発に最も適した言語はRustです。理由:(1)ゼロランタイムオーバーヘッドによる最小バイナリサイズ、(2)最新のWASI 0.2/0.3標準を最初にサポート、(3)SpinやWasmtimeなどのコアツールがRustで書かれておりツールサポートが最も豊富、(4)メモリ安全性の保証。ただしGoやC/C++もプロダクション水準であり、チームの既存技術スタックに応じて選択は変わり得ます。
12. まとめ — Wasmの現在と未来
2025年はWebAssemblyが「興味深い実験」から「プロダクション必須技術」へと転換した年です。WASI 0.3のネイティブasync、AkamaiによるFermyon買収、そしてCloudflare/Fastlyの大規模プロダクション事例がこれを明確に示しています。
要点まとめ:
- Wasmはブラウザを超えてサーバー、エッジ、AI、IoTまで拡大しました
- WASI 0.3のネイティブasyncによりサーバーサイドの実用性が大幅に向上しました
- マイクロ秒コールドスタートと内蔵サンドボックスはコンテナに対する明確な利点です
- RustがWasm開発の最適な選択ですが、多言語サポートも急速に拡大中です
- エッジコンピューティングとAI推論でWasmの価値が特に輝きます
Dockerがコンテナでインフラを革新したように、WebAssemblyはより軽く、より速く、より安全な方法でコンピューティングの次の章を開いています。今がWasmを学ぶ最適な時期です。
参考資料
- WebAssembly公式サイト — Wasmスペック、チュートリアル、コミュニティ
- WASI.dev — WASI標準ドキュメントとロードマップ
- Bytecode Alliance — WasmtimeとWASI標準化を主導する組織
- Fermyon公式ブログ — SpinフレームワークとWasmエコシステムニュース
- Cloudflare Workersドキュメント — エッジWasmデプロイガイド
- Fastly Computeドキュメント — Wasmベースのエッジプラットフォーム
- WasmEdge公式サイト — AI/ML最適化Wasmランタイム
- Wasmer公式サイト — 汎用Wasmランタイムとパッケージマネージャー
- wazero GitHub — GoネイティブWasmランタイム
- コンポーネントモデルドキュメント — コンポーネントモデルスペック
- ONNX Runtime Web — ブラウザ/WasmでのAI推論
- Spinドキュメント — Spinフレームワーク公式ガイド
- TinyGo Wasmガイド — GoでのWasm開発
- AkamaiのFermyon買収発表 — 2025年3月公式発表
- WebAssembly Weekly — Wasmエコシステム週刊ニュースレター
- Lin ClarkのWasm漫画シリーズ — ビジュアルWasm入門