モデル写真は「次へ」ではなく、選んだ時点でアップロードされます

作成フローのモデルのステップでは、カタログからモデルを選ぶか、自分の写真を使うかのどちらかになります。自分の写真の側では、選んだ瞬間にファイルがサーバーへ送られます。「次へ」を押す前、そして生成が始まる前です。

引き返したときに感じ方がずれるのは、このためです。押した操作が生成を一つ費やしたわけではないので、画面はまだ何にも踏み切っていないステップのように見えます。しかし転送は、選択の時点で要求され、始まっています。

ここで確かめられているのは、その一つのステップについてのことです。アプリのすべての選択画面についての表明ではなく、ほかの画面が選ばれたファイルをどう扱うかについての主張でもありません。

この挙動はapps/jewelry-mobile/src/features/generation/create-flow/steps/model-source-step.tsxから読み取っています。そこでは、選ばれたアセットのハンドラーの中に直接アップロードの呼び出しがあり、その行には選択時にアップロードするというコメントが付いています。リポジトリ上で2026年8月18日に確認しました。

どの生成にも結び付けられないままのアップロードは、サーバー上の後片付けのコードが扱います。フローの中で提供される操作ではなく、気が変わった瞬間が、何かが取り除かれる瞬間でもありません。

使われないアップロードを片付けの候補として扱うまでにサーバーが待つ時間は、署名付きのアップロードのリンクが有効な15分よりも何倍も長く、その差は意図されたものです。回線が遅い場合や、アプリがバックグラウンドに回された場合を、放棄ではなく正当な転送として数えるためです。

ユーザーのモデルアセットは、データベース層にある別の経過観察と後片付けの監視が対象にしています（packages/db/src/asset-purge.ts:265-286）。コードから分かるのは、そうしたアセットが監視されているということです。特定のファイルがいつ削除されるかは示されないため、モデル写真についての間隔はここでは示しません。

同じ仕組みには、さらに二つの限界があります。結び付けられていないアップロードの掃引は連続ではなくスケジュールに従って動くこと、そして実際に生成で使われた画像はその手の届く範囲の外にあり、それらに触れるのはこの掃引ではないことです。

削除と、遅れて到着する転送との競合もコードは扱っています。アップロードの猶予がまだ開いているあいだ、アセットは完全に失われたものとしては扱われず、その猶予が閉じたあとに二度目の削除が続きます。そのため、すでに削除されたファイルが、まだ有効なリンクを通じて静かに戻ってくることはありません（apps/api/src/storage/asset-purge-sweeper.ts）。

これらの監視が本番の環境で動いているかどうかは、コードからは読み取れません。コードが保証しているのは、もっと狭いことです。テストの環境ではタイマーが組み込まれない、という点です。以上のどれも、保管の期間でも、削除の保証でも、プライバシー上の約束でもありません。仕組みの説明であり、約束ではなくスケジュールされたものです。