WebAssembly (Wasm) エコシステム 2026 完全ガイド - Wasmtime・WasmEdge・Wasmer・WASI 0.2・Component Model・Spin (Fermyon)・Cosmonic wasmCloud・Bytecode Alliance・Wasmer Edge・WAVM 徹底解説

「Wasmの本質はもはや『ブラウザの中で速く動くコード』ではない。コンテナとJavaScriptの間にあった空白を埋める、ポータブルで安全な隔離プリミティブだ。2026年のWasmはまさにその位置にいる。」 — Bytecode Alliance, State of Wasm 2025

WebAssembly(以下Wasm)は、2017年にブラウザ4社(Chrome・Firefox・Safari・Edge)がMVPを公表してから9年でまったく別の領域に到達しました。2024年1月25日にWASI 0.2(Preview 2)がGAし「標準システムインターフェース」問題が解け、Component Model Preview 2が「言語間呼び出し」問題を解きました。結果として2026年のWasmは、ブラウザよりもサーバ・エッジ・プラグイン・組み込みで速く成長しています。

2026年5月時点のWasm生態系は単独勝者をもたず、リファレンスランタイム(Wasmtime)、CNCFエッジ(WasmEdge)、マルチコンパイラ(Wasmer)、組み込み(WAMR)、純Go(wazero)、ブラウザ(V8・SpiderMonkey・JSC) の6陣営に分岐しました。本稿ではランタイム・WASI・Component Model・PaaS・言語サポート・AI/ML・プラグイン・実例導入までを一気に整理します。

1. 2026年のWasm地図 — ブラウザを越えた5領域

2026年のWebAssemblyは大きく5領域に分けられます。

要点は、「Wasmの本当の価値はコンパイル済み.wasmモジュールではなく、wit ファイルで定義されたComponent Modelインターフェース」 だという点です。WASI 0.2のGAによって、1枚のwitファイルからRust・Go・Python・Rubyが互いを呼べるようになり、Wasmは「次世代コンテナ」よりむしろ「次世代ABI」として位置づけられるようになりました。

2. WASI 0.2 GA — 2024年1月の分岐点

WASI(WebAssembly System Interface)はWasmモジュールがホスト側のファイル・ネットワーク・時計などのシステム資源にアクセスするための標準インターフェースです。2019年にPreview 1が公表された後5年間漂流しましたが、2024年1月25日にWASI 0.2(Preview 2)がGAし、ようやく分岐点が来ました。

WASI 0.2の核心変更は3つです。第一に、Component Modelに基づくインターフェース分割 — wasi:cli, wasi:http, wasi:filesystem, wasi:sockets, wasi:keyvalue, wasi:logging などが個別の world に分かれ、ホストは必要な権限だけを露出できます。第二に、POSIX互換を捨てた能力ベース(capability-based)モデル — 既定のファイルディスクリプタではなくリソースハンドルを明示的に渡します。第三に、言語中立なインターフェース定義 — witファイルが標準となり、Rust・Go・Pythonのバインディングを同時生成します。

# wasm32-wasip2 ターゲットでビルド(Rust 1.78+)
rustup target add wasm32-wasip2
cargo build --target wasm32-wasip2 --release

# 結果モジュールの実行(Wasmtime 21+)
wasmtime run --wasi http target/wasm32-wasip2/release/myapp.wasm

# witファイルでインターフェース定義
cat > world.wit <<'WIT'
package example:greet@0.1.0;

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

world greet-world {
  export greeter;
}
WIT

WASI 0.3のロードマップは非同期(async)とストリーム対応が核心です。2026年5月時点で 0.3 はpre-release で、2026年後半のGAを目指しています。

3. Component Model — WasmをABIにした決定打

Component Modelは「モジュール単位ではなくコンポーネント単位で合成する」という概念です。従来のWasmモジュールはi32・i64・f32・f64・v128しか受け渡しできませんでしたが、コンポーネントはrecord・variant・list・option・result・stringなど豊かな型をwitインターフェースで定義し、言語間で直接やり取りします。

// wit インターフェース例
package shop:checkout@0.2.0;

record cart-item {
  sku: string,
  quantity: u32,
  unit-price-cents: u64,
}

