世界を動かす技術を、日本語で。

WebAssemblyに何が起こったのか

2026年1月9日原文(emnudge.dev)

概要

  • WebAssembly (Wasm)の現状と実用例を解説
  • Wasmの 本質的な役割 と設計思想
  • 速度・安全性・移植性 の観点からの評価
  • 言語開発 や今後の展望について考察
  • Wasmが JavaScriptの完全な代替 ではない理由を説明

WebAssemblyの現実世界での利用

  • Godot はWasmを使いWeb向けゲームを構築
  • Squoosh.app は画像処理ライブラリの利用にWasmを活用
  • Zellij はプラグインエコシステムにWasmを採用
  • Figma はC++コードをWasmに変換しブラウザで利用可能化
  • StackblitzRuffle もWasmを重要な基盤技術として使用
  • これらの多くでWasmは製品や主要機能の根幹を担う
  • ただし、Wasmベースのフレームワークのみで構築された大規模Webサイトはまだ少数
  • 直接Wasm向けにアプリケーションを構築する例も一般的ではない現状

WebAssemblyとは何か

  • 一言で言うと WebAssemblyは言語
  • 「Wasmの速度は?」という問いは言語そのものより実行エンジン依存
  • JavaScript同様、Wasm自体に速度はなく、V8等のエンジン性能が重要
  • 問われるべきは「この言語の構造が現代ハードウェアにどれだけ効率的にマッピングできるか」

効率的なマッピング

  • Wasmはアセンブリ言語に近い抽象度 を持つ
  • ただし完全なローレベルではなく、より高水準
  • 大半のアセンブリ言語へ効率的にコンパイル可能
  • WAT (WebAssembly Text Format)で手書きも可能
  • JVMバイトコードと似た設計思想だが、APIが小さく安全性が高い
  • メモリ管理や権限はより厳格で、ホストからの明示的なインポートが必要

コンパイルターゲットとしてのWasm

  • Rust, C, Zig, Go, Kotlin, Java, C# など多くの言語がWasmへコンパイル可能
  • Python, PHP, Ruby などインタープリタ言語もWasm上で動作
  • AssemblyScript, Grain, MoonBit などWasm専用言語も存在
  • ガーベジコレクタの有無も選択可能(GC対応は最近の進化)
  • ブラウザにはWasmエンジンが標準搭載
  • Wasmtime, WasmEdge, Wasmer 等、独立実装も多数存在
  • 単一バイナリ成果物を生成し、ハードウェア非依存で実行可能

セキュリティとその恩恵

  • deny-by-default 設計、最小限API、隠蔽された制御フロースタック、リニアメモリで高い安全性
  • 単一プロセス内でプロセス並みの分離を実現
  • Cloudflare はV8 Isolateで未信頼コードを高速かつ安全に実行
  • Fermyon はミリ秒未満の起動時間を実現
  • セキュリティが効率や新機能解放につながる
  • Ruffle はFlashを安全に復活、 Pyodide はPythonを安全に実行
  • Figma はQuickJS(Wasmビルド)でプラグインを安全に実行

移植性と組み込みやすさ

  • Wasmランナーは軽量で多様な環境に対応
  • プラグインエコシステムで Zellij, Envoy, Lapce 等がWasmを採用
  • JSエンジン環境でWasmがあれば多様なプログラムが利用可能
  • 画像処理、OCR、物理エンジン、メディアツール、DB、パーサ等で活用
  • GodotやFigmaはC++コードをWasm経由でブラウザ対応
  • 言語間の橋渡し用途が主流

速度とサイズの再考

  • ブラウザはJSと同様のパイプラインでWasmを実行
  • 言語やコンパイラの最適化次第で効率向上が可能
  • JITエンジンの特性やメガモーフィック関数の回避も影響
  • ホスト境界のコストやバイナリ肥大化の課題も存在
  • WASI 等の標準化で改善が進む
  • Zig は特に小さなWasmバイナリを生成
  • ネイティブ環境でのWasmはスレッドやIOでコスト増
  • 多くの用途で「十分速い」が、極端なパフォーマンス要求には不向き

言語開発と今後

  • Wasm IO YouTubeチャンネル などで活発な議論・発表
  • 標準化と進化のスピードに賛否両論
  • W3CワーキンググループBytecode Alliance で異なる進行
  • WITやWebAssembly Component Model等、周辺ツールも急速発展
  • 進化の可視性が低く「何も起きていない」と感じる人も多い
  • WasmはJSの完全な代替とはならず、主にライブラリ作者が活用
  • アプリ開発者には内部実装がブラックボックス化
  • フレームワーク( Blazor, Leptos 等)経由でWasm利用が進行

