NSFW画像AI APIの再試行：同じ画像に二重で支払わない方法

成人キャラクターのアプリが、新しい画像1枚を約束している。顧客が生成を押すと、しばらく待機表示が続き、接続がタイムアウトしたと表示される。もう一度押すと、1分後には画像が2枚現れ、残高も2回減っていた。

2枚目も素敵な画像かもしれません。それでも、接続のタイムアウトは生成の失敗ではないと気付くためには、高くつく方法です。

NSFW画像APIで「再試行」と呼ばれる動作は3種類あります。既存タスクの確認、元の送信の再送、新しい創作試行の購入です。これらを分けてください。タスクIDがあるなら、そのタスクを確認します。作成応答が失われたなら、変更しないリクエストを元の冪等キーで再送します。タスクが完了したのに画像が制作指示に合わないなら、次の生成は新しい購入です。

最後の区別は、成人向けの人物画像で特に重要です。モデルは、求めた場面を弱めたり、服を変えたり、別の顔にしたりしても、正常完了することがあります。タスクの成功は結果が届いたことを示し、採用したくなることまでは約束しません。

何が起きたか、どのボタンを出すべきか

待機、送信の復旧、新しいバリエーションは異なる動作です。

成人向け制作のUIなら、これらを既存画像を確認、送信を復旧、別のバリエーションを生成、ダウンロードを再試行と表示すると役立ちます。「再試行」1つでは、無料の状態確認と、新しい生成支出の承認の違いが隠れます。

タスクIDがあるなら、元のタスクを保持する

SpicyAPIの非同期画像ワークフローは、リクエストを受理し、タスクIDを返し、後から画像を利用できるようにします。受理された作成応答は、完成画像ではありません。タスクはqueued、running、succeededなどを通り、failed、canceled、expiredも終端状態です。

サーバーがタスクIDを受け取ったら、ブラウザーを更新する前にすぐ保存します。顧客がページを更新、再ログイン、別の端末でプロジェクトを開いても、アプリはプロンプトを再送せず、保存済みのタスクを取得すべきです。

たとえば制作者が、架空の成人キャラクターの新しい夜のポートレートを依頼します。サーバーはタスクIDを受け取ったものの、待機カードを描画する前にブラウザーの接続が切れました。戻ったら、そのカードは同じタスクへの接続を再開すべきです。ページを更新しただけで、2枚目を依頼したことにはなりません。

タスクIDを付けたGET /api/v1/jobs/recordInfoで現在の状態を復旧します。タスク文書にリクエストと応答の説明があります。完了通知にはWebhookも使えますが、Webhookの遅延で既存タスクが失敗になるわけではありません。ポーリングは復旧方法として引き続き使えます。

ローカルの待機上限を課金判断にしないでください。ブラウザーは30秒、サーバーからのHTTP接続は60秒で待機を止めても、リモートのタスクはまだ実行中かもしれません。返るタスク記録には実行期限deadlineAtがあります。これはリモート実行の期限であり、ページが接続を維持する時間とは違います。結果のダウンロードリンクの失効も、また別の時計です。

待機画面には、「画像を処理中です。このページを離れても、同じタスクに戻れます」のような表示を使います。そのモデルと作業量の測定がなければ、正確な完了時間を主張しないでください。競合が通常の商品画像で測定した遅延は、あなたのNSFWプロンプトの所要時間の保証ではありません。

作成応答が失われたら、同じ送信を再送する

難しいのは、サーバーがリクエストを送った後、確認を受け取る前に接続が切れる場合です。接続エラーだけでは、プラットフォームがジョブを受理したかわかりません。

SpicyAPIには実際のサーバー側保護として、任意のIdempotency-Keyヘッダーがあります。同じアカウントと同じAPIキーで、正規化されたモデル、入力、コールバックURLが同じリクエストを24時間以内に同じキーで繰り返すと、資金を再確保せず元のタスクを返します。変更したリクエストは、そのキーと競合します。同じアカウントに属する別のAPIキーでも、この対応関係を再利用できません。元のタスクIDを開示せず、競合が返ります。

HTTP試行ごとではなく、顧客が依頼した画像に対して安定したキーを作ります。アプリが生成するproject-8-image-12-v1のような値が考え方を示します。個人情報やプロンプト原文は入れないでください。最初の作成リクエストを送る前に生成して保存します。ネットワークの再試行では再利用し、本当に新しい画像には新しいバージョンか操作IDを与えます。

最小限の復旧手順は次のとおりです。

1. 意図した画像操作、元のリクエスト本体、キーをアプリに保存する。
2. Idempotency-Keyを付けて送信する。
3. 確認が失われたら、ローカルの操作を確認待ちとする。
4. 同じAPI認証情報で、変更しない本体とキーを再送する。
5. 返ったタスクIDを保存し、状態の確認に切り替える。

復旧中は、実際に送ったリクエストを固定します。顧客が変更したかもしれないUIの設定から作り直さないでください。近いポートレートから広い構図に変える、解像度を上げる、プロンプトを変える、コールバックURLを変えるなら、もはや元の送信ではありません。

