一時アップロードには保持ルールが必要です

“一時アップロード”は、宿題付きの約束です。

一見すると明快です。ユーザーがファイルをアップロードし、システムがしばらく使ってから、消える。いいですね。しかしシステムは単一の場所ではありません。ファイルは、ブラウザ、エッジキャッシュ、アプリケーションサーバー、オブジェクトストレージ、キュー、モデル実行環境、リトライ用ワーカー、サムネイル生成、CDN、サポートツール、そしてログを通過する可能性があります。

もし「一時」がメインのデータベース上だけで一時的という意味なら、その約束は薄すぎます。ユーザーが気にするのは、あなたのスキーマ図ではなくファイルそのものです。

一時アップロードの保持ポリシーは、オリジナル、リサイズ版、マスク、プレビュー、サムネイル、リトライ用ペイロード、失敗したジョブ、出力の配信URL、キャッシュ、ログをカバーすべきです。何が作られるのか、なぜ存在するのか、どれくらいの期間生きるのか、そしてその後何が残るのかを明確にします。

これは、すべての一時ファイルを即座に消す必要があるという意味ではありません。短寿命の配信リンクが必要なシステムもあります。短いリトライ期間が必要なシステムもあります。請求や不正防止のために内容を持たない記録が必要な場合もあります。重要なのは、保持の挙動が意図的で、説明されていることです。

また、一時には失敗時の扱いも必要です。生成が途中でクラッシュしたら、アップロードは残りますか？ワーカーがタイムアウトしたら、デバッグのために元画像は保持されますか？ユーザーがキャンセルしたら、途中まで作られた出力はどうなりますか？失敗経路こそが、一時的な約束が意図しない保管になってしまう場所です。

最も安全なアプローチは、コピーを減らすことです。コピーが少なければ、保持ルールもクリーンアップジョブも減ります。コンテンツを受け取り、処理して結果を返し、機密性のある素材を捨てる短寿命の「Generation Session」は、花火のようにアップロードの派生物を散らすプロダクトよりも、説明しやすく推論しやすいのです。

「一時的」はUIに貼り付けるだけの言葉ではありません。それはエンジニアリング上の主張です。

さらに読む： クラウド用語なしでエフェメラル（短命）な計算を考える方法、Unexposedのデータストレージ、OpenAIの [APIデータコントロール] (https://developers.openai.com/api/docs/guides/your-data)。