アップロード削除は検証可能でなければならない理由

“アップロードを削除する” は、実際のシステムにぶつかるまで簡単そうに聞こえる言葉のひとつです。

削除はどこから？ ギャラリー？ オブジェクトストア？ CDN？ キャッシュ？ キュー？ エラートラッカー？ サポートチケット？ サムネイルテーブル？ バックアップ？ モデル提供元？ アナリティクスのパイプライン？ デバッグ中に誰かが作った final-final-private-test というフォルダ――ソフトウェアが自分自身を食い始めた証拠ですね。

AI画像プロダクトでは、削除はオブジェクトの観点で定義される必要があります。ソース画像。プロンプト。マスク。参照画像。生成された出力。サムネイル。 一時ファイル。配信URL。運用メタデータ。課金レコード。各オブジェクトには異なるライフサイクルがあり得ます。強いプロダクトはそれらのライフサイクルを理解しています。弱いプロダクトは「削除済み」と言って、誰も追及してこないことを願います。

検証可能な削除は、必ずしもユーザーが、すべての媒体からすべてのバイトが即座に消えたことを暗号学的に証明できることを意味しません。多くのシステムでは、バックアップ、ログ、不正検知記録、税務記録、法的義務が削除を複雑にします。誠実なプロダクトは、その制約を説明します。重要なのは、保持される記録が「コンテンツを含むのか（content-bearing）」それとも「コンテンツを含まないのか（content-blind）」です。

もしプロダクトが画像は削除するが、「1回の画像生成が行われた」という課金記録を残すなら、それは妥当な場合があります。ギャラリー項目は削除するが、「quality」バケットにサムネイル、プロンプト、ソース画像を残すなら、それは規制の照明が当たるコメディのようなものです。

良い削除は削除の前から始まります。不要な場所にプライベートなコンテンツをコピーしないことから始まります。コンテンツが行く場所が少なければ少ないほど、後で小さなほうきと少し悲しい顔で削除を追いかける必要が減ります。データの経路が短いほど、検証しやすくなります。

UIも正確であるべきです。「ギャラリーから削除」は「ソースのアップロードを削除」とは違います。「出力を削除」は「アカウントを削除」とは違います。「非表示」は「削除」ではありません。「アーカイブ」は、フォントがどれだけ高価でも、絶対に「削除」ではありません。

プライバシー重視のAI画像インフラでは、より良いデフォルトは、そもそも耐久性のあるアップロード保存を避けることです。短命のセッションでソース画像を処理し、出力を返し、コンテンツを含まない運用レコードだけを保持します。そうすれば、削除の約束が英雄譚になりにくくなります。削除待ちのプライベートコンテンツがそもそも少ないからです。

ユーザーは論文のような説明を必要としていません。削除を押した後に、何が残るのか、そしてなぜ残るのか――明確な答えが必要です。

プロダクトがそれに答えられないなら、「削除」は飾りです。

さらなる読み物: Unexposed data storage、AI画像におけるゼロ保持の考え方、およびOpenAIのAPIデータ保持に関するドキュメント。