メタデータの安全な削除と保持設計 2025 — プライバシー/コンプラ対応

画像メタデータはワークフローの可視化・検索最適化・権利表示に有用である一方、**個人情報（PII）や撮影位置情報（GPS）**の漏えいリスクを伴います。本稿は「何を削除し、何を残すか」を実務ベースで設計し、運用・監査までを含めて安全に回し続けるためのガイドです。以下を目標にします。

• プライバシー保護（不要な個人/位置情報の徹底除去）
• コンプライアンス（GDPR/CCPA/個人情報保護法 等への整合）
• 運用性（自動化・監査可能性・チーム内標準化）

関連: EXIFとプライバシー情報の安全な除去フロー 2025 ／ 安全なメタデータ方針 2025 — EXIF 削除・自動回転・プライバシー保護の実務

背景と範囲

扱う主なメタデータ体系は以下です。

• EXIF（カメラ由来。撮影日時/露出/GPS 等）
• IPTC（報道・出版向け。クレジット/タイトル/説明/キーワード 等）
• XMP（拡張可能なRDFベース。著作権/ライセンス/記述/アクセシビリティ情報 等）

また、RAW/HEIC/WebP/AVIF などコンテナごとの保持挙動にも差異があります。派生生成（サムネイル/OGP/Web用書き出し）時に「元の危険なメタデータが混入しない」設計が重要です。

基本ポリシー

• 安全側に倒す: デフォルトは「削除」し、業務要件で必要なキーのみホワイトリスト保持
• 監査可能性の確保: 原本はセキュア保管、処理ログは改ざん困難に
• 自動回転: Orientation タグに依存せずピクセルを正規化
• データ最小化: 目的達成に不要なら保持しない（GDPRの基本原則）
• 公開前チェック: ランダムサンプリング＋自動スキャンで「GPSや端末固有IDが残っていない」ことを確認

推奨ホワイトリスト（例）

• 著作権/クレジット: XMP-dc:creator, IPTC:Credit
• ライセンスURL: XMP-cc:license
• 代替テキスト生成に資する説明文: XMP-dc:description
• アクセシビリティ目的の代替説明（公開前に二次確認）

保持しない（削除推奨）例:

• 位置情報: GPS*
• 端末固有ID/シリアルに準じるもの
• 撮影経路や下書き状態の編集履歴（内部ノート類）

リスクと代表シナリオ

• SNS/ブログ公開時にGPS座標が残存 → 自宅/学校/勤務先の特定
• デバイス固有IDや署名情報の残存 → なりすまし・機材特定・ストーカー被害
• 顔写真や車両/書類の写り込み → 画像本体のマスキングやトリミングも必要

これらはメタデータだけでなく画素内容のマスキング（レダクション）も視野に入れた二段構えが有効です。

法令/規格への整合（要点）

• GDPR: データ最小化/目的限定/透明性/削除権（再処理能力）
• CCPA/CPRA: 公開情報の扱い、削除/オプトアウト対応
• 日本 個人情報保護法: 目的外利用の抑止、適正な取得・管理
• ISO/IEC 27001/27701: プロセス標準化と監査証跡の維持

運用上は「保持する理由を文書化」し、変更時は DPIA 相当の簡易影響評価を残します。

自動化パイプライン例

# exiftool による削除/保持
exiftool -all= -TagsFromFile @ \
  -XMP-dc:creator -IPTC:Credit -XMP-cc:license -XMP-dc:description \
  -overwrite_original in/*.jpg

# 自動回転（ピクセル正規化）
magick in.jpg -auto-orient out.jpg

Node.js（sharp）を併用してICCプロファイルや再圧縮を管理する例:

import sharp from 'sharp'

export async function publishJpeg(input, output) {
  const s = sharp(input)
  const meta = await s.metadata()
  // 画素正規化 + sRGB埋め込み + EXIFは原則ストリップ
  await s
    .rotate()
    .withMetadata({ icc: 'sRGB' })
    .jpeg({ quality: 86, chromaSubsampling: '4:2:0' })
    .toFile(output)
}

CDN/ストレージ（S3等）では、アップロード時に Lambda@Edge / CloudFront Functions / S3 Object Lambda を使い、公開導線で必ずストリップ済み派生が返るようにします。

検証と監査

• ランダムサンプリングで差分比較 (exiftool -json)
• CI でのスキャナ（意図しない位置情報の検知）
• ログ署名（HMAC）で改ざん検出

監査ログ設計（例）:

async function logMetadataOperation(entry) {
  // 例: 署名付きでAppend-onlyなストレージへ
  const payload = JSON.stringify(entry)
  const signature = hmac(payload, process.env.LOG_SECRET)
  await appendAuditLog({ payload, signature })
}

再処理（削除権）要求に備え、原本の所在・処理ポリシー・派生の生成規則をトレースできるよう ID で結びます。

Web 配信での注意

• ファビコン/マニフェスト等は robots.txt でブロックしない
• OGP 画像には作者/ライセンスの最小限情報のみ（パブリック公開を前提）
• サムネイル/レスポンシブ画像も同一ポリシーで再生成し、元画像の危険なメタデータが伝播しないようにする
• sRGB固定・ICC明示でレンダリング差異を抑制（色管理とプライバシーは併存可能）

よくある落とし穴

• EXIF のみ削除し、XMP に GPS が残存
• CMS のサムネイル生成が元のEXIFをコピー
• RAW→JPEG 書き出し時にアプリ既定で位置情報が保持
• 画像本体のレダクション漏れ（顔・車両・文書の写り込み）

公開前チェックリスト

• [ ] GPS/位置情報フィールド（GPS*）が全て消えている
• [ ] 端末固有情報/内部メモが含まれていない
• [ ] 著作権者/ライセンスURL/説明の最小限が保持されている
• [ ] OGP/サムネイル/派生群でも同一結果である
• [ ] ランダムサンプリングの監査ログが保存された

FAQ

• Q: すべてのメタデータを削除しても問題ない？

• A: 法務・検索要件によっては保持が必要です。ホワイトリスト方式で最小限を残すのが安全です。

• Q: 端末側の位置情報を確実に落とすには？

• A: GPS* タグの完全削除をテストで担保し、処理後の画像を二次検査（exiftool -gps*）してください。

• Q: 画質や色再現は落ちない？

• A: EXIFストリップ自体は画質に影響しません。色は ICC を sRGB に正規化し、品質パラメータを適正化してください。

• Q: ライセンス表記とプライバシーは両立できる？

• A: 可能です。クレジット/ライセンスURL/説明のみ保持し、PII/位置情報は保持しない設計にします。

まとめ

メタデータは価値とリスクが表裏一体です。デフォルト削除＋ホワイトリスト保持、監査可能な自動化、派生画像まで一貫したストリップを徹底すれば、プライバシー・コンプライアンス・運用性の三立が実現できます。詳細なワークフローは EXIFとプライバシー情報の安全な除去フロー 2025 も参照してください。さらに、著作権やライセンス記述の設計は 安全なメタデータ方針 2025 — EXIF 削除・自動回転・プライバシー保護の実務 で解説しています。