Skip to content
Published on

WebAssembly 2025:ブラウザを超えてサーバー・エッジ・AIへ — Wasmが変えるコンピューティングの未来

Authors

はじめに

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つの基本型(きほんがた)i32i64f32f64)と参照型(さんしょうがた)funcrefexternref)をサポートし、すべての演算(えんざん)(かた)チェックが(おこな)われます。

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/JVMDocker/コンテナ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.2WASI 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/FermyonCloudflare WorkersFastly Compute
ランタイムWasmtimeV8 + WasmWasmtime(カスタム)
コールドスタートマイクロ秒ミリ秒35us未満(みまん)
言語(げんご)サポートRust, Go, JS, Python, C#JS, Rust, C, C++Rust, Go, JS
ストレージKV, SQLite, RedisKV, D1, R2, DOKV 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 詳細(しょうさい)比較(ひかく)テーブル

特性(とくせい)WasmtimeWasmEdgeWasmerwazero
開発元(かいはつもと)Bytecode AllianceCNCFWasmer Inc.Tetratelabs
言語(げんご)RustC++ / RustRustGo(純粋(じゅんすい)
コンパイル戦略(せんりゃく)Cranelift AOT/JITLLVM AOT + インタプリタCranelift/LLVM/Singlepassインタプリタ + コンパイラ
WASIサポート0.2 + 0.3(先導(せんどう)0.20.2Preview 1
コンポーネントモデル完全(かんぜん)サポート部分的(ぶぶんてき)部分的(ぶぶんてき)()サポート
()()Rust, C, Python, Go, .NETRust, C, Go, PythonRust, C, Python, Go, JSGoネイティブ
(つよ)標準(ひょうじゅん)準拠(じゅんきょ)安定性(あんていせい)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 + GGMLLlama-2-7B Q4(やく)12(やく)500ms(やく)4GB
ネイティブllama.cppLlama-2-7B Q4(やく)15(やく)400ms(やく)4GB
Spin AILlama-2-7B Q4(やく)10(やく)600ms(やく)4GB
ONNX WasmMobileNet-V2(やく)30 FPS(やく)50ms(やく)20MB

Wasm環境(かんきょう)でのAI推論(すいろん)はネイティブの(やく)70〜85%の性能(せいのう)発揮(はっき)し、セキュリティと移植性(いしょくせい)考慮(こうりょ)すれば十分(じゅうぶん)実用的(じつようてき)です。


7. Wasm vs コンテナ vs サーバーレス — 比較(ひかく)分析(ぶんせき)

7.1 総合(そうごう)比較(ひかく)テーブル

特性(とくせい)DockerコンテナAWS LambdaWasm(Spin/Wasmtime)
コールドスタート1〜10秒100ms〜数秒マイクロ秒
イメージ/バイナリサイズ数十〜数百MB50MB(zip)数KB〜数MB
メモリオーバーヘッド数十MB128MB最小(さいしょう)数MB
セキュリティ隔離(かくり)カーネルnamespacesFirecracker VM内蔵(ないぞう)サンドボックス
移植性(いしょくせい)CPUアーキテクチャ依存(いぞん)クラウド依存(いぞん)どこでも実行(じっこう)
ネットワーキング完全(かんぜん)サポートVPC設定(せってい)必要(ひつよう)WASIベース
ファイルシステム完全(かんぜん)サポート一時的(いちじてき)/tmpWASI仮想(かそう)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バージョンバイナリサイズ成熟度(せいじゅくど)備考(びこう)
Rustcargo + wasm32-wasip20.2 / 0.3数十〜数百KBプロダクション第一級(だいいっきゅう)
C/C++wasi-sdk / Emscripten0.2数十〜数百KBプロダクション既存(きぞん)コード活用(かつよう)
GoTinyGo / 標準(ひょうじゅん)Go0.2数百KB〜数MBプロダクション可能(かのう)TinyGo推奨(すいしょう)
C#.NET 8 WASI0.2数MBプロダクション可能(かのう)AOTコンパイル
Pythoncomponentize-py0.2数十MB実験的(じっけんてき)CPython(ふく)
JS/TSStarlingMonkey / javy0.2数MB実験的(じっけんてき)ランタイム(ふく)
KotlinKotlin/Wasmブラウザ数MB実験的(じっけんてき)サーバーサポート予定(よてい)
SwiftSwiftWasmPreview 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の大規模(だいきぼ)プロダクション事例(じれい)がこれを明確(めいかく)(しめ)しています。

要点(ようてん)まとめ:

  1. Wasmはブラウザを()えてサーバー、エッジ、AI、IoTまで拡大(かくだい)しました
  2. WASI 0.3のネイティブasyncによりサーバーサイドの実用性(じつようせい)大幅(おおはば)向上(こうじょう)しました
  3. マイクロ秒コールドスタートと内蔵(ないぞう)サンドボックスはコンテナに(たい)する明確(めいかく)利点(りてん)です
  4. RustがWasm開発(かいはつ)最適(さいてき)選択(せんたく)ですが、多言語(たげんご)サポートも急速(きゅうそく)拡大(かくだい)(ちゅう)です
  5. エッジコンピューティングとAI推論(すいろん)でWasmの価値(かち)(とく)(かがや)きます

Dockerがコンテナでインフラを革新(かくしん)したように、WebAssemblyはより(かる)く、より(はや)く、より安全(あんぜん)方法(ほうほう)でコンピューティングの(つぎ)(しょう)(ひら)いています。(いま)がWasmを(まな)最適(さいてき)時期(じき)です。


参考(さんこう)資料(しりょう)

  1. WebAssembly公式(こうしき)サイト — Wasmスペック、チュートリアル、コミュニティ
  2. WASI.dev — WASI標準(ひょうじゅん)ドキュメントとロードマップ
  3. Bytecode Alliance — WasmtimeとWASI標準化(ひょうじゅんか)主導(しゅどう)する組織(そしき)
  4. Fermyon公式(こうしき)ブログ — SpinフレームワークとWasmエコシステムニュース
  5. Cloudflare Workersドキュメント — エッジWasmデプロイガイド
  6. Fastly Computeドキュメント — Wasmベースのエッジプラットフォーム
  7. WasmEdge公式(こうしき)サイト — AI/ML最適化(さいてきか)Wasmランタイム
  8. Wasmer公式(こうしき)サイト汎用(はんよう)Wasmランタイムとパッケージマネージャー
  9. wazero GitHub — GoネイティブWasmランタイム
  10. コンポーネントモデルドキュメント — コンポーネントモデルスペック
  11. ONNX Runtime Web — ブラウザ/WasmでのAI推論(すいろん)
  12. Spinドキュメント — Spinフレームワーク公式(こうしき)ガイド
  13. TinyGo Wasmガイド — GoでのWasm開発(かいはつ)
  14. AkamaiのFermyon買収(ばいしゅう)発表(はっぴょう) — 2025年3月公式(こうしき)発表(はっぴょう)
  15. WebAssembly Weekly — Wasmエコシステム週刊(しゅうかん)ニュースレター
  16. Lin ClarkのWasm漫画(まんが)シリーズ — ビジュアルWasm入門(にゅうもん)