Jewelry AI・失敗メッセージ
失敗の文はエラーを分類するもので、写真を診断するものではありません
実行が失敗しても、プロバイダー自身のエラーテキストが目に入ることはありません。そのテキストは3つのキーワード群と照合され、どれにも当たらないものには4つ目の結果が用意されています。画面に出る文は、この照合が決めています。
読んでいる文はキーワード照合で選ばれています
生成が失敗したとき、アプリはプロバイダーのエラーをそのまま目の前に置くことはしません。失敗のテキストは、キーワード群が含まれているかを調べて4つの結果のどれかを返す対応づけを通ります(store.tsx:2360-2375、確認日2026-08-18)。画面に出る文は、その結果です。
言い回しが自信ありげであると同時に曖昧にも感じられるのは、これが理由です。対応づけが分類しているのは文字列です。ジュエリーの写真も、モデルの写真も、アカウントも対応づけの入力ではないため、そこは調べられていません。
ここから2つの帰結が出てきます。まったく違う原因の失敗でも、テキストが同じキーワード群に入れば同じ文として届きます。そして、対応づけが探している語にたまたま何も当たらなかったというだけで、失敗が「generic」として届くこともあります。
4つの区分と、そこへ振り分けられるもの
中央の列はコードで使われている結果の名称、右の列はその正直な読み方として読んでください。対応づけは2026-08-18にstore.tsx:2360-2375で確認しています。
| 失敗のテキストに含まれる語 | 対応づけられる結果 | その結果が言っていること・言っていないこと |
|---|---|---|
| timeout、stuck-timeout、または「zaman asimi」 | timeoutRefunded | 失敗のテキストがタイムアウトに言及していたということです。サーバーが実際にどれだけ時間をかけたかは報告していません。 |
| nsfw、safety、blocked | contentBlocked | 失敗のテキストが安全性に関する語を持っていたということです。プロバイダーの安全性の層がなぜ反応したのかは、このページが述べられる範囲の外です。 |
| quota、rate limit、429 | serviceBusy | 失敗のテキストが割り当て量や制限に言及していたということです。待ち行列がどれだけ埋まっていたかは報告していません。 |
| 上の3つの群のいずれにも当たらない | generic | 失敗のテキストが、対応づけの探す語に何も当たらなかったということです。この文は原因をまったく持ちません。 |
4つの文それぞれの読み方
結果ごとに1行、そして4つすべてに続く判断を1行にしています。各行は、対応づけが支えている範囲のことだけを述べています。
| 状況 | 選択 | 理由 |
|---|---|---|
| タイムアウトの文が出た。 | 失敗のテキストにタイムアウトのキーワードが含まれていた、と読む。 | 「timeout」「stuck-timeout」「zaman asimi」がそこへ振り分ける文字列です(store.tsx:2360-2375)。この文は、サーバーが実際にかけた時間の測定値を持っていません。 |
| コンテンツがブロックされたという文が出た。 | 失敗のテキストが安全性に関する語を持っていた、と読む。 | 「nsfw」「safety」「blocked」がそこへ振り分ける文字列です(store.tsx:2360-2375、確認日2026-08-18)。プロバイダーの安全性の層がなぜ反応したのかは、この文が述べていることではなく、このページでも説明しません。 |
| サービスが混み合っているという文が出た。 | 失敗のテキストが割り当て量や利用制限に言及していた、と読む。 | そこへ振り分けるのは「quota」「rate limit」「429」です。サービスが実際にどれだけ混んでいたかは文に含まれておらず、ここでも主張しません。 |
| 一般的な文が出た。 | 何にも当たらなかった、と読む。 | 「generic」はどれにも当たらなかった場合の受け皿なので、失敗のテキストが3つのキーワード群すべての外にあったということだけを伝えます。 |
| 同じ作品をもう一度送信するかどうかを決めようとしている。 | 自分で決める。代わりにもう一度実行しようと待っているものはない。 | 1回の送信はプロバイダーの実行ちょうど1回であり、失敗すると返金されます(generation-queue.ts:39、確認日2026-08-18)。 |
どの文が出ても変わらないこと
失敗がどの区分に入ったかに左右されない4つの記述です。
- 実行は終わっており、そのクレジットは戻ります。
- 1回の送信はプロバイダーの実行1回で、自動の再試行はなく、失敗すると返金されます(generation-queue.ts:39、確認日2026-08-18)。
- ワーカーには再試行可能という区分がありますが、それは自分のジョブについてのものではありません。
- 再試行可能と分類されたプロバイダーのエラーは、送信をもう一度実行するのではなく、制限側のペナルティによって待ち行列を遅くします(model-generate-provider.ts:280-284、確認日2026-08-18)。この仕組みには専用のページがあり、ここでは導き直しません。下の関連ページを参照してください。
- まったく再試行できないと分類される結果もあります。
- 安全性によるブロック、応答が返らない場合、そして画像ではなくテキストとして返ってきた応答は、いずれもワーカー側で再試行不可と分類されます(model-generate-provider.ts:296, 310, 317、確認日2026-08-18)。
- リリースビルドが見せるのは、その文がすべてです。
- 対応づけを通っていないエラーの詳細が描画されるのは、開発ビルドだけです(result-screen.tsx:383-387、確認日2026-08-18)。
この文が誤って読まれる3つの形
どれも、分類が支えられない結論へ分類を押し広げてしまう読み方です。
コンテンツがブロックされたという文を作品への判定として読み、撮り直してしまう。
対応づけの入力は失敗のテキストであり、その結果へ振り分けるのは「nsfw」「safety」「blocked」という語です(store.tsx:2360-2375)。画像を見た結果の出力ではありません。
サービスが混み合っているという文を待ち行列の報告として読み、それを根拠にまとめての作業を止めてしまう。
そこへ振り分けるのは「quota」「rate limit」「429」です。メッセージもこのページも待ち行列の状態を述べていないため、それを根拠にした判断は何にも支えられていません。
一般的な文を、わざと伏せられた具体的なエラーとして読んでしまう。
「generic」は、どのキーワード群にも当たらなかったテキストの受け皿です。4つの結果という枠の中で、対応づけができるかぎり正確に答えた形です。
この文からは分からないこと
このページの境目を、推測に委ねずに限界として書いておきます。
- プロバイダーの安全性の層がなぜ反応したのか。プロバイダー側のモデルの内部の動きは、このページが確認も説明もできる範囲の外です。
- サーバーが自分の実行に実際にどれだけ時間をかけたのか、失敗した時点で待ち行列がどれだけ深かったのか。
- ワーカー側のどの結果がどの文を生んだのか。ワーカーの再試行可否の分類と、4つの区分によるメッセージの対応づけは別々の分類であり、ここには両者を結びつけるものが何もありません。
- 同じ写真が、2回目の送信では違う結果になるのかどうか。
- 返金がいくらにあたるのか、請求がどう動くのか。金額と方針はこのページでは扱いません。
- 透過のない背景削除の素通りが、4つの文のどれを生むのか。
よくある質問
失敗メッセージは、写真の何がよくなかったのかを教えてくれますか。
いいえ。メッセージは失敗のテキストに含まれるキーワードの照合で選ばれるので(store.tsx:2360-2375、確認日2026-08-18)、そのテキストがどの群に入ったかを報告しています。写真はこの判断の入力ではありません。
サービスが混み合っているというメッセージが出ました。待ち行列が長いということですか。
失敗のテキストに「quota」「rate limit」「429」のいずれかが含まれていたということです。それがその結果へ振り分ける条件です。サービスが実際にどれだけ混んでいたかは文に含まれておらず、このページも主張しません。
プロバイダー自身のエラーテキストを見ることはできますか。
リリースビルドでは見られません。対応づけを通っていないエラーの詳細が描画されるのは開発ビルドだけです(result-screen.tsx:383-387、確認日2026-08-18)。読めるのは対応づけられた文です。
背景削除が失敗を報告しました。その実行の料金は引かれたままですか。
失敗した実行はそのクレジットを返金します(generation-queue.ts:39)。背景削除では特に、透過のない状態で戻ってきた結果も失敗として扱われ、同じ規則で返金されます(background-remove-provider.ts:10)。その結果にどの文が付くのかは、このページが述べられることではありません。