variant payment-method {
  card(string),
  bank-transfer,
  crypto(string),
}

interface checkout {
  use cart-item;
  use payment-method;

  finalize: func(items: list<cart-item>, method: payment-method)
    -> result<string, string>;
}

world checkout-service {
  export checkout;
  import wasi:http/outgoing-handler@0.2.3;
}

このwitファイル1枚から wit-bindgen がRust・Go・Python・JSバインディングを自動生成します。呼び出し側はコンポーネントがどの言語で書かれているか知る必要がなく、ホストはコンポーネントのimport/exportを満たしさえすれば実行できます。2026年5月時点で Component Model Preview 2 が安定段階に入っており、Preview 3 のロードマップにはasync と stream の正式対応が含まれています。

4. Wasmtime — Bytecode Allianceのリファレンスランタイム

WasmtimeはBytecode Allianceが開発するWasm・WASIのリファレンスランタイムで、Rust製、Craneliftコンパイラを採用しています。2026年5月時点でWasmtime 25(LTS)が安定版で、プロジェクトはSemVerに従います。

Wasmtime の強みは3つあります。第一に、Component Model のファーストクラス対応 — 0.2 GA に合わせて最も早くコンポーネント実行を安定化させました。第二に、決定論的実行と fuel メカニズム — Config::consume_fuel(true) で命令単位の上限を設定でき、マルチテナント環境で決定的に重要です。第三に、プーリングアロケータ — コンポーネントのインスタンス化コストが100マイクロ秒程度で、サーバレスのコールドスタートに最適です。

// Wasmtime 25 - コンポーネントを埋め込む例
use wasmtime::{Engine, Config, Store};
use wasmtime::component::{Component, Linker};

let mut config = Config::new();
config.wasm_component_model(true);
config.consume_fuel(true);
let engine = Engine::new(&config)?;

let component = Component::from_file(&engine, "checkout.wasm")?;
let mut linker = Linker::new(&engine);
wasmtime_wasi::add_to_linker_sync(&mut linker)?;

let mut store = Store::new(&engine, MyState::default());
store.set_fuel(10_000_000)?;

let instance = linker.instantiate(&mut store, &component)?;
let finalize = instance.get_typed_func::<(Vec<CartItem>, PaymentMethod), Result<String, String>>(
    &mut store, "finalize"
)?;
let result = finalize.call(&mut store, (items, method))?;

WasmtimeはFermyon Spin・Shopify Functions・Microsoft Hyperlight・Fastly Computeの基盤として採用されており、事実上の業界標準となっています。

5. WasmEdge — CNCFのエッジ・サーバランタイム

WasmEdgeはSecond Stateが立ち上げたWasmランタイムで、2021年にCNCF Sandbox、2024年にIncubatingへ昇格しました。C++で書かれており、LLVMベースのAOTコンパイラを内蔵します。

WasmEdgeの強みはエッジ・組み込み領域に特化した拡張です。wasi-nnでONNX・OpenVINO・PyTorchの推論を回し、WasmEdge TensorFlow PluginでモバイルやIoTでもMLを動かせます。さらにLangChainやllama.cppと統合し、LLMをWasm上で動かす事例が増えています。

# WasmEdge のインストールとLLM実行例
curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh \
  | bash -s -- --plugin wasi_nn-ggml

# 8B モデル推論(Llama 3.1 ベース)
wasmedge --dir .:. \
  --nn-preload default:GGML:AUTO:llama-3.1-8b-instruct-Q5_K_M.gguf \
  llama-chat.wasm \
  --prompt-template llama-3-chat \
  --ctx-size 4096

WasmEdgeはDocker DesktopがWasmランタイムとして統合した2つのプロジェクト(WasmtimeとWasmEdge)のうちの1つで、docker run --runtime=io.containerd.wasmedge.v1 ... のかたちでコンテナツールチェインに直接組み込めます。

6. Wasmer — マルチコンパイラ + Wasmer Edge

Wasmer(2019〜)は複数のコンパイラバックエンド(Cranelift・LLVM・Singlepass)を選択できるWasmランタイムです。Rust製で、2026年5月時点で Wasmer 5 が最新安定版です。