保護には限界があります。24時間は、アプリの重複防止情報を永久に保存する期間ではありません。期間後、古いキーの再利用で昔のジョブを復旧できると思わないでください。後日の復帰には、自分で永続的に保存する操作とタスクの対応が必要です。受理が不明のまま元のジョブを特定できなければ、自動で代替を作る前にアカウントのタスク記録を照合するか、サポートに相談します。

生成ボタンの無効化は役立つが、それだけでは足りない

読み込み中のボタンを無効にすると、よくある連続タップを防げます。ブラウザーの2つのタブ、再接続するモバイルクライアント、バックグラウンドワーカー、サーバー再起動による重複送信は防げません。

アプリは、それらのイベントを1つの論理的な画像操作に結び付けるべきです。自分のデータベースの一意性ルールで、2つのワーカーが同じ操作を独立して取得するのを防ぎます。プラットフォームの冪等キーは、リモートの作成境界を保護します。これらは別の保護であり、ジョブの送信経路が複数あるアプリでは両方が必要です。

会話後に任意で新しいキャラクターポートレートを生成するコンパニオン製品を考えます。その自動リクエストの確認前に、利用者が手動のポートレートボタンも押します。両方が同じ画像の依頼を満たす意図なら、1つの操作に結び付けます。手動ボタンが明示的に2つ目のバリエーションを求めるなら、別の有料生成であると表示します。意図的な2件の購入を黙ってまとめたり、1つの約束に黙って2回課金したりしないでください。

何を同じ依頼とするかという製品の意味を、キー自体は決めません。アプリが判断します。また、送信クライアントが復旧のたびに新しいリモートキーを付けるなら、ローカルで重複排除したデータベース行も役立ちません。値は経路全体で維持される必要があります。

拒否、技術的失敗、気に入らない画像では請求が違う

成人向けコンテンツのリクエストには、いくつかの終わり方があります。失敗したNSFW生成は常に無料という一律の約束も、すべてのエラーが課金されるという逆の主張も避けましょう。

タスクの状態と、創作上の満足は別です。確定した記録と、モデル別の課金例外を確認してください。

SpicyAPIはタスク受理時に、見積もり額を確保します。settledがfalseの間、タスクのcostは確保した見積もりです。精算後は最終課金を表します。成功したタスクは確保額までの範囲で課金され、未使用分は解放されます。

失敗または期限切れのタスクは、通常、確保額を解放します。返金ポリシーには、拒否・失敗リクエストが課金されるとページに記載されたモデルや、中断前に提供した使用分など、例外があります。モデルが拒否した画像タスクでは、そのモデルの課金注記と最終精算記録を確認します。HTTPエラーだけでアカウント残高を説明しないでください。

成功しても弱められた画像は別です。特定の成人向けエディトリアル場面で、堂々とした架空の成人キャラクターを求めたのに、普通のポートレートが届いたとします。タスクが成功して結果を提供したなら、場面への不満だけで返金対象の技術的失敗にはなりません。間違った髪型、不要なアクセサリー、好みでない表情も同じです。

だから、役立つ再試行方針には、ネットワークの再試行回数だけでなく、創作支出の上限が必要です。アプリが気に入らないすべての画像を再試行するワーカーは、技術的問題を解決した後も、成功した出力を買い続けるかもしれません。

使う正確なタスクのモデルページを読んでください。制限の少ないテキストから画像生成経路でも、編集経路が同じ挙動とは証明できず、系列名だけであらゆるNSFWリクエストを予測することもできません。成人キャラクターと、提出する権利のある素材だけを使います。再試行は、許可されないリクエストを受理可能にする方法ではありません。

終端の失敗を再試行すると、新しい作業が生まれる

APIにはPOST /api/v1/jobs/retryもあり、元のタスクIDを受け取り、再試行可能な終端の失敗から新しいタスクを作ります。古いタスクを実行中に戻すのではありません。現在のモデル入力、権限、可用性、残高、料金を再評価します。元タスクには保持された入力と完了した課金の照合が必要で、実行中や成功済みのタスクはこの再試行の対象外です。

元タスクを作成した同じAPIキーを使います。再試行の動作に冪等キーを付ける場合、そのキーはこの特定の新しい試行を保護し、元タスクの範囲で扱われます。再試行の操作を再送すると、その新しいタスクを復旧できます。元のタスクを復旧するために最初の作成リクエストを再送することとは違います。

制作者のアプリでは、料金を伴う新しい生成試行として表示します。プロンプトを変える必要があるなら、元タスクの再試行で変更できると期待せず、修正入力で新しいリクエストを作ります。失効した参照画像による失敗も、再度成功させるには利用可能な参照が必要です。元の課金の解放と、新しい試行の確保は別の記録です。

試行を繰り返すと、実際にいくらかかるか

3つの画像エンドポイントについて、現在の開始構成を示します。料金は生成の説明であり、すべての画像がNSFWの制作指示を満たす保証ではありません。

仮の計画例：意図的な創作試行$7.20に、偶発的な重複ジョブ$2.40が加わります。

