Skip to content
Published on

WASMエコシステム2026 — Wasmtime・Wasmer・WasmEdge・Spin・Component Model・Extism 徹底ガイド(ブラウザを超えた汎用実行レイヤー)

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 2008年の約束、2026年の請求書

2017年にWebAssembly 1.0 MVPがブラウザに入ったとき、約束は二つあった。「ブラウザでC/C++/Rustをほぼネイティブ速度で動かせる。」そして「いつかブラウザの外でも動かす。」9年が経った。一つ目の約束はFigma・AutoCAD Web・Photoshop Webで既に証明されている。二つ目の約束は — 正直に言えば — 2024年1月にWASI 0.2が finalized されてからやっと本当に動き始めた。

今は2026年5月。WASMは我々が気づかぬところでproductionを支えている。Cloudflare Workersの一部はV8 isolateではなくWasmtime上で走り、Shopify Functionsはマーチャントが投稿したRust/JSコードをWASMにコンパイルしてエッジで実行する。Fastly Computeは最初からWasmtimeベースだった。AWS LambdaはSnapStartの文脈で一部ワークロードのWASM化を検討中であり、Azure Container AppsはSpinKubeで正式にWASMワークロードを支える。「コンテナの次がWASM」という言葉はもう発表スライドの約束ではない — 請求書に載るホスティング単位になった。

この記事は2026年5月時点のWASMエコシステムを一気に描き出す。ランタイム4種(Wasmtime・Wasmer・WasmEdge・Spin)、標準(WASI 0.2/0.3・Component Model・WAC)、ツール(Jco・Extism・wasm-tools・Wash)、言語(Wing・Kotlin/WASM・Dart/WASM)、そして実際のproduction事例まで。どのツールをいつ使うのか、なぜComponent Modelが大変化なのか、そして韓国と日本で誰が使っているのか。

1. 2026年のWASM — どこまで来たか

まず1行サマリー。WASMはブラウザ用アクセラレータから「汎用実行レイヤー」へと成長した。 言葉は大げさだが意味は単純 — 同じ.wasmバイナリがブラウザ・サーバ・エッジ・組み込み・プラグインホストで動く。「一度書けばどこでも動く」という約束が(やっと)現実になった。

2026年時点のWASM座標。

領域状況(2026.05)主要ツール
ブラウザ標準 WASM 1.0全主要ブラウザでGAV8・SpiderMonkey・JavaScriptCore
Reference Types・SIMDGA同上
Tail Call・Multiple MemoriesGA同上
GC提案全主要ブラウザでGA(2024後半)Kotlin/WASM・Dart/WASM実戦
Exception HandlingGAC++例外・Java例外
Threads・Atomics部分GA(cross-origin isolated必須)rayon・OpenMP移植
サーバサイド WASI 0.1安定Wasmtime 1+
サーバサイド WASI 0.2(Component Model)GA(2024.01)Wasmtime 17+
サーバサイド WASI 0.3(async)GA(2025 Q4)Wasmtime 28+
ランタイム — 標準OSS4強+小勢Wasmtime・Wasmer・WasmEdge・Spin
パッケージレジストリ分断(wasmer.io / OCI / wa.dev)wapm・warg・OCI
コンテナ統合k8sで正式対応containerd shim・runwasi・SpinKube
プラグインシステムあらゆる言語ホストExtism・wasmtime embed API
クラウドネイティブ言語登場Wing・Grain・MoonBit

核心的洞察3つ。

第一に、Component Modelが最大の変化だ。 2017年のWASM 1.0は「コアモジュール」しか定義していなかった。コアモジュールはi32・i64・f32・f64・メモリ・テーブルしか知らない。文字列を受け渡せない。だからホストとゲストが文字列を交換するには毎回「メモリのアドレスXからNバイト読め」というABI協議が必要だった。Component ModelはそのABIを標準としてまとめた。Rustで書いたモジュールをPython・Go・JSのホストが個別のグルーコードなしで呼び出せる。これが本当に動き始めたのが2024年1月だ。

