AI画像におけるゼロ保持（Zero retention）を考える方法

ゼロ保持はポリシーのように聞こえますが、実際には設計上の制約です。

重要なのは「その製品が『プロンプトは保存しない』と言っているかどうか」ではありません。重要なのは、プロンプトや元画像が行き着く先が非常に少なくなるようにシステムが作られているかどうかです。

コンテンツと運用を分ける

運用メタデータは有用です。チームは、ジョブが失敗しているかどうか、どのモデルが遅いか、生成された画像が何枚か、キューが過負荷になっていないかを把握する必要があります。

ユーザーコンテンツは別物です。プロンプト、マスク、参照画像、生成された出力、アップロードされたアセットは、通常のログのように扱うべきではありません。

優れたゼロ保持の設計では、最初からこの2種類のデータを分けます。

一時的なものは本当に一時的にする

ジョブが実行されている間は、いくつかのデータが存在する必要があります。プロンプトはモデルに届く必要があります。元画像は読み取られる必要があります。出力は返される必要があります。

ポイントは、そのデータを短命な経路に置き、ジョブが終わったら削除することです。一時ストレージは、退屈であること（＝特別扱いしないこと）、明示的であること、そして検査しやすいことが重要です。

うっかり保持を避ける

最大のプライバシー上のミスは、しばしば「うっかり」です。たとえば:

• エラーログに含まれるリクエストボディ
• サポートツールにおけるスクリーンショット
• アナリティクスイベントに含まれるプロンプト
• デバッグ用フォルダにコピーされたソースファイル
• 「品質レビュー」のために保存された生成出力

ゼロ保持には、データベースのスキーマだけでなく、こうした通常の経路をチェックすることが必要です。

モデルの動きをわかりやすく説明する

顧客は、自分のコンテンツがどう扱われるのかを理解するのに、セキュリティの専門知識を必要としないはずです。シンプルな説明は、たいていシステム自体がシンプルである良い兆候です。

その物語に例外が多すぎる必要があるなら、実装もおそらく多すぎます。