【ITニュース解説】No Uploads, No Servers: What I Learned Building Image Tools That Run 100% in Your Browser

多くのオンライン画像処理ツールは、ユーザーがファイルを選んでサーバーにアップロードし、サーバーで処理された結果をダウンロードするという流れで動作する。この過程で、個人の写真や機密文書が他者のサーバーに一時的に保存されることになり、プライバシーやセキュリティのリスクが生じる可能性がある。開発者はこの状況に疑問を抱き、「なぜ画像処理にサーバーが必要なのか？」と考えた。現代のウェブブラウザは「Canvas API」「WebAssembly (WASM)」「Web Workers」といった強力な機能を持ち、画像処理の大部分をユーザーのブラウザ内で完結させることが可能になっている。

この考えに基づいて開発されたのが「SnappyKit」という画像処理ツール群だ。SnappyKitでは、圧縮、変換、トリミング、サイズ変更、透かし追加、HEIC変換といった処理が提供されるが、その処理中に画像のデータがユーザーのデバイスから外部のサーバーへ送信されることは一切ない。実際に開発者ツールでネットワーク通信を監視しても、画像データに関するアップロードリクエストは確認できない。

SnappyKitの核となるアーキテクチャは、「画像処理コードはすべてブラウザ内で動作する」という厳格なルールに基づいている。ウェブサイト自体はNext.js、React、TypeScriptといった技術で構築されているが、これらは主にページの表示やレイアウト、検索エンジン最適化に利用される。実際の画像処理ロジックは、ブラウザが持つAPIのみにアクセスする独立したプログラムとして実装されている。

具体的には、サイズ変更、形式変換、圧縮、トリミングといった基本的な操作は、ブラウザの描画機能である「Canvas API」が担当する。一方、Canvas APIだけでは対応できない特殊な処理、例えばHEIC形式のデコード（読み込み）などには、「WebAssembly (WASM)」が活用される。これにより、画像ファイルがネットワーク経由で外部に送信される経路は完全に排除される。このような「クライアントサイド（ブラウザ内）での処理完結」という制約が、開発における最も有効な設計判断であった。この方針により、「この機能はブラウザ内で実行できるか？」という問いに答えられないものは実装しない、という厳格な基準が徹底された。

しかし、この新しいアプローチにはいくつかの課題も存在した。

一つ目の課題は、「Canvas API」にも限界があることだ。ブラウザのCanvasには、縦横のピクセル数や総ピクセル数（メガピクセル）に上限が設定されている。例えば、一辺が約16,000ピクセル、総面積が約2億6800万ピクセルといった制限が一般的だ。これを超える超高解像度画像をCanvasで処理しようとすると、静かに失敗したり、何も表示されなかったりする可能性がある。このためSnappyKitでは、処理を開始する前に画像の最大ファイルサイズを20メガバイト、最大総ピクセル数を1億ピクセル、一辺の最大ピクセル数を16,000ピクセルと制限し、これを超えるファイルに対しては事前にユーザーにわかりやすいエラーメッセージを表示する。これにより、ユーザーが予期せぬ失敗に直面するのを防ぎ、ピクセル操作の前に必ず入力値を検証することの重要性が示された。

二つ目の課題は、「HEIC形式のデコード」だった。iPhoneで標準のHEIC形式は、多くの環境で読み込めない上に、どのブラウザもこれをネイティブにデコードする機能を持たない。この解決策として、HEIC処理ライブラリを「WebAssembly (WASM)」にコンパイルし、必要な時だけブラウザに読み込ませる方法が取られた。WASMバンドルはそれなりのサイズがあるため、HEIC変換ページが開かれたときに初めて読み込むことで、他のツールを使うユーザーが無駄なデータをダウンロードしないよう工夫されている。この実装には、セキュリティ設定やビルド設定など、いくつかの技術的な調整が必要だったものの、結果としてHEICファイルがユーザーのブラウザ内でデコードされ、JPGファイルとして出力されるまでの一連の処理が、サーバーへのアップロードなしで高速に実行できるようになった。

三つ目の課題は、「AVIF形式」のブラウザ間互換性だった。次世代の画像圧縮形式であるAVIFはブラウザのサポートが進んでいるが、その実装はブラウザによって完全に同一ではない。特にAVIFファイルのエンコード（書き出し）においては、ブラウザ間でサポートレベルに差が見られた。そのため、SnappyKitでは「このブラウザはこの操作でAVIFをサポートしているか？」と、操作ごとに細かく機能検出を行う必要があった。実用的な解決策として、特定の操作でAVIFエンコードが利用できない場合は、すぐにユーザーにその旨を伝え、代わりにWebPなどの代替形式を提案する「優雅な劣化」の仕組みが導入された。これにより、ユーザーが設定を選んだ後に処理が失敗するのを防いでいる。

四つ目の課題は、「ブラウザ内での処理にも安全対策が必要」という点だった。データがデバイスから外部に出ないからといって、リソースの制限が不要になるわけではない。巨大な画像をブラウザのメインスレッドで処理しようとすると、ユーザーインターフェースがフリーズし、製品の不具合と認識されてしまう。サーバーのように処理のタイムアウトで強制終了されることもないため、画像サイズの上限設定や、長時間かかる処理では進捗状況をユーザーにフィードバックする仕組みが不可欠となる。ブラウザは「監視者のいない敵対的な実行環境」であり、防御的な制限は必須の要素なのだ。

SnappyKitの開発から得られたこれらの知見は、ブラウザだけで完結する画像処理ツールの可能性と、その実現における具体的な課題を明確にした。今後も、この基盤の上でさらに多くの機能が追加されていく予定だが、すべては引き続き100%クライアントサイドでの処理にこだわり続ける。プライバシー保護こそがSnappyKitの核となる価値であり、これを損なうような妥協は決して行われないだろう。