第二に、ランタイムが4強に絞られた。 2020年に10以上あったWASMランタイムが事実上4つに整理された。Bytecode AllianceのWasmtime(標準)、Wasmer(商用+レジストリ)、WasmEdge(CNCF・エッジ)、Spin(サーバレスプラットフォーム)。残りは組み込み特化(WAMR・wasm3)か停滞気味。

第三に、2026年のWASMは「使う」段階であって「待つ」段階ではない。 2022年までは「いつproduction-readyになるか」が話題だった。2026年は「どのツールでどのワークロードを移すか」が話題だ。自分のチームが使っていなくても、社内の別チームは使っている可能性が高い。

2. WASI 0.2 Component Model(2024.01) — なぜ大変化なのか

Component Modelを一言で言えば — 言語非依存の呼び出し規約(calling convention)+ インターフェース定義言語(IDL)+ 型システムだ。gRPCがProtobufでサービス間RPCを標準化したことを、WASMモジュール間でやったような話。

まず既存のコアWASMの限界。コアモジュールは次の型しか知らない。

i32, i64, f32, f64, v128, funcref, externref

文字列・構造体・オプション型・結果型(Result) — どれもない。だからRustモジュールがJSホストにstringを返すには、毎回「メモリのアドレスXからNバイトUTF-8で読め」という合意を再設計する必要があった。wasm-bindgenはこれを自動化したが、JS限定だった。

Component Modelが導入したもの — 4つ。

  1. WIT(Wasm Interface Type) — IDL。.witファイルにインターフェースを宣言する。record・variant・option・result・list・stringのような高水準型を使う。
  2. Canonical ABI — WIT型がコアWASMのi32・i64・メモリレイアウトにどう写るかを定めた標準ABI。すべての言語が同じ規約に従う。
  3. コンポーネント(component) — コアモジュール+WITインターフェース+インポート/エクスポート仕様をまとめた単位。.wasmファイルだがヘッダが異なる(layer 1 = モジュール、layer 2 = コンポーネント)。
  4. WASI標準インターフェース — wasi:filesystem、wasi:http、wasi:cli、wasi:clocks、wasi:random、wasi:sockets、wasi:ioなどがWITで標準定義された。

たとえばこんな.witファイル。

package example:greeter@0.1.0;

interface greet {
  hello: func(name: string) -> string;
}

world greeter {
  export greet;
}

Rustで実装すると:

wit_bindgen::generate!({
    world: "greeter",
});

struct Component;

impl exports::example::greeter::greet::Guest for Component {
    fn hello(name: String) -> String {
        format!("Hello, {}!", name)
    }
}

export!(Component);

要点は — このモジュールをRust・Python・Go・JS・C#のホストがすべて同じ方法で呼び出せること。wasm-bindgenはJSホストだけだった。Component Modelはすべてのホストで動く。

2026年5月現在、WASI 0.2インターフェースが定義されている領域 — wasi:filesystem(ファイル)、wasi:http(HTTPクライアント/サーバ)、wasi:cli(CLI引数・環境変数)、wasi:sockets(TCP/UDP)、wasi:clocks(時計)、wasi:random(乱数)、wasi:logging(ログ)、wasi:keyvalue(KVストア・proposal)、wasi:blobstore(オブジェクトストア・proposal)。次のステップはwasi:nn(機械学習推論)とwasi:graphics(GPU)。

3. WASI 0.3(2025 Q4) — Asyncサポート到来

WASI 0.2の最大の制約はasyncがなかったこと。wasi:httpクライアントで外部APIを呼ぶとblockingだった。サーバを書くとき、「リクエストAの処理中にリクエストBを処理する」ができなかった。

WASI 0.3はこれを解決する。2025年Q4にWasmtime 28+ と wit-bindgen 0.36+ でGA。変更の核は2つ。

  1. WITに async キーワード追加。 関数宣言に async を付けるとfutureを返す。
  2. stream<T> と future<T> 型。 標準ライブラリレベルで非同期ストリームを扱う。

たとえば:

package example:fetcher@0.3.0;

interface fetch {
  use wasi:http/types@0.3.0.{request, response};

  async fetch: func(req: request) -> result<response, string>;
}

Rust実装:

impl Guest for Component {
    async fn fetch(req: Request) -> Result<Response, String> {
        let client = wasi::http::outgoing_handler::handle(req).await?;
        Ok(client.into_response().await?)
    }
}

