Seedance 2.5のエラー・待機列・タイムアウトを切り分ける方法

Seedance 2.5で動画を生成できないとき、最初にVPNやキャッシュ削除を試す必要はありません。まず、どの入口を使ったか、履歴またはtask IDが残ったか、どの段階で止まったかを確認してください。同じ「Generation failed」や「タイムアウト」でも、送信前の拒否、正常な待機、モデル実行の失敗、完成動画の受け取り失敗では対処が変わります。

Dreaminaの2.5と公式APIの2.0を分ける

Dreamina公式のSeedance 2.5ページでは、2.5がAI Videoで選べるモデルとして案内されています。一方、現行のBytePlusタスク作成リファレンスが明記している動画API能力はSeedance 2.0シリーズです。Dreamina 2.5の履歴表示へ2.0 APIのraw状態をそのまま当てはめたり、第三者の「2.5 API」という表記だけで同じモデル・待機列・エラー契約だと判断したりしてはいけません。

画面上のモデル名、入口URL、アカウント、入力モードを保存します。消費者向けUIは生成履歴、APIはtask IDが受理の手掛かりです。この区別があれば、ブラウザ表示のタイムアウトとAPIの終端状態expiredを分けられます。

生成履歴自体がない場合は、CapCutのAIアクセス診断に沿って地域、クレジット、会員状態、アプリ版、ブラウザ互換性を別々に確認します。Thinkingのままなら、CapCutの案内は負荷、入力の複雑さ、通信、利用上限、セッションを分けています。これは一般的なUI診断で、Seedance 2.5の待機時間保証ではありません。

まず1分で確認すること

次の順番なら、原因を決めつけずに次の一手を選べます。

1. 入口を記録する：Webアプリ、第三者プラットフォーム、ComfyUI、公式Ark API、別のAPI事業者のどれか。
2. タスクIDを探す：履歴、開発者ツール、APIレスポンス、ジョブログを確認する。
3. 状態をそのまま保存する：queued、running、succeeded、failed、expired、または画面に出た日本語の全文。
4. 時刻と条件を残す：タイムゾーン、モデル/モード、参照素材の有無、Request ID、課金履歴の表示。

一つの入口のエラーだけではSeedance全体の障害は証明できません。各入口が正常とも限らないため、現在状態はその入口の通知とサポートで確認します。

「Seedance 2.0」ではなく利用入口を固定する

ByteDanceの公式発表は、Jimeng、Doubao、Volcengine Arkを体験入口として案内しています。実際には第三者サービスやComfyUIから利用するケースもあります。同じモデル名でも、アカウント、キュー、料金処理、エラー文、サポート担当は入口ごとに異なります。

たとえば、ある第三者サービスが「model unavailable」と表示しても、わかるのはそのサービスからモデルへ到達できなかったことまでです。ByteDance側の停止、第三者側の認証切れ、そのアカウントの利用権限、同時実行制限のどれかは、タスク情報がなければ決まりません。

画面を閉じる前に、URL、アプリ名、バージョン、プラン、モデル名、モードをメモしてください。ComfyUIならインストール形態とノード名、APIならbase URLとendpointも必要です。APIキーそのものは保存資料やスクリーンショットに含めません。

タスクIDが分岐点になる

タスクIDが発行されていない

この段階を「キューが遅い」とは呼べません。考えるべき場所は送信前です。

• セッション切れ、ログイン失敗、モデル利用権限の不足
• 残高やアカウント側の制限
• 参照ファイルのアップロード失敗
• endpointが受け付けないパラメータや入力の組み合わせ
• 安全審査、実在人物の参照、権利確認
• ブラウザ、拡張機能、社内ネットワークによる送信遮断

WebならNetworkタブと履歴、APIならHTTPステータスとレスポンス本文を確認します。HTTP 400や429だけで原因を決めないでください。Volcengine Arkの公式エラー一覧は、パラメータ、認証/権限、レート、クォータ、キュー上限、過負荷、内部サービスを別のクラスとして扱っています。

queued または running

公式Ark APIのタスク仕様では、queuedとrunningは処理途中です。終端状態はsucceeded、failed、expiredです。したがって、queuedを見ただけで「生成失敗」と判断して再送しないでください。

