WebAssemblyがブラウザのプログラミング言語をどう変えるか

WebAssemblyを一言で：何で、なぜ存在するのか

WebAssembly（通常WASMと略されます）は、モダンなブラウザがほぼネイティブに近い速度で実行できる、コンパクトな低レベルのバイトコード形式です。JavaScriptのようにソースコードをそのまま配る代わりに、WASMモジュールは事前コンパイルされた命令群と、必要なもの（例：メモリ）や公開する関数の一覧を配送します。

ブラウザがWASMを導入した理由

WASM以前は、ブラウザで「実行する」というと実質的にJavaScriptしか選択肢がありませんでした。これは可搬性やアクセシビリティに優れていましたが、すべての種類の処理に最適というわけではありません。大量の数値計算、リアルタイム音声処理、複雑な圧縮、大規模なシミュレーションなどは、JavaScriptの実行モデルだけでは滑らかに保つのが難しいことがあります。

WASMはこうした問題を狙っています：プラグイン無しで、ユーザーに何かをインストールしてもらうことなく、ブラウザ内で他言語で書かれたコードを高速かつ予測可能に実行する手段です。

JavaScriptを置き換えるわけではない

WASMは新しいスクリプト言語ではなく、単独でDOM（ページのUI）を支配するものでもありません。多くのアプリではJavaScriptがコーディネータのままです：WASMモジュールの読み込み、データの受け渡し、ユーザー操作の処理を行います。WASMは、タイトなループや一貫した性能が求められる部分の“エンジンルーム”です。

役割のイメージ：

• JavaScript：UI、イベント、ネットワーク呼び出し、グルーコード
• WASM：計算負荷の高い関数、再利用可能なライブラリ、パフォーマンス重視のアルゴリズム

この記事の範囲

この記事は、WASMがブラウザにおけるプログラミング言語の役割をどう変えるか——何が可能になり、どこに適合し、実際のウェブアプリで考慮すべきトレードオフは何か——に焦点を当てます。

ビルドツールの詳細や高度なメモリ管理、低レベルなブラウザ内部実装には深く入り込みません。実用的な観点で、WASMが有効なとき、無意味なとき、そしてフロントエンドの保守性を落とさずに使う方法を示します。

WASM以前：なぜJavaScriptがブラウザを支配したか

ウェブの歴史の大半では、「ブラウザで実行する」とは実質的に「JavaScriptを実行する」ことを意味していました。それはJavaScriptが常に最速で愛されていたからではなく、ブラウザがどこでも直接実行でき、ユーザーに何もインストールさせずに動作させられる唯一の言語だったからです。

ブラウザのデフォルト言語としてのJavaScript

ブラウザにはJavaScriptエンジンが組み込まれており、インタラクティブなページのための普遍的な選択肢となりました。JSを書けばどのOSのユーザーにも届き、単一のダウンロードで配布でき、更新も即座に反映できます。

他の言語はサーバー側では使えましたが、クライアント側は別世界でした。ブラウザランタイムは厳格なサンドボックスや互換性要件、高速な起動を求められ、JavaScriptはそのモデルに早期に適合しました。

他言語がブラウザで動くとはどういうことだったか

C++、Java、Python、C#をクライアント側で使いたい場合、通常は翻訳、埋め込み、あるいは外部化が必要でした。「クライアント側」で動かすというと、多くは「JavaScriptに書き換える」ことを意味し、既に成熟した他のコードベースがあっても再実装が求められました。

WASM以前の回避策と限界

WASM以前の選択肢には次がありました：

• トランスパイラ（別言語をJavaScriptに変換）
• プラグイン（Flash、Javaアプレット、Silverlight）
• サーバー往復（重い処理をサーバーで行い結果を返す）

これらは助けになりましたが、大規模アプリでは限界が出ました。トランスパイルされたコードは肥大化しやすく、性能が不安定なこともあります。プラグインはブラウザ間で一貫性がなく、セキュリティや保守の観点で縮小しました。サーバー処理はレイテンシやコストを増やし、「ブラウザ内アプリ」という感覚を損なうことがありました。

WASMの実行モデル：シンプルな心的モデル

WebAssembly（WASM）を、ブラウザが効率よく実行できる小さな標準化された“アセンブリ風”の形式だと考えてください。日常的にWASMで直接書くのではなく、WASMはビルド出力として生成します。