内部的にはwit-bindgenがfuture・promiseのpollingをcanonical ABIに変換する。ホストから見ると、コンポーネントが一時停止(pause)して別作業へ譲るyieldポイントが生まれたことになる。これが重要な理由は — WASMサーバを1インスタンスで多重化できるからだ。0.2までは「リクエストごとにインスタンス」が事実上強制だった。

ただし注意 — 2026年5月時点で asyncを完全にサポートするゲスト言語はRust(wit-bindgen)・JS(Jco)のみ。Go・Python・C#は部分対応で、安定化は2026年後半の見込み。

4. Wasmtime — Bytecode Alliance標準

WasmtimeはBytecode Alliance(Mozilla・Fastly・Intel・Microsoft・Armなど)が共同開発するリファレンスランタイム。2026年5月時点でWasmtime 30+。月1回メジャーバージョンを切る運用(2024年1月の17.0 → 2026年5月の30+)なのでバージョン番号が早く上がる。

Wasmtimeの座標 — 1行サマリー。

「WASI/Component Model標準の事実上のリファレンス実装。JIT(Cranelift)コンパイラベース。安全性と正確性を最優先。」

主な特徴5つ。

  1. Cranelift JIT — 自前のコンパイラバックエンド。SpiderMonkeyのCranelift移植も同じコードベース。AOTコンパイル(wasmtime compile)も対応。
  2. Pulleyインタプリタ — Wasmtime 25+ から導入された自前のインタプリタ。JITが使えない環境(iOS、JIT禁止ホスト)でのfallback。
  3. WASI 0.2/0.3 first-class — Component Model標準実装。wit-bindgenが生成するRustコードはWasmtimeのRust APIに直接マッピングされる。
  4. ホスト埋め込みAPIが豊富 — Rust・C・Python・.NETの埋め込み。ホスト関数をコンポーネントへ公開する方法が標準化されている。
  5. フォークが多い — Cloudflareは自社用フォークをV8 isolateと並行で動かし、Fastly ComputeはWasmtimeベース。

基本使い方 — CLI。

# 1. Rustでコンポーネントをビルド
cargo build --target wasm32-wasip2 --release

# 2. Wasmtimeで実行
wasmtime run --invoke 'hello("world")' \
  ./target/wasm32-wasip2/release/greeter.wasm

Rust埋め込みAPI。

use wasmtime::{Engine, Store, component::{Component, Linker}};

fn main() -> anyhow::Result<()> {
    let engine = Engine::default();
    let component = Component::from_file(&engine, "greeter.wasm")?;
    let linker = Linker::new(&engine);
    let mut store = Store::new(&engine, ());
    let instance = linker.instantiate(&mut store, &component)?;

    let hello = instance
        .get_typed_func::<(String,), (String,)>(&mut store, "hello")?;
    let (result,) = hello.call(&mut store, ("world".into(),))?;
    println!("{}", result);
    Ok(())
}

いつWasmtimeを選ぶか — ほぼ常に。標準追従が強く、新機能が最も早く入り、ドキュメントが最も厚い。迷ったらWasmtime。

5. Wasmer — 商業志向のランタイム+レジストリ

Wasmerは2018年に設立されたWasmer Inc.が作るランタイム。Bytecode Allianceには(一度入って出た後)属していない。だから標準追従よりもプロダクト化・DX・配布に重きが置かれる。

Wasmerの座標。

「実用性最優先。マルチコンパイラバックエンド(Singlepass・Cranelift・LLVM)。wasmer.ioパッケージレジストリ(=wapm後継)。Edge・Functionホスティングサービス。」

差別化4点。

  1. コンパイラを選べる。 Singlepass(コンパイル速い・実行遅い)、Cranelift(バランス)、LLVM(コンパイル遅い・実行速い)。サーバ起動時はLLVM、JIT環境ではSinglepassのような使い分け。
  2. wasmer.ioレジストリ。 npmのようなWASMパッケージレジストリ。wasmer run wasmer/python で公開パッケージを即実行。これがwapmの後継。
  3. Wasmer Edge. 自社サーバレス/エッジホスティング。Cloudflare Workersに近いモデルだがWASMコンポーネントがfirst-class。
  4. WASIX. Wasmer独自のPOSIX拡張仕様。WASI 0.2 +追加システムコール(threads・fork・full sockets)。ただし標準ではなくWasmer専用 — 2026年現在、他ランタイムでは動かない。

