削除されたのに、まだ公開されていることがある

“削除” はプロダクトのコピーで最も危険な言葉の一つです。ユーザーはそれが普通の意味だと思ってしまうからです。

ユーザーは「削除＝消える」と考えます。自分には見えない。ほかの人にも見えない。検索できない。リンクでアクセスできない。しかも、公共のバケットに紛れ込んで、偽の口ひげをつけたまま静かに残っているわけではない。

ソフトウェアは、もっと狭い意味で捉えがちです。リストから削除。アカウントから削除。有効なデータベースから削除。保管期間の後に削除。プライマリストレージからは削除されたがバックアップには残っている。ログを除いて削除。サムネイルを除いて削除。誰も覚えていなかったもの（「quick fix（応急処置）」というスプリント名の間に追加されたもの）を除いて削除。

AI画像ツールでは、この食い違いは厳しい現実になります。ユーザーは顔をアップロードし、プライベートな出力を生成し、セッションを削除すれば、作業は消えたと当然に考えるかもしれません。しかし、共有URL、公的なギャラリーパス、CDNキャッシュ、または派生プレビューが引き続きアクセス可能なら、プロダクトはその言葉の通常の意味を壊しています。

より良いプロダクト言語は具体的です。「ギャラリーから削除」は「システムから削除」とは違います。「一時ファイルはXの後に期限切れ」は「すぐに削除」とは違います。「バックアップはY日間、暗号化されたコピーを保持する場合があります」は、「削除」と書かれた陽気なボタンでインフラに即興を任せるより正直です。

エンジニアリングは、削除をフラグではなくワークフローとして扱うべきです。ソースのアップロード、生成された出力、プロンプトの記録、サムネイル、エクスポート、ログ、モデレーション用のコピー、キャッシュキー、共有リンクなど、すべてに対して判断が必要です。削除すべきものもあります。セキュリティや法的理由で保持が必要なものもあります。重要なのは、どれがどれかを把握することです。

公開アクセスには独自のテストが必要です。削除前にユーザーが直接リンクを持っていた場合、削除後も開けるでしょうか？答えが「はい」なら、UIは多くのユーザーが理解する「削除」を提供できていません。

正当な例外もあります。法的な保留（リーガルホールド）があります。悪用調査があります。バックアップがあります。しかし、例外が存在することは、曖昧なデフォルトを許す理由にはなりません。例外は狭く、文書化され、ポリシーの言語として明確に示されるべきです。

AI画像プロダクトは親密な素材を扱います。「削除」を飾りのコピーとして使うわけにはいきません。その言葉は、ダイレクトリンクのテストに耐える必要があります。

さらに読む： 画像を生成することと保持することの法的な違い, 一時的なアップロードには保持ポリシーが必要な理由, プライベートAIが平易な英語で意味するもの.