ブラウザだけで画像・動画・データベースまで処理できるのはなぜ？

1. 読む — 選んだファイルを「送らずに読む」

最初の土台になるのが、ブラウザからローカルファイルを扱う仕組みです。ユーザーがファイル選択画面やドラッグ＆ドロップで選んだファイルは、Webアプリから「ファイルのデータ」として読めます。画像なら画像データ、動画なら動画ファイルのバイト列、データベースならDBファイルそのものをブラウザ内のプログラムへ渡せます。

ここで重要なのは、ファイルを選ぶこととサーバーへ送ることは別だという点です。Webアプリ側がネットワーク送信の処理を行わなければ、そのファイルを端末内で読んで処理するだけの構成にできます。一方で、ブラウザはPC内の好きなファイルを勝手に読めるわけではなく、基本的にはユーザーが明示的に選んだものを扱います。

2. 処理する — 画像はCanvasで画素まで触れる

画像は、ブラウザが比較的得意としてきた分野です。Canvasという仕組みを使うと、画像を描画するだけでなく、画素データを読み出して書き換えることもできます。明るさを変える、縮小する、一部をぼかす、複数画像を合成するといった処理は、ブラウザ内だけでも実現できます。

さらに、ブラウザが標準では扱いにくい形式や高度な画像処理では、画像処理ライブラリをWebAssembly向けにビルドして組み込む方法もあります。Webツールから見ると「画像を選ぶ → 端末内で処理する → 新しい画像を保存する」という流れになります。

2. 処理する — 動画・音声はコーデック機能とWebAssemblyを使える

動画は画像より処理が重く、圧縮形式も多いため少し複雑です。それでも現在のブラウザには、映像や音声をエンコード・デコードするためのWebCodecsのような仕組みがあります。対応しているコーデックなら、映像や音声のエンコード・デコードをブラウザの機能から利用できます。WebCodecsは映像フレームやエンコード済みのデータを細かな単位で扱うAPIで、MP4などの動画ファイル全体の読み書きまでを一つで担うものではありません。必要に応じて、動画コンテナを読み書きする別の仕組みと組み合わせます。

別の方法として、FFmpegのような既存のメディア処理ソフトウェアをWebAssembly向けにビルドし、ブラウザ内で動かす構成もあります。この場合も計算は利用者の端末で行われます。ただし、使えるコーデック、処理速度、メモリ使用量はブラウザや端末によって差が出ます。

2. 処理する — WebAssemblyが処理の幅を広げる

WebAssembly（Wasm）は、C/C++などで作られてきた既存の処理エンジンを、ブラウザでも効率よく動かしやすくする仕組みです。実際には、そうしたプログラムをブラウザが実行できるバイナリ形式へコンパイルして使います。JavaScriptだけで一から書き直さなくても、既存のライブラリや処理エンジンをWebアプリへ持ち込みやすくなり、画像処理、動画変換、PDF処理、AI推論、圧縮・展開など、以前ならデスクトップアプリ側で行っていた処理をブラウザへ移しやすくなりました。

ただしWasmは、PC全体へ自由にアクセスできる仕組みではありません。ブラウザの権限やサンドボックスの中で動きます。ファイルへのアクセス、カメラ、マイク、ネットワークなどは引き続きブラウザ側のルールに従います。

2. 処理する — データベースエンジンもブラウザ内で動かせる

データベースについては、単にファイルの中身をJavaScriptで読み取るだけでなく、データベースエンジンそのものをWebAssemblyとして動かす方法があります。たとえばDuckDB-Wasmは、DuckDBエンジンをWebAssemblyへコンパイルしたもので、完全なDuckDBエンジンをブラウザ内で動かしてSQLを実行できます。

そのため、ローカルのDuckDBファイルやParquetなどをブラウザへ渡し、テーブル一覧を確認したり、SELECT文を実行したり、集計結果を表示したりできます。サーバー上のDBへ問い合わせているように見えても、実際にはタブの中でDBエンジンが動いている構成を作れます。もちろん、Webアプリ側が外部データ取得やクラウドDB接続を実装すれば通信は発生するため、「ブラウザで動くDB」と「必ず完全ローカル」は同じ意味ではありません。

3. 返す — 結果を画面に表示し、ファイルとして保存できる

処理した結果は、ブラウザ内に留めたまま画面へ表示できます。画像ならCanvasへ描画し、SQLの結果なら表として表示し、音声や動画ならプレビュー用のデータとして再生できます。

保存したい場合は、処理結果をBlobなどのブラウザが扱えるデータにまとめ、ダウンロードできるファイルとして利用者へ返せます。つまり、ローカルファイルを入口で受け取り、中間で端末のCPU・メモリを使って計算し、出口で新しいファイルを返す、という一本の流れをサーバーなしで作れます。

便利になった代わりに、端末性能とブラウザの制限をそのまま受ける

サーバーへ処理を任せない場合、計算に使うCPUやメモリは利用者の端末のものです。数MBの画像なら軽くても、数GBの動画や巨大なデータベースではメモリ不足になったり、処理に長い時間がかかったりします。スマートフォンと高性能PCで同じ速度になるわけでもありません。

また、ブラウザごとに対応するコーデックやWeb API、WebAssembly機能に差があります。マルチスレッド処理など追加条件が必要な機能もあります。そのためブラウザ内処理は「サーバー処理の完全な上位互換」ではなく、ファイルを外へ出さずに済むこと、インストール不要で使えることと引き換えに、利用者の端末性能とブラウザ制約を受ける方式だと考えるのが現実的です。

注意点

• 「ブラウザで処理」と「オフラインで動く」は同じではありません。処理はローカルでも、初回表示時にライブラリやモデルを取得するWebアプリはあります。
• WebAssemblyを使っていても、ブラウザのサンドボックスや権限制御を飛び越えてPC全体へ自由にアクセスできるわけではありません。
• 動画の対応コーデックやハードウェア支援はブラウザ・OS・端末によって異なります。同じHTMLでも使える出力形式や速度が変わることがあります。
• 非常に大きなファイルを扱う場合、アップロード時間が不要になる一方で、端末のメモリ不足や発熱、バッテリー消費が問題になることがあります。
• ローカル処理はファイル送信を減らせる設計ですが、利用するWebツール自体が信頼できるか、説明と実装が一致しているかという確認は別に必要です。