基本使い方。

# パッケージレジストリから即実行
wasmer run wasmer/python -- -c "print('hello')"

# ローカル.wasm実行
wasmer run ./hello.wasm

Rust埋め込み。

use wasmer::{Store, Module, Instance, imports, Function};

fn main() -> anyhow::Result<()> {
    let mut store = Store::default();
    let wat = r#"(module
        (func (export "add") (param i32 i32) (result i32)
            local.get 0
            local.get 1
            i32.add)
    )"#;
    let module = Module::new(&store, wat)?;
    let imports = imports! {};
    let instance = Instance::new(&mut store, &module, &imports)?;
    let add = instance.exports.get_typed_function::<(i32, i32), i32>(&store, "add")?;
    println!("{}", add.call(&mut store, 7, 35)?);
    Ok(())
}

いつWasmerを選ぶか — WASIXのPOSIX拡張が必要なとき(既存Linuxバイナリに近い環境)、wasmer.ioレジストリでパッケージ配布したいとき、またはWasmer Edgeにホスティングするとき。Component Model追従ではWasmtimeが先行する。

6. WasmEdge — CNCF、エッジ/IoT特化

WasmEdgeはCNCF Sandbox(2021)→ Incubating(2024)へ昇格したランタイム。Second Stateという会社が主導するがCNCFガバナンス下にある。座標は明確。

「エッジ・IoT・サーバレス特化。AOTコンパイル優先。小さいバイナリ・低メモリ。コンテナランタイム統合(runwasi・crun)。」

差別化4点。

  1. AOT first. WasmEdgeはLLVM AOTコンパイルをデフォルト推奨。起動時間が短く(コールドスタート ~ms)、メモリフットプリントが小さい。WasmtimeはJITがデフォルト。
  2. コンテナランタイム統合. Docker DesktopがWasmEdge経由で docker run --runtime=io.containerd.wasmedge.v1 のように.wasmコンテナをサポート。crun(OCIランタイム)にもWasmEdgeバックエンドがある。
  3. wasi:nn実装が豊富。 TensorFlow Lite・OpenVINO・llama.cppバックエンドを含む。エッジでLLM・ビジョン推論を回すのに使う。2026年時点でggml(llama.cpp)バックエンドにより7B/13Bモデルをエッジで動かす事例が多い。
  4. 言語SDKが多い。 Rust・Go・JS(QuickJS埋め込み)・Python(pyo3-asyncioアダプタ)・C/C++。JSの場合はQuickJSをWASMにコンパイルした上でJSを動かす形。

基本使い方。

# AOTコンパイル
wasmedge compile hello.wasm hello.aot.wasm

# 実行
wasmedge --dir .:. hello.aot.wasm

llama.cppバックエンドでモデル推論。

wasmedge --dir .:. \
  --nn-preload default:GGML:AUTO:llama-2-7b.Q5_K_M.gguf \
  llama-chat.wasm default

いつWasmEdgeを選ぶか — コールドスタートが本当に重要なとき(エッジ関数・IoT)、Docker/k8sにWASMコンテナとして統合したいとき、またはエッジでLLM/ビジョン推論を回すとき。Component Model追従はやや遅れるが、コアWASM性能は最速級。

7. Spin(Fermyon) — サーバレスWASMプラットフォーム

SpinはFermyonが2022年に発表したサーバレスWASMフレームワーク+CLI+ランタイム。2026年現在Spin 3.x。内部ランタイムにWasmtimeを使い、その上に「関数型サーバレス」抽象を載せている。Cloudflare WorkersのWASM版 — というのが近いイメージ。

座標。

「WASMコンポーネント=関数。spin.tomlでトリガー(HTTP・Redis・Cron)を宣言。CLIでビルド・実行・デプロイ。SpinKubeでk8s運用。」

中心概念 — Spin App = N個のコンポーネント。

# spin.toml
spin_manifest_version = 2

