Picovert

オンライン画像変換ツールは安全か? アップロード後に写真に何が起きているか

Picovert チーム著2026-04-247分で読了

「convert PNG to JPG」と検索すれば、無料の変換ツールが画面いっぱいに並びます — 多くは広告 収益型で、ビジネスモデルもほぼ同じです: ファイルをアップロード、サーバー側で変換実行、結果を 返す。流れがあまりに滑らかなので、アップロードとダウンロードの間に何が起きているかを大半の 人は意識しません。本記事ではそこで実際に何が起きているか、プライバシーポリシーが何を言って いて何を言っていないか、そして変換ツールがあなたのファイルを一切見ない場合を見分ける方法を 解説します。

「サーバーへアップロード」の実際の意味

一般的な変換ツールでアップロードを押すと、ブラウザは事業者のサーバーへファイルをPOSTします。 ファイルは一時ディレクトリに置かれ、変換が走り、結果のリンクが返されます。UIには見えませんが、 この流れの中で次の3つが起きます:

  1. ファイルは少なくとも変換期間中は残ります。 リトライやダウンロードのため にもっと長く残ることが多いです。
  2. ログに残り得ます。 サーバーアクセスログ、エラーログ、CDNログ、解析ログ のいずれもファイル名、IP、メタデータを日常的に記録します。
  3. 司法管轄をまたぎます。 事業者があなたと異なるデータ保護規制の国で運用 している可能性があります。EUのユーザーがUSサーバーに上げると、毎回その境界を越えます。

プライバシーポリシーの典型表現

たくさん読むとパターンが見えてきます:

  • 「ファイルは24時間後に削除されます」 — よく見るが検証手段がなく、24時間 はバックアップスナップショットが取り込むのに十分な時間です。
  • 「ファイルを第三者と共有しません」 — 通常は「当社のサービスプロバイダを 除き」で限定されており、これはほとんど誰でも該当し得ます。
  • 「本サービスを利用することで、コンテンツ処理に関するライセンスを付与します」 — 解釈によってはモデル学習まで包含するほど広い。
  • ログと解析については沈黙 — どのログが何を集めるかをポリシーが列挙する ことはまれです。

これらが必ずしも悪用というわけではありません。ユーザーアップロードを扱うサーバーの正常な 運用現実を反映しています。同時に、最もプライバシーを尊重する答えが「ファイルを送らない」 ことになる理由でもあります。

2026年の代替: ブラウザ完結型変換

モダンブラウザはffmpeg、libwebp、libheifに同梱される画像・動画コーデックを、WebAssemblyで ネイティブに実行できます。変換はタブ内で完結し、ファイルは端末から出ません。

これは限られた部分集合ではありません。当サイトが扱うすべての変換 — PNG、JPG、WebP、AVIF、 HEIC、GIF、MP4、WebM — がブラウザ内で動きます。パイプラインはこう:

  1. ドロップゾーンにファイルを落とす。ファイルはページのメモリにFileオブジェクト として入ります。
  2. WebAssemblyモジュール — 通常はlibwebp、libheif、ffmpeg.wasm — がソースフォーマットを デコード。
  3. デコードされた画素データを、再びタブ内でターゲットフォーマットへエンコード。
  4. 結果はBlobに包んでダウンロードとして提供されます。

ブラウザのネットワークパネルは変換中にゼロ件の送信POSTを示します。ネット ワーク活動はページの初回読み込みと、サイトが出荷した解析や広告スクリプトのみ。(Picovertは 解析を出荷していますが、ファイル内容は対象外です — そもそも当社サーバーに到達しないので 読みたくても読めません。)

ブラウザ完結型かどうかを見分ける

実践的な5つのチェック、徐々に厳格になります:

  1. 主張そのものを探す。 ブラウザ完結型は意味のある差別化なので前面に出します。 ホームに変換場所の記載が無いならサーバー側と仮定。
  2. DevToolsを開いて変換してみる。 Networkタブを観察。変換中にPOST/PUTが 飛ばないなら未アップロード。最も信頼性の高い単独チェックです。
  3. 変換途中でネットを切る。 それでも変換が完了するならローカル実行です。
  4. Service WorkerやWASMの利用を確認。 ソースを見て.wasmを 検索。ブラウザ側変換はほぼ必ずWASMモジュールを読み込みます。
  5. ソースコードを探す。 オープンソースの変換ツールは何をしているかを公開して います。Picovertのリポジトリは公開されています。

サーバー側が妥当なケース

サーバー側変換が本質的に悪いわけではありません。それが正しいアーキテクチャである実例も あります:

  • ブラウザのメモリに収まらないファイル — 10GBの素材動画をffmpeg.wasmで 回すのは現実的ではありません。
  • 集中GPUリソースが必要な変換 — AIアップスケール、超解像、複雑な動画 トランスコードパイプライン。
  • 出力を共有場所に保存するワークフロー — チーム共有の素材、コンテンツ パイプライン。

個人写真の単発変換にはどれも当てはまりません。サーバー側はWebAssemblyが実用化される前から の慣性的なエンジニアリングにすぎません。

Picovertの選択

我々は早い段階で意図的な選択をしました: すべてのツールはブラウザで動く。変換サーバーを 運用していません。あなたの写真を保管するS3バケットもありません。「ユーザーアップロード」 テーブルを持つデータベースもありません。マーケコピーではありません — 我々が出荷する唯一 のアーキテクチャで、上記DevToolsチェックで検証可能です。

トレードオフは、ブラウザのタブが扱える容量(多くのマシンで約2GB)を超えるファイルは扱えず、 マルチGPUサーバークラスタを要求する変換はできない、という点です。99%のケース — スマホ写真 の変換、サイト用素材の最適化、GIFをMP4へ — ではブラウザで十分です。

結論

「オンライン変換ツール」が自動的に「ファイルをアップロードする」を意味してはいけません。 2026年、ブラウザベースの変換は成熟し、速く、無料です。変換ツールがあなたのファイルがどこへ 行くかを語らないなら、答えは「あなたが管理しないサーバーへ行く」と仮定してください。上記の DevToolsテストは30秒で真実を教えてくれます。