Featured image of post WebAssemblyによるブラウザアプリケーション：誇大広告を超えて Featured image of post WebAssemblyによるブラウザアプリケーション：誇大広告を超えて
Web

WebAssemblyによるブラウザアプリケーション：誇大広告を超えて

WebAssemblyのブラウザアプリケーション実践ガイド：コンパイルターゲット選択、ランタイムインスタンス化、メモリ管理、JS相互運用、デバッグ、バンドル戦略を解説。

English
  1. ホーム
  2. web
  3. WebAssemblyによるブラウザアプリケーション：誇大広告を超えて

はじめに

WebAssemblyはニッチな技術から、ブラウザベースアプリケーションの本番ツールへと成熟しました。初期のデモがゲームエンジンや科学計算に焦点を当てていたのに対し、現在では画像エディタ、動画トランスコーダ、圧縮ライブラリ、暗号処理ユーティリティがブラウザ上でネイティブに近い速度で動作しています。

2024年の大きな変化はエコシステムの成熟です。WasmGCがChrome 119+でサポートされ、SIMDは全主要ブラウザで利用可能に。Reference TypesによりDOMノードを直接Wasmモジュールに渡せるようになりました。本記事では、本番アプリケーションにおける現実的なユースケース、コンパイルターゲットの選択、メモリ管理戦略、統合パターンを解説します。

1. 2024年のWebAssembly — 何が変わったか

Wasm MVPは線形メモリ、関数エクスポート、4つの基本型（i32, i64, f32, f64）を提供しました。最近のプロポーザルがブラウザの可能性を大きく広げています。

Reference TypesはJavaScriptオブジェクトやDOMノードへの参照をシリアライズなしでWasmに渡せます。Bulk Memory Operations（memcpy、memmove、table.copy）はデータ操作を大幅に高速化します。SIMDは128ビットベクトル演算を提供し、メディア処理や暗号処理で2-4倍の高速化を実現します。Multi-value ReturnsはWasm関数が複数の値をボックス化なしで返却できるようにします。

機能対応状況影響
Reference Types全ブラウザJS/DOMの直接連携
Bulk Memory全ブラウザ高速なデータ操作
SIMD全ブラウザベクトル演算で2-4倍
Multi-value Returns全ブラウザクリーンな関数シグネチャ
WasmGCChrome 119+GC言語を手動管理なしで実行

WasmGCは特に重要です。Java、Kotlin、Dartが共有ガベージコレクタを使ってWasmにコンパイルできるようになり、手動メモリ管理が不要になります。

2. コンパイルターゲットの選択

ソース言語の選択は、ツールチェーンの複雑さ、バイナリサイズ、開発体験を左右します。

Rustは最も人気のあるWasmコンパイルターゲットです。wasm-packでビルド、wasm-bindgenでJSバインディング生成、wasm-optでバイナリ最適化と、ツールチェーンが成熟しています。web-sysとjs-sysクレートはWeb APIへの型付きバインディングを提供します。

