Monday, September 29, 2025

WebAssemblyで蘇るC/C++資産：レガシーコードを現代ウェブ技術で活用する実践
  /   No comments   

多くの企業や組織には、長年にわたって開発・保守され、その性能と安定性が証明されてきた貴重なC/C++のコード資産が存在します。これらは、複雑な数値計算ライブラリ、独自の物理シミュレーションエンジン、高性能な画像処理アルゴリズム、あるいは基幹業務を支えるビジネスロジックなど、多岐にわたります。これらの資産は、組織の競争力の源泉そのものであることも少なくありません。しかし、その一方で、これらのコードは特定のOSやハードウェアに依存したデスクトップアプリケーションやサーバーサイドのコンポーネントとして構築されていることが多く、現代のウェブ中心の開発パラダイムから取り残されがちです。ウェブアプリケーションで同様の機能を実現しようとする場合、多くの開発チームはJavaScriptやTypeScriptによる「再実装」という選択を迫られます。しかし、このアプローチは多大なコスト、時間、そしてリスクを伴います。ゼロからの再実装は、元のコードに暗黙的に含まれていた細かなノウハウやエッジケースの考慮が漏れる危険性を常に孕んでおり、オリジナルの性能や安定性を再現できる保証はありません。

このジレンマを解決する革新的な技術として登場したのが、WebAssembly（Wasm）です。WebAssemblyは、ウェブブラウザ上でネイティブコードに匹敵する速度で実行可能な、新しいバイナリ形式のコードです。これは、特定のプログラミング言語ではなく、C、C++、Rustといった多様な言語からのコンパイルターゲットとして設計されています。WebAssemblyの登場により、これまでデスクトップやサーバーに閉じていたC/C++の資産を、大規模な書き換えを行うことなく、ウェブブラウザという広大なプラットフォーム上で再利用する道が開かれました。これにより、開発者は既存の資産が持つ性能と信頼性を維持しつつ、ウェブの持つアクセシビリティと展開の容易さを享受できるようになります。

本記事では、WebAssemblyを用いて既存のC/C++資産をウェブアプリケーションで活用するための、具体的かつ実践的な手順を詳細に解説します。環境構築から始まり、単純な関数の呼び出し、複雑なデータ型（文字列や構造体）の連携、さらにはファイルシステムの利用やパフォーマンス最適化といった高度なトピックまで、段階的に掘り下げていきます。単なる技術の紹介に留まらず、実世界のプロジェクトで直面するであろう課題や、その解決策についても踏み込んで考察します。この記事を読み終える頃には、あなたは自社の貴重なコード資産を現代のウェブ技術と融合させ、新たな価値を創造するための確かな知識とインスピレーションを得ていることでしょう。

第1章 WebAssemblyの基礎概念：なぜ今、C/C++資産の活用に最適なのか

WebAssembly（Wasm）がなぜこれほどまでに注目を集め、特にレガシーコードの再利用という文脈で強力なソリューションとなり得るのかを理解するためには、その技術的な背景と特性を正しく把握することが不可欠です。

1.1 WebAssemblyとは何か？

WebAssemblyは、しばしば「ウェブのためのアセンブリ言語」と形容されますが、その本質はもう少し深遠です。主要な特徴を以下に挙げます。

  • バイナリ命令フォーマット: WebAssemblyは、人間が直接読み書きするためのテキストベースの言語ではありません。それは、スタックベースの仮想マシンが効率的に解釈・実行できるように設計された、コンパクトなバイナリ形式の命令セットです。ただし、デバッグや理解のために、.wat (WebAssembly Text Format) という人間が読めるテキスト表現も存在します。
  • コンパイルターゲット: 開発者が直接WebAssemblyバイナリを書くことは稀です。通常は、C、C++、Rust、Go、C#といった既存のプログラミング言語で書かれたソースコードを、専用のコンパイラ（例えば、C/C++向けのEmscriptenやRust向けのwasm-pack）を用いてWebAssemblyにコンパイルします。
  • ブラウザ内サンドボックス実行: WebAssemblyの最も重要なセキュリティ機能の一つが、サンドボックス環境での実行です。Wasmコードは、ウェブブラウザが提供する厳格に管理されたメモリ空間内でのみ動作し、ホストOSのファイルシステムやネットワーク、その他のリソースに直接アクセスすることはできません。すべての外部とのやり取りは、JavaScript APIを介して、ブラウザのセキュリティポリシーに従って明示的に許可される必要があります。これにより、ネイティブコードをウェブ上で安全に実行することが可能になります。
  • ニアネイティブなパフォーマンス: Wasmバイナリは、JavaScriptのような動的型付け言語とは異なり、静的に型付けされ、事前に最適化されています。ブラウザの実行エンジンは、このバイナリを非常に高速にデコードし、マシンコードにコンパイル（AOT/JITコンパイル）できます。その結果、特にCPU負荷の高い計算処理（画像・動画処理、3Dレンダリング、暗号化、物理シミュレーションなど）において、JavaScriptを遥かに凌ぎ、ネイティブアプリケーションに迫るほどの実行速度を達成します。

1.2 JavaScriptとの関係性：競合ではなく共生