高レベルなフロー

多くのプロジェクトは次のようなパイプラインを踏みます：

• Rust、C/C++、Goなどでコードを書く
• wasm32ターゲット向けにツールチェインでコンパイルする
• 結果を.wasmモジュールとしてウェブアプリと共に配布する

重要な転換点は、ブラウザがソース言語を理解する必要がなくなったことです。ブラウザが理解すべきはWASMだけです。

ブラウザが実際に実行するもの

ブラウザはRustやC++を直接実行するわけではなく、WebAssemblyバイトコード——迅速に検証でき、一貫して実行できるよう設計された構造化されたバイナリ形式——を実行します。

アプリが.wasmファイルを読み込むと、ブラウザは：

1. モジュールが正しく安全に構成されているか検証する
2. （多くはストリーミングコンパイルで）コンパイルする
3. ブラウザのWASMエンジン内で実行し、必要に応じてエクスポートされた関数を呼び出す

実際にはJavaScriptからWASM関数を呼び、WASMは定義されたインタロップを通じてJavaScript側にコールバックできます。

サンドボックス化実行（平易に）

サンドボックス化とは、WASMモジュールが：

• コンピュータのファイルやネットワーク、メモリに自由にアクセスできない
• OSへ「脱出」できない
• ブラウザが明示的に与えたもの（メモリバッファやインポートされた関数）だけを操作する

この安全モデルがあるため、ブラウザは多くのソースのWASMを安心して実行できます。

ブラウザ上の“言語”が変わる理由

共通のバイトコードをブラウザが実行できるようになると、問いは「ブラウザはこの言語をサポートしているか？」から「その言語がWASMに良い形でコンパイルでき、ツールが整っているか？」に移ります。これにより、ブラウザで実用的に使える言語の範囲が広がります——ただしブラウザが実行するものは変わりません。

JavaScriptとWASM：異なる役割を持つパートナー

WebAssemblyはブラウザでJavaScriptに取って代わるものではなく、分担を変えます。

JavaScriptはページを“所有”し続けます：クリックに反応し、DOMを更新し、ブラウザAPI（fetch、storage、audio、canvasなど）とやり取りし、アプリのライフサイクルを調整します。レストランで例えると、JavaScriptはフロント・オブ・ハウス——注文を取り、タイミングを管理し、結果を提示する役割です。

WASMは計算エンジンとして使う

WASMはJavaScriptから呼び出す集中的な計算エンジンとして扱うのが最適です。入力を渡し、重い処理を行い、結果を返します。

典型的なタスクは、パース、圧縮、画像／映像処理、物理計算、暗号、CAD演算など、CPU負荷が高く予測可能な実行が求められるものです。JavaScriptはそれらをいつ実行するか判断し、結果を扱います。

データ受け渡しの基本（高レベル）

JavaScriptとWASMの手渡しが性能改善（あるいは損失）を左右します。

• 数値は最も簡単：渡して返すだけ。\n- 配列／バイナリはTypedArrayや共有メモリバッファ経由で動くことが多い。JavaScriptがバッファにバイトを書き込み、WASMが読み、結果を書き戻す。\n- 文字列は扱いが難しく、エンコード／デコード（一般的にUTF-8）とメモリ管理が必要になる。\n 境界を越えるデータ転送にはコストがあると考えてください。

JS–WASM境界が重要な理由

1フレーム内で何千回もWASMを呼び出したり、大量のデータを頻繁にやり取りすると、WASMの高速化効果は消えてしまいます。

実践的な目安：呼び出しは少なく、大きくまとめる。作業をバッチ化し、コンパクトなデータを渡し、WASM側で一回あたり長く実行させる一方、JavaScriptはUIやオーケストレーションに集中させます。

得られるもの（得られないもの）：性能、サイズ、予測可能性

WASMは「JavaScriptより速い」と紹介されがちですが、実際には限定的です：特定の種類の処理で速く、他ではそれほどでもありません。勝利は大量の同種計算を行い、一貫した動作が欲しい場合に現れます。

性能：あるワークロードでは速いが、すべてに効くわけではない

WASMはCPU負荷の高い処理（画像／動画処理、オーディオコーデック、物理演算、データ圧縮、大きなファイルのパース、ゲームエンジンの一部など）で輝きます。そこではホットループをWASM内に留め、動的型付けや頻繁な割り当てのオーバーヘッドを回避できます。

