保持と破棄

保持には 2 つの層があります。プラットフォームの上限は公開の約束で、内部の調整項目ではありません。その上限の範囲内で、自分でより短い期間を設定できます。また、個別タスクの内容はいつでも破棄を依頼できます。

両者の関係は明確です。短くすることだけができ、どの設定でも上限は延びません。

保持期間（プラットフォームの上限）

最初の 4 行は、以下の 4 つの保持設定で短縮できます。対象は生成結果（メディアと結果ペイロード）、短編映画のメディア、プロンプトのテキスト、アップロードファイルです。

短編映画のメディアは、Spicy Studio の映画制作に数日から数週間かかり、最初の週に作ったシーンも全編の書き出し時に必要なため、長めに保持します。これは Studio の短編映画プロジェクト内で開始したタスクだけに適用します。同じモデルを API、SDK、Playground から呼び出した場合は 14 日上限のままで、プロンプトのテキストはどちらも 30 日上限です。残りはプラットフォームの義務や法定期間であり、ユーザー設定では変わりません。

個別に設定する 4 つの保持期間

同じ対象に 4 段階の期間を選ぶのではなく、4 種類の対象を別々に設定します。以下の名前はコンソールに表示されるものです。

コンソールの データ保護ページの 保存期間 で設定します。タスクを受理すると、これらの設定と以下のヘッダーから結果・プロンプトの期限が決まり、recordInfo の retention で確認できます。

「タスク終了時に削除」は、そのファイルを使うすべてのタスクが最終状態（succeeded / failed / canceled / expired）に達した後、通常 1 分以内に削除する設定です。再試行で必要なため、タスク作成時には削除しません。影響を理解してから選んでください。同じ画像をもう一度使うには再アップロードが必要で、再試行は失敗します。

設定変更が既存データに与える影響

保持期間の変更は単純な「今後だけ」の切り替えではありません。実行済みタスクにも影響する変更と、影響しない変更があります。現在の動作は次のとおりです。

一部の変更が遡って適用されるのは、受理時に個別の期限を固定する処理とは別に、日単位の清掃処理があるためです。この処理はプロンプトのテキスト設定を 1・7・30 日へ切り上げ、アカウント内の全完了済みタスクに適用します。タスクを消去する際はプロンプトと結果を一緒に消去します。

同じページの 2 枚目のカード ジョブ内容の保存期間 は、この日単位の処理を直接設定します。

• 1 日または 7 日を選ぶと、その期間より前に完了した全タスクのプロンプト、結果、生成ファイルを削除します。その後も各タスクがその経過期間に達すると削除します。
• 完了後すぐに内容を消去をオンにすると、有効化前のタスクも含め、すべての完了済みタスクの内容をそれぞれ完了から約 1 時間後に消去します。
• 2 枚のカードは設定を共有し、一方を保存するともう一方の表示も変わります。

リクエストごとの指定：X-Spicy-Retention

アカウント設定を変えずに、その生成だけを早く消したい場合は、タスク作成時にヘッダーを送信します。値は秒単位の整数で、そのタスクの生成ファイルとプロンプトに適用します。

curl -X POST https://api.spicyapi.ai/api/v1/jobs/createTask \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $SPICY_IDEMPOTENCY_KEY" \
  -H "X-Spicy-Retention: 3600" \
  --data "$TASK_PAYLOAD"

• 短縮のみです。 有効値は min(header, account setting, platform cap) です。管理者がアカウントを 1 時間にした後、個別リクエストで 14 日へ戻すことはできません。それができれば設定ではなく提案になってしまいます。
• 0 も有効で、「タスクが最終状態になったらすぐ生成ファイルを削除する」を意味します。
• 不正な値でもリクエストは失敗しません。 負の値は 0、上限を超える値は上限に収めます。十進整数でない値は無視し、アカウント設定を使います。実際に適用した値は常に recordInfo の retention で返します。保持をより控えめにするためだけのヘッダーで、生成を壊さない設計です。
• 読み取るエンドポイント。 jobs/createTask と jobs/stream はどちらも読み取ります。jobs/retry は元タスクの有効値を継承し、ヘッダーを無視します。再試行は同じ処理への 2 回目の試みで、別期間を選べると同じタスク系列に 2 種類の期限ができるためです。jobs/quote はタスクを作らないため読み取りません。

recordInfo は各タスクの retention を返します。createTask レスポンス自体には含まれないため、作成後に確認してください。

{
  "retention": {
    "outputsExpireAt": "2026-09-13T12:00:00Z",
    "promptsExpireAt": "2026-09-13T12:00:00Z",
    "source": "header"
  }
}

source は、決定した層を示します。header はこのリクエスト、account はアカウント設定、platform は上限です。ヘッダーを送っても account が返る場合は、アカウント設定が指定よりすでに短かったことを意味します。

タスク完了前の outputsExpireAt は受理時刻から計算します。最終状態になると、同じ期間を完了時刻から計算し直します。そのため、期限は後ろに動くことはあっても前には動きません。自分で再計算せず、レスポンスの日時を使ってください。3 層の最小値は想定どおりとは限りません。自分で破棄する場合を除き、この時刻より前に削除し得るのは、上記の遡及するアカウント設定だけです。

任意のタイミングで破棄：POST /jobs/purge

期限まで待ちたくない場合は、次の操作を使います。

• コンソールでは ログでタスクを開き、生成結果を破棄 を選びます。以下のエンドポイントと同じ操作です。
• 同じタスクの 履歴から削除 もプロンプトと結果を消去し、メディア削除を予約します。さらにログからタスクを非表示にします。タスクが終了し、課金が精算済みになってから利用できます。

どちらも請求額を変えず、タスクをキャンセルする操作でもありません。コードからは次を使います。