WebAssemblyの登場は、「JavaScriptの終わり」を意味するものではありません。むしろ、WebAssemblyとJavaScriptは、それぞれが得意な領域を担当し、互いを補完し合う共生関係にあります。この関係性を理解することは、効果的なウェブアプリケーションを設計する上で極めて重要です。

  • JavaScriptの役割（オーケストレーター）: JavaScriptは、ウェブプラットフォームの「母国語」であり続けます。DOM（Document Object Model）の操作、UIイベントのハンドリング、ネットワークリクエスト（Fetch API）、そしてアプリケーション全体のロジックの組み立てといった、柔軟性と動的な性質が求められるタスクに非常に優れています。ウェブアプリケーションにおいて、JavaScriptは全体の流れを制御する「指揮者（オーケストレーター）」の役割を担います。
  • WebAssemblyの役割（ワークホース）: 一方、WebAssemblyは、前述の通り、計算集約的なタスク、つまり「働き蜂（ワークホース）」の役割を担います。JavaScriptから重い処理をWasmモジュールにオフロードすることで、UIのスムーズな応答性を維持しつつ、高度な機能を実現できます。例えば、ユーザーがアップロードした画像を加工するウェブアプリケーションを考えてみましょう。画像の読み込み、UIのボタン操作などはJavaScriptが担当し、ボタンがクリックされたら、実際の画像フィルタ適用やリサイズといったピクセル単位の重い計算をWebAssemblyモジュールに渡し、その結果を再びJavaScriptが受け取って画面に表示する、という分業が理想的です。

この連携は、WebAssembly JavaScript API を通じて行われます。JavaScriptからWasmモジュールをロードし、その中からエクスポート（公開）された関数を呼び出したり、Wasmモジュールのメモリ空間にデータを書き込んだり、逆に読み取ったりすることができます。この「境界」を越えるデータのやり取りには一定のオーバーヘッドがあるため、頻繁な細切れの呼び出しよりも、一度にまとまったデータを渡してWasm側で集中的に処理させる方が効率的です。

1.3 C/C++資産活用におけるWebAssemblyの圧倒的優位性

これらの特性を踏まえると、WebAssemblyが既存のC/C++資産をウェブで活用する上で、なぜこれほど強力な選択肢となるのかが明らかになります。

  1. パフォーマンスの維持: C/C++で書かれたコードの最大の利点の一つは、その実行速度です。WebAssemblyは、このパフォーマンスをほとんど損なうことなくウェブブラウザ上で再現できる唯一の現実的な手段です。JavaScriptへの再実装では、たとえ高度に最適化しても、元のC/C++コードの性能に追いつくことは困難な場合が多いです。
  2. コードの再利用による開発効率の向上: 数万、数十万行に及ぶ実績あるコードベースを再実装する手間とリスクを完全に排除できます。これにより、開発期間を大幅に短縮し、本来注力すべき新しい機能の開発やUI/UXの改善にリソースを集中させることができます。
  3. 信頼性と正確性の担保: 長年使われ、十分にデバッグされてきたロジックをそのまま流用できるため、再実装に伴うバグの混入リスクを最小限に抑えられます。特に、金融計算や科学技術シミュレーションのように、寸分の狂いも許されない分野では、この利点は計り知れません。
  4. 成熟したエコシステム: 特にC/C++からWebAssemblyへのコンパイルにおいては、Emscriptenという非常に成熟したツールチェインが存在します。Emscriptenは、単なるコンパイラに留まらず、標準Cライブラリ（libc）やC++標準ライブラリ（libc++）、さらにはOpenGL（WebGL経由）やSDLといった一般的なライブラリのAPIまでをもエミュレートする機能を提供します。これにより、多くの既存C/C++プロジェクトは、最小限のコード修正でWebAssemblyに移植することが可能です。

結論として、WebAssemblyは、パフォーマンス、安全性、そして既存資産の再利用という、これまでウェブプラットフォームが抱えていた課題に対するエレガントな解答です。それは、過去の偉大な技術的投資を未来のウェブアプリケーションへと繋ぐ、強力な架け橋となるのです。

第2章 開発環境の構築：Emscriptenツールチェインのセットアップ

C/C++コードをWebAssemblyに変換する旅は、適切な道具を揃えることから始まります。その中心となるのがEmscriptenです。この章では、Emscriptenとは何かを理解し、実際に開発マシンにセットアップするまでの詳細な手順を解説します。

2.1 Emscriptenとは？ LLVMを基盤とした強力なコンパイラ

Emscriptenは、C/C++コードをWebAssemblyにコンパイルするための、オープンソースのコンパイラ・ツールチェインです。その心臓部には、業界標準のコンパイラ基盤であるLLVMが使われています。Emscriptenの役割は、単にC/C++の構文をWasmの命令に変換するだけではありません。それ以上に、既存のC/C++プログラムが動作するために必要な「環境」を、ウェブブラウザ上で再現するという、より広範な役割を担っています。