[application]
name = "hello"
version = "0.1.0"

[[trigger.http]]
route = "/hello"
component = "hello-handler"

[component.hello-handler]
source = "target/wasm32-wasip2/release/hello.wasm"
allowed_outbound_hosts = ["https://api.example.com"]

Rustハンドラ:

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
fn handle_hello(req: Request) -> anyhow::Result<impl IntoResponse> {
    Ok(Response::builder()
        .status(200)
        .header("content-type", "text/plain")
        .body("Hello from Spin!")
        .build())
}

# ローカル実行
spin build
spin up

# Fermyon Cloudへデプロイ
spin deploy

Spinの差別化。

  1. Component Model first. Spin 2以降、WASI 0.2コンポーネントがデフォルト。
  2. トリガーが多彩. HTTP・Cron・Redis Stream・Kafka・MQTT。各トリガーが別コンポーネントを呼び出す。
  3. ホストコンポーネントが豊富. wasi:keyvalue(KV・Redis・Postgres)、wasi:sqlite(SQLite・Turso)、wasi:llm(ローカルLLM推論)、wasi:mqtt(IoT)。ゲストコードは標準インターフェースだけを呼び、Spinがバックエンドをルーティングする。
  4. SpinKube. k8sでSpinアプリをCRDで運用。kind: SpinApp を作るとk8sがWasmtimeノードプールで実行する。コンテナなしでWASMだけ回すk8sクラスタを作れる、という意味。

いつSpinを選ぶか — サーバレス関数をWASMで書くとき、マルチトリガーワークロード(HTTP + Cron + Redis)、またはk8s上でWASM関数プラットフォームを運用したいとき。Cloudflare Workersのセルフホスト版というのも誤りではない。

8. Extism — あらゆる言語のためのプラグインシステム

Extismはやや毛色の違うプロジェクト。「WASMをランタイムとして使うのではなく、プラグインシステムとして使おう」が1行サマリー。Dylibsoという会社が作る。

基本アイデア — ホストアプリケーションがユーザーの書いたコードを安全に実行するにはどうするか? 昔の答え:組み込みLua/JSインタプリタ。新しい答え:WASM。どんな言語で書こうと.wasmにコンパイルすればホストがsandboxで実行する。

Extismの差別化。

  1. 15+言語のSDK. Rust・Go・Python・Node.js・Ruby・PHP・Java・Kotlin・.NET・Elixir・Zig・C++・Haskell・OCaml・Swift。ホスト側SDKカバー範囲が最も広い。
  2. PDK(Plugin Development Kit). プラグイン作者側SDKも多彩 — Rust・Go・JS・AssemblyScript・Zig・C++など。
  3. 標準ABI. Extism独自のABI(extism_input_length・extism_alloc・extism_log_info 等)があり、ホスト-プラグイン間通信を規格化する。
  4. Component Model部分統合. 2025年からWASIコンポーネントもロードできる(完全互換ではないが大半は動く)。

ホスト側Go SDKの例:

import "github.com/extism/go-sdk"

func main() {
    manifest := extism.Manifest{
        Wasm: []extism.Wasm{
            extism.WasmFile{Path: "count_vowels.wasm"},
        },
    }
    plugin, _ := extism.NewPlugin(ctx, manifest, extism.PluginConfig{}, nil)
    _, output, _ := plugin.Call("count_vowels", []byte("hello world"))
    fmt.Println(string(output))
}

プラグイン側Rust PDK:

use extism_pdk::*;

#[plugin_fn]
pub fn count_vowels(input: String) -> FnResult<i64> {
    let count = input.chars().filter(|c| "aeiouAEIOU".contains(*c)).count();
    Ok(count as i64)
}

いつExtismを使うか — 自社プロダクトに「ユーザーコード実行」機能を入れるとき。例:SaaSのwebhook処理・DBトリガー関数・ゲームMODシステム・Notion風ワークスペースの自動化。Component Model標準への100%準拠より「いま全言語ホストで使えるプラグインABI」が重要なとき。

9. Wing(Winglang) — WASM+IaC融合言語

Wingは2022年にMonadaが発表したクラウドネイティブプログラミング言語。2024年1.0、2026年現在2.x。座標は独特だ。

