ブラウザ内だけの画像アニメーションは、なぜ安全なのか

オンライン画像ツールの多くは、最初にファイルをサーバーへアップロードします。大規模な 処理には便利ですが、サービス側が画像を受け取り、少なくとも処理中は保存し、安全に管理する 必要があります。Purupuru Makerは別の方式を採用し、編集と書き出しをブラウザ内で行います。

ここでは「ブラウザ内処理」が実際に何を意味するのか、運営者にはどの情報が届くのか、 ほかの画像ツールでもローカル処理を確認する方法を説明します。

ファイルを開くことと、アップロードは別の操作

画像を選ぶと、ブラウザはそのファイルだけをページへ一時的に読み取らせます。JavaScriptは 画像をピクセルへ変換できますが、そのデータが自動的にインターネットへ送信されることは ありません。

Purupuru Makerでは、画像を端末内で読み込み、必要な場合だけ縮小し、WebGLのテクスチャへ 配置します。塗ったマスクも別のローカルテクスチャです。アニメーション用のシェーダーが 元画像、マスク、時間、揺れ設定を組み合わせて各フレームを描きます。

この処理に画像アップロードのリクエストはありません。サーバーはアプリのコードを配信しますが、 写真そのものを処理するのは利用者の端末です。

WebGLがプレビューを描く

WebGLは、制限されたブラウザAPIを通して端末のグラフィックス機能を利用します。同じ小さな 変形を毎フレーム大量のピクセルへ適用するぷるぷる効果に向いています。

マスクは各ピクセルの動く強さを決めます。プリセットは時間による変位の変化を決め、 向きと速さが動きを調整します。ブラウザがキャンバスを連続して描き直すため、 サーバーのレンダー待ちをせずにリアルタイムで確認できます。

端末によって速度が違うのも、このローカル設計によるものです。新しいデスクトップGPUは 大きな画像を快適に扱えますが、古いスマートフォンでは小さな元画像のほうが滑らかです。 これはサーバー混雑ではなく、端末側の処理能力の差です。

書き出しも端末内で完了する

GIFでは、ブラウザが決められた枚数のフレームを描き、ピクセルデータをブラウザ内の エンコーダーへ渡します。動画では、対応ブラウザのメディア機能を使ってキャンバスの動きを エンコードします。完成したBlobはブラウザのダウンロード機能へ渡されます。

Blob URLは一時的なWebアドレスのように見えますが、現在のブラウザプロセス内にあるデータを 参照しています。公開インターネットのURLではなく、ページを閉じるか参照を破棄すると消えます。

運営者へ届く可能性がある情報

画像処理がローカルでも、サイト全体の通信がゼロになるわけではありません。HTML、 JavaScript、フォント、サンプル画像を配信するため、ホスティング事業者は通常の技術的な リクエストを受け取ります。アカウント作成、購入、サポートへの連絡を行えば、その機能の ために入力した情報は関連するサーバーや事業者へ送られます。

任意のアクセス解析やサポートチャットは画像処理とは別です。Purupuru Makerでは、 プライバシー設定で選択されるまで読み込まれません。選んだ画像自体がアクセス解析イベントへ 追加されることもありません。

「画像はローカル処理」と「どのデータも一切収集しない」は同じ意味ではありません。 正確なプライバシー説明では、画像、アカウント、配信ログ、任意解析を分けて説明する必要があります。

本当にアップロードされないか確認する方法

技術に詳しい利用者は、説明文だけに頼らず次の手順で確認できます。

1. ブラウザの開発者ツールでNetworkパネルを開く
2. リクエスト一覧を消去する
3. 機密情報を含まないテスト画像を選ぶ
4. 塗る、再生する、書き出す操作を行う
5. 大きなリクエスト本文や画像MIMEタイプを持つアップロード通信がないか確認する

スクリプト、フォント、同意後の解析、サンプル画像の通常リクエストには、選択したローカル ファイルは含まれません。ファイル本体を受け取るアップロードAPIがあれば、それは別の構成です。

最初のページ読み込み後に一時的にオフラインへ切り替える方法もあります。必要なアプリコードが すでに読み込まれていれば、ローカルのプレビューと書き出しはそのまま動作します。

ブラウザ内処理は、個人写真、未公開イラスト、クライアント向け下書き、短い実験に特に向いています。 ぷるぷる効果には画像をサーバーへ送る必然性がありません。ローカルに保つことで、 待ち時間を減らし、構成を単純にし、プライバシーも守りやすくなります。