やることは、同じIDを入口の仕様に従って再取得することです。履歴に更新時刻があるなら保存し、画面表示とAPI状態が食い違う場合は両方を記録します。Arkの優先度は同一Endpoint内の順番にだけ作用し、実行中のタスクを割り込ませるものではありません。また、Arkの期限設定を消費者向けアプリの待ち時間に読み替えることもできません。

固定の「何分待てばよい」という答えはありません。サービスが示す期限、状態更新、キャンセル/課金規則を使います。それらを公開していない入口では、勝手な再送よりサポート確認のほうが安全です。

failed または expired

ここで必要なのは、翻訳した要約ではなく正確な失敗コードです。APIならerror.code、error.message、Request IDをコピーします。UIしかない場合は、全文とタスク履歴を保存し、サポートに内部コードの確認を依頼します。

同じHTTP 429でも、短時間のリクエスト過多、利用クォータ、待機タスク数の上限は別問題です。実在人物を含む入力のprivacy/policyエラーと、サーバー過負荷も対処が異なります。「もう一度試してください」という表示だけで、プロンプト、回線、サーバーのどれかに決めないことが重要です。

同じ入口で最小canaryを1回だけ実行する

最小canaryは品質テストではなく、入力依存か入口依存かを分けるためのものです。

1. 同じアカウント、同じURLまたはendpoint、同じSeedance 2.0モードを使う。
2. 参照画像、参照動画、音声をすべて外す。
3. 白い紙の風車が机の上でゆっくり回る。固定カメラ。のような中立で単純なテキストだけにする。
4. その入口が提供する最短時間と標準または低い解像度を選ぶ。
5. 1回だけ送信し、ID、状態、正確なエラー文、課金表示を保存する。

canaryも同じコードで失敗するなら、元の長いプロンプトを何度も書き換える根拠は弱くなります。新しい変数がないまま再送せず、証拠をまとめて入口のサポートへ進みます。

canaryが成功したら、参照画像、動画、音声、複雑な動作の順に1項目ずつ戻します。初めて同じ失敗が再現した要素が、次に調べる対象です。この手順は原因を絞る方法であり、成功を保証するものではありません。この記事の作成時に読者のアカウントで実生成したわけでもありません。

Generation failedを入力別に読む

パラメータとモード

Arkの現行仕様はbody parameterの厳格な検証を案内しており、未対応値は入力方法によって無視または拒否される場合があります。model ID、時間、解像度、ratio、入力種別を、実際に使うendpointの文書と照合してください。別のプラットフォームのパラメータ表をコピーしても検証にはなりません。

参照素材と実在人物

ByteDanceの発表では、Seedance 2.0はテキスト、画像、動画、音声を扱い、実在人物の肖像を参照する場合は本人確認または事前の適法な許諾が必要です。テキストcanaryは通るのに人物参照で失敗する場合、フィルターを回避する言い換えは行わず、その入口の本人確認フローか権利を持つ別素材を使います。

ComfyUIでは、AI生成ポートレートと実在人物で手順が異なります。詳しい権利・確認の分岐はSeedance 2.0 APIの実在人物ルールに分けています。

プロンプトまたは素材の複雑さ

canaryが成功したときだけ入力を疑います。一度にプロンプト短縮、ファイル圧縮、別回線、別モデルを全部試すと、何が効いたかわかりません。参照を1つずつ戻し、正確なコードが変わるかを見ます。結果品質の崩れと、タスク自体のfailedも別の問題です。

ネットワークエラーを4つの通信区間に分ける

「ネットワークエラー」は原因ではなく表示ラベルです。次のどこで止まったかを確認します。

1. アップロード

ファイルの進捗が始まらずIDもない場合、小さなファイルとテキストのみを比較します。この区間では、別回線、DNS、社内フィルター、proxy/VPN、ブラウザ拡張、request sizeの確認に意味があります。ただし一度に一つだけ変更します。

2. タスク作成

POSTがIDを返さない場合、HTTPステータスと本文を保存します。認証、残高、パラメータ、安全審査を一般的なネットワーク障害にまとめないでください。

