WebAssembly
はじめに
WebAssembly（Wasm）は、ウェブ中心の最適化ツールから高性能なユニバーサルバイトコードフォーマットへと進化しました。2019年にW3C標準として正式に採用され、2025年12月のWasm Version 3.0のリリースでエコシステムは技術的な転換点を迎えました。このバージョンはガベージコレクション、64ビットアドレス空間、Multiple Memoriesなどの高度な機能を標準化しており、Java、Kotlin、DartなどのハイレベルなLanguageがブラウザとスタンドアロン環境の両方でネイティブかつ効率的に動作することを可能にしています。
方法論
WebAssemblyが初めて紹介された2021年版Web Almanacと同じ方法論に従っています。
データ収集: 本章は、Google BigQueryにホストされているHTTP Archiveの2025年7月クロールデータを利用して、Content-Type（application/wasm）と.wasmファイル拡張子を照合することでWebAssemblyモジュールを特定しています。この方法で、43,000サイトで少なくとも1つのWebAssemblyモジュールを発見し、分析した全サイトの0.35%を占めています。
分析: HTTP Archiveデータセットに加えて、HTTP Archiveから特定されたWebAssemblyモジュールをダウンロードして検証するツールalmanac-wasm-statsをローカル分析に使用しています。このツールはダウンロードしたファイルからメタデータを抽出し、Wasmモジュール内で使用されているプログラミング言語、ライブラリ、特定の機能を特定することを可能にします。
制限事項: almanac-wasm-statsツールはWasmモジュールの静的解析に焦点を当てており、実行はしません。そのため、ブラウザやスタンドアロン環境での実際の実行中に存在する可能性のある動的な動作やランタイム機能を捉えることができません。また、一部のWasmモジュールは難読化またはminify化されている場合があり、その特性を正確に特定する能力が制限される可能性があります。 言語使用分析に役立つ以下の機能を(wasm-stats)を拡張してalmanac-wasm-statsに実装しました。
- URLと対応するユーザーエージェント文字列を入力として受け取ることで、ダウンロードタスクを改善します。
- BigQueryのJSONL結果形式で大量の入力を受け付けます。
- Binary ToolkitでWasmを検証し、統計改善に役立つインサイトを提供します（wasm2wat参照）。
- Wasmファイルのダウンロード、検証、統計収集などのタスクを並行して実行・追跡します。
-
古いRust実装（
wasm-stats）の言語識別子を拡張し、Scala、Dotnet/Mono、Go & TinyGo、TeaVMベースの言語、Kotlinを新たに追加。これにより「Unknown」の数が減少し、言語統計が改善されます。 - 検証とダウンロードの失敗とともに、完全なWasm言語使用統計を生成します。
- 将来の拡張に向けて、既存のJSON統計形式でWebAssembly Toolkit / SDKを使用した新しい統計を導入できるプラグアンドプレイアーキテクチャを採用しています。
WebAssemblyの使用状況
このセクションでは、ウェブにおけるWebAssemblyの使用状況に関する結果を紹介します。
年次トレンド
WebAssemblyの採用は2021年の0.04%から成長していますが、直近2年間は一定の水準を維持しています。2025年には、デスクトップサイトの0.35%、モバイルサイトの0.28%でWebAssemblyモジュールを確認し、約43,000サイトに相当します。また、観測された全ての年でモバイルの採用率はデスクトップより低く、平均30%の差があります。
ランク別WebAssembly
サイトの人気度とWebAssemblyの採用には強い相関関係があります。使用はトップ1,000サイトに最も集中しており、デスクトップで2%、モバイルで1.27%に達しています。これらのトップクラスのサイトは、Wasmが提供する高いパフォーマンスを必要とするデザインツールや重いメディアエディターなどの複雑なアプリケーションを頻繁にホストしています。
サイトのランクが下がるにつれて採用率も低下し、一貫した分布パターンに従っています。トップ1,000万サイト外では、採用率はデスクトップで約0.33%、モバイルで0.28%です。
トップランクグループではデスクトップの使用率が高いままですが、ロングテールではその差が大幅に縮まっており、ウェブの大多数においてWebAssemblyは特定の環境に限定されるのではなく、クロスプラットフォームリソースとして展開されていることを示しています。
WebAssemblyのリクエスト
全体で、デスクトップで303,496件、モバイルで308,971件のWebAssemblyリクエストを記録しました。デスクトップサイトの方がWebAssemblyを多く利用していますが、リクエストの総量はモバイルがわずかに多くなっています。
さらに、デスクトップで157,967個、モバイルで165,870個のユニークなURLを特定しました。ユニークなバイナリ数を推定するために、同一のファイル名とレスポンスサイズでモジュールをグループ化しました。この方法で、デスクトップで87,596個、モバイルで84,851個のユニークなWasmモジュールが見つかりました。これらの結果は、名前ベースで約72%のWebAssemblyリクエストが重複モジュールを提供していることを示しており、ウェブ全体でのライブラリの大規模な再利用を浮き彫りにしています。
MIMEタイプ
application/wasm MIMEタイプはデスクトップで293,470件、モバイルで301,127件のリクエストで確認されました。MIMEタイプが欠落または不正確（text/htmlやtext/plainなど）なケースは少なく、デスクトップで3.2%、モバイルで2.4%のリクエストに影響していました。これらは2021年と比較して大幅に減少しており、適切なサーバー設定への意識と遵守が向上していることを示しています。
モジュールサイズ
WebAssemblyモジュールのサイズは使用ケースによって大きく異なります。下位50%のモジュールは2KBから14KBの範囲で非常に小さいことが確認されました。これらは通常、JavaScriptが精度に欠けるパフォーマンスクリティカルなタスクを処理するために、AssemblyScriptやRustで書かれたBase64エンコーダーやチェックサム計算機などの「マイクロユーティリティ」です。
一方、90パーセンタイルではサイズがデスクトップで381KB、モバイルで316KBへと大幅に増加します。これらの大きなバイナリは通常、複雑な3Dレンダリングやロジックを処理するためにC++やC#などの重い言語からコンパイルされた、Adobe PhotoshopやGoogle Earthなどのフルデスクトップグレードのアプリケーションをウェブに移植したものです。
上記のグラフはレスポンスボディのサイズを示しており、「生のレスポンスサイズ」と呼ばれ、クライアントが受信したデータペイロードのデコード済みの生データのみを測定します。リソース自体のサイズを表しています。ただし、Wasmの成果物に関する研究と一般的な慣行によると、WasmモジュールはBrotliなどの様々なツールで圧縮・最適化され、Content-Encodingヘッダーとともにgzip、br、zstdなどの圧縮方法でネットワーク経由でクライアントに転送されます。
興味深いことに、過去数年間の様々なコミュニティによるパフォーマンスベンチマーク活動を見ると、’br’と’zstd’の圧縮方法への認知が高まっており、開発者やCDNプロバイダーによる継続的な進化と採用が見られます。
これらの標準的な分布を超えて、データセットには重要な外れ値が含まれています。特定された最大の単一WebAssemblyモジュールは、デスクトップで234MB、モバイルで170MBを記録しており、大規模なクライアントサイドアプリケーションが展開されていることを示しています。
興味深いことに、JSの成果物がMBサイズであることが多いのに対し、Wasmの成果物がかなり小さいサイズである理由は、JSが人間が読める高レベルのソースコードであるのに対し、バイトコードはマシンに依存しないコードの低レベルな中間表現であるからです。
Google V8のような現代のJSエンジンは、実行プロセスの一部としてJSソースコードを内部的にバイトコードに変換しています。これはバイトコードのJSに比べた小さなサイズでの効率性を示しています。
WebAssemblyライブラリ
次に、エコシステムで最も人気のある基盤となるライブラリとフレームワークを理解するために、WebAssemblyバイナリ内のインポート名を分析します。
WebAssemblyモジュールで最も使用されているライブラリやフレームワークは、System（43%）、Microsoft（23%）、RXEngine（6%）、Dotnet（6%）であり、特にDotnetとBlazorフレームワークによって牽引されるMicrosoftのエコシステムの優位性を示しています。
MicrosoftはSystemユーティリティ、Identity、ネットワーキング、ストレージ、JSONなど、多数の再利用可能なライブラリ向けに様々なWebAssemblyライブラリとフレームワークを持っています。それらのライブラリとフレームワークを組み合わせることで、WebAssemblyにおけるMicrosoftエコシステムはデスクトップで78.8%、モバイルクライアントで79.3%をカバーしています。
WebAssembly言語
WebAssemblyはC++、C#、Rubyなど様々な言語で開発できます。Wasm 3.0の導入により、Java、Scala、Kotlin、Dartなどのサポート言語の範囲が拡大しました。このセクションでは、WebAssemblyモジュールの開発に使用されている言語の概要を説明します。
ツールはデスクトップで64.3%、モバイルで72.8%のWebAssemblyモジュールのソース言語を正常に特定しました。残りの（35.7%と27.2%）は、主にminify化（メタデータの除去）、WebAssemblyの検証またはダウンロードの失敗により特定できませんでした。
特定された言語の中では、.NET/Mono + Blazorが最も一般的で、デスクトップで41.7%、モバイルで38.7%のシェアを持っています。minify化されたエクスポート/インポート名はソース言語を不明瞭にすることが多いですが、Emscripten（C++）ツールチェーンは独自の命名規則を使用しています。これにより確信を持ってこれらのモジュールを帰属させることができ、Emscriptenがデスクトップで10.1%、モバイルで7.8%を占め、Scalaがデスクトップで3.6%、モバイルで3.4%という結果が得られました。
ライブラリ使用に関する調査結果と合わせると、これらの結果はWebAssemblyの領域におけるMicrosoftエコシステムの圧倒的な優位性を強調しています。
WebAssembly機能
このセクションでは、MVP後（Minimum Viable Product以降）のWebAssembly機能の使用状況を分析します。ここで取り上げる機能はWebAssemblyがサポートする全機能を網羅していないことを認識していますが、これらの機能の採用状況を強調することは重要だと考えています。読者の方々には、将来的により多くの機能を追跡できるよう、本章で使用した分析ツールへの貢献をお願いします。
バルクメモリが最も広く採用されている機能で、デスクトップで187,674、モバイルで204,103のモジュールに登場しています。この機能は大きなメモリブロックの効率的なコピーと初期化を可能にすることでパフォーマンスを向上させ、CのネイティブなmemcpyFunction の効率を模倣しています。さらに、符号拡張（8ビット整数から32ビットへの拡張など、整数値を拡張する演算子を提供する）が2番目に人気の機能で、デスクトップで45,969、モバイルで50,394のモジュールで確認されました。
結論
WebAssemblyの採用は過去4年間で大幅に増加し、2021年の0.04%から2025年の0.35%へと上昇しましたが、直近2年間では成長が安定しています。使用は高ランクのウェブサイトで最も多く、人気の低いページでは大幅に減少します。WebAssemblyは現在、特定のユーティリティ機能（暗号化やチェックサムなど）の処理と、完全なスタンドアロンアプリケーションの駆動という2つの異なる目的で展開されています。さらに、調査結果はMicrosoftのフレームワークの広範な採用を示しており、現在のWebAssemblyエコシステムを牽引するうえでの重要な役割を示しています。
Wasm仕様の大きな進展とコミュニティからの関心の高まりを考慮すると、WebAssemblyの採用は今後さらに増加すると考えています。
