Skip to content
Published on

ブラウザで本物のエンジンが動く：WebAssembly開発ツール集

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — インストールなし、サーバーなし、データ流出なし

ここ数週間で、このサイトにブラウザツールを大量に追加しました。Pythonインタプリタ、PostgreSQLデータベース、動画変換、さらにはx86 PCエミュレーターまで。共通点が一つあります。これらは真似ではなく本物だということです。Pythonプレイグラウンドは実際にCPythonを実行し、SQLプレイグラウンドは本物のSQLiteを動かします。そしてそのすべてが、バックエンドなしで、あなたのブラウザタブの中で起こります。

これを可能にした技術がWebAssembly（略してWASM）です。この記事はマーケティング文句ではなく、WASMが実際に何を解決し、何はまだできないのか、そしてその上に作ったツールをどう使えばいいのかを扱います。

WebAssemblyがなぜ流れを変えたのか

WebAssemblyはブラウザで動く低レベルのバイトコード形式です。JavaScriptを置き換えようとするものではなく、JavaScriptが苦手だった仕事を引き受けます。核心的な利点は四つです。

  • 近ネイティブ速度：WASMは事前コンパイルされたバイナリ形式なのでパースが速く、JIT/AOTで機械語に近く実行されます。C、C++、Rustで書かれた重いエンジンも実用的な速度で動きます。
  • 言語の移植性：LLVMや専用ツールチェーンでコンパイルできる言語なら、ほとんどWASMへ移植できます。CPython、CRuby、SQLite、ffmpegといった既存のC/Rustコードベースを、ほぼそのままブラウザに持ち込めます。
  • サンドボックス隔離：WASMモジュールは、デフォルトでメモリとシステムアクセスが遮断されたサンドボックスで実行されます。ホスト（JavaScript）が明示的に渡した機能だけを使えるため、信頼できないコードを動かすのに安全です。
  • サーバー不要 + プライバシー：計算がすべてクライアントで行われるのでサーバーが不要です。その結果、入力データがブラウザの外に出ません。写真、コード、ドキュメントをアップロードする必要がありません。

特に最後の項目は実務的に大きいです。iPhoneのHEIC写真を変換したり、会社のログをSQLで分解したりするとき、そのデータがどのサーバーにも送信されないというのは、単なる利便性ではなくセキュリティ要件です。

WASMモジュールはどうロードされるのか

ブラウザがWASMツールを実行する流れは、おおむね次のとおりです。

  1. ページ読み込み
        |
        v
  2. .wasm バイナリをダウンロード（CDN または自己ホスト）
        |
        v
  3. WebAssembly.instantiate() でコンパイル + インスタンス化
        |
        v
  4. JavaScript がホスト関数（ファイル・コンソールなど）を注入
        |
        v
  5. エンジン実行 — 以降の計算はすべてローカル

.wasmファイルはCDNから取得するか、サイトが直接ホストします。Pythonのような大きなランタイムはダウンロードが数MBから数十MBに及ぶため、初回ロードには時間がかかります。その代わりブラウザがこのファイルをキャッシュするので、二回目以降ははるかに速くなります。これが「初回だけ遅く、その後は即座」の理由です。

一つ注意すべきは隔離要件です。スレッドや共有メモリ（SharedArrayBuffer）を使う重いWASMツールは、ブラウザのクロスオリジン隔離（COOP/COEP）ヘッダを要求することがあります。ffmpegのマルチスレッドビルドが代表例です。サイトがこれらのヘッダを正しく設定してはじめて、その機能が有効になります。

言語プレイグラウンド — 本物のインタプリタが動く

もっとも直感的な活用は、プログラミング言語を丸ごとブラウザに入れることです。これらは構文ハイライトだけのエディタではなく、実際のインタプリタを実行します。

  • PythonプレイグラウンドはPyodideでコンパイルされた本物のCPython 3.14を実行します。print出力がそのままキャプチャされ、必要ならnumpyもインストールできます。
  • Rubyプレイグラウンドはruby.wasmでCRuby 3.4を動かします。ブロック、クラス、パターンマッチングまで本物のRubyセマンティクスそのままです。
  • PHPプレイグラウンドはWordPress PlaygroundのWASMエンジンでPHP 8.3を実行します。
  • LuaプレイグラウンドはwasmoonでLua 5.4を動かします。テーブル、メタテーブル、コルーチンまで対応します。

簡単な例として、Pythonプレイグラウンドに次のコードを入れると、サーバー往復なしで即座に結果が出ます。

def fib(n):
    a, b = 0, 1
    for _ in range(n):
        a, b = b, a + b
    return a

print([fib(i) for i in range(10)])
# [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

重要なのは、この結果が「あらかじめ保存された正解」ではないということです。コードを変えれば本物のインタプリタが再実行します。

データベースとデータツール — SQLをブラウザで

データ系のツールはWASMの真価が特によく表れます。実際のデータベースエンジンがタブの中で動くからです。

  • SQLプレイグラウンドは本物のSQLiteをWASMで実行します。サンプルDBでJOIN、GROUP BY、ウィンドウ関数を練習し、結果をCSVにエクスポートできます。
  • PostgreSQLプレイグラウンドはPGliteで本物のPostgreSQL 18を動かします。JSONB、全文検索、再帰CTE、EXPLAIN ANALYZEまで本物のPostgres構文そのままに動作し、IndexedDBにデータを保存することもできます。
  • DuckDBデータ分析プレイグラウンドはDuckDB-WasmでCSV、JSON、ParquetをSQLで分析します。SUMMARIZE、PIVOTのような分析特化の構文を使えます。
  • jqプレイグラウンドはJSONをjqフィルターでリアルタイムに加工します。

たとえばPostgresプレイグラウンドでは、次の再帰CTEが実際に実行されます。