しかしWASMは万能ではありません。アプリの大半がDOM更新、UIレンダリング、ネットワークリクエスト、フレームワークロジックであれば、ほとんどはJavaScriptと組み込みAPIの範疇で処理されます。WASMはDOMを直接操作できないため、頻繁な往復は性能を損ないます。

予測可能性：重い計算に対する安定したランタイム

実用的な利点は予測可能性にあります。WASMはより制約された環境で、単純な性能プロファイルを持つため、タイトな計算コードでの“驚きの遅延”を減らせます。フレーム時間の安定や処理スループットの一貫性が重要なワークロードに魅力的です。

サイズ：ツール次第で小さくも大きくもなる

WASMバイナリは圧縮されるとコンパクトになり得ますが、実際のダウンロードサイズはツールや依存関係次第です。小さく手書きしたモジュールは軽量ですが、標準ライブラリやアロケータ、ヘルパーコードを引き込むと期待より大きくなることがあります。圧縮は助けになりますが、起動時のパースやインスタンス化のコストは残ります。

性能以外の理由でWASMを選ぶケース

多くのチームは、既存のネイティブライブラリを再利用したい、プラットフォーム横断でコード共有したい、あるいはRustのようなメモリ安全性やツールの恩恵を受けたいという理由でWASMを選びます。その場合は“十分に速く予測可能”であることが目的で、ベンチマークの最上位を追うことが主眼ではありません。

ブラウザでWASMの恩恵を最も受ける言語

WASMはJavaScriptを置き換えませんが、これまでブラウザで扱いにくかった（あるいは不可能だった）言語を選択肢にします。最大の恩恵を受けるのは、既に効率的なネイティブコードへコンパイルでき、多くの再利用可能なライブラリを持つ言語です。

Rust：安全志向のシステムコードのWASM化

Rustは高速な実行と堅牢な安全性（特にメモリ関連）を兼ね備えており、ブラウザWASMに適しています。パーザ、データ処理、暗号、パフォーマンスに敏感なコアモジュールに向いています。

RustのWASM向けツールは成熟しており、DOM操作はJSに委ね、計算部分をWASMに任せるパターンがコミュニティで確立されています。

C/C++：成熟したネイティブライブラリやエンジンの再利用

C/C++は既存の大規模ネイティブコードを流用したい場合に強みを発揮します：コーデック、物理エンジン、画像・音声処理、エミュレータ、CADコアなど。WASMへコンパイルする方がJSで書き直すよりはるかに現実的です。

トレードオフとして、C/C++のメモリ管理やビルドパイプラインの複雑さを引き継ぎ、デバッグやバンドルサイズに影響する可能性があります。

Goやその他：可能性と制約

GoもブラウザでWASMとして動きますが、ランタイムオーバーヘッドがRustやC/C++より大きくなることが多いです。開発者の親和性やバックエンドとのコード共有が重要なら有力な選択肢ですが、レイテンシやサイズが厳しい小さなモジュールにはあまり選ばれません。

Kotlin、C#、ZigなどもWASM化できますが、エコシステムの成熟度は異なります。

言語選択は往々にして既存コードベースに従う

実務ではチームは理念より実利で選びます：「既に信頼しているコードは何か？」「再実装にコストが掛かるライブラリは何か？」WASMは実証済みのコンポーネントをほとんど翻訳せずにブラウザに持ってこれる点で有用です。

WASMが得意な一般的ユースケース

WASMは、計算負荷が高く再利用可能で、DOMから比較的独立した処理があるときに最も有効です。高性能な“エンジン”をJavaScriptから呼び出すイメージで、UIはJavaScriptが主導します。

適合度が高い例：重い計算とタイトなループ

WASMが効く場面：

• 画像／音声／動画処理：フィルタ、リサイズ、ノイズ除去、トランスコーディングの補助、波形解析
• ゲーム／シミュレーション：物理演算、パスファインディング、衝突検出、エミュレータ
• CADや高度なデータ可視化：幾何カーネル、メッシュの細分化、巨大データセットの変換

これらはWASMの機械寄りで予測可能なコード実行に合致します。

ライブラリ形状の機能に向くもの

次のような、コンパイル済みモジュールとして落とし込める機能は自然にマッチします：