まとめ

  • WebAssembly は多くの分野で現実的な価値を発揮
  • 速度・安全性・移植性 を兼ね備えた汎用コンパイルターゲット
  • 直接的な「革命」ではなく、 裏方的技術基盤 として浸透中
  • 今後も標準化やエコシステムの進化が期待される

Hackerたちの意見

ウェブアセンブリの大きな可能性って、すごいと思うんだ。理論的には、WASMは単一のクロスプラットフォームコンパイルターゲットになれるから、まさにコンピュータサイエンスの聖杯みたいなもんだよね。すべてがウェブアセンブリで動く世界を想像するのは簡単だし、デスクトップ環境やサーバー、日常のソフトウェアアプリケーションまで。そういうのを考えた後に、ウェブアセンブリがFigmaの一部を速くする手助けをしているって聞くと、ちょっとがっかりしちゃうよね。もちろん、それはフェアじゃないけど、WASMに対する期待に応えられるものなんてほとんどないから。開発も委員会方式だから、今の状況ではそれがベストかもしれないけど、物事が進むのが遅いことで有名だしね。

JavaScriptを単一のクロスプラットフォームコンパイルターゲットとして使うこともできるよね。何が違うの?

コンテナをWASIに置き換えない理由はないよ。コンテナって本当にひどいもので、VMにすべきだと思う(WASMの意味でね、「仮想X86でLinuxを動かす」って意味じゃなくて)。ツールがまだ整ってないんだよね。みんなDockerのサポートにまだ囚われてるし。

そうだね、問題は…「理論上」ってことは、WASMが本当に役に立たないなら誰も賭けないってことなんだ。人々はHTML、CSS、JavaScriptを使ってるけど、それはすごく役に立つって証明されてるから。WASMは無駄ではないけど、どうやって人々がそれに親しむことができるの?ほとんどの人にとっては異星のスタックみたいなもんだよ。

まだ見てないなら、[0]を観ることをおすすめするよ。JavaScriptの歴史について、たしか2035年まで説明してるから。 [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

30歳でママと住んでる天才児みたいに、いつかは潜在能力の話をやめて、結果の話をしなきゃいけない時が来るよね。この場合、理論と実践が合ってないし、WhatWGのボードにいる企業は、自分たちの儲かるアプリストアが、どんなアプリも同じように動かせるプラットフォームに脅かされないようにする利害関係があるって多くの人が指摘してるのを覚えてる。Native Clientが登場して、複雑なネイティブアプリをウェブにコンパイルして、ネイティブの95%の速度で動かせるようになった時のことを思い出す。あれは多くの点で洗練されていなかったけど、今のWebAssemblyよりもよく機能してた。WebAssemblyのもう一つのキラー機能は、ネイティブなウェブ統合だったはず。JSエンジンの仕組みは、JSクラスのインターフェースを説明するIDLがあって、それを使ってC++の実装にバインドするコードを生成するんだ。おそらくそれをWebAssemblyにもバインドできると思う。クロスプラットフォーム、つまりCPUアーキテクチャを越えることはあまり重要じゃないと思うけど、「すべてで動く」って意味なら同意するよ。それに、WebAssemblyの隠れた秘密は、実はJSより速くないってこと。

WASMは単一のクロスプラットフォームコンパイルターゲットになり得る、それはCSの聖杯みたいなものだね。JVMは1995年から「こんにちは!」と言ってるよ。

WebAssemblyがFigmaの一部を速く動かすのに役立つと言われるのは、ちょっとがっかりだね。Figmaのようなツールは、実際にはそれがなければ成り立たなかったから。

*純粋な潜在能力 = すぐに壊れそう

またJavaとJVMの話か。

スピードで見落とされがちなのがバイナリサイズなんだ。WebAssemblyはストレージスペースに関して非常に非効率的なんだよね。DSLを使ってる人は、実行を始める前にブロブをダウンロードするのに数秒(場合によってはGodotだと数分)待たなきゃいけない。一方で、JavaScriptはサイズが小さいからダウンロードがずっと速いし、ダウンロード中に実行もできるからね。

もっと言うと、JavaScriptにはすでに大きな標準ライブラリが用意されてるからね。整数を印刷したり、JSONやUnicodeテーブルを解析するためのコードを送る必要がないんだ。

Hacker Newsで議論の続きを見る