2026/08/09

Seedance 2.5 のコンテンツフィルタリング：拒否原因の診断

送信レスポンス、タスクエラー、ルーティング設定、確定使用量から Seedance 2.5 の拒否原因を切り分け、パラメータ検証と安全審査を区別する方法。

Seedance 2.5 のリクエストが失敗したとき、最初に確認すべきなのは失敗の時点です。タスクが作られる前に API が入力を拒否したのか、それとも作成済みの非同期タスクが後から安全性チェックに失敗したのか。レスポンスには、この 2 つを切り分ける材料がすでに含まれています。

ここでは、実際に確認できるルート、リクエスト項目、タスク状態、エラーコード、確定使用量だけを使って診断します。別のホストの挙動を当てはめたり、制限の少ないルートを「無検閲モデル」と扱ったりはしません。

TL;DR

経過時間より先に、タスクが作成されたかを確認します。 同期的な 400 は、タスク作成前の入力検証で失敗したことを示します。作成済みタスクが後から failed になった場合は、error と usage を確認します。^[2]^[3]
content_filter: false は「フィルターなし」という意味ではありません。 reAPI では Flexible チャネルを選ぶ設定で、料金は変わらず、上流のポリシーチェックも残ります。^[2]
エラー 80006 だけでは審査段階を特定できません。 プロンプト、参照画像や動画、生成結果のいずれが原因の場合もあります。^[3]
終端タスクの請求を確認します。 失敗したタスクの usage.credits を見れば、予約分が全額返却されたのか、生成後の料金が残ったのかが分かります。^[3]^[4]
モデルの上限も重要です。 Seedance 2.5 は 1 回で最長 30 秒を生成し、参照素材として画像 30 枚、動画 10 本、音声 10 本まで受け付けます。^[1]

ルートの違いを記録すべき理由

同じモデルでも、提供経路によって入力検証やルーティングは変わります。reAPI の content_filter は上流モデルのパラメータではなく、明示的なルーティング設定です。既定値は true。API を直接呼び出す場合は false で制限の少ない Flexible チャネルを選べますが、安全性審査そのものは無効になりません。^[2]

診断では、次の 4 段階を分けて考えます。

同期的なリクエスト検証。 項目の誤りや未対応メディアは、タスクが作られる前に HTTP エラーになります。
ルート選択。 有効なリクエストは、content_filter などモデル固有の設定に応じたチャネルへ送られます。
非同期タスクの実行。 タスクは processing を経て、completed または failed になります。
安全性による失敗。 80006 はプロンプト、参照素材、生成結果の拒否をまとめて表すため、コードだけではどの審査が反応したか分かりません。^[3]

これは API から観測できる段階の整理であり、すべてのホストが同じ内部構成を持つという主張ではありません。

失敗箇所を絞り込む 5 つの確認

以下はすべて API が公開する項目で確認できます。わざと禁止対象のプロンプトを送る必要はありません。

確認 1：送信時にタスクが作成されたか

POST の HTTP ステータスとレスポンス本文を保存します。2xxxx 系エラーを伴う同期的な 400 は入力検証の失敗なので、示された項目またはメディア形式を直します。レスポンスにタスク ID があれば送信は通っており、その後の診断対象はタスクレコードです。^[2]^[3]

経過時間は補助情報にはなりますが、どの内部コンポーネントが判断したかを証明するものではありません。

確認 2：ルートとルーティング項目を残す

エンドポイント、正確なモデル ID、完全なペイロード、content_filter の値を記録します。reAPI では、この項目を省略すると true、false にすると Flexible チャネルです。値を残さずに結果を比べると、別ルート同士を比較することになります。^[2]

確認 3：参照素材の入力条件を照合する

所有している、または処理許可を得た素材だけを使います。すべての URL が公開 HTTP(S) であること、実際のファイル形式が対応対象であること、画像・動画・音声の数が文書上の上限内であることを確認してください。未対応メディアは同期的に 400 を返すため、モデルによる審査拒否とは区別すべきです。^[2]

確認 4：終端タスクのエラーを読む

GET /api/v1/tasks/{id} を completed または failed になるまでポーリングします。失敗したら error.code、error.message、タスク ID、元のリクエストを記録します。80006 はコンテンツポリシーによる失敗を示しますが、プロンプト、参照素材、生成結果のどれが原因かまでは示しません。^[3]^[4]

確認 5：確定使用量を読む

同じ終端タスクの usage.credits を確認します。ゼロなら予約分が返却され、正の値なら文書にある生成後料金が残っています。エラーメッセージだけから請求額を判断しないでください。^[3]^[4]

エラー 80006 だけでは原因を特定できない

公開エラー仕様では、複数の安全性結果を 1 つのワークフローコードにまとめています。80006 はプロンプト、参照画像、参照動画、生成結果のどれでも発生し得ます。^[3] このコードだけでは、ホストがプロンプトを書き換えたこと、特定の顔分類器を使ったこと、しきい値を変更したことの証拠にはなりません。

同じペイロードをそのまま再送しないでください。まず慎重な表現に直し、各参照素材を確認します。モデルが対応し、API を直接呼んでいる場合は、content_filter: false で制限の少ないルートを試せます。ただし、安全性審査が停止するわけではありません。^[2]^[3]

確認できるルートとパラメータの仕様

ルートは非同期です。 POST /api/v1/videos/generations に送信し、返されたタスク ID を保存して、GET /api/v1/tasks/{id} をポーリングします。ポーリングは credits を消費しません。^[2]^[4]

content_filter はモデル固有のルーティング設定です。 reAPI の Seedance 2.5 ルートでは true が既定値です。false はチャネルを変えますが料金は変えず、そのルートでもタスクが失敗する可能性はあります。^[2]

現在の reAPI の解像度は 480p、720p、1080p です。 他社のより広い解像度表記に依存する前に、返却ファイルを確認してください。^[2]

参照素材の上限は明記されています。 画像 30 枚、動画 10 本、音声 10 本まで受け付けます。ByteDance の発表資料にも同じマルチモーダル参照容量が記載されています。^[1]^[2]

ByteDance Seed. One-take Creation, Flexible Referencing: Introducing Seedance 2.5. Published 31 July 2026, retrieved August 2026 from seed.bytedance.com/en/blog/one-take-creation-flexible-referencing-introducing-seedance-2-5
reAPI. Seedance 2.5 API — route, request parameters, reference limits, content_filter, task flow, and refund behavior. Retrieved August 2026 from reapi.ai/docs/seedance-2-5
reAPI. API errors — validation codes and 80006 content-policy handling. Retrieved August 2026 from reapi.ai/docs/api/errors
reAPI. Tasks API — status, settled usage, polling, and output contract. Retrieved August 2026 from reapi.ai/docs/api/tasks