Wasmerの差別化要素は言語ごとのSDKが最も豊富である点です。Rust・C/C++・Python・Go・JavaScript・Java・Ruby・PHP・C#・Swift・R 向けの公式SDKがあり、「自分の言語の中からwasmモジュールをホストする」体験が滑らかです。また、WAPM(WebAssembly Package Manager) を運用し、wasmモジュールをnpmのように配布・検索できます。

// Wasmer Rust API - Cranelift バックエンド
use wasmer::{Store, Module, Instance, Value, imports};
use wasmer_compiler_cranelift::Cranelift;

let compiler = Cranelift::new();
let mut store = Store::new(compiler);

let module = Module::from_file(&store, "add.wasm")?;
let import_object = imports! {};
let instance = Instance::new(&mut store, &module, &import_object)?;

let add = instance.exports.get_function("add")?;
let result = add.call(&mut store, &[Value::I32(2), Value::I32(3)])?;

Wasmer Edge(2023〜)は独自のサーバレスPaaSで、git push 1回でwasmコンポーネントをグローバルエッジに配置できます。Cloudflare WorkersやFastly Computeの競合で、差別化点は Wasmerがビルドできるどの言語でも同じように配置できる ことです。

7. WAMR — Intelの組み込み向けWasm

WAMR(WebAssembly Micro Runtime)はIntelが主導する組み込みフレンドリーなWasmランタイムで、Bytecode Alliance傘下のプロジェクトです。インタプリタ・クラシックJIT・Fast JIT・AOTの4つの実行モードに対応し、メモリフットプリント50KB以下でRISC-V・ARM・Xtensaなどのマイクロコントローラ上で動作します。

WAMRはIoT・自動車・産業用PLCで急速に採用が進んでいます。2025年にはBMWが車載インフォテインメントの一部モジュールをWAMRベースWasmへ移行したと発表し、NVIDIA Jetsonラインアップでもエッジ推論モジュールをWAMRで隔離するパターンが出てきています。

# WAMR - STM32 ARM Cortex-M ビルド例
git clone https://github.com/bytecodealliance/wasm-micro-runtime
cd wasm-micro-runtime/product-mini/platforms/zephyr/simple

# Zephyr SDK で RTOS 組み込みビルド
west build -b nucleo_f767zi -p auto

# 生成バイナリにwasmモジュールが含まれ、起動時に自動ロード
west flash

WAMRの弱点はComponent Modelの対応が部分的であることです。組み込みではモジュール単位での実行が依然として一般的ですが、Bytecode Allianceとしてもコンポーネント対応の強化を進めています。

8. wazero — 純Goで書かれたWasm

wazero(Tetrate, 2022〜)はCGOなしの純GoでつくられたプロダクションWasmランタイムで、現状で唯一の存在です。Goエンジニアにとって最大の魅力はクロスコンパイルがそのまま機能することです — LinuxでビルドしたバイナリをそのままmacOS・Windows・FreeBSDに持ち込め、Dockerイメージは5MB以下に収まります。

// wazero - Goからwasmモジュールを呼び出す
package main

import (
    "context"
    "os"
    _ "embed"
    "github.com/tetratelabs/wazero"
    "github.com/tetratelabs/wazero/imports/wasi_snapshot_preview1"
)

//go:embed app.wasm
var appWasm []byte

func main() {
    ctx := context.Background()
    r := wazero.NewRuntime(ctx)
    defer r.Close(ctx)

    wasi_snapshot_preview1.MustInstantiate(ctx, r)

    config := wazero.NewModuleConfig().
        WithStdout(os.Stdout).
        WithStderr(os.Stderr).
        WithArgs("app", "--input", "hello")

    _, err := r.InstantiateWithConfig(ctx, appWasm, config)
    if err != nil {
        panic(err)
    }
}

wazeroはEnvoy・Dapr・OpenTelemetry Collector・Tetrate Service BridgeなどGo陣営の主要プロジェクトのプラグインホストとして採用されています。トレードオフはAOTコンパイルがなく、ホットループ性能がWasmtimeの60〜70%程度であることですが、その代わりコールドスタートは最速クラスです。

9. WAVM — LLVMベースの研究系ランタイム

