JPEG写真のEXIFデータを削除
01 なぜほとんどの「EXIF削除」ツールがJPEGを中心に作られているのか
JPEGは古く（1992年誕生）、今なお多くの旧型カメラやスマートフォンの標準出力形式です。そのメタデータは、フ ァイル内部の番号付き「APP」マーカーセグメントに格納されています——APP1には通常EXIF（カメラ機種、GPS、タ イムスタンプ）が、時にはXMPも含まれ、APP2には多くの場合埋め込みICCカラープロファイルが含まれ、単純なCOM セグメントには任意の自由記述コメントが含まれることがあります。これらすべては実際の画像データより前に位 置し、適切なツールがあれば簡単に読み取れます——だからこそ、JPEGのメタデータ削除は、この分野全体の中でも っとも成熟し、もっとも競争の激しい領域なのです。
詳しく見る：量子化テーブル、サムネイル、そして「画質」が実際に変えるもの
JPEGのDQT（量子化テーブル）マーカーは、画像の各8x8ピクセルブロックがどれだけ強く圧縮されるかを制御し ています——本ツールはこれを推測ではなく直接読み取り、一部のフォレンジックツールのように「画質スコア」 を当てずっぽうで示すのではなく、実際のテーブル値を表示します。EXIFにはしばしば、より小さな第二のサム ネイルも埋め込まれており、これは一度だけ生成され、後の編集で更新されないまま残っていることがよくあり ます——このサムネイルがメイン画像には写っていない何かを示している場合、それは後から編集が行われたこ とを示す、実際に確認できる根拠であり、メタデータのページでさら に詳しく解説しています。
知っておくべき、もう一つ現実的で独立したリスクがあります。JPEGの画像終端マーカー（0xFFD9）は明確に定 義されていますが、多くの破損した、あるいは意図的に細工されたファイルは、その後に追加データを付加しま す——これは古典的な「複数形式混合」の手口で、第二のファイル（スクリプトやアーカイブ）が、一見普通の 写真に見えるものの中に隠れて一緒に運ばれます。どのプリセットを選んでいても、ここで実際に行われる完全 なピクセル再構築は、このマーカー以降のすべてを、特別なチェック項目としてではなく、構造的な保証として 拒否します。
知っておく価値のある現実の歴史
画像処理ソフトウェアには、深刻なセキュリティ上の欠陥の実例があり、それは文書として記録されています——こ れは仮定の話ではありません。2016年、広く使われていた画像ライブラリの脆弱性「ImageTragick」（CVE-2016-3714） は、特別に細工された画像ファイルによって、それを処理したサーバー上でコマンドを実行できてしまうというもの で、実際に悪用されているのが発見されました。完全なピクセル再構築は、まさにこの種の攻撃を防ぐために設計さ れています。どのプリセットを選んでいても、他の場所にあるデコーダーのバグが本来見逃してしまうかもしれない 何かがあっても、元のファイルのどのバイトも、それを実行できるものに到達することは決してありません。
JPEG専用に圧縮プリセットを選ぶ
PNGやGIFとは異なり、JPEGの画質は本当に意味のあるトレードオフです——ここでの「無損失」モードは非常に高い 画質を目指しており（サイズよりも忠実度を優先するため、圧縮率の高い元ファイルより大きくなること もあります）、「バランス」は妥当な折衷点を、「超圧縮」はファイルサイズが完璧なピクセル品質より重要な場合 に実際に容量を削減します。3つとも、メタデータはバイト単位で等しく削除されます——プリセットが変えるのはピ クセルの圧縮方法だけで、削除される内容が変わることは決してありません。