# RustプロジェクトをWasm用にビルド
wasm-pack build --target web --release
wasm-opt -Oz -o pkg/optimized.wasm pkg/*.wasm

GoはGOOS=js GOARCH=wasmでWasmをターゲットにできますが、Goランタイムのオーバーヘッド（約2MB）によりバイナリサイズが大きくなります。バックエンドロジックの移植に向いています。

**C/C++（Emscripten）**は最も成熟したツールチェーンで、Web Workerによるスレッディング、OpenGLからWebGLへの変換、ファイルシステムエミュレーションをサポートします。libjpegやzlib、ffmpegなどの既存ライブラリの移植に最適です。

**C#（Blazor）**は.NETランタイム全体をWasmにコンパイルし、DOM相互運用を含む完全な.NETフレームワークをブラウザで実行します。.NETチームのエンタープライズアプリ移植に適していますが、初期ダウンロードサイズは大きくなります。

AssemblyScriptはTypeScriptライクな構文でWasmにコンパイルでき、JS開発者には学習曲線が低いですが、エコシステムはRustやEmscriptenほど成熟していません。

3. ランタイムインスタンス化とメモリ管理

WasmモジュールはWebAssembly APIを使ってインスタンス化します。可能な限りinstantiateStreaming()を使用すると、フェッチとコンパイルを並行して実行できます。

const importObject = {
  env: {
    memory: new WebAssembly.Memory({ initial: 100, maximum: 1000 }),
    abort: () => console.error("Wasmからabortが呼ばれました"),
  },
};

const { instance, module } = await WebAssembly.instantiateStreaming(
  fetch("module.wasm"),
  importObject
);

instance.exports.main();

Wasmは線形メモリモデルを採用しています。JSとWasmはArrayBufferを介して連続したバイト配列を共有します。1ページは64KBで、memory.grow(pages)で動的に拡張できますが、コストがかかるため可能な限り事前割り当てを行います。

WasmGCがない場合、RustやC++は独自にメモリを管理します。解放忘れはリークにつながり、JSからガベージコレクトできません。バッファの事前割り当て、再利用、デストラクタ関数のエクスポートが重要です。

// Rust — JSから呼び出せるデストラクタをエクスポート
#[wasm_bindgen]
pub fn free_buffer(ptr: *mut u8, len: usize) {
    unsafe {
        let _ = Vec::from_raw_parts(ptr, len, len);
    }
}

4. JavaScript相互運用

WasmはI/O用にJS関数をインポートし、関数・メモリ・テーブルをJSにエクスポートします。Rustではwasm-bindgenが型変換を含むJSバインディングを自動生成します。

use wasm_bindgen::prelude::*;
use web_sys::console;

#[wasm_bindgen]
pub fn greet(name: &str) -> String {
    console::log_1(&format!("こんにちは、{}!", name).into());
    format!("こんにちは、{}!", name)
}

境界を越える呼び出しには約5-20nsのオーバーヘッドがあります。小さな呼び出しを多数行うのではなく、バッチ処理で境界越えを最小化します。複合データの受け渡しには、文字列はTextEncoder/TextDecoder、バイナリデータはArrayBufferを使用します。

クロージャをWasmに渡す場合は、ライフサイクル管理に注意が必要です。RustのClosure::wrapを使用し、不要になったクロージャは適切にドロップします。

5. バンドル戦略

Viteは?wasmサフィックスまたはvite-plugin-wasmとvite-plugin-top-level-awaitの組み合わせでWasmをサポートします。

// Vite — ネイティブWasmインポート
import init, { process_image } from "./image-processor/pkg/image_processor.js";

await init();
const result = process_image(inputBuffer);

本番環境では、動的インポートによるコード分割でWasmモジュールを遅延読み込みし、初期ページ読み込みをブロックしないようにします。wasm-optとwasm-stripでバイナリサイズを最適化します。Wasmのツリーシェイキングは現在限定的なため、モジュールを細かく分割することが推奨されます。

6. デバッグ

Chrome DevToolsはソースマップ、ステップ実行、ブレークポイント、変数インスペクションによるWasmデバッグをサポートしています。wasm-pack build --debugでDWARFデバッグ情報を生成し、wasm-dwarfでソースマップに変換します。

よくある問題として、JSとWasm間の型不一致、メモリアクセス違反（範囲外アクセス）、未処理のWasmトラップがあります。パフォーマンスプロファイリングにはChrome DevToolsのPerformanceパネルでWasm関数の実行時間を確認できます。

# デバッグシンボル付きでビルド
wasm-pack build --debug
# 本番用からデバッグセクションを除去
wasm-strip pkg/*.wasm
wasm-opt -Oz -o pkg/optimized.wasm pkg/*.wasm

7. 現実的なユースケース

WasmはCPUバウンドで計算量の多いワークロードに優れています。

  • 画像・動画処理：形式変換、トランスコーディング、リアルタイムフィルター — ピクセル操作でJS比2-5倍高速
  • データ圧縮：zlib、Brotli、LZ4 — 圧縮ワークロードでWasmがJS実装を上回る
  • 暗号処理：AES、SHA、Argon2 — 定数時間演算と大規模入力での高速処理
  • ゲームエンジン：物理シミュレーション、ゲームロジック、レンダリングパイプライン
  • CAD・3Dモデリング：計算幾何学、メッシュ操作、CPUバウンドのレンダリング
  • 科学計算：大規模データセット処理、数値計算、統計分析

単純なDOM操作や小さなユーティリティ関数（相互運用オーバーヘッドが計算時間を上回る場合）、インタラクティブなUIロジックにはWasmを使用すべきではありません。

8. パフォーマンスの現実

Wasmが常にJavaScriptより高速とは限りません。V8やSpiderMonkeyなどのJSエンジンは典型的なWebワークロードに高度に最適化されています。WasmはCPUバウンド計算、決定論的パフォーマンス（JITウォームアップ不要）、SIMD最適化可能なワークロードに優れ、I/Oバウンドタスクや頻繁なJS相互運用には向いていません。

ワークロードWasm vs JS
画像処理3-5倍高速
JSONパースJSが高速（JIT最適化）
暗号ハッシュ2-4倍高速
文字列操作JSが高速なことが多い
圧縮2-3倍高速

まとめ

WebAssemblyはJavaScriptの代替ではなく、特定のユースケースに強力なツールです。メディア処理、圧縮、暗号処理、ゲームエンジンなどの計算集約型タスクに最適です。新規プロジェクトにはRustがツールチェーンの成熟度とパフォーマンスのバランスに優れています。JS-Wasm境界越えの最小化とメモリの事前割り当てに注力して最適なパフォーマンスを実現しましょう。

WasmGC、コンポーネントモデル、スレッディングなどのプロポーザルにより、Wasmの可能性は今後も拡大し続けます。コンパイルターゲットを慎重に選び、プロファイル後に最適化を行い、Wasmを万能薬ではなくパフォーマンスレバーとして活用してください。

© 2022 - 2026 たかおの解説