• 圧縮／解凍：ZIP、Brotliなどのヘルパー
• 暗号／ハッシュ：高速な暗号プリミティブ（Web Cryptoと併用することも）
• パーサ：言語パーサ、ファイルフォーマットリーダー、バリデータ
• 科学計算：線形代数、最適化、信号処理

成熟したC/C++/Rustライブラリがあれば、WASMにコンパイルする方がJSで書き直すより現実的です。

不適合なケース：DOM中心のアプリや小さなCRUDページ

アプリの大半がDOM更新、フォーム配線、API呼び出しで構成される場合、WASMは効果が薄いことが多いです。ビルドパイプラインの複雑化やJS↔WASMのデータ転送コストがメリットを上回る可能性があります。

ルール・オブ・サム：簡単なチェックリスト

WASMを使うべきなら多くが「はい」になるはず：

1. 機能は計算負荷が高いか？（DOM中心ではないか）
2. 入出力が明確な自己完結モジュールにまとめられるか？
3. 十分に頻繁に実行されて、速度改善が意味を持つか？
4. ネイティブに近い性能や実行時間の一貫性が必要か？
5. 再利用に値する既存のネイティブライブラリがあるか？

UI中心ならまずJavaScriptに注力し、メリットが明確になってからWASMを導入しましょう。

計画しておくべき制限とトレードオフ

WASMはアプリの一部を高速化し得ますが、ブラウザのルールを免除するものではありません。事前に制約を想定しておくことで、後での大規模な書き換えを避けられます。

DOMを直接操作できない

WASMはJSのようにDOMを直接操作できません。実務上は：

• UIレンダリング、イベント処理、ブラウザとの大半のやり取りはJavaScript（またはJSフレームワーク）側に残ります
• WASMは計算作業（パース、画像処理、シミュレーション、圧縮、暗号など）向け

細かいUI更新をWASM↔JSで行うと呼び出しオーバーヘッドやデータコピーで遅くなります。

Web機能にはJS APIを介する

fetch、WebSocket、localStorage/IndexedDB、canvas、WebGPU、WebAudioなどの多くのWebプラットフォーム機能はJavaScript APIとして提供されます。WASMでそれらを使うにはバインディングや小さなJSの“グルー”コードが必要です。

これにより相互運用コードの維持や、データ形式（文字列、配列、バイナリバッファ）を効率的に扱う設計が必要になります。

スレッドと共有メモリ（高レベル）

ブラウザはWeb WorkerとSharedArrayBufferを介したWASMのスレッドをサポートしますが、デフォルトで自由に使えるわけではありません。使用にはセキュリティ関連ヘッダ（クロスオリジンアイソレーション）やデプロイ設定の変更が必要になることがあります。

スレッドを使う場合でも、重い処理はバックグラウンドワーカーに回し、UIメインスレッドはレスポンシブに保つ設計が求められます。

デバッグと開発体験

ツールチェインは改善中ですが、デバッグは依然としてJSとは異なります：

• スタックトレースやソースマップはJS／WASM境界で見づらいことがある
• ロギング、カスタムアサーション、プロファイリングに頼る場面が増える
• ビルド時間やバイナリサイズ調整（シンボルの除去、LTOなど）が日常的な作業になる

結論：WASMはフロントエンドアーキテクチャ内の集中コンポーネントとして扱い、アプリ全体の代替にはしないでください。

アーキテクチャパターン：複雑化させずにWASMを使う方法

WASMは通常のウェブアプリの中で焦点を絞ったコンポーネントとして働くときに最も効果的です。実用的なルールは、プロダクトの“表面”（UI、ルーティング、状態、アクセシビリティ、分析）はJavaScript/TypeScriptに残し、コストの高い部分だけWASMに移すことです。

JS/TSとWASMの仕事を明確に分ける

WASMを計算エンジンと見なしてください。JS/TSは以下を担当します：

• DOM更新とイベント処理
• ネットワーキング（fetch）、ストレージ、権限管理
• アプリ状態とユーザーインタラクション

WASMは次に向きます：

• タイトなループ（パース、圧縮、画像／音声処理）
• CPU重めのアルゴリズム（検索、マッチング、シミュレーション）
• JSで簡単に書き直せない既存ライブラリ（Rust/C++など）

JS↔WASMのインターフェースは安定に設計する