「単一の言語でアプリケーションコード(ランタイム)とインフラ(コンパイル時)を同時に表現。コンパイラがTerraform・CloudFormation・k8s YAMLとWASMバイナリを同時出力。」

中心概念 — 2フェーズ(phase)モデル。 すべてのコードが preflight(コンパイル時、インフラ)または inflight(ランタイム、関数本体)のいずれかに属する。

bring cloud;

let bucket = new cloud.Bucket();
let queue = new cloud.Queue(timeout: 1m);

queue.setConsumer(inflight (msg: str) => {
  bucket.put("msg-{util.nanoid()}", msg);
});

このコードを wing compile -t tf-aws でコンパイルすると — preflightコードはTerraform HCLに変換(S3 bucket + SQS queue + Lambda function)され、inflightコードは.wasmまたは.jsにコンパイルされてLambdaへデプロイされる。-t sim を使うと同じコードがローカルシミュレータで動く — AWSを立てずに。

WingがWASMエコシステムで面白いのは — inflightコードのコンパイルターゲットの一つが.wasm(主にcomponent)であること。だからWingで書いた関数がSpinKubeのようなWASMプラットフォームに直接デプロイされる。2026年のWing 2.xでは wing compile -t spin-kube が正式サポートされる。

いつWingを使うか — インフラとアプリケーションを一つの言語でまとめたいとき、マルチクラウド抽象が必要なとき、またはWASM関数プラットフォームへIaC統合でデプロイするとき。CDK・Pulumiの次世代を狙う。

10. ブラウザWASM — GC提案、Kotlin/WASM、Dart/WASM

サーバサイドの話が長かったが、WASMの出発点はブラウザだった。2024-2026年のブラウザWASMで最大の変化は — GC(Garbage Collection)提案の主要ブラウザGA。

WasmGC以前、JVM・CLR・V8のようなGC言語をWASMにコンパイルするには自前のGCをWASMの上に実装する必要があった(linear memory内にヒープを置きmark-sweepを回す形)。結果 — メモリ使用量が2-3倍、コードサイズが大きい、ブラウザのGCと衝突(JSとWASMヒープが別々に走りcross-reference非効率)。

WasmGCはWASMレイヤーでGCオブジェクト・struct・arrayを定義する。だからコンパイラはhost GC(V8・SpiderMonkey)に委譲できる。

2026年5月時点のWasmGC利用事例。

  1. Kotlin/WASM(JetBrains) — 2024年Beta、2025年Stable。Compose Multiplatform Webターゲットのデフォルトコンパイラ。Compose for WebアプリがKotlin/WASMでビルドされ、dart-native比30-50%小さいバンドル、ほぼネイティブ速度。
  2. Dart/WASM(Google) — 2024年Stable。Flutter Webの新レンダラ(impeller・CanvasKit次世代)がDart/WASMベース。Flutter Webアプリの起動時間が半減。
  3. Java/WASM(TeaVM・CheerpJ) — TeaVMがWasmGCバックエンドを正式サポート。既存のJava GUIアプリ(Swing含む)がブラウザで動くようになった。
  4. OCaml/WASM(Wasm_of_ocaml) — 2025年リリース。Js_of_ocamlの後継。

非GC言語(Rust・C/C++・Zig)は依然としてlinear memoryのみを使う — 自前のメモリ管理がある言語のため、GCは要らない。

ブラウザWASMのもう一つの大きな論点 — Component Modelをブラウザに持ち込むか。 いまのところ「ノー」。ブラウザWASMはJSとのABI統合にwasm-bindgen/Jcoで十分で、Component Modelはサーバサイド利用に最適化されている。ただしJco(JSコンポーネントランタイム)がブラウザでも動くため、結果的に迂回路は開いている。

11. 誰が実際にWASMをproductionで使っているか

理論はもう十分なので実例を見る。2026年5月時点で確認済みのproduction利用事例(公開発表・ブログ・カンファレンス基準)。

Cloudflare Workers

V8 isolateベースで知られているが、2024年から一部ワークロードはWasmtimeベースのコンポーネントで動く。特にWorkers AI、Durable Objectsの一部バックエンド、そしてWorkers for Platformsのサードパーティコード実行。Workers Component Bindings(2025年後半発表)はComponent Modelコンポーネントを直接Workersにデプロイできる。

