ffmpeg.wasm はどのようにして動画変換をブラウザタブの中に閉じ込めるか
ffmpeg.wasm は C 言語で書かれた ffmpeg をブラウザで動く WebAssembly にコンパイルしたライブラリです。初回に約 30 MB をダウンロードする仕組みから、SharedArrayBuffer を使ったマルチスレッド実行、そして「メディアが一切デバイスの外に出ない」理由をサンドボックスの観点から解説します。
ダウンロードされる 30 MB の正体
ffmpeg.wasm を初めて使うツール (video-compress, video-cut, audio-convert など) を開くと、ブラウザは 30 MB 前後のファイル群を取得します。内訳は大きく 2 つです。ffmpeg.js は JavaScript 側の薄いラッパーで、Worker の起動・メッセージパッシング・バッファ管理を担います。もう一方の ffmpeg-core.wasm が本体で、コーデック処理 (H.264 / VP9 / AAC / MP3 など) を含む ffmpeg のバイナリをそのままコンパイルした WebAssembly モジュールです。
マルチスレッドが有効な場合は ffmpeg-core-mt.wasm (mt = multi-threaded) が使われます。このバリアントは SharedArrayBuffer を介して複数の Web Worker がメモリ空間を共有し、エンコードを並列化します。SharedArrayBuffer は Spectre 脆弱性への対応として一時廃止されましたが、Cross-Origin Opener Policy (COOP: same-origin) と Cross-Origin Embedder Policy (COEP: require-corp) の両ヘッダーを同時に返すページでのみ再有効化されました。nosend-tools.com はこの 2 ヘッダーを配信しており、対応ブラウザではマルチスレッド版が使われます。
WASM サンドボックスがメディアをデバイス内に閉じ込める仕組み
WebAssembly モジュールはブラウザの隔離されたメモリ領域で動作します。外部ネットワークへの直接アクセス手段を持たず、ファイルシステムも仮想的なもので実際の OS 上のパスとは対応しません。ffmpeg.wasm が扱うメディアデータはすべて、JavaScript 側から ArrayBuffer として WASM のリニアメモリに書き込まれ、処理後に ArrayBuffer として読み出される形を取ります。このデータを外部 URL へ fetch / XMLHttpRequest / WebSocket で送信するコードが存在しない限り、WASM の境界をデータが越えることはありません。
NoSend Tools の各ツールページでは、ffmpeg.wasm の処理が終わった後の Network タブが初回ロード以外のリクエストをほぼ記録しません。これは「送らないと約束している」のではなく「送る経路がコードに存在しない」ことを DevTools で目視確認できる状態です。asm.js フォールバックは現行バージョンでは提供されておらず、WASM 非対応ブラウザではツールが起動しません。CSP 側では wasm-unsafe-eval を明示的に許可する必要があり、これを入れ忘れると WASM モジュールの実行が CSP でブロックされます。
NoSend Tools の音声・動画ツール群との対応
video-compress (MP4 サイズ圧縮), video-cut (時間範囲カット), video-to-gif (GIF 変換), audio-convert (MP3 / WAV / OGG 変換), audio-noise (ノイズ除去), audio-cut (波形カット) などは、すべて ffmpeg.wasm の同一のコアバイナリを共有します。ツールごとに ffmpeg の CLI 引数に相当するコマンド列を組み立て、ffmpeg.exec() を呼び出すだけです。たとえば MP4 圧縮なら ffmpeg.exec(["-i", "input.mp4", "-crf", "28", "output.mp4"]) のようなかたちになります。
初回ロードが重い (10〜20 秒) のはコアバイナリが 30 MB あるためですが、ブラウザのキャッシュに載れば 2 回目以降は即起動します。同一セッション内で複数の音声・動画ツールを使う場合、ffmpeg-core.wasm は再ダウンロードされません。各ツールページの e2e テストがタイムアウトを 180 秒に設定しているのも、初回 Worker 起動を待つためです。
「送信しない」はサンドボックス設計に由来する
アップロード型の変換サービスは、処理のためにファイルをサーバーへ送ることが設計の前提です。利用規約に「処理後に削除」と書かれていても、送信した瞬間からデータは CDN キャッシュ・WAF ログ・リバースプロキシのバッファを通過し、ユーザーは検証手段を失います。ffmpeg.wasm を使うブラウザ内処理は、「送る手段を持たない」という点でこれと根本的に異なります。
SharedArrayBuffer / COOP / COEP などの仕組みはもともとセキュリティ強化のために導入されたもので、ffmpeg.wasm はその副産物として高速なマルチスレッド実行を得ています。nosend-tools.com の音声・動画ツールがプライバシー保護を「機能として提供している」のではなく、WebAssembly のサンドボックスモデルがその性質を構造として持っているという見方が、より正確です。