ブラウザ内でファイル処理は「どこまで」できるか — 2026 年の現在地

「ファイルをサーバーに送らずに処理する」は、2026 年のブラウザでかなりの範囲が実現可能です。ただし万能ではありません。Zerosend が採用している技術と、その限界を正直に整理します。

なぜ「ブラウザだけで処理する」選択を採るのか

送らないので漏れない、という直球の設計

サーバー送信を伴わない構造そのものが、個人情報漏洩・誤操作・第三者共有 のリスクを原理的にゼロにします。「漏れない仕組み」を語るより、漏れる場所をなくすほうが検証しやすい設計です。

設定や権限に依存しない単純さ

サーバー側で暗号化キーを守る / ログを消す / バックアップから除外する、という細かい運用は継続的な手間がかかります。ブラウザ内で完結するなら、そもそもその運用自体が発生しません。

使っている技術スタック

Canvas API — 画像の基礎処理

2D 描画と画像ピクセル操作の標準 API。Zerosend の画像圧縮・リサイズ・形式変換はすべて Canvas 経由です。drawImage() で任意の描画、toBlob() で指定フォーマットに書き出せます。

Web Worker — メインスレッドを止めない

重い処理をメインスレッドで回すと UI がフリーズします。Web Worker で別スレッドに逃がすことでスムーズな UX を維持します。browser-image-compression のように Worker を内包しているライブラリは、そのまま使うだけでメインスレッドを解放してくれます。

WebAssembly — ffmpeg / pdf 系ライブラリの移植

C / C++ で書かれたネイティブライブラリを WASM 化することで、ブラウザで直接実行できます。Zerosend では ffmpeg.wasm (動画・音声) と pdfjs-dist (PDF レンダリング) が WASM ベースです。

File System Access API / Blob — 入出力

モダンブラウザは showOpenFilePicker() / showSaveFilePicker() で OS のファイル選択ダイアログを呼べます。非対応の環境でも <input type="file"> + Blob + URL.createObjectURL でダウンロードできるため、互換性の最低ラインは広いです。

できること

数 MB 〜数十 MB のファイル処理

現代のブラウザは 100MB 級のファイルでも (メモリ次第で) 安定して扱えます。JPG/PNG 画像の圧縮・リサイズ・一括 ZIP 生成は問題なく動作します。

バッチ処理 (ZIP 生成を含む)

jszip を使えば複数ファイルの圧縮まとめもブラウザ内で完結します。100 ファイル程度の一括処理は実用範囲です。

逆圧縮・形式変換

JPG → WebP、HEIC → JPG、PDF → PNG、MP4 → GIF などの変換は、すべてブラウザ内で実行できます。

苦手なこと・できないこと

数 GB 級の動画処理はメモリが持たない

ブラウザのプロセスメモリ上限はだいたい 2〜4 GB 程度。それ以上の動画をまるごと処理するのは困難です。1 GB を超える動画はデスクトップツール (ffmpeg CLI 等) のほうが安定します。

機械学習推論は遅い (ONNX Runtime Web は軽量モデル限定)

ONNX Runtime Web や TensorFlow.js で推論は可能ですが、数 GB 級のモデルはブラウザで回すとかなり遅く、UX が実用的ではありません。軽量モデル (数百 MB) に限定するか、サーバー推論と割り切るのが現実的です。

OS ネイティブ機能への直接アクセス

ブラウザはサンドボックス内で動くので、OS のファイルシステム全体を書き換えるような処理・プロセス起動はできません。セキュリティの観点からも妥当な制約です。

Zerosend での実装のコツ (開発者向け)

ドメイン層を UI から分離する

domain/processors/ 配下に純粋関数を置き、Vue / DOM API に依存させない設計にしています。テストが書きやすく、将来的に CLI 化・API 化もしやすくなります。

Web Worker に重い処理を分離する判断基準

目安は 100 ms を超える処理はすべて Worker。メインスレッドがそれ以上ブロックすると、ユーザー操作への応答 (クリック・スクロール) が目に見えて遅延します。

CSP を破らずに WASM を読み込む

CSP (Content Security Policy) に wasm-unsafe-eval を追加する必要があります。Zerosend では meta と _headers の両方に設定し、本番でも正しく動作することを確認しています。

Content-Security-Policy: script-src 'self' 'wasm-unsafe-eval'

今後の展望

WebGPU / OPFS の成熟

• WebGPU: GPU を直接使える API。機械学習推論や 3D レンダリングで大きく速度改善が見込まれます
• OPFS (Origin Private File System): Origin ごとにブラウザが管理する高速ファイル領域。大容量ファイル処理時の中間ストレージに使えます

これらが広く使える前提になれば、現状「苦手」としている領域の多くがブラウザだけで片付くようになります。

まとめ

ブラウザ内ファイル処理は Canvas / Web Worker / WebAssembly / File System Access API の組み合わせで、日常的な軽作業のほぼ全域をカバーできます。GB 級や重い ML 推論は依然として苦手ですが、Zerosend が対象とする画像・PDF・音声・短い動画の範囲では実用レベルです。

この設計の結果、Zerosend のツール群 はサーバーに何も送らずに動作し、DevTools で自ら検証できる透明性を持っています。

関連: なぜ Zerosend はブラウザ内処理にこだわるのか / ピラー記事