Emscriptenが提供する主な機能は以下の通りです。

  • C/C++からWasmへのコンパイル: LLVMのフロントエンドであるClangを利用してC/C++コードをパースし、LLVMの中間表現（IR）に変換します。その後、LLVMのWasmバックエンドを用いて、この中間表現を最適化し、最終的な.wasmバイナリを生成します。
  • JavaScriptグルーコードの生成: Wasmモジュールは、それ単体では動作できません。JavaScriptからロードされ、呼び出される必要があります。Emscriptenは、このWasmモジュールをロードし、メモリを初期化し、エクスポートされた関数を呼び出すためのインターフェースを提供するJavaScriptファイル（通称「グルー（接着剤）コード」）を自動的に生成します。
  • 標準ライブラリのサポート: C/C++プログラムは、printf, malloc, strcpyといった標準Cライブラリ（libc）や、C++のSTL（Standard Template Library）に大きく依存しています。Emscriptenは、これらの標準ライブラリの大部分（musl libcやlibc++をベースにしています）を実装しており、コンパイル時にWasmモジュールに静的にリンクします。例えば、Cコード内のprintf("hello");は、ブラウザのconsole.log("hello");を呼び出すJavaScriptコードに変換されます。
  • システムAPIのエミュレーション: デスクトップアプリケーションは、ファイルI/Oやグラフィックス、音声など、OSが提供する様々なAPIを利用します。Emscriptenは、これらのAPIの一部をウェブ標準技術を用いてエミュレートします。
    • ファイルシステム: メモリ上に仮想的なファイルシステム（MEMFS）を構築し、標準的なファイルI/O関数（fopen, fread, fwriteなど）をサポートします。これにより、ファイル操作を前提としたライブラリも、コードを変更することなく動作させることが可能です。
    • OpenGL: OpenGL ES 2.0/3.0のAPIコールを、ブラウザのWebGL 1/2のAPIコールに変換する層を提供します。これにより、OpenGLで書かれた3Dグラフィックスアプリケーションをウェブに移植できます。
    • SDL (Simple DirectMedia Layer): ゲーム開発で広く使われるマルチメディアライブラリSDLのAPIもサポートしており、SDLベースのゲームをウェブに移植する際の強力な助けとなります。

2.2 Emscripten SDK (emsdk) を用いた環境構築

Emscriptenとそれに必要なClang, LLVM, Python, Node.jsといった多数の依存ツールを個別にインストールするのは非常に煩雑です。幸いなことに、これらすべてを簡単に管理・インストールできるEmscripten SDK (emsdk) という公式ツールが提供されています。ここでは、emsdkを使った推奨のインストール手順を解説します。

ステップ1: emsdkリポジトリのクローン

まず、emsdkをインストールしたいディレクトリに移動し、Gitを使ってリポジトリをクローンします。


# 任意のインストール先ディレクトリに移動
cd /path/to/your/development/folder

# emsdk のリポジトリをクローン
git clone https://github.com/emscripten-core/emsdk.git

# 作成された emsdk ディレクトリに移動
cd emsdk

ステップ2: 最新ツールの取得とインストール

次に、emsdkのスクリプトを使って、Emscriptenツールチェインの最新バージョンをダウンロードし、インストールします。


# 最新のツールチェインをフェッチ
./emsdk install latest

# Windowsの場合:
# emsdk install latest

このコマンドは、Emscripten本体、特定のバージョンのClang/LLVM、Node.js、Pythonなど、コンパイルに必要なすべてのコンポーネントをダウンロードしてemsdkのディレクトリ内に配置します。インターネット接続の速度によっては、数分から数十分かかることがあります。

ステップ3: 最新ツールの有効化（アクティベート）

インストールが完了したら、そのツールチェインを「現在使用するバージョン」として設定（アクティベート）する必要があります。


# インストールした最新のツールチェインをアクティベート
./emsdk activate latest

# Windowsの場合:
# emsdk activate latest

このコマンドは、.emscriptenという設定ファイルをユーザーのホームディレクトリに生成し、各種ツールのパスなどを記録します。これにより、emsdkはどのバージョンのツールを使えばよいかを認識します。

ステップ4: 環境変数の設定

最後に、現在のターミナルセッションでEmscriptenのコンパイラコマンド（emcc, em++など）を使えるように、環境変数を設定します。emsdkには、このための便利なスクリプトが用意されています。


# 現在のターミナルセッションの環境変数を設定 (Linux/macOS)
source ./emsdk_env.sh

# Windows (Command Prompt) の場合:
# emsdk_env.bat

重要: この環境変数の設定は、現在のターミナルセッションでのみ有効です。ターミナルを新しく開いた場合は、再度このコマンドを実行する必要があります。毎回実行するのが面倒な場合は、~/.bash_profile, ~/.zshrc, ~/.bashrcといったシェルの設定ファイルにsource /path/to/your/emsdk/emsdk_env.shの一行を追記しておくと、ターミナル起動時に自動で環境変数が設定されるようになります。

ステップ5: インストールの確認

すべてが正しく設定されたかを確認するために、Emscriptenのコンパイラコマンドemccのバージョンを表示させてみましょう。


emcc -v

以下のように、emccのバージョン、ターゲット、使用しているLLVMのバージョンなどの情報が表示されれば、環境構築は成功です。


