「WASMがDockerを置き換える」は本当か
Docker創業者のSolomon Hykesが「2019年にWASMとWASIがあれば、Dockerを作る必要はなかった」と発言して以来、WASM（WebAssembly）のサーバーサイド活用への期待が高まっている。2025年現在、WASMランタイムとフレームワークは実用段階に入りつつある。KGAの検証と一部本番導入の経験をもとに、現実的な評価をまとめる。
WASMのサーバーサイド利点
WASMの核心的な利点は3つ。第一に起動速度。コールドスタートが1ms以下で、Dockerコンテナの数百ms〜数秒、Lambda関数の100ms〜数秒と比較して桁違いに速い。エッジコンピューティングやサーバーレスで、コールドスタートが無視できるレベルになる。
第二にサンドボックスのセキュリティ。WASMモジュールはデフォルトでファイルシステム、ネットワーク、環境変数へのアクセスが一切ない。WASI（WebAssembly System Interface）で明示的に許可した機能のみ使用できる。capability-based securityにより、コンテナエスケープのような脆弱性が原理的に発生しにくい。
第三にポータビリティ。一度コンパイルすれば、Linux、macOS、Windows、各種アーキテクチャで動作する。真のwrite once, run anywhereだ。
Wasmtime: 最も成熟したランタイム
Bytecode Allianceが開発するWasmtimeは、WASI対応の本番グレードランタイムだ。Rust、C/C++、Go（TinyGo）、Python（実験的）からのコンパイルに対応する。
KGAの検証では、Rustで書いたHTTPハンドラをWasmtimeで実行した場合、同等のRustバイナリと比較してレイテンシのオーバーヘッドは約5-10%。CPU集約的な処理（画像リサイズ、JSONパース等）ではネイティブの85-95%の性能が出る。
一方、I/Oバウンドな処理（DB接続、外部API呼び出し）ではWASIのネットワーキングサポートがまだ成熟しておらず、制約がある。wasi:[email protected]インターフェースは安定したが、TCP/UDPの直接制御やTLSの扱いにはまだ課題が残る。
Spin: WASMネイティブなマイクロサービスフレームワーク
FermyonのSpinは、WASMモジュールをHTTPハンドラ、Redis subscriber、cronジョブなどとしてデプロイするフレームワークだ。spin.tomlでルーティングとコンポーネントの定義を行い、spin buildでビルド、spin upで起動する。
Spinの最大の魅力はコールドスタートの速さだ。リクエストごとに新しいWASMインスタンスを起動するモデルだが、起動が1ms以下なのでサーバーレスの理想形に近い。各リクエストが完全に独立したインスタンスで処理されるため、メモリリークや状態汚染の心配がない。
KGAではWebhookハンドラーをSpinで実装した。GitHub、Stripe、Slack等からのWebhookを受信し、ペイロードを検証してイベントキューに投入する軽量な処理だ。Dockerコンテナ版と比較して、メモリ使用量が90%削減（256MB→25MB）、コールドスタートが99%短縮（800ms→0.5ms）された。
Fermyon Cloud: WASMネイティブのPaaS
Fermyon CloudはSpinアプリケーションをデプロイするマネージドプラットフォームだ。spin cloud deployコマンドでデプロイが完了し、自動スケーリング、カスタムドメイン、KVストアが組み込みで提供される。
価格体系はリクエスト数ベースで、月間500万リクエストまで無料枠がある。Webhookハンドラーや軽量APIのような小規模ワークロードなら、実質無料で運用できる。ただしリージョンの選択肢が限られ、日本リージョンは2025年時点で提供されていない。
現実的なユースケース
KGAの経験から、WASMが本当に輝くユースケースを4つ挙げる。
エッジでの軽量処理: CDNエッジでのリクエスト変換、A/Bテストのルーティング、地理情報ベースのコンテンツ出し分け。Cloudflare Workers（WASMベース）が先行しており、実績も豊富。
プラグインシステム: ユーザーがカスタムロジックをWASMモジュールとして提供し、プラットフォーム上で安全に実行する。WASMのサンドボックスがホストシステムを保護するため、任意コードの実行を安全に許可できる。
Webhookハンドラー: 前述の通り、コールドスタートの速さと低リソース消費が際立つ。
マルチ言語関数実行: Rust、Go、Python等で書かれた関数を統一的にWASMにコンパイルし、同一ランタイム上で実行。言語ごとにコンテナを用意する必要がなくなる。
現実的な限界
率直に言えば、2025年時点でWASMがDockerを置き換える段階には達していない。最大の課題はエコシステムの未成熟だ。データベースドライバー、ORMライブラリ、認証ミドルウェアなど、Webアプリケーション開発に必要なエコシステムがWASM環境では揃っていない。
マルチスレッドのサポートも限定的だ。wasi-threadsの提案はあるが、まだ広く実装されていない。CPU集約的な並列処理にはネイティブバイナリが依然として優位。
デバッグ体験も改善の余地がある。WASMモジュールのスタックトレースは難読で、ソースマップのサポートはまだ不完全。本番障害の調査では苦労することがある。
KGAの現時点での評価は「特定のユースケースで導入し、経験を蓄積するフェーズ」だ。全面的な移行は時期尚早だが、エッジ処理とプラグインシステムの2領域では既に本番採用の価値がある。今のうちにWASMの開発経験を積んでおくことは、3-5年後のアーキテクチャ選定で大きなアドバンテージになるだろう。