細部が重要です。Z-Image Turboのプロンプト拡張オンは、1枚$0.010ではなく$0.016です。Seedream 5.0 Proの既定値は2Kで、1Kの$0.036ではなく$0.072です。解像度の段階を明示的に選ぶと、計算がジョブに合います。

Qwen Image 2.1の1Kポートレートを最終100枚作るとします。各最終画像に平均3回の課金される創作試行が必要なら、生成支出は100 × 3 × $0.024で$7.20です。確認処理の不具合で各最終画像の送信が1回ずつ重複すると、100 × $0.024 = $2.40が加わり、支出は$9.60になります。これらは計画例であり、測定した成功率ではありません。

HTTPのタイムアウトを変えても、3回の創作試行が1回にはなりません。偶発的な4回目は取り除けます。意図的なバリエーションと重複ジョブを別々に合計し、どの問題に支払っているかわかるようにします。

小規模な制作ワークフローなら、生成前に上限を決めます。たとえば、この特定の枠に初回1枚と修正2回。これはアプリの予算提案であり、プラットフォームの制限ではありません。3回すべてが同じ要件を外したら、ほぼ同じ依頼を買い続けず、方法を変えます。

完成したNSFW画像が意図と違うなら、重要な1点を変える

顔が正しく、部屋や服が違うなら、全く新しいテキストから画像生成より、対象を絞った編集が次の購入に合うかもしれません。役立つ結果を保持し、変更点を説明して、適切な編集タスクを持つモデルを選びます。編集にも費用がかかり、最初の生成に含まれる無料修正ではありません。

同じリクエストで弱められた場面が続くなら、まず内容による拒否、許容されたリクエストの控えめな解釈、詰め込みすぎたプロンプトのどれかを特定します。同一のプロンプトを繰り返し送っても、どれが起きたかわかりません。NSFWという単語を万能の切り替えと見なさず、届いた画像と、ある場合は安定したエラーコードを見ます。

直接的でない計画例として、ポートレートに、架空の成人キャラクター1人、暗いサテンのジャケット、座る姿勢、暖かな横光、整った部屋を求めるとします。毎回部屋が雑然となるなら、二次的なセットの細部を除き、人物と光の指示を残します。顔が違うなら、文章だけのプロンプトに形容詞を増やさず、適切な参照画像ワークフローへ移ります。

本当に新しいバリエーションが必要なら、新しい操作とキーを使います。最初に受理されたリクエストを元のキーで再送すると、最初のタスクを復旧します。モデルにもっと良い2枚目を想像させる依頼ではありません。新しいバリエーションでシードを変えたら、新しい創作試行として記録します。シードはリクエストの特定に役立ちますが、異なるモデルで同じ人物を保証しません。

数回の試行後は、広告の開始料金だけでなく、使える最終画像の費用を比較します。$0.010の生成を4回使えば$0.040、$0.024の生成を1回使えば$0.024です。この算術は2つ目のモデルがより確実という証拠ではなく、自分の制作指示で測るべきものを示しています。

既存画像のダウンロードが失敗した場合

ダウンロードエラーだけで、成功した画像を再生成しないでください。一時アクセスリンクが動かなくてもファイルが存在する場合や、アプリがコピー中に失敗した場合があります。

完了したタスクと出力素材の識別情報を保持します。出力の保持中に、現在の許可されたダウンロード経路を復旧し、その素材の転送を再試行します。別の署名付きメディアURLにAPIキーを付けないでください。顧客のライブラリーに「保存済み」と表示する前に、保存先に実際のバイト列があることを確認します。

メディア配信ガイドでは、管理するストレージに結果をコピーする方法を扱います。成人向けの制作者には、プライバシーの境界でもあります。生成画像や参照画像は、コピーが成功しただけで公開ギャラリー素材になるわけではありません。復旧でも、意図した非公開アクセスを維持すべきです。

元の出力がタスクに適用される保持方針ですでに削除されていれば、タスクIDで失われたバイトを復元することはできません。代替は新しい生成になり、見た目が違う可能性があります。古いポートレートを新しく課金した画像に黙って置き換えず、その違いを顧客に伝えます。

顧客の次の動作と、課金を一致させる

既存タスクの状態と確定課金を一緒に表示します。未解決のジョブは、プロジェクト内の場所を保持し、新しい有料再試行を唯一の進め方として出さないようにします。失敗したら理由と確保額が戻ったかを示します。成功したら、再ダウンロードと別バリエーションの生成を分けます。

サポートに役立つ証拠は、タスクID、利用可能ならリクエストID、日時、金額、短い問題説明です。異なるタスクIDが2つ作られたことと、1つのタスクに2回課金されたことは別です。返金ポリシーは、二重課金、確保額を超えた課金、成功扱いなのに未配信の出力、24時間以内に戻らない失敗タスクの確保額を報告するよう求めています。通常のログやサポートのスクリーンショットに、APIキー、署名付きメディアリンク、機微な制作プロンプトを入れないでください。

制作者が理解できる履歴は、見えないHTTP試行の一覧ではなく、「ポートレートを1枚依頼し、送信を1回復旧し、結果が1つ届いた」であるべきです。目指すのは、ネットワーク復旧が元の購入を保ち、新しい創作試行は料金が見える意図的な判断になることです。