Jewelry AI・保存と共有

ここでの画像のアドレスは、要求のたびに署名され、期限が切れます

サーバーが署名する二つの方向には、どちらも有効期限が付いています。保存された画像を表示するなら1時間、ファイルをアップロードするなら15分です。この二つの経路のどちらも、手元に取っておけるアドレスは渡しません。だから出品者が決めるべきことは、画像の残り続けるコピーをどこに置くか、になります。

しまっておけるアドレスはありません

アプリが保存された画像を表示するとき、サーバーはその画像のためにアドレスを署名し、そのアドレスに寿命を付けます。アドレスは、画像がずっと持ち続ける名前ではありません。画像を取得するための許可であり、許可は尽きます。

読み取り経路は3600秒、つまり1時間の有効期限で署名します(apps/api/src/storage/storage.service.ts、2026-08-18に確認)。書き込み経路、つまり端末がファイルをアップロードする先のアドレスは、同じサービスの定数PRESIGN_PUT_EXPIRES_SECによって900秒、つまり15分だけ署名されます。この差は意図的です。読み取りはアップロードの4倍の長さになります。

このページが存在する理由になっている事例の背後にある仕組みは、これで全部です。コピーした時点では動き、開き直すと拒まれるアドレスは、画像を失ったのではありません。許可を使い切ったのです。

完了した結果について一つだけ恒久的なものがありますが、それはアドレスではありません。完成した結果にはすべて開示の帯が付きます。その仕組みはベースとなる写真の基準を扱うページに属しており、ここでは導き直しません。

二つの猶予を並べて見る

どちらの数値も、サーバーのストレージサービスにある定数です(apps/api/src/storage/storage.service.ts、2026-08-18に確認)。

方向署名付きアドレスの寿命その数値が支配するものその数値が支配しないもの
保存された画像を表示する1時間(3600秒)その特定のアドレスを使って画像を取得できる長さアプリの中で画像を見ていられる長さ。アプリは別のアドレスを改めて要求できます
選んだファイルをアップロードする15分(900秒)そのアドレスがアップロードを受け付ける長さ。同じ定数が、遅れて届くアップロードはもう到着しえないと削除処理が判断するためのしきい値でもあります転送にかけてよい時間。猶予の内側で始まり外側で終わる転送は、コードでは定まっていません

アドレスは何でできていて、誰が決めたのか

オブジェクトの識別に関わる部分は、すべてサーバー側で決まります。ファイルの名前について端末から来るものは、申告された種類だけです。

名前も場所も、サーバーが生成します。
キーは、固定のプレフィックス、ランダムなUUID、拡張子として組み立てられます(apps/api/src/uploads/uploads.controller.ts、2026-08-18に確認)。バケットもフォルダーもファイル名もアプリからは選べないため、あとで推測したり、覚えておいたり、組み立て直したりする対象もありません。
プレフィックスは利用者の識別子を含み、コードはそのキーをログに残さないようにしています。
キーが識別子を含むため、あるスイーパー処理は意図的にキーをログへ書きません(apps/api/src/storage/asset-purge-sweeper.ts:202、2026-08-18に確認)。これはコードにおけるログ出力の判断であり、このページはそれをプライバシーの保証として提示しません。ここで読んだ範囲には、署名付きアドレスがひとたび存在したあと、誰がそれを使えるかを定める記述はありません。
拡張子は申告されたものであり、測定されたものではありません。
クライアントが述べたコンテンツタイプから導かれたものであり、ファイルのバイト列から導かれたものではありません。したがって、ある形式で終わるアドレスは、保存されたオブジェクトがその形式である証拠にはなりません。
寿命はアドレスに属し、画像には属しません。
あとから呼び出せば、同じ保存オブジェクトに対して新しく署名されたアドレスが作られます。モデルカタログでは、呼び出しのたびに一覧の画像アドレスが署名し直されます(apps/jewelry-mobile/src/features/generation/create-flow/steps/model-source-step.tsx、2026-08-18に確認)。

画像が削除の待ち行列に入ると、新しいアドレスは止まります

この製品で削除は一瞬の出来事ではありません。画像はまず待ち行列に入ります。待ち行列に入った瞬間から、サーバーはその画像の新しい表示用アドレスの署名を拒み、すべての読み取り経路が、アセットの削除処理の状態に対する同じ確認を通ります(apps/api/src/storage/storage.service.ts、2026-08-18に確認)。したがって拒否は、削除そのものが終わる前に届きます。

関門が支配するのは新しいアドレスであり、それだけです。待ち行列に入る前に署名され、まだ1時間の内側にあるアドレスについては、このコードは答えを持ちません。ですから、状況を誰かに説明しなければならないときは、定まっている部分を説明してください。アプリはその画像について新しいアドレスを作りません。

モデルカタログでは、呼び出しのたびにアドレスが署名し直されます

モデルカタログはクライアント側のキャッシュを持ちません。フィルターを変えるたびに一覧をサーバーから取得し直し、呼び出しのたびに画像のアドレスがすべて署名し直されます。署名されたアドレスは1時間で無効になるため、あの画面から集められる恒久的な画像URLはありません(apps/jewelry-mobile/src/features/generation/create-flow/steps/model-source-step.tsx、2026-08-18に確認)。

一つだけ、はっきり言っておく価値のある帰結があります。逆のことを心配しやすいからです。取得されたモデルはidによってアプリのストアへ統合されます。理由も書かれていて、フィルターを変えたあとでも、選んだモデルが確認のステップで解決できなければならないからです。フィルターを変えても、すでに選んだモデルの画像が失われることはありません。