curl -X POST https://api.spicyapi.ai/api/v1/jobs/purge \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"taskId": "job_01k..."}'

レスポンス：

{
  "taskId": "job_01k...",
  "contentState": "purged",
  "purgedAt": "2026-09-13T12:00:00Z",
  "contentRemovedBy": "user",
  "billingRetained": true,
  "mediaDeletionPending": true
}

次の規則があります。

• 最終状態のタスクのみ（succeeded / failed / canceled / expired）。実行中は終了まで待ちます。生成ファイルがまだ揃っておらず、一部だけ削除する方が問題を生むためです。生成タスクは受理後にキャンセルできないため、「先にキャンセルしてから破棄」の手順はありません。
• 冪等で、Idempotency-Key は不要です。 taskId 単位で冪等なため、破棄済みタスクへの再呼び出しも 200 を返します。purgedAt はこの呼び出しではなく最初の破棄の時刻です。タイムアウト後も安全に再試行できます。
• レスポンスは「予約済み」であり「削除完了」ではありません。 mediaDeletionPending が true の間は、contentState はすでに purged でも、バックグラウンド処理がまだオブジェクトを削除していません。通常は 1 分以内に完了します。同期削除では 1 つの削除しにくいオブジェクトがリクエスト全体を止めてしまうため、明確な応答が必要なこの操作では避けています。
• まだ present のレスポンスは、今回何も削除しなかったことを意味します。例えばタスクに保存措置が適用されている場合です。後で再試行できますが、具体的な理由は意図的に公開しません。
• billingRetained は常に true です。 冗長に見えても、呼び出し側が誤解しやすい点なので明示しています。詳細は以下です。

contentState：内容の有無と削除した主体

タスク詳細の contentState には 3 つの値があります。

後の 2 つには、purgedAt（内容がなくなった時刻）と contentRemovedBy（清掃処理は system、ユーザーは user）も付きます。

purged を「期限切れ」と表示するのも逆の意味で不正確です。一方はユーザーが押したボタン、もう一方は予定どおりのポリシー実行です。逆に説明すると、プラットフォームがファイルを紛失したと受け取られてしまいます。

期限切れで消すのはフィールドであり、行ではありません

清掃の対象は input、output、コールバック URL、関連イベント・コールバック内容です。タスクの行自体は無期限に保持します。課金紛争の唯一の証拠であり、消すと会計記録が成立しなくなるためです。内容の削除後は、タスク ID、モデル、状態、金額、日時、作成元キーといった数百バイトのメタデータになります。任意の破棄も同じ規則で、違うのは時期だけです。

内容がなくなった後も、次の違いがあります。

• 「今月いくら請求されたか、どのタスクが失敗したか、どのキーが送信したか」は確認できます。
• 「どんなプロンプトを送ったか、生成ファイルのオブジェクトキーは何か」は確認できません。その時点から recordInfo は input と output を返しません。

より長くプロンプトを残す場合は、自分のコピーを保存してください。有効な保存措置がある間は該当データの削除を停止し、任意の破棄もブロックします。どちらも物理削除済みの出力を復元することはできません。

残高履歴とタスク内容は別です

期限切れでも任意の破棄でも、タスクの input と output の消去は、入金、仮押さえ、精算、仮押さえの返却、手動調整を変えません。コンソールの課金ページで引き続き照合できます。課金台帳は 10 年の保持ポリシーに従い、タスク内容の期限切れ・破棄に合わせて削除しません。

アクセス・削除請求の対象に、紛争、セキュリティ調査、適用法により保持が必要なデータが含まれる場合は、回答で範囲と理由を説明します。

できないことが 2 つあります

例外：法的な保存措置

紛争、フォレンジック調査の要請、法定報告義務に関係するタスクには保存措置を適用し、解除するまで保持期間の進行を停止します。有効な間は任意の破棄も実行しません。

これは上記のすべての期間と設定に優先します。密かに留保した抜け道ではありません。この仕組みがなければ、最初の法的要請だけで保持の約束を破る必要が生じ、文書に 14 日と書いた理由を説明しなければなりません。必要な条件なのでここに明記しています。

ユーザーが選べること

• それぞれを実際に必要な期間に設定します。 別々の設定なので、プロンプトを短くしたいだけでアップロードを「タスク終了時に削除」にしないでください。
• 短縮前にダウンロードします。 短い設定は実行済みタスクにも遡って影響し得ます。設定変更の影響を参照してください。
• 機密性の高い単発リクエストには X-Spicy-Retention を使います。 1 回の生成のためにアカウント全体を変更する必要はありません。
• 不要な情報を送信しません。 参照画像とプロンプトは特に機密性が高く、内容をユーザーが選ぶ 2 つの項目です。
• 生成ファイルは自分で保管します。 最長でも約 14 日、短編映画のメディアは約 60 日で、設定を短縮すればさらに短くなります。
• アカウントデータをコピーします。 データ保護ページの 自分のデータをダウンロード は、プロフィール、チームのロール、API キーの詳細（秘密キーは含まない）、保持中のタスクデータ、課金記録を JSON で取得できます。メディアファイルは含まれないため、必要な結果は別途ダウンロードしてください。
• ダウンロード URL をデータベースへ保存しません。 20 分で期限切れになり、発行後は取り消せません。必要な時に署名を発行します。メディアを参照してください。
• コールバック URL は HTTPS にします。 ペイロードにはタスク状態と生成ファイルの参照があり、平文 HTTP では通信経路上の第三者に渡ってしまいます。

ユーザーの内容を学習には使いません

プロンプト、参照画像、生成ファイルは学習データに入りません。

この文の範囲はSpicyAPI 自身です。各モデルのポリシーは SpicyAPI が決めるものではありません。上記の最初の点を参照してください。