WITH RECURSIVE counter(n) AS (
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM counter WHERE n < 5
)
SELECT n, n * n AS square FROM counter;

データがブラウザを離れないので、機密のCSVを貼り付けて分析しても安全です。これはオンラインSQLツールのほとんどが提供できない性質です。

ビルド・コンパイルツール — ツールチェーンがブラウザの中に

ビルドツールこそ、本来ネイティブ性能が切実に必要な領域ですが、WASMのおかげでこれらもブラウザに入ってきました。

  • SWCプレイグラウンドはRustで作られた超高速コンパイラSWCを実行し、TypeScript/JSXをトランスパイルしてASTまで表示します。
  • esbuildプレイグラウンドはesbuild-wasmでトランスフォームとバンドルを行います。
  • Sass/SCSSコンパイラはdart-sassでSCSSをCSSにコンパイルします。
  • GraphvizレンダラーはDOT言語をSVG図に描画します。
  • TypstプレイグラウンドはRustで書かれたTypst組版エンジンを実行し、LaTeX代替のドキュメントをPDFで出力します。
  • WebAssemblyスタジオはwabtでWAT（WebAssemblyテキスト）をバイナリにコンパイルし、ヘックスダンプと逆アセンブルを表示して、実際に実行までします。WASMでWASMを学ぶわけです。

これらの共通点は「インストール地獄」がないことです。node_modulesもローカルツールチェーンも要らず、リンクを開くだけでコンパイラが動きます。

メディアと画像 — ffmpegとImageMagickが丸ごと

メディア処理は伝統的に重いネイティブライブラリの領域でした。それらも今やブラウザで動きます。

  • 動画変換はffmpeg.wasmで動画をGIFにし、音声を抽出し、トリミング・リサイズ・倍速を処理します。ファイルのアップロードがありません。
  • 万能画像変換は本物のImageMagickエンジン（WASM）でiPhoneのHEIC、TIFF、PSDなど270余りのフォーマットを読み込み、JPG、PNG、WebP、AVIFへ変換します。
  • OCRテキスト抽出はTesseract WASMで画像内の日本語・英語・韓国語の文字を抽出します。
  • ASCIIアート変換は写真を文字絵に変えます。

動画変換はWASMの限界と強みを同時に示すよい例です。ネイティブのffmpegよりは遅いですが、短いクリップをGIFにする程度なら十分実用的で、何よりも動画ファイルがサーバーへアップロードされません。

その他のツール — AI、エミュレーター、シミュレーター

WASMの応用は言語とメディアを超えます。

  • ブラウザAIラボはTransformers.js（ONNXランタイム）で感情分析、埋め込み類似度、日↔英翻訳、ゼロショット分類、要約をサーバーなしで実行します。WebGPUがあればGPUアクセラレーションまで使います。入力テキストはどこにも送信されません。
  • ブラウザPCエミュレーターはv86で本物のx86 PCを起動します。FreeDOSをワンクリックで起動したり、自分の.img/.isoイメージを起動したりできます。
  • Git実習場とウェブターミナル、Linuxターミナルはコマンド実習環境をシミュレーションします。
  • eBPFプレイグラウンドはeBPF命令セットとカーネル検証器をシミュレーションします。（実際のカーネルフックではなく概念学習用です。）
  • 暗号 & ハッシュ実験室と暗号学スタディはArgon2、SHA/HMAC、AES-GCM、RSA/ECDSAと古典暗号・暗号解読をクライアントで実習します。

このリストには二つの筋が見えます。一つは本物のエンジン（AIモデル、x86 CPU、暗号ライブラリ）をWASMで持ち込んだもの、もう一つは概念を可視化するシミュレーター（gitグラフ、eBPF検証器）です。後者は実際のシステムを実行しませんが、原理を目で身につけるのに最適化されています。

現実的な限界 — WASMができないこと

WASMは強力ですが万能ではありません。ツールを使う前に知っておくべき限界があります。

  • 初回ロードのサイズ：PythonやPostgresのような大きなランタイムはダウンロードが数MBから数十MBです。キャッシュが助けますが、初回訪問は遅いです。
  • ネイティブより遅い：近ネイティブであってネイティブそのものではありません。重い動画エンコードや大容量データ処理はネイティブツールより遅いです。
  • 直接のシステムアクセス不可：サンドボックスなので、任意のファイルシステム、ネットワークソケット、GPUに自由にアクセスできません。ブラウザが許可したAPI（File System Access、WebGPUなど）だけを使います。だから本物のLinuxカーネルを起動するv86のようなツールも、実際にはエミュレートされたハードウェアの上で動きます。
  • メモリ上限：ベースラインのWASMは32ビットアドレス空間なのでメモリに上限があります（Memory64提案がこれを緩和中です）。超大容量のデータセットは負担になります。
  • マルチスレッドは条件付き：スレッドを使うには前述の隔離ヘッダが必要で、すべての環境で有効になるわけではありません。

まとめると、WASMは「そこそこ重い作業を、サーバーなしでプライバシーを守りながら」行うのに最適です。超大容量・超高性能の作業は、依然としてサーバーやネイティブのほうが優れています。

おわりに

WebAssemblyがもたらした変化の本質は「重いツールを、何のインストールもなく、何のデータ流出もなくブラウザで使う」ことです。本物のCPython、本物のPostgreSQL、本物のffmpegがあなたのタブの中で動き、その過程でコードもデータも外へ出ません。

限界は明白です。初回ロードは遅く、超高性能の作業には不向きです。しかし、学び、実験し、機密データを扱う日常的な作業のほとんどには十分です。上でリンクしたツールを一つずつ開いてみてください。サーバーなしでここまでできるという事実は、なかなか驚きのはずです。

参考資料

Discuss on Twitter • View on GitHub