WAVM(WebAssembly Virtual Machine)はAndrew Scheideckerが開発したLLVMベースのWasmランタイムで、学術・研究領域で影響力を持つプロジェクトでした。2026年時点で活発な開発は鈍化しましたが、Cranelift・LLVMのWasmバックエンドに着想を与え、一部のHPCワークロードでは現役です。

10. ブラウザエンジン — V8・SpiderMonkey・JSC

ブラウザは依然としてWasmの最大の利用先です。3つの主要エンジンはいずれも2段階のコンパイルパイプラインを採用しています。

V8(Chrome・Edge) はLiftoff(5ms以内に初回実行を生み出すベースラインコンパイラ)とTurboFan(バックグラウンドでホット関数を最適化する最適化コンパイラ)を組み合わせます。V8はWasm GC・Tail Calls・Exception Handling・SIMD・Threads・JSPIを最も早く安定化させたエンジンでもあります。

SpiderMonkey(Firefox) はWasmコンパイラとしてCraneliftを採用しており、Firefox自体をBytecode Allianceスタックに直結させています。CraneliftはFirefox 110で安定段階に入り、GC・Threads・SIMDはいずれも安定対応です。

JavaScriptCore(Safari) はBBQ(Build Bytecode Quickly)とOMG(Optimized Machine code Generator)の2段階コンパイラを使います。Safari 18でWasm GCとTail Callsが安定段階に入り、2026年のSafari 19ではJSPIの安定対応が追加されました。

11. Wasm GC・Tail Calls・Exception Handling — Phase 4 達成

2024〜2025年にかけて3つの中核提案がPhase 4(標準採択)へと到達しました。

Wasm GCはWasmモジュールがホストのGCオブジェクト(JavaScriptオブジェクト、JVMオブジェクト)と直接相互運用できるようにする仕組みです。これまではWasmモジュールが自身のリニアメモリ内でしかオブジェクトを扱えませんでしたが、GC提案によってstruct・array・ref型が追加されました。結果としてKotlin/Wasm・Dart→Wasm・Java→Wasmバックエンドが実用的な性能を出せるようになりました。

Tail Callsは関数型言語(Scheme・OCaml・Haskell・Scala)や一部コンパイラ(JVMのtail-rec)がWasmターゲットを取るうえで核心となる機能でした。2025年1月にPhase 4に到達しました。

Exception HandlingはC++・C#・Java→Wasmでthrow/catchを自然に表現するための機能で、2024年にPhase 4に到達しています。

// Wasm GC を使った Kotlin/Wasm 概念図
// Kotlin 側:
//   data class User(val id: Int, val email: String)
//   fun greet(u: User) = "Hello, ${u.email}!"
//
// 概念的なコンパイル後 wat:
//   (type $User (struct (field $id i32) (field $email (ref string))))
//   (func $greet (param $u (ref $User)) (result (ref string)) ...)

12. JSPI・Memory64・js-string-builtins — Phase 4 新規入り

2025年にはさらに3つの提案がPhase 4に到達しました。JSPI(JavaScript Promise Integration) は同期Wasm関数からJSのPromiseを待てるようにする機構で、Pyodide・Ruby.wasm・Blazor のように「JS の非同期IOを呼ぶ必要のある」ランタイムにとって決定的でした。

Memory64はwasm32の4GiBメモリ上限を64ビットアドレッシングへ拡張します。AutoCAD WebやPhotoshop Webのような大容量メモリアプリの基盤です。

js-string-builtinsはJavaScriptのStringメソッド(charCodeAt・fromCharCode・length など)を、wasm import を経由せずに直接呼べるようにします。文字列処理性能が2〜5倍向上しました。

13. Fermyon Spin — Wasmサーバレスの先頭走者

Fermyon Spin(Matt Butcher, 2022〜)はWasmコンポーネントをHTTPトリガのサーバレス関数として実行するフレームワークです。2026年5月時点でSpin 3.xが安定版で、GitHubスター6K+を保持しています。

Spinの中心価値はサブミリ秒のコールドスタートです。Wasmtimeのpooling allocatorを活用することで、インスタンス化コストは1万分の1秒オーダー — AWS Lambda(100〜500msのコールドスタート)とは別の応答性ティアにあります。