境界の往復にはオーバーヘッドがあるため、呼び出しを少なくする設計が重要です。インターフェースは小さく単純に：

• 深いオブジェクトではなくTypedArrayや数値を渡す
• バージョン付き関数（例：process_v1）を定義して進化を楽にする
• JS側で入力を検証して、失敗時にユーザー向けの親切なエラーメッセージを出す

バンドルを管理可能に保つ

小さなクレートやパッケージが依存の鎖を引き込み、サイズが急増することがあります。対策：

• 推移的依存を早期に監査する
• サイズ重視のコンパイル設定でビルドしてシンボルを削る
• 必要な画面でのみWASMを遅延ロードする（動的import）

テストの負担を減らす

実用的な分割：

• コアロジックはネイティブで単体テスト（Rust/C++の高速フィードバック）
• ブラウザ統合テストで実際のWASMを読み込み、入出力・エラー・性能を検証

このパターンでプロジェクトは通常のウェブ開発のまま、高性能モジュールを持てます。

Koder.aiがこのワークフローにできること

プロトタイプでWASM機能を試す際、アーキテクチャを早期に正しく固める（JS↔WASM境界、遅延ロード、予測可能なデプロイ）ことがパフォーマンスに直結します。Koder.aiはチャットで機能を説明すればReactベースのフロントエンドとGo + PostgreSQLのバックエンドをスキャフォールドし、WASMモジュールの配置（UIはReact、計算はWASM、オーケストレーションはJS/TS）を素早く試す手助けができます。

高速に動くチームにとっての実利は、ラッパー、APIエンドポイント、ロールアウトの仕組みといった“グルー作業”を削減できる点にあります。コードはエクスポート可能で、カスタムドメインやスナップショット、ロールバックもサポートできます。

WASMの出荷（build、load、measure、iterate）

WASMモジュールを本番に乗せるときは「コンパイルできるか」よりも、素早く読み込めるか、安全に更新できるか、本当にユーザー体験が改善するかが重要です。

ビルドとパッケージング

多くのチームはフロントエンドと同様のパイプラインでWASMを配布します：バンドラは.wasmファイルを生成し、ランタイムで参照する形です。

実用的なアプローチは.wasmを静的アセットとして扱い、初回描画をブロックしないよう非同期に読み込むこと。多くのツールチェインはインポート／エクスポートを処理する小さなJS“グルー”を生成します。

// Minimal pattern: fetch + instantiate (works well with caching)
const url = new URL("./my_module.wasm", import.meta.url);
const { instance } = await WebAssembly.instantiateStreaming(fetch(url), {
  env: { /* imports */ }
});

instantiateStreamingが利用できない、またはサーバが誤ったMIMEタイプを返す場合は、fetch(url).then(r => r.arrayBuffer())とWebAssembly.instantiateにフォールバックしてください。

バージョニングとキャッシュ

.wasmはバイナリなので、攻めたキャッシュ戦略が必要です。

• コンテンツハッシュ付きファイル名（例：my_module.8c12d3.wasm）を使い、長いキャッシュヘッダを設定する
• ローダーJSは小さくキャッシュフレンドリーに保つ（現在のハッシュを指す役割）
• エクスポート関数の署名を壊す変更はJSラッパーのバージョンと合わせて行う

頻繁にイテレートする場合、こうした仕組みが「古いJS + 新しいWASM」のミスマッチを防ぎます。

実ユーザーへの影響を計測する

WASMモジュールは単体ベンチでは速くても、ダウンロード負担やメインスレッドへの仕事の移動でページに悪影響を与えることがあります。

計測すべき項目：

• 読み込み時間：フェッチ時間、コンパイル／インスタンス化時間、描画に干渉しているか
• 実行時影響：長時間タスク、フレーム落ち、メモリ増加（WASMメモリの拡張がユーザーに影響することがある）
• 境界コスト：呼び出し回数が多すぎて速度改善が失われていないか

リアルユーザーモニタリングで導入前後を比較してください。計測や予算設定で支援が必要なら /pricing を参照し、関連する記事は /blog にあります。

安全にイテレートする

まずは機能フラグの背後にモジュールを置いて1つずつ展開し、計測してから範囲を広げてください。最速のWASMデプロイは素早くロールバックできるものです。

セキュリティ、互換性、UXに関する考慮点