emcc (Emscripten gcc/clang-like replacement) 3.1.25 (a5397c64b184749a9578164f16362d2d184719c8)
clang version 17.0.0 (https://github.com/llvm/llvm-project.git 28919630e2f5b8c9913063f169f4cb0a95e0c511)
Target: wasm32-unknown-emscripten
Thread model: posix
...

これで、C/C++のコード資産をWebAssemblyへと変換するための強力な武器が手に入りました。次の章からは、いよいよ実際にコードをコンパイルし、ウェブブラウザで動かしていきます。

第3章 実践(1)：基本的なC/C++コードのWebAssembly化

環境が整ったところで、いよいよC/C++コードをWebAssemblyにコンパイルするプロセスを体験してみましょう。この章では、最も単純な例から始め、徐々にJavaScriptとの連携を深めていく方法を学びます。

3.1 最初のステップ：C言語での "Hello, WebAssembly!"

まずは、Emscriptenがどれだけ簡単にCコードをウェブページに変換できるかを見てみましょう。コンソールにメッセージを出力するだけの、古典的な "Hello, World!" プログラムを作成します。

ステップ1: Cソースコードの作成

hello.cという名前で、以下の内容のファイルを作成します。


#include <stdio.h>

int main() {
    printf("Hello, WebAssembly!\n");
    return 0;
}

これはごく普通のCプログラムです。特筆すべきは、WebAssemblyを意識したコードは一切含まれていないという点です。Emscriptenがprintfのような標準ライブラリ関数を適切に処理してくれます。

ステップ2: Emscriptenによるコンパイル

ターミナルで、このファイルをemccコマンドを使ってコンパイルします。


emcc hello.c -o hello.html

このコマンドの意味を分解してみましょう。

  • emcc: Emscriptenのコンパイラコマンドです。GCCやClangと似たインターフェースを持っています。
  • hello.c: 入力となるソースファイルです。
  • -o hello.html: 出力ファイル名を指定します。Emscriptenは、出力ファイルの拡張子を見て、生成するファイルの形式を賢く判断します。
    • .htmlを指定すると、Wasmモジュール、それをロードするためのJavaScriptグルーコード、そして実行結果を表示するためのHTMLシェルページの3点セットが自動的に生成されます。これは動作確認に非常に便利です。
    • .jsを指定すると、WasmモジュールとJavaScriptグルーコードが生成されます。
    • .wasmを指定すると、Wasmモジュールのみが生成されます（グルーコードは生成されないため、手動でロード処理を書く必要があります）。

コマンドを実行すると、カレントディレクトリに以下のファイルが生成されているはずです。

  • hello.html: Wasmモジュールをロードして実行するHTMLページ。
  • hello.js: WasmモジュールとJavaScript世界を繋ぐグルーコード。
  • hello.wasm: コンパイルされたWebAssemblyバイナリ本体。

ステップ3: 実行と確認

生成されたhello.htmlをブラウザで開いてみましょう。ただし、多くのブラウザはセキュリティ上の理由から、ローカルファイルシステム（file://プロトコル）から直接JavaScriptモジュールやWasmファイルをフェッチすることを制限しています。そのため、ローカルウェブサーバーを立ててアクセスする必要があります。

Pythonがインストールされていれば、以下のコマンドで簡単にサーバーを起動できます。


# Python 3.x の場合
python -m http.server

# Python 2.x の場合
# python -m SimpleHTTPServer

サーバーが起動したら、ウェブブラウザで http://localhost:8000/hello.html にアクセスします。ページのコンソール（開発者ツール）を開くと、以下のように表示されているはずです。


Hello, WebAssembly!

見事に、Cのprintfがブラウザのコンソール出力にリダイレクトされました。これが、Emscriptenの強力なエミュレーション機能の一端です。

3.2 C++関数をエクスポートし、JavaScriptから呼び出す

main関数を実行するだけでは、ウェブアプリケーションとの連携はできません。次に、C++で定義した特定の関数をJavaScriptから自由に呼び出せるようにする方法を学びます。これにより、Wasmを計算ライブラリとして利用する道が開けます。

ステップ1: C++ソースコードの作成

calculator.cppという名前で、2つの数値を加算する簡単な関数を持つファイルを作成します。


#include <emscripten.h>

extern "C" {

EMSCRIPTEN_KEEPALIVE
int add(int a, int b) {
    return a + b;
}

}

ここには、いくつかの重要な新しい要素が含まれています。

  • #include <emscripten.h>: Emscriptenが提供する特別なマクロや関数を使うために必要なヘッダーファイルです。
  • extern "C" { ... }: C++コンパイラは、関数名をマングリング（修飾）して、オーバーロードなどを可能にしています。しかし、このマングリングされた名前はJavaScript側からは非常に扱いにくいため、extern "C"ブロックで囲むことで、C言語形式のシンプルな関数名（この場合はadd）でエクスポートするようにコンパイラに指示します。
  • EMSCRIPTEN_KEEPALIVE: これは非常に重要なマクロです。Emscripten（というか、その背後にあるLLVM）は、積極的な最適化の一環として、どこからも呼び出されていないように見えるコード（デッドコード）を最終的なバイナリから削除します。main関数から直接的・間接的に呼び出されていないadd関数は、コンパイラから見ればデッドコードです。EMSCRIPTEN_KEEPALIVEマクロを付与することで、「この関数は外部（JavaScript）から呼び出される可能性があるため、削除しないでください」とコンパイラに伝えることができます。

ステップ2: コンパイルと関数のエクスポート

次に、このC++ファイルをコンパイルしますが、今回はJavaScriptから呼び出したい関数を明示的に指定する必要があります。


emcc calculator.cpp -o calculator.js -s EXPORTED_FUNCTIONS="['_add']"

新しいコンパイルフラグについて解説します。

  • -o calculator.js: 今回はHTMLは不要なので、グルーコードとWasmファイルのみを生成するように.jsを指定します。
  • -s <KEY>="<VALUE>": Emscriptenのコンパイル設定を変更するためのフラグです。
  • EXPORTED_FUNCTIONS="['_add']": これが、JavaScript側にエクスポートする関数を指定する部分です。注意点として、Cの関数名は先頭にアンダースコア_を付けて指定する必要があります。 したがって、add関数は_addとしてエクスポートします。複数の関数を指定する場合は、"['_add', '_subtract']"のようにカンマ区切りでリストします。

ステップ3: JavaScriptからの呼び出し

Wasmモジュールとグルーコードcalculator.jsが生成されたので、これらをロードしてadd関数を呼び出すHTMLファイルを作成します。index.htmlという名前で以下のファイルを作成してください。


<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Wasm Calculator</title>
</head>
<body>
    <h1>WebAssembly Calculator</h1>
    <p>コンソールを開いて結果を確認してください。</p>

    <!-- Emscriptenが生成したグルーコードを読み込む -->
    <script src="calculator.js"></script>
    <script>
        // Emscriptenのモジュールが初期化されるのを待つ必要がある。
        // Moduleオブジェクトはグルーコードによってグローバルスコープに作られる。
        Module.onRuntimeInitialized = function() {
            console.log("WebAssembly module is ready.");

            // _add関数をJavaScriptの関数としてラップする
            // 'cwrap'はEmscriptenのヘルパー関数。
            // cwrap(関数名, 戻り値の型, [引数の型の配列])
            const addFunction = Module.cwrap('add', 'number', ['number', 'number']);
            
            const result = addFunction(15, 27);
            console.log("15 + 27 =", result); // 42 が出力されるはず
        };
    </script>
</body>
</html>

このHTMLのJavaScript部分が鍵となります。

  • <script src="calculator.js"></script>: まず、Emscriptenが生成したグルーコードを読み込みます。これにより、グローバルスコープにModuleというオブジェクトが作成されます。
  • Module.onRuntimeInitialized: Wasmモジュールのダウンロード、コンパイル、初期化は非同期で行われます。そのため、エクスポートされた関数を安全に呼び出せるようになるのは、これらの処理がすべて完了してからです。Module.onRuntimeInitializedコールバックプロパティに関数を設定しておくと、モジュールが準備完了になった時点でその関数が呼び出されます。
  • Module.cwrap(): Emscriptenが提供する便利なヘルパー関数です。これは、エクスポートされたC/C++関数を、型変換などを自動的に処理してくれる使いやすいJavaScript関数でラップ（包み込み）します。
    • 第1引数: C/C++での関数名（アンダースコアなし）。
    • 第2引数: 関数の戻り値の型（'number', 'string', 'null'など）。
    • 第3引数: 関数の引数の型を配列で指定します。
    cwrapの代わりにccallという関数もあり、こちらはラップせずに一度だけ関数を呼び出すのに使います。

先ほどと同様にローカルサーバーを起動し、http://localhost:8000/index.htmlにアクセスしてください。コンソールに "WebAssembly module is ready." と "15 + 27 = 42" が表示されれば成功です。これで、C++で書かれたロジックを、ウェブアプリケーションのJavaScriptから部品として呼び出す基本的なワークフローが完成しました。

第4章 実践(2)：複雑なデータ型とメモリ管理の探求

数値の受け渡しは簡単でしたが、実際のアプリケーションでは文字列、配列、構造体といった、より複雑なデータを扱う必要があります。これらのデータをJavaScriptとWebAssemblyの間でやり取りするには、両者のメモリモデルの違いを深く理解することが不可欠です。

4.1 WebAssemblyのメモリモデル：分離されたリニアメモリ

WebAssemblyのセキュリティとパフォーマンスの根幹をなすのが、そのメモリモデルです。

  • リニアメモリ (Linear Memory): 各Wasmモジュールは、サンドボックス化された、連続した単一のメモリ領域を持ちます。これは、JavaScriptの世界からは一つの巨大なArrayBufferオブジェクトとして見えます。Wasmコードはこのメモリ領域に対してのみ、自由に読み書きができます。
  • 分離されたメモリ空間: 重要なのは、Wasmのリニアメモリは、JavaScriptのヒープ（オブジェクトや変数が格納される場所）とは完全に分離されているということです。WasmはJavaScriptのオブジェクトに直接アクセスできませんし、逆もまた然りです。
  • データの共有方法: 両者がデータを共有するには、一方のメモリ空間からもう一方のメモリ空間へ、データを明示的にコピーする必要があります。このコピー処理は、Emscriptenが生成したグルーコード内のヘルパー関数や、JavaScriptのTypedArray（Uint8Arrayなど）を介して行われます。

この「メモリの壁」と「明示的なコピー」という概念を念頭に置きながら、具体的なデータ型の扱い方を見ていきましょう。

4.2 文字列の受け渡し (JavaScript → WebAssembly)

JavaScriptの文字列を、それを受け取るC++関数に渡すシナリオを考えます。C++側では文字列は通常const char*（ヌル終端文字列へのポインタ）として扱われます。

ステップ1: C++ソースコードの作成

string_processor.cppというファイル名で、受け取った文字列をコンソールに出力し、その長さを返す関数を作成します。


#include <cstdio>
#include <cstring>
#include <emscripten.h>

extern "C" {

EMSCRIPTEN_KEEPALIVE
void greet(const char* name) {
    printf("Hello from C++, %s!\n", name);
}

EMSCRIPTEN_KEEPALIVE
int get_string_length(const char* str) {
    return strlen(str);
}

}

ステップ2: コンパイル

今回は_greetと_get_string_lengthの2つの関数をエクスポートします。


emcc string_processor.cpp -o string_processor.js -s EXPORTED_FUNCTIONS="['_greet', '_get_string_length']"

ステップ3: JavaScriptからの呼び出し

文字列を渡すプロセスは、数値よりも少し複雑になります。

  1. JavaScriptの文字列をWasmに渡すことはできません。
  2. 代わりに、Wasmのリニアメモリ内に、その文字列を格納するのに十分な領域を確保します。（Cのmallocに相当）
  3. 確保した領域に、JavaScript文字列をUTF-8エンコードしたバイト列としてコピーします。
  4. その領域の開始アドレス（ポインタ）を、C++関数に数値として渡します。
  5. 処理が終わったら、確保したメモリを解放します。（Cのfreeに相当）

幸いなことに、Emscriptenのグルーコードは、このプロセスを簡単にするためのヘルパー関数を提供しています。ccallやcwrapは、引数に'string'型を指定すると、これらの処理を内部で自動的に行ってくれます。


<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>JS to Wasm String</title>
</head>
<body>
    <script src="string_processor.js"></script>
    <script>
        Module.onRuntimeInitialized = function() {
            console.log("Wasm module ready.");

            const myName = "WebAssembly Developer";

            // --- ccall を使ったシンプルな呼び出し ---
            // ccall(関数名, 戻り値の型, [引数の型], [引数の値])
            Module.ccall('greet', null, ['string'], [myName]);

            // --- cwrap を使った呼び出し ---
            const getStringLength = Module.cwrap(
                'get_string_length', 
                'number', 
                ['string']
            );
            
            const len = getStringLength(myName);
            console.log(`The length of "${myName}" is ${len}`);
        };
    </script>
</body>
</html>

これを実行すると、コンソールには以下のように表示されます。


Wasm module ready.
Hello from C++, WebAssembly Developer!
The length of "WebAssembly Developer" is 21

ccallやcwrapが裏側でメモリの確保、コピー、解放をすべて自動で行ってくれるため、非常にシンプルに記述できました。ただし、内部で何が起こっているかを理解しておくことは、より高度なメモリ操作やパフォーマンスチューニングを行う上で重要です。

4.3 文字列の受け渡し (WebAssembly → JavaScript)

次に、C++側で生成した文字列をJavaScript側で受け取る方法を見てみましょう。この場合、メモリの所有権と解放の責任が誰にあるかを意識することが重要になります。

ステップ1: C++ソースコードの作成

string_generator.cppというファイル名で、文字列を生成してそのポインタを返す関数を作成します。


#include <cstdlib> // for malloc
#include <cstring> // for strcpy
#include <emscripten.h>

extern "C" {

// この関数が返す文字列のメモリは、呼び出し側（JavaScript）で解放する必要がある。
EMSCRIPTEN_KEEPALIVE
const char* get_greeting_message() {
    const char* message = "This message was generated in C++!";
    // Wasmのヒープ上にメモリを確保
    char* buffer = (char*)malloc(strlen(message) + 1); 
    strcpy(buffer, message);
    return buffer;
}

// JavaScript側からメモリを解放するために、free関数もエクスポートする
EMSCRIPTEN_KEEPALIVE
void free_memory(void* ptr) {
    free(ptr);
}

}

極めて重要なポイント: get_greeting_message関数は、mallocを使ってWasmのヒープ上にメモリを確保しています。このメモリは自動的には解放されません。したがって、JavaScript側で文字列を使い終わった後に、このメモリを解放する手段を提供する必要があります。そのために、標準のfree関数をラップしたfree_memory関数もエクスポートしています。

ステップ2: コンパイル

mallocとfreeはデフォルトでエクスポートされることが多いですが、明示的に指定しておくと安全です。今回は_get_greeting_message, _free_memory, そして内部で使われる_malloc, _freeをエクスポートします。


emcc string_generator.cpp -o string_generator.js -s EXPORTED_FUNCTIONS="['_get_greeting_message', '_free_memory', '_malloc', '_free']"

ステップ3: JavaScriptからの呼び出し

JavaScript側では、以下の手順で文字列を受け取ります。

  1. C++関数を呼び出し、Wasmのリニアメモリ内の文字列へのポインタ（メモリアドレスを示す数値）を受け取ります。
  2. Emscriptenのヘルパー関数Module.UTF8ToString(ptr)を使い、そのポインタが指すアドレスからヌル終端文字までを読み取り、JavaScriptの文字列にデコードします。
  3. 文字列を使い終わったら、エクスポートしておいたfree_memory関数を呼び出して、ポインタが指すメモリを解放します。これを忘れるとメモリリークになります。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Wasm to JS String</title>
</head>
<body>
    <h2 id="message">Loading...</h2>
    <script src="string_generator.js"></script>
    <script>
        Module.onRuntimeInitialized = function() {
            const getGreetingMessage = Module.cwrap(
                'get_greeting_message', 
                'number', // CのポインタはJSでは数値として扱われる
                []
            );
            
            const freeMemory = Module.cwrap(
                'free_memory', 
                null, 
                ['number']
            );

            // 1. C++関数を呼び出してポインタを取得
            const messagePtr = getGreetingMessage();

            // 2. ポインタからJavaScript文字列に変換
            const message = Module.UTF8ToString(messagePtr);

            console.log("Received message:", message);
            document.getElementById('message').textContent = message;

            // 3. 使い終わったメモリを解放 (非常に重要！)
            freeMemory(messagePtr);
            console.log("Memory freed at pointer:", messagePtr);
        };
    </script>
</body>
</html>

4.4 構造体と配列の操作

構造体や配列のような、より複雑なデータ構造を扱う場合も、基本は同じです。Wasmのメモリ上に適切なレイアウトでデータを配置し、その開始ポインタを渡します。

例えば、struct Point { int x; int y; }; という構造体を扱うC++関数 void process_point(Point* p) があるとします。JavaScriptからこれを呼び出すには、

  1. _malloc(sizeof(Point))でメモリを確保します。C++のsizeof(Point)は8バイト（32ビット環境でintが4バイトの場合）なので、JavaScript側でModule._malloc(8)を呼び出します。
  2. 確保したポインタptrに対して、Module.HEAP32というTypedArrayビューを使って値を書き込みます。HEAP32はWasmのリニアメモリを32ビット整数の配列として見なします。
    • Module.HEAP32[ptr / 4] = 100; // x座標をセット (バイトオフセットを4で割る)
    • Module.HEAP32[ptr / 4 + 1] = 200; // y座標をセット
  3. C++関数 process_point(ptr) を呼び出します。
  4. 処理が終わったら_free(ptr)でメモリを解放します。

このように、複雑なデータ構造を扱う際には、Wasmのリニアメモリを直接TypedArrayで操作する必要が出てきます。データのエンディアンやアラインメントにも注意が必要になる場合がありますが、Emscriptenのヘルパービュー（HEAP8, HEAPU8, HEAP16, HEAP32, HEAPF32, HEAPF64など）がこれらの低レベルな操作を強力にサポートしてくれます。

第5章 高度なトピックと最適化

基本的なデータのやり取りができるようになったら、次は実用的なアプリケーションを構築するために必要な、より高度な機能とパフォーマンスチューニングについて見ていきましょう。

5.1 ファイルシステムのエミュレーション：既存のコードをそのまま動かす

多くの既存C/C++ライブラリは、設定ファイルを読み込んだり、処理結果をファイルに書き出したりするなど、ファイルI/Oを前提としています。ブラウザのサンドボックス環境では直接ホストのファイルシステムにアクセスできませんが、Emscriptenはこの問題を解決するために洗練された仮想ファイルシステムを提供します。

  • MEMFS: デフォルトで使用される、完全にメモリ上に構築されるファイルシステムです。プログラムの実行が終了すると内容は消えます。
  • NODEFS: Node.js環境で実行する場合に、ホストのローカルファイルシステムをマウントして直接読み書きできます。
  • IDBFS: ブラウザのIndexedDBを利用して、永続的なストレージを実現するファイルシステムです。ユーザーがページをリロードしてもファイルの内容が保持されます。

ファイルのプリロード

最も一般的なユースケースは、アプリケーションが必要とするデータファイル（設定ファイル、機械学習モデル、3Dモデルデータなど）を、実行開始前に仮想ファイルシステムに配置しておくことです。これはコンパイル時の--preload-fileオプションで実現できます。


# assetsディレクトリ内の config.json と model.bin を仮想ファイルシステムの /data に配置する
emcc my_app.cpp -o my_app.html --preload-file assets@/data

このコマンドを実行すると、my_app.dataというパッケージファイルが生成されます。実行時に、グルーコードがこの.dataファイルを非同期でフェッチし、内容を展開して仮想ファイルシステムを構築します。その後、C++コードからは、fopen("/data/config.json", "r")のように、通常のファイルパスでこれらのファイルにアクセスできます。

JavaScriptからのファイル操作

JavaScript側から動的に仮想ファイルシステムを操作することも可能です。FSというグローバルオブジェクト（Moduleが初期化された後に利用可能）を介して行います。


// ユーザーがアップロードしたファイルを仮想FSに書き込む
const data = new Uint8Array(fileReader.result);
FS.writeFile('/input/uploaded_image.png', data);

// C++の処理を実行
Module.ccall('process_image', null, ['string'], ['/input/uploaded_image.png']);

// C++が生成した結果ファイルを読み出す
const resultData = FS.readFile('/output/result.txt', { encoding: 'utf8' });
console.log(resultData);

5.2 パフォーマンスチューニング

WebAssemblyの真価を発揮させるには、適切なコンパイルオプションと最新のウェブ技術を活用した最適化が重要です。

コンパイラ最適化フラグ

GCCやClangと同様に、emccも最適化レベルを指定する-Oフラグをサポートしています。

  • -O0: 最適化なし。デバッグに最適。コンパイルが最も速い。
  • -O1, -O2: 一般的な最適化。-O2がパフォーマンスとコードサイズのバランスが良い推奨レベルです。
  • -O3: 最も積極的な最適化。実行速度は最速になる可能性がありますが、コンパイル時間が長くなり、コードサイズも増大することがあります。
  • -Os, -Oz: コードサイズの削減を最優先する最適化。-Ozが最もアグレッシブにサイズを削減します。ネットワーク経由でWasmを配布するウェブ環境では、ダウンロード時間を短縮するために非常に重要です。

SIMD (Single Instruction, Multiple Data)

SIMDは、1つの命令で複数のデータ（例えば、4つの32ビット浮動小数点数）を並列に処理するCPUの機能です。画像処理、音声処理、物理演算などで劇的なパフォーマンス向上をもたらします。WebAssemblyも128ビットのSIMDを仕様としてサポートしており、対応するブラウザで利用できます。

C/C++コードでSSEやNEONといったSIMD命令を使っている場合、EmscriptenはそれをWasm SIMDに変換しようと試みます。-msimd128フラグを付けてコンパイルすることで、この機能を有効化できます。


emcc my_simd_code.cpp -o my_simd_code.js -msimd128 -O3

マルチスレッド (Wasm Threads)

非常に重い計算処理をUIスレッド（メインスレッド）で実行すると、ブラウザがフリーズしてしまいます。WebAssembly Threadsは、Web WorkersをベースにしたPthreads（POSIX Threads）ライブラリのサポートを提供し、真の並列処理を可能にします。

スレッドを有効にするには、-pthreadフラグを付けてコンパイルし、JavaScript側でSharedArrayBufferを扱える環境を整える必要があります。セキュリティ上の要件から、SharedArrayBufferを有効にするには、ウェブサーバーが以下のHTTPヘッダーを返す必要があります。


Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

これらの設定は複雑さを増しますが、デスクトップ級のアプリケーションをウェブに移植する際には不可欠な技術です。

5.3 デバッグ手法

Wasmのデバッグは以前は困難でしたが、最近のブラウザ開発者ツールは大幅に進化しています。

-g4フラグを付けてコンパイルすると、EmscriptenはDWARFデバッグ情報とソースマップを生成します。


emcc my_buggy_code.cpp -o my_buggy_code.html -g4

これにより、ChromeやFirefoxの開発者ツールで、元のC/C++ソースコードに行単位でブレークポイントを設定し、変数の値を検査し、ステップ実行することが可能になります。これは、複雑な問題を解決する上で非常に強力なツールです。

第6章 実世界のシナリオと課題

WebAssemblyは強力な技術ですが、万能の銀の弾丸ではありません。その適用が特に効果的なシナリオと、採用にあたって考慮すべきトレードオフを理解することが成功の鍵です。

6.1 代表的なユースケース

WebAssemblyは、すでに多くの大規模な商用アプリケーションで採用され、その価値を証明しています。

  • Google Earth: WebAssemblyを用いて、デスクトップ版の巨大なC++コードベースをウェブに移植し、高性能な3D地球儀を実現しました。
  • Figma: デザインツールのFigmaは、C++で書かれたレンダリングエンジンをWebAssemblyにコンパイルすることで、ブラウザ上で高速かつ複雑なグラフィック描画を可能にしています。
  • AutoCAD Web: Autodeskは、主力製品であるAutoCADのコアなC++ジオメトリエンジンをWebAssembly化し、数十年にわたる資産をウェブプラットフォームで活用しています。
  • ビデオ・画像編集: FFmpegのような強力なマルチメディアライブラリをWebAssemblyに移植したプロジェクト（例: ffmpeg.wasm）により、サーバーサイドの処理を介さずに、ブラウザ内で直接ビデオのエンコードやフォーマット変換が可能になりました。
  • ゲームエンジン: UnityやUnreal Engineといった主要なゲームエンジンは、WebAssemblyをエクスポートターゲットとしてサポートしており、高品質な3Dゲームをプラグインなしでウェブブラウザに展開できます。

6.2 考慮すべき課題とトレードオフ

WebAssemblyプロジェクトを計画する際には、以下の点に注意が必要です。

  • バンドルサイズ: Wasmモジュール、JavaScriptグルーコード、そしてプリロードされるデータファイルを合わせると、全体のダウンロードサイズが大きくなりがちです。特にモバイル環境では、初期ロード時間に大きな影響を与えます。-Ozフラグによるサイズ最適化、不要な機能の削除、遅延ロードなどの戦略が重要になります。
  • 初期化時間: 大きなWasmモジュールは、ダウンロード後のコンパイルとインスタンス化にも時間がかかります。この処理はメインスレッドをブロックする可能性があるため、async/awaitを用いた非同期でのモジュールロードを徹底し、ユーザーにローディングインジケータを表示するなど、UI/UXへの配慮が不可欠です。
  • DOM操作のオーバーヘッド: WebAssemblyはDOMに直接アクセスできません。WasmモジュールからUIを更新したい場合は、必ずJavaScriptを介して行う必要があります。この「JavaScriptとWasmの境界」を頻繁にまたぐような処理（例えば、ループの中で毎回DOMを更新する）は、呼び出しのオーバーヘッドが大きくなり、パフォーマンスのボトルネックになる可能性があります。処理はWasm内で完結させ、最終結果のみをJavaScriptに返すような設計が理想的です。
  • ライブラリの互換性: すべてのC/C++ライブラリが簡単にEmscriptenでコンパイルできるわけではありません。特定のOSに強く依存した機能（低レベルなネットワークソケット、プロセス操作など）や、GUIツールキット（Qt, Gtkなど）は、そのままでは動作しません。これらの機能については、ウェブAPIを使った代替実装を提供するか、ライブラリの該当部分を無効化するなどの対応が必要になります。

まとめ：過去の資産を未来へ繋ぐ

WebAssemblyは、ウェブ開発の風景を塗り替えるポテンシャルを秘めた、画期的な技術です。特に、長年にわたって培われてきた信頼性の高いC/C++のコード資産を持つ組織にとって、それは単なる新技術以上の意味を持ちます。WebAssemblyは、これらの貴重な資産を陳腐化から救い出し、現代のウェブという広大な舞台で再び輝かせるための、強力な架け橋となります。

本記事で見てきたように、Emscriptenという成熟したツールチェインを用いることで、既存のコードに最小限の変更を加えるだけで、ウェブブラウザ上で実行可能なモジュールへと変換できます。もちろん、メモリ管理の理解、JavaScriptとの連携、パフォーマンスチューニングなど、習得すべき事柄は少なくありません。しかし、その先には、コードの再実装という巨大なリスクとコストを回避し、自社の持つ独自の強みを最大限に活かした、高性能でユニークなウェブアプリケーションを実現するという、大きな見返りが待っています。

WebAssemblyの進化はまだ止まっていません。WASI（WebAssembly System Interface）によるブラウザ外での標準化された実行環境の整備、ガベージコレクションのサポート、より高度な言語機能の統合など、その可能性は広がり続けています。今こそ、あなたの組織に眠るコード資産を掘り起こし、WebAssemblyと共に新たな価値創造の旅を始める絶好の機会です。


0 개의 댓글:

Post a Comment