// Spin 3.x - HTTPトリガ
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");
    Ok(Response::builder()
        .status(200)
        .header("content-type", "text/plain")
        .body(format!("Hello, {name}!"))
        .build())
}

# spin.toml
spin_manifest_version = 2

[application]
name = "hello-wasm"
version = "0.1.0"
authors = ["youngju@example.com"]

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

[component.hello]
source = "target/wasm32-wasip1/release/hello.wasm"
allowed_outbound_hosts = ["https://api.openai.com"]

Fermyon CloudはSpinアプリを spin deploy ひとつで配置するPaaSで、2024年からはFermyon Wasm FunctionsとしてAkamaiのエッジ上でも直接稼働しています。Microsoft Azureも2025年、SpinをAzure FunctionsのWasmワーカーとして統合するプレビューを公表しました。

14. Cosmonic wasmCloud — CNCFの分散アクターモデル

wasmCloud(Cosmonic, 2020〜)は分散アクターモデルベースのWasmプラットフォームです。2022年にCNCF Sandbox、2024年にIncubatingへ昇格しました。Spinが「関数単位サーバレス」だとすれば、wasmCloudは「アクター・複数ノード・ルーティング・capability provider」を標準化したより大きなシステムです。

wasmCloudの核心概念はCapability Providerです。アクター(wasmコンポーネント)はKV・メッセージング・HTTPサーバなどの「機能」が必要だとwitインターフェースで宣言するだけで、実装はホストノードがcapability providerの形で実行時に提供します。この分離のおかげで、同じアクターをdev環境ではSQLite KV、prod環境ではRedis KVとして実行できます。

# wash CLI で wasmCloud を運用
wash up                          # ホストノード起動
wash app deploy app.yaml         # アクターを配置(wadm マニフェスト)
wash app list
wash claims inspect actor.wasm   # 署名済みアクターのメタデータ確認

wasmCloudはBMW Group・IBM・Akamaiが本番採用事例を公表しており、2025年末のCNCF Graduation を目指して準備中です。

15. Cloudflare Workers — V8 + Wasm ハイブリッド

Cloudflare WorkersはV8 isolate上で動作するサーバレスプラットフォームですが、Wasmモジュールを一級市民として扱います。JS/TS WorkerからインポートしたWasmモジュールはV8でそのまま動き、コールドスタートは5ms以下です。

2025年にCloudflareは workerd(Workersランタイムのオープンソース版)を公開し、外部環境でも同じモデルでWasmをホストできるようにしました。workerdは外部サービス(KV・D1・R2・Queue)とCap'n Proto RPCで通信します。

// Cloudflare Workers - JSからwasmを呼ぶ
import wasm from "./image_resize.wasm";

export default {
  async fetch(request: Request, env: Env) {
    const module = await WebAssembly.instantiate(wasm, {
      env: { now: () => Date.now() }
    });
    const buf = await request.arrayBuffer();
    const resized = module.instance.exports.resize(buf, 800, 600);
    return new Response(resized, {
      headers: { "content-type": "image/webp" }
    });
  }
};

特筆すべきは Cloudflare D1 で、バックエンドはSQLite-WASMをV8 isolateの中で動かしています。同じwasmがブラウザのOPFS(Origin Private File System)上でも動き、「オフラインファースト」のSQLiteを実現します。

16. Fastly Compute — 純Wasm PaaS

Fastly Compute@Edgeは純Wasmベースのサーバレスプラットフォームで、JSエンジンを経由せずにWasmtimeを直接使います。2026年5月時点でRust・Go(TinyGo)・JavaScript(組み込みSpiderMonkey)・AssemblyScript を公式サポートします。

Fastly Computeの強みは35マイクロ秒のコールドスタートという極端な応答性で、同じバイナリがFastlyのPoP 80カ所以上に同時配置されます。トレードオフはV8 isolateではないためnpmエコシステム全体を持ち込めない点ですが、Fastlyはこの課題に対し、SpiderMonkey自体をWasmにビルドして組み込むという解決策をとりました。

// Fastly Compute Rust SDK
use fastly::{Error, Request, Response};

#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
    let path = req.get_path();
    if path == "/healthz" {
        return Ok(Response::from_status(200).with_body_text_plain("ok"));
    }
    let upstream = req.send("origin_0")?;
    Ok(upstream)
}