3. 状態取得

IDがあるのに画面が止まった場合、履歴または取得APIで同じタスクを確認します。ブラウザのセッションや第三者サービスのpollingが止まっても、上流タスクが動いている可能性があります。元のIDを確認する前に再送しません。

4. 結果取得

backendが成功を返しているのに動画を開けない場合、結果URL、リンクの有効期限、CDN、認証、メディアドメインのブロックを確認します。これは生成済み動画の配信問題であり、モデルのGeneration failedとは異なります。

「同じ入口・同じアカウント・同じ最小入力」で回線だけを変え、結果が再現性をもって変わったときに初めてローカルネットワーク仮説が強くなります。変わらなければ、VPNやキャッシュ削除を続けても診断材料は増えません。

ComfyUIで止まる場合

ComfyUIの公式日本語ドキュメントは、APIノードの利用に正しいログインと許可されたネットワーク環境を求めています。テンプレートにノードがない場合は、stable/nightlyの差や起動時のimport failureも確認対象です。ノードが存在しない問題をプロンプト変更で直すことはできません。

記録する項目は、ComfyUIのバージョン、Desktop/Cloud/portableなどの形態、workflow名、ノード名、execution errorです。AI生成ポートレートが保護対象の実在人物として分類された場合、公式文書はReal Human workflowへの切り替えを案内しています。本人確認を迂回する方法ではありません。

API利用者はコードとRequest IDを優先する

公式Ark APIでは、作成リクエストと状態取得リクエストが分かれています。queued/runningなら同じIDを取得し続け、failedならerror objectを読みます。第三者APIを使う場合、その事業者のstatus名、polling、期限、課金ルールだけを適用してください。

開発者がAPI経路そのものを必要としている場合に限り、laozhang.aiはSeedance 2.0の非同期APIを文書化しています。ただし、すべてのアカウントで有効とは限らず、そこで使うsubmittedやin_progressなどの状態は事業者の契約です。JimengやDoubaoのUI障害を直す方法でも、ByteDance全体の稼働証明でもありません。

API経路を比較する段階ならSeedance 2.0 APIプロバイダー比較を参照し、料金・クレジット・優先キューはSeedance 2.0の料金ガイドで現在条件を確認してください。排障記事に変動しやすい価格を固定して載せると、原因切り分けを誤らせます。

再送を止めてサポートへ渡す基準

最小canaryが同じコードで再現し、新しく比較できる変数がなければ、連続再送を止めます。問い合わせには次を添えます。

• 利用URL/アプリ/API事業者、アカウントの地域と利用区分
• 発生時刻とタイムゾーン
• モデル、モード、主要パラメータ
• エラー全文、正確なcode、Request ID
• タスクID、最後の状態、最終更新時刻
• 参照なしcanaryの結果
• 画面上の予約、消費、返却表示（返金を推測しない）
• 秘密情報を消したスクリーンショット

APIキー、cookie、決済情報、私的な人物画像、公開できないプロンプト全文は送らないでください。サポートが安全な提出経路を指定した場合だけ、必要最小限の素材を渡します。

別の入口やモデルへ切り替えるタイミング

次のどれかを確認してから切り替えます。

• その入口が自分のアカウントにモデル利用権限を提供していない
• 同一入口のcanaryがroute-specificなコードで再現する
• 必要なworkflowが現在の統合にない
• サポートが入口固有のインシデントを確認した
• その入口の期限、同時実行、監視方法が制作要件に合わない

一般利用者にとって、APIへ移ることは最初の修正ではありません。開発者も、入口を変える前に元タスクの状態と課金履歴を保存します。入口を変えて成功しても証明できるのは「別経路では通った」ことまでで、元の失敗がローカル回線だったとは限りません。

覚える順番は、入口 → タスクID → 停止段階 → 正確なコードです。queuedとrunningでは元タスクを追跡し、failedではerror objectを読み、成功後のネットワークエラーでは配信経路を調べます。この順番なら、一般的な表示に振り回されず、待つ・入力を直す・通信を調べる・サポートへ渡すを区別できます。