Shopify Functions

Shopifyが2022年からマーチャントが投稿したRust/JSコードをWASMにコンパイルし、チェックアウト・割引・配送ロジックを実行している。バックエンドはWasmtime。1リクエストあたり~5ms・1MBメモリ上限。2026年時点で日次10億+ 呼び出し。

Fastly Compute

Fastlyのエッジコンピュートプラットフォーム。最初からWasmtimeベース。2026年時点でComponent Modelがデフォルト(WASI 0.2)。FastlyはBytecode Allianceのコアメンバーでもある。

Figma

Figmaのレンダリングコアは C++ で書かれ、WASMにコンパイルされる。 2017年から。Figma Desktopも同じWASMモジュールをElectron内で動かす。これが可能な理由 — WASMのSIMD・ThreadsがGAされてほぼネイティブ速度が出るから。

Adobe(Photoshop Web・Illustrator Web)

Photoshopの中核画像処理エンジン(C++)をEmscriptenでコンパイルしブラウザで動かす。2021年Photoshop Web Beta、2023年Illustrator Web。フルデスクトップPhotoshopの30-50%機能がブラウザで動作。

AutoCAD Web

AutoDeskが2018年からAutoCADのC++コアをWASMでビルド。2D/3D CADをブラウザでフル機能。

Disney+、Microsoft Office for Web

Disney+動画プレーヤーの一部(コーデック追加処理)とOffice for WebのExcel・WordコアがWASMにコンパイルされたC++モジュールに依存。

Bloomberg Terminal Web

2024年リリース。1990年代のC++ベースターミナルをWASMに移してブラウザで動作。

12. 韓国・日本のWASM活用事例

海外事例ほど頻繁に取り上げられないが、韓国・日本でもproduction利用がある。公開資料ベース。

LINE — 日本・韓国

LINEの一部エッジワークロードがWASMコンポーネントで運用されている。特にチャットメッセージのスパム・不正コンテンツフィルタリングがWasmtimeベースのサイドカーで動く。LINE Engineering Blogで2024年に発表。メリットは — ルール更新をコンテナ再デプロイなしに.wasmモジュール差し替えで済むこと。

Toss — 韓国

Tossの一部セキュリティ検証ロジック(クライアント改ざん検出)がWASMにコンパイルされたRustモジュールで動く。トスペイメンツでもPGマーチャントが投稿した検証ルールをExtismベースで実行。SLASH 2024カンファレンスで一部公開。

Coupang — 韓国

Coupangの検索ランキング推論の一部がWasmEdge + wasi:nnの上で動く — 正確にはONNXモデルをWasmEdgeに統合した形。検索レイテンシ安定性と多言語モデル統合に有利。

ZOZO — 日本

ZOZOTOWNのレコメンドシステムA/Bテスト基盤で実験的なルールをWASMモジュールとしてデプロイ。ルール変更をビルドなしのホットリロードで行うため。2025年ZOZO Tech Blogで公開。

Mercari — 日本

Mercariの決済検証の一部(特に本人確認ルールエンジン)がWASMベース。2026年初頭のMercari Engineering Blogで事例公開。

CyberAgent — 日本

CyberAgentの広告配信の一部エッジロジックをSpinKubeで運用。Spin/SpinKubeをproductionに最も積極的に投入した日本事例の一つ。

NTTドコモ・KDDI

5G MEC(Multi-access Edge Computing)ノードでWasmEdgeをコンテナ代替として実験中。小さなフットプリントと速いコールドスタートが5Gエッジに合う。2025年NTT Technical Reviewで事例掲載。

13. ツール集 — WAC・Jco・wasm-tools・Wash

最後に日常的に使うツール集。

wasm-tools

Bytecode Allianceの万能CLI。迷ったらまずwasm-tools。

# コンポーネントヘッダ確認
wasm-tools component wit greeter.wasm

# コンポーネント検証
wasm-tools validate --features all greeter.wasm

# WATへディスアセンブル
wasm-tools print greeter.wasm | less