17. Wasmer Edge・Suborbital Sat — その他PaaS

Wasmer Edge(2023〜)はwasmモジュールをグローバルエッジにワンコマンドで配置する独自PaaSです。Fastly Computeと似たモデルですが、Wasmerのマルチコンパイラバックエンドとwapmパッケージマネージャが統合されている点が差別化要素です。

Suborbital Sat(2022〜)は分散システムにwasm関数を埋め込むためのライブラリでしたが、2024年にF5に買収され、NGINX Wasm 統合の流れの一部に吸収されました。NGINXはnjsと並んでWasmフィルタを推す方向に進んでいます。

18. 言語サポート — Rust が一級、Go・Python・Java が追走

Wasmターゲットを持つ言語は2026年5月時点で40を超えました。主な言語のステータスは次の通りです。

MoonBit(IDEA Software, 2023〜)は最も興味深い新言語です。Wasmを一級ターゲットとして設計されており、2025年に1.0が公開されました。Rustよりコンパイルが速く、wasm出力サイズも小さい点が強みです。

// MoonBit - Wasm ファースト設計
pub fn fib(n : Int) -> Int {
  if n < 2 {
    n
  } else {
    fib(n - 1) + fib(n - 2)
  }
}

pub fn main {
  println(fib(20))
}

19. Rust + Wasm — 最も成熟した組み合わせ

Rustは2018年からWasmの一級ターゲットで、2026年5月時点で3つの中心ターゲットをサポートします。

• wasm32-unknown-unknown: ブラウザ向け、標準ライブラリは一部のみ利用可
• wasm32-wasip1: WASI Preview 1、従来のPOSIX互換モード
• wasm32-wasip2: WASI Preview 2、Component Modelを一級でサポート

# Rustでコンポーネントをビルドして検査
rustup target add wasm32-wasip2
cargo install cargo-component

# wit インターフェース + Rust 実装
cargo component new my-checkout --lib
cd my-checkout
# wit/world.wit を作成のうえ
cargo component build --release

# wasm-tools でコンポーネントのメタデータを確認
wasm-tools component wit target/wasm32-wasip2/release/my_checkout.wasm

Rust+Wasmワークフローの中心となる4ツールは、wasm-bindgen(ブラウザ)、wit-bindgen(コンポーネント)、wasm-tools(メタデータ・合成)、wasm-pack(npmパッケージ化)です。

20. Go・TinyGo・Python・Ruby — 非Rust言語の道

Goは1.21から GOOS=wasip1 ターゲットを標準サポートしています。トレードオフはGoランタイム自体が大きいため、生成wasmが数MBに達することです。TinyGoはLLVMベースのGoコンパイラで、100KB級のwasmを出力します。標準ライブラリの一部は欠けますが、組み込み・エッジ領域では事実上の標準です。

Pythonには2つの道があります。PyodideはCPythonをEmscriptenでビルドしたもので、ブラウザ上でNumPy・Pandas・SciPyまで動かせます。py2wasm(Wasmer)はCPythonバイトコードをwasmへ変換し、より高速な実行を狙います。

Rubyには公式の ruby.wasm プロジェクト(Yuta Saito, 2022〜)があり、Ruby 3.2から本体に取り込まれました。Rails自体はまだ難しいですが、ブラウザ上でRuby DSLを動かす事例は増えています。

<!-- ruby.wasm ブラウザ例 -->
<script src="https://cdn.jsdelivr.net/npm/@ruby/3.3-wasm-wasi@latest/dist/browser.script.iife.js"></script>
<script type="text/ruby">
  require "js"
  puts "Hello from Ruby #{RUBY_VERSION}!"
  document = JS.global[:document]
  document.body.innerText = "Ruby in the browser"
</script>

21. Java・.NET・Kotlin・Swift — エンタープライズ陣営

Javaには2系統あります。TeaVM(2014〜)はJVMバイトコードをwasmへ変換するコンパイラで、GraalVM Native Imageは2024年からwasmバックエンドが実験段階に入りました。Wasm GCが標準化されたことでJava→Wasmの性能が実用域に入りました。