この挙動はカタログの画面で読み取ったものです。アプリの他のすべての画面がアドレスをどう扱うかについての記述ではありません。また1時間という寿命は、すでに画面に描かれている画像が1時間を過ぎると壊れる、という主張でもありません。それは検証されていません。

画像がどこへ行くかで、必要なものが決まります

役に立つ問いは、アドレスがどれだけ持つか、ではありません。そもそもその置き場所に必要なのがアドレスなのか、です。

状況選択理由
今すぐ結果を見たい。あるいは、一緒に見ている相手に見せたい。署名付きアドレスで足ります。署名された瞬間から1時間有効であり、何かを見るにはその範囲で足りるためです。
商品ページ、カタログのページ、あるいは店舗のページが、これから先ずっと画像を表示しなければならない。その置き場所が、自分のアドレスから画像を配信する必要があります。ここで説明したどちらの署名経路も、動き続けるアドレスを作りません。そこを指した置き場所は、有効期限の付いたものを指していることになります。
どの画像がどの作品のものかを、自分で記録している。アドレスではなく、作品に対して記録してください。アドレスは期限が切れ、オブジェクト名は自分では選んでいないサーバー生成のUUIDです。どちらも、記録の仕組みを組み立てられる手がかりではありません。
画像の削除を依頼し、その状況を顧客に伝えなければならない。アプリはその画像に新しいアドレスを発行しない、と伝えてください。関門は、削除が完了する前に新しい署名を止めます。すでに発行され、まだ期限が切れていないアドレスの行方は、コードでは定まっていません。

これを知らない出品者が払う代償

いずれも、署名付きアドレスを名前のように扱った結果として起こります。

  • 公開した商品ページが、1時間を過ぎると静かに写真を失います。

    商品ページは、その置き場所が保持している画像を指してください。署名付きアドレスは見るためだけに使い、供給元にはしないでください。

  • 削除の依頼を根拠に、画像へ到達できないと顧客に伝えてしまい、その主張が根拠より広くなります。

    定まっている部分、つまり新しいアドレスは署名されないということだけを伝え、すでに送ったアドレスについては何も言わないでください。

  • ファイル形式を気にする経路に、アドレスから読み取った拡張子が信用されて渡されます。

    拡張子は、申告された種類であって測定された形式ではないものとして扱い、重要な場面ではファイルから確かめてください。

  • 期限切れになるアドレスが、プライバシーやセキュリティの対策として顧客に説明されます。

    その説明はしないでください。寿命はアドレスの発行のされ方であり、ここで読んだ範囲には、有効な間に誰がそれを使えるかを定める記述はありません。

画像のアドレスをどこかに貼り付ける前に

  • その置き場所が、これから先ずっと画像を表示しなければならないのか、一度見られればよいのかを決める。
  • 1時間は、貼り付けた時点ではなく、アドレスが署名された時点から数える。
  • 自分の記録は、アドレスやオブジェクト名ではなく、作品に対して残す。
  • アドレス末尾の拡張子を、ファイルの本当の形式として読まない。
  • 有効期限を、プライバシーやアクセスの対策として顧客に説明しない。
  • 画像が削除の待ち行列に入っているなら、新しいアドレスは発行されない、とだけ伝える。

このページが決めていないこと

いずれも、このページのために読んだコードが定めている範囲の外にあります。だから答えは示しません。

  • 署名付きアドレスがまだ有効な間、誰がそれを使えるか。有効期限は、ここではアクセス制御の手段として提示していません。
  • 画像が削除の待ち行列に入る前に署名され、まだ期限が切れていないアドレスがどうなるか。
  • 15分の猶予の内側で始まり、外側で終わるアップロードがどうなるか。
  • アプリの他の画面がアドレスをどう扱うか。このページのためにアドレスの扱いを読んだクライアント側の画面は、モデルカタログだけです。
  • 生成を送信したときにAIプロバイダーへ何が送られるか。これは別の主題であり、ここでは答えません。
  • 始めたまま生成に使わなかったアップロードがどうなるか。これも別の主題です。
  • 生成が返すファイルの形式、透過、ピクセルサイズ。これらは製品の別の場所で決まっており、このページが依拠するコードでは定まりません。

よくある質問

生成した画像のリンクをコピーして、商品ページに貼れますか。

コピーはできますが、表示用のアドレスは1時間だけ署名されています(apps/api/src/storage/storage.service.tsで3600秒の有効期限)。そこを指した商品ページは、やがて解決しなくなるものを指していることになります。商品ページがこれから先ずっと画像を表示しなければならないなら、画像は、その商品ページが配信する場所に置く必要があります。

1時間前は読み込めた画像が、今は読み込めません。なぜですか。

手元に残したアドレスは1時間の寿命で署名されており、その許可が尽きました。こうなるために、保存された画像の側で何かが変わっている必要はありません。新しいアドレスは、同じオブジェクトに対する新しい許可です。

15分の時点でアップロードがまだ続いていました。この上限が止めたのですか。

15分は、アップロード用アドレスが有効でいる長さであり(PRESIGN_PUT_EXPIRES_SECは900秒)、転送にかけてよい時間ではありません。猶予の内側で始まり外側で終わる転送がどうなるかはコードからは読めないため、その猶予が止めたとは、このページからは言えません。

画像を削除しました。すでに誰かに送ったリンクは動かなくなりますか。

画像が削除の待ち行列に入ると、サーバーはその画像の新しい表示用アドレスを署名しなくなり、しかもそれは削除が終わる前に止まります。すでに署名され、まだ期限が切れていないアドレスがどうなるかは、コードが決めていません。ですから、古いアドレスがもう動かないと言うのではなく、アプリはその画像に新しいアドレスを発行しない、と伝えてください。