# コンポーネント -> 組み立てたコアモジュール
wasm-tools component unbundle greeter.wasm

WAC(WebAssembly Composition)

複数のコンポーネントを合成してより大きなコンポーネントを作るツール。 Component Modelの真価はコンポジションにある。WACがそれを可能にする。

# authコンポーネント+storageコンポーネントを束ねてappコンポーネントへ
wac compose -d auth=./auth.wasm -d storage=./storage.wasm \
  -o app.wasm composition.wac

package example:app;

let auth = new auth:lib { ... };
let storage = new storage:lib { ... };
let app = new app:lib {
  authenticator: auth.authenticator,
  store: storage.store,
};

export app...;

Jco(JavaScript Component Toolkit)

JSとComponent Modelの架け橋。 双方向対応。

  1. .wasmコンポーネントをJSから呼ぶ — jco transpile greeter.wasm でESモジュールラッパーを生成。
  2. JSソースをコンポーネントへコンパイル — jco componentize greet.js -w greet.wit で.wasmコンポーネント生成(StarlingMonkey JSエンジン埋め込み)。
# RustコンポーネントをJSから使う
jco transpile ./greeter.wasm -o ./out
# out/greeter.js, out/greeter.d.ts, out/greeter.core.wasm が生成される

import { hello } from './out/greeter.js'
console.log(hello('world')) // "Hello, world!"

Wash(wasmCloud Shell)

wasmCloudのCLI/REPL。wasmCloudは別のWASMプラットフォームで、分散アクター(actor)モデルの上にコンポーネントを載せるアプローチ。NATSメッセージバス上でアクターが通信する。

# ローカルwasmCloudホスト起動
wash up

# コンポーネント(アクター)起動
wash start component ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0

# capability provider(HTTPサーバ)起動
wash start provider ghcr.io/wasmcloud/http-server:0.20.0

いつwasmCloudを使うか — 分散アクターモデルが合うワークロード(IoT・ゲームサーバ・分散シミュレーション)、多数のノードへコンポーネントを動的にデプロイする必要があるとき。Spinが「サーバレス関数」ならwasmCloudは「分散アクターメッシュ+コンポーネント」。

エピローグ — 2026年にWASMをどう見るか

ここまでが2026年5月のWASMエコシステム地図だ。頭に入るようにもう一度縮めると:

  1. 標準が固まった。 WASI 0.2(コンポーネントモデル)が2024.01 GA、WASI 0.3(async)が2025 Q4 GA。「待つ段階」は終わった。
  2. ランタイムは4強。 Wasmtime(標準)、Wasmer(商用+レジストリ)、WasmEdge(エッジ/IoT)、Spin(サーバレスプラットフォーム)。迷ったらWasmtime。
  3. WASM最大の価値はもはや「速いブラウザコード」ではない。 「一度ビルドしてブラウザ・サーバ・エッジ・プラグインホストすべてで動く」汎用実行レイヤーだ。Component Modelがそれを可能にした。
  4. 誰が使っているか — 大手はすでにproductionで使っている。 Cloudflare・Shopify・Fastly・Figma・Adobe・LINE・Toss・Coupang・ZOZO・Mercari・CyberAgent。
  5. いつ使うか — (a) ユーザーコードを安全に実行する必要があるとき(Extism)、(b) エッジ関数のコールドスタートが短くなければならないとき(Spin・WasmEdge)、(c) 多言語ライブラリをサーバサイドで呼び出すとき(Wasmtime+Component Model)、(d) 重いネイティブロジックをブラウザへ持っていくとき(Emscripten・wasm-bindgen)。
  6. いつ使わないか — 普通のマイクロサービス、ネイティブOS APIが深く必要なコード、GPU直接アクセス(wasi:graphicsはまだ標準化中)、既存のコンテナワークロードで満足のとき。

最後に一行。2017年にWASM 1.0がブラウザに入ったとき、9年後にCloudflare・Shopify・LINEがproductionで回しているとは誰が予想しただろう。標準が一つGAになるのに7年、市場がその標準に乗るのにさらに2年。 これがインフラが固まる速度だ。今が2026年で、自分のチームが使わないなら隣のチームが使っている。

参考文献 / References

Discuss on Twitter • View on GitHub