.NETはBlazor(ブラウザ)と Mono+WASI(サーバ)の2トラックです。Blazor WebAssemblyは.NET 9でAOT性能が大きく改善され、.NET 10(2025年11月)ではWASI 0.2を正式サポートします。

Kotlin/WasmはJetBrainsの優先事項です。2024年にKotlin Multiplatformのwasmターゲットがプレビュー入りし、Compose Multiplatformがwasmターゲットでブラウザ向けUIをビルドできるようになりました。

SwiftWasmはコミュニティ主導ですが、Swift 6.0で公式ツールチェインに部分統合されました。

22. Wasm + AI/ML — wasi-nn・WebLLM・ONNX Runtime Web

WasmはAI/ML推論領域で急速に定着しつつあります。中心となる標準は wasi-nn で、ホストがGPU・NPUアクセラレーションを提供し、wasmモジュールが標準APIで呼び出します。

WebLLM(MLC-AI, 2023〜)はLLMをブラウザ内で直接動かすプロジェクトです。WebGPU + Wasmの組み合わせで、量子化されたLlama 3.1 8Bをノートパソコン搭載GPUで推論します。同チームのMLC-Chatは同モデルをモバイルでも動かします。

ONNX Runtime WebはPyTorch・TF・scikit-learnモデルをONNXへ変換したうえでwasm上で実行します。SIMD・Threads・WebGPUバックエンドを自動選択します。

Burn(Rust)と Candle(Rust, Hugging Face)はRust製MLフレームワークで、wasmターゲットを一級サポートします。同じコードをサーバGPUとブラウザwasmの両方で動かすシナリオを狙います。

// Candle - Rust の ML を wasm へ
use candle_core::{Device, Tensor};
use candle_nn::{linear, Module, VarBuilder};

// 小さな MLP の推論
fn forward(weights: &VarBuilder, x: &Tensor) -> anyhow::Result<Tensor> {
    let l1 = linear(784, 128, weights.pp("l1"))?;
    let l2 = linear(128, 10, weights.pp("l2"))?;
    Ok(l2.forward(&l1.forward(x)?.relu()?)?)
}
// ビルド: cargo build --target wasm32-unknown-unknown

23. Extism・proxy-wasm — プラグインシステム

Extism(Dylibso, 2022〜)は「どこでも同じプラグインAPI」を目指すユニバーサルプラグインフレームワークです。C・Rust・Go・Python・Node・Ruby・PHP・Java・.NET向けのホストSDKが揃っており、同じwasmプラグインが9言語ホストで同一に動きます。

// Extism プラグイン(Rust で実装)
use extism_pdk::*;

#[plugin_fn]
pub fn count_vowels(text: String) -> FnResult<Json<serde_json::Value>> {
    let count = text.chars().filter(|c| "aeiouAEIOU".contains(*c)).count();
    Ok(Json(serde_json::json!({ "vowels": count })))
}

# Extism Python ホスト
import extism

manifest = {"wasm": [{"path": "count_vowels.wasm"}]}
with extism.Plugin(manifest, wasi=True) as plugin:
    result = plugin.call("count_vowels", b"Hello, Wasm!")
    print(result.decode())  # {"vowels": 3}

proxy-wasmはEnvoy・Istio・NGINX・Kongなどのプロキシが採用するwasmフィルタABIです。Rust・Go・AssemblyScriptで書かれたフィルタは、proxy-wasm互換のどのプロキシ上でも同一に動作します。

24. 実例導入 — Figma・Adobe・AutoCAD・Notion

WebAssemblyの実例導入は、2017年にFigmaがC++製レンダリングエンジンをwasmへコンパイルしたことから始まりました。FigmaはwasmによってElectronデスクトップとWebが同じコードを共有できるようになり、これ以降の「Webへ向かうデスクトップアプリ」全般の青写真となりました。

Adobe Photoshop Web(2021)は25年もののC++コードベースをEmscriptenでwasm化した代表事例です。64ビットメモリが必要なほど巨大で、Memory64提案の推進力にもなりました。

AutoCAD Web(Autodesk)も同パターンで、35年もののObjectARX C++コードをwasmへ移して、ブラウザ上でのDWG編集を実現しています。

