Redditには、「Seedance 2.0 is Now Uncensored」という強いタイトルの投稿がある一方、「Seedance Models & Censorship - clearing up the confusion」のように、モデルと提供経路を分けて考えるべきだという議論もあります。
結論から言うと、Seedance 2.0/2.5をモデル名だけで「無検閲」または「NSFW対応」と断定するのは不正確です。少なくともAPIを組み込む側は、モデルの世代、実行チャネル、APIのルーティング設定、サービスの利用規約を別々に確認する必要があります。
開示：reAPIは、本稿で扱うSeedance 2.0/2.5への有料APIアクセスを提供しています。本稿ではReddit上の体験談を製品仕様の証拠として扱わず、公開ドキュメントで確認できるAPI契約と区別して記述します。
公開前の確認：cURL例は公開スキーマとの照合までで、有料の生成リクエストは実行していません。投稿者自身のアカウントで一度実行し、日時・最終ステータス・使用したモデルIDを記録してから公開してください。
まず「無検閲」という言葉をAPIの用語に分解する
「無検閲」はAPI仕様の用語ではありません。同じ言葉が、少なくとも次の異なる状態を指して使われています。
- Web画面がプロンプトを事前に拒否しない
- 人物を含む参照画像をアップロードできる
- ある提供経路の判定が、別の経路より緩やかに見える
- 生成モデルが依頼した表現を学習済みで、正しく描ける
- サービス規約上、その用途が許可されている
これらは同値ではありません。入力が受理されても非同期タスクの実行段階で失敗することがありますし、フィルターを通過してもモデルの能力不足で意図と違う映像になる場合があります。反対に、無害な人物参照や映画的なアクションが誤検知されれば、利用者には「モデルが検閲した」ように見えます。
Redditのタイトルは利用者が観測した現象を探す入口としては有用です。しかし、どのサイト、モデルID、時点、入力条件だったかが揃っていない投稿同士を、そのまま再現結果として比較することはできません。
Seedance 2.0と2.5で確認できるAPI上の違い
reAPIの公開仕様では、Seedance 2.0と2.5は同じ非同期エンドポイントを使います。ただし、モデルIDとcontent_filterのルーティングは同一ではありません。
| 項目 | Seedance 2.0 Standard | Seedance 2.5 |
|---|---|---|
| 主なモデルID |
doubao-seedance-2.0-face / doubao-seedance-2.0-fast-face
|
doubao-seedance-2.5-face |
| 出力尺 | 4〜15秒 | 4〜30秒、編集では-1を使用 |
| 解像度 | 480p / 720p / 1080p / 4K（Fastは480p / 720p） | 480p / 720p / 1080p |
content_filter既定値 |
true |
true |
falseの意味 |
互換性のあるFlexibleチャネルがあれば、その経路へ直接送る | Flexibleチャネルへ送る |
| フォールバック | そのリクエストには付かない | そのリクエストには付かない |
Seedance 2.0では、content_filter: falseを指定しても、互換性のあるFlexibleチャネルが利用できなければStandardチャネルが選ばれる場合があります。その場合、Standard側の安全判定は残ります。「falseを書けば必ず同じ挙動になる」というスイッチではありません。
Seedance 2.5では、falseはFlexibleチャネルを選ぶルーティング制御です。ドキュメント上、料金ティアを変える指定ではなく、フォールバックなしの単一試行になります。失敗時は予約分が返金され、再試行はクライアント側の責任です。
もう一つ見落としやすい点があります。これはreAPIが解釈するフィールドであり、上流の動画生成エンドポイントへそのまま渡すモデルパラメータではありません。したがって「Seedanceそのものに検閲解除フラグがある」と一般化すべきではありません。
content_filter: falseを安全な入力で確認する
以下はSeedance 2.5へ、ポリシーに抵触しない風景描写を送る最小のcURL例です。目的は表現上の制限を回避することではなく、リクエストの形と非同期処理を確認することです。
curl -sS https://reapi.ai/api/v1/videos/generations \
-H "Authorization: Bearer ${REAPI_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"model": "doubao-seedance-2.5-face",
"prompt": "雨上がりの石畳を進む青い路面電車。固定カメラ、自然な環境音、夕方の柔らかな光",
"resolution": "720p",
"size": "16:9",
"duration": 5,
"content_filter": false
}'
POSTは完成動画ではなく、idとprocessing状態を返します。取得したIDを使い、共通タスクAPIをポーリングします。
TASK_ID="task_..."
curl -sS "https://reapi.ai/api/v1/tasks/${TASK_ID}" \
-H "Authorization: Bearer ${REAPI_API_KEY}"
statusがcompletedになれば、output.video_urlsに出力URLが入ります。failedならerror.codeとerror.messageを記録します。ポーリング自体はクレジットを消費せず、失敗した生成タスクは自動返金される、というのが公開されているタスク契約です。
Seedance 2.0で同じ経路を確認する場合は、modelをdoubao-seedance-2.0-faceに替えます。2.0はdurationが最大15秒であること、Fast系では1080p/4Kが使えないことも同時に固定してください。
APIキーをソースコードや記事へ直接書かないでください。環境変数またはシークレット管理機能から読み込み、ログにもAuthorizationヘッダーを残さない構成にします。
「対応しているか」を再現可能に調べるテスト設計
フィルターの比較では、刺激の強いサンプルを大量に投げるより、変更点を一つに絞ったほうが原因を追えます。テスト用プロジェクトでは次の条件を固定します。
- モデルID、プロンプト、参照素材、尺、解像度、アスペクト比を同じにする
-
content_filterだけをtrueとfalseで切り替える - POST時のHTTPステータスとレスポンスを保存する
- タスクID、最終
status、エラーコード、完了時刻を記録する - 利用規約に適合する複数の境界例で繰り返し、単発の成功を一般化しない
境界例には、人物を含まない夜間シーン、舞台用の特殊メイク、接触のないスポーツ動作など、通常の制作で誤判定を受けうるものを使えます。実在人物の素材を扱う場合は、アップロード前に権利と同意を確認します。
判定結果は、少なくとも三段階に分けて読みます。
- 送信時に4xx：スキーマ、認証、残高、入力ファイルなどの同期エラーを先に疑う
-
受理後に
failed：errorの内容から上流拒否、パラメータ不整合、タイムアウトを分ける -
completedだが意図と違う：安全判定だけでなく、プロンプト追従や学習上の能力差も候補にする
この記録があれば、「このサイトは厳しい」という感想を、どのモデルIDと経路で何が起きたかという技術的な報告に変えられます。逆に、難読化やjailbreakで判定をすり抜ける試験は、原因分析を壊すうえ、利用規約にも抵触します。
content_filter: falseでも利用規約は消えない
ここが「NSFW対応」という表現で最も誤解される部分です。reAPIのcontent_filterドキュメントは実行経路を説明していますが、Acceptable Use Policyの例外を作るものではありません。
同ポリシーでは、未成年者の性的搾取、同意のない性的な肖像・ディープフェイク、性的暴力、露骨な性的コンテンツなどが禁止されています。著作権、プライバシー、実在人物の同意、上流プロバイダーの規約も別途守る必要があります。設定値が受理されたことは、素材の権利や用途の適法性をサービスが認定したという意味ではありません。
そのため、製品UIではcontent_filter: falseを「何でも許可」のように表示せず、例えば「Flexibleルート（AUP適用、フォールバックなし）」と説明するほうが実態に近くなります。監査ログには、利用者、タスクID、選択したルート、入力素材の同意記録を関連付けておくと運用しやすくなります。
reAPIを使う意味は、モデル名ではなくAPI契約を固定できること
Webサービスごとに画面、事前判定、モデルの表示名が違うと、拒否がどの層で起きたか追いにくくなります。reAPIではSeedance 2.0/2.5を同じPOST /api/v1/videos/generationsとGET /api/v1/tasks/{id}で扱い、モデルIDとcontent_filterをリクエストに明示できます。
これは「無制限」を保証する機能ではありません。実装上の利点は、入力条件とルーティング指定をログに残し、失敗を再現しやすくすることです。料金は変更されうるため、記事内の固定値ではなくSeedance 2.0モデルページとSeedance 2.5モデルページで、送信前に現在値を確認してください。
FAQ
Seedance 2.0は本当に無検閲ですか？
モデル名だけでは答えられません。Redditの報告は利用したサイトや経路に依存します。reAPIのStandardモデルではcontent_filterが既定でtrueで、falseは条件に応じてFlexible経路を選ぶ指定です。利用規約と上流側の制御は残ります。
Seedance 2.5でcontent_filter: falseにすると料金は変わりますか？
公開ドキュメントでは同一料金です。変わるのは実行経路と、フォールバックを付けないという実行条件です。最新料金はモデルページで確認してください。
content_filter: falseならNSFWコンテンツを生成してよいですか？
いいえ。フラグは許諾ではありません。reAPIのAUPは全ルートに適用され、露骨な性的コンテンツや同意のない性的肖像などは禁止されています。上流プロバイダーの規約と適用法も確認が必要です。
2.0と2.5を比較するとき、最初に何を固定すべきですか？
モデルID、入力素材、プロンプト、尺、解像度を固定し、最初はcontent_filterだけを変えます。POSTの受理と非同期タスクの完了を別々に記録すると、拒否された層を切り分けやすくなります。
まとめ
「Seedance 2.0 is Now Uncensored」というRedditの見出しは需要をよく表していますが、API実装の結論にはできません。Seedance 2.0/2.5のcontent_filterは、許可されるコンテンツの宣言ではなく、reAPI上の実行経路を選ぶためのフィールドです。
実装ではモデルID、ルーティング、タスク結果、AUPを分けて記録してください。Seedance 2.0 APIとSeedance 2.5 APIの仕様から始めれば、コミュニティ上の「無検閲」という曖昧な言葉を、再現可能なAPI条件へ置き換えられます。