WASMは“ネイティブに近い”感覚がありますが、ブラウザではJavaScriptと同じセキュリティモデルの下にあります。適切に計画すれば安心です。

セキュリティの基礎：サンドボックス、オリジン、更新

WASMはサンドボックス内で実行され、ユーザーのファイルやOS、任意ネットワークに直接アクセスできません。外部とのやり取りは通常JS経由で明示的に与えた能力のみです。

オリジンルールは依然として適用されます。CDNや別ドメインから.wasmを取得する場合はCORSを正しく設定し、そのバイナリを実行可能コードとして扱ってください。HTTPSを使い、SRIやバージョン管理、キャッシュバスティング、ロールバック計画を用意しておくと、静かにバイナリが差し替えられたときのデバッグが容易になります。

サプライチェーンリスク：ネイティブライブラリの持ち込み

多くのWASMビルドはもともとデスクトップ向けに設計されたC/C++やRustライブラリを引き込みます。信頼するコードベースが急速に増えるため、依存を絞り、バージョンを固定し、画像解析や圧縮、暗号といった脆弱性の起こりやすい領域に注意してください。可能なら再現可能ビルドやバックエンド同様のセキュリティスキャンを導入しましょう。

ブラウザ互換性とフォールバック

古いブラウザや埋め込みWebView、企業の制約環境では同じ挙動にならないことがあります。機能検出を行いフォールバックを用意してください：簡易なJS実装、機能を限定した体験、あるいはサーバサイドの代替処理など。重要なフロー（チェックアウトやログインなど）ではWASMを唯一の手段にしないでください。

アクセシビリティとUX：UIの応答性を保つ

重い処理はメインスレッドを凍結させます。可能な限りWeb Workerにオフロードし、UIスレッドはレンダリングと入力に専念させてください。WASMの読み込み／初期化は非同期に行い、大きなダウンロードにはプログレス表示を行い、キーボードやスクリーンリーダー利用者が長時間待たされないように設計してください。どれだけ高速なアルゴリズムでも、ページが応答しないと意味がありません。

大きな変化：WebAssembly後のブラウザにおける言語像

WebAssemblyは“ブラウザでのプログラミング言語”の意味を変えます。以前は「ブラウザで動く＝JavaScriptで書く」に近かったのが、今は「多くの言語で書き、ポータブルなバイナリにコンパイルしてブラウザで安全に実行する」が成立するようになりました——ただしJavaScriptは体験を調整する役割で残ります。

現在の“ブラウザ言語”の意味

WASM以降、ブラウザは単なるJS専用エンジンではなく、二層をホストできるランタイムになっています：

• UI + プラットフォームグルー：DOM更新、イベント、ストレージ、ネットワーキングAPI
• 計算モジュール：高性能かつ複雑なロジックをWASMで実行

この変化はJavaScriptを置き換えるのではなく、アプリの“部分”に対する選択肢を広げます。

なぜJavaScriptが不可欠であり続けるか

JavaScript（とTypeScript）は中心的なままです：

• 多くのブラウザAPIはJSから使うのが最も簡単（場合によっては唯一の現実的手段）
• UI仕事は依然としてDOMやフレームワーク主導
• WASMモジュールの読み込みや呼び出しは通常JS経由で行われる

WASMはアタッチする専用エンジンであり、すべてを構築する新手段ではありません。

WASMのこれから（実務的な期待）

劇的な“ウェブを作り直す”瞬間ではなく、漸進的な改善が続くと予想してください。ツールやデバッグ、相互運用は滑らかになり、より多くのライブラリがWASMビルドを提供するでしょう。一方でブラウザはセキュアな境界や明示的な権限、予測可能な性能を重視し続けるため、すべてのネイティブパターンがそのまま移行できるわけではありません。

導入判断のための質問集

WASM導入前に自問してください：

1. 明確なホットスポットがあるか？（例：動画処理、CAD、重いパース）
2. モジュールに明確な境界を設けられるか？ JSとの往復が最小か
3. 既存のライブラリが必要か？ WASMで成熟したC/C++/Rustコードを活かせるか
4. 成功を計測できるか？ バンドルサイズ、起動時間、実ユーザーのレイテンシを評価できるか

確信が持てない場合はまずJavaScriptで進め、見返りが明確になったらWASMを追加してください。