Cloudflare D1はSQLiteをwasmへビルドしてV8 isolate内で動かしています。同じwasmはブラウザのOPFS(Origin Private File System)上でも動かせ、「オフラインファースト」アプリの基盤になっています。

Notion AI inlineはテキストの後処理の一部をクライアント側wasmへ移して応答遅延を短縮し、Microsoft Office Web の数式エンジンの一部もwasmで動作しています。

25. 韓国事例 — NAVER・Kakao・LINE

NAVER Cloud Wasm Functions(2024年発表)はWasmtimeベースのサーバレスで、Spinに似たモデルですが韓国リージョン・課金システムへ統合されています。NAVER内部の検索・翻訳の後処理モジュールの一部がwasm上で運用されています。

KakaoはKakaoTalkのチャットボットメッセージ後処理の一部をwasmプラグインで隔離するR&Dを2024年に発表しました。proxy-wasm互換フィルタが採用候補として検討されています。

LINEヤフー(旧Yahoo! JAPAN)はメール・ニュースのコンポーネントの一部でwasmベースの隔離を採用し、広告サンドボックスにwasmを使う事例発表もありました。

26. 日本事例 — Cybozu・NTT・DeNA・Mercari

CybozuはkintoneのJavaScriptユーザーコード隔離にwasm導入のR&Dを発表しました。ユーザーが書いた任意JSをwasmサンドボックスで動かし、マルチテナント安全性を担保する方向です。

NTT CommunicationsはSDPF Edge上でwasmベースのエッジ関数を実験しており、DeNAはゲームサーバの一部ドメインロジックをwasmモジュールへ隔離するアーキテクチャをGREE Tech Confで共有しています。

Mercariは検索ランキング後処理にwasi-nnベースのwasm推論を活用する取り組みを発表しており、Cookpadは ruby.wasm をユーザーレシピDSLの評価に適用する実験を進めています。

27. ガバナンス — Bytecode Alliance・CNCF・W3C

WebAssemblyのガバナンスは3軸で運営されています。

Bytecode Allianceは2019年にMozilla・Fastly・Intel・Red Hatが立ち上げた非営利で、Wasmtime・WAMR・Cranelift・wasm-tools・cargo-componentをホストします。2024年時点でメンバーは60を超え、Microsoft・Google・Arm・SiemensがPremierメンバーです。

CNCFはクラウドネイティブ陣営のwasmプロジェクトをホストします。WasmEdgeとwasmCloudがIncubating段階で、Spin・SpinKube・Krustletなどは Sandbox / Incubating に分布します。

W3C WebAssembly Working Groupはwasm標準化の公式本部です。Phase 0〜5の提案フローを運営し、主要な提案はすべてここで合意されます。中心メンバーはGoogle・Mozilla・Apple・Microsoft・Intel・Arm・Fastlyです。

28. 参考資料 (References)

本文で引用した事実・数値を直接検証できる一次・二次情報源です。

1. WebAssembly 公式サイト
2. WASI 0.2 GA 発表 (Bytecode Alliance, 2024-01-25)
3. Component Model 仕様 (W3C / Bytecode Alliance)
4. Wasmtime 公式ドキュメント
5. WasmEdge CNCF プロジェクトページ
6. Wasmer 公式サイト
7. WAMR (WebAssembly Micro Runtime) GitHub
8. wazero 公式サイト
9. Fermyon Spin 公式ドキュメント
10. Cosmonic wasmCloud 公式
11. Cloudflare Workers Wasm ガイド
12. Fastly Compute ドキュメント
13. Wasmer Edge ドキュメント
14. wit-bindgen GitHub
15. wasm-tools GitHub
16. Bytecode Alliance 公式
17. MDN WebAssembly リファレンス
18. TinyGo 公式サイト
19. Pyodide
20. ruby.wasm
21. Kotlin/Wasm ガイド
22. MoonBit 公式サイト
23. Extism 公式
24. WebLLM プロジェクト
25. Figma WebAssembly 導入事例 (2017)

免責: 本稿は2026年5月時点の情報をまとめたもので、Wasm標準とランタイムは非常に速く進化します。本番投入時には上記の一次情報源を直接確認のうえ、本文は学習・比較目的に限定してご活用ください。