Seedance 2.0で顔を使う前に：実在人物、本人確認、拒否時の安全な判断

2026年6月12日時点で、Seedance 2.0の顔まわりの依頼は、プロンプトを書く前に「誰の顔か」「同意があるか」「どのルートが確認を担うか」を決める必要があります。架空人物や一般的な人物像は通常のクリエイティブ作業として扱えます。自分の顔、従業員、俳優、顧客、モデルの顔は、実在人物の確認を扱えるルートが必要です。著名人、公人、無断のそっくり顔、顔検出の回避を前提にした依頼は、素材をアップロードする前に止めるべきです。

顔の依頼	最初の判断	安全な次の行動
架空人物、汎用的な人物、識別不能なキャラクター	作成できる	実在人物を示す名前や特徴を入れず、一般的な人物表現に保つ。
自分の識別可能な顔	確認が必要	実在人物確認をサポートするルートを使い、確認記録を残す。
俳優、従業員、顧客、モデルの顔	同意後に確認	用途への許諾を得てから、real-human asset または確認済みプロバイダールートを使う。
顔の参照画像が拒否された	再分類する	架空人物、本人、許諾済み人物、公人、またはそのルート非対応のどれかを判定する。
著名人、公人、無断の似顔	停止する	名前を伏せた近似顔、同じ雰囲気、顔検出回避の表現に置き換えない。
回避方法を知りたい依頼	停止する	許可された架空人物または確認済み実在人物ワークフローへ変更する。

Seedance 2.0における「顔」の分け方

Seedance 2.0は人物を扱えないモデルではありません。ByteDance Seedのモデルページは、Seedance 2.0をテキスト、画像、音声、動画参照を使えるマルチモーダルな音声動画生成モデルとして説明しています。公式発表でも、主体の一貫性、カメラワーク、動き、編集、参照制御が強調されています。つまり、架空の医師、広告の出演者風キャラクター、街頭インタビュー風の人物など、実在人物を指さない表現は通常の映像制作に含められます。

境界が変わるのは、顔が特定の実在人物に結びつくときです。社員の顔写真、顧客の自撮り、俳優のポートレート、著名人に似た顔、SNSで知られる人物の顔は、単なる「雰囲気の参照」ではありません。同意、肖像権、用途、本人確認、素材の状態、保存期間、削除依頼、サポート先が関わります。ここを曖昧にすると、「画像参照に対応している」ことを「どんな顔でも使える」と誤解しやすくなります。

したがって最初の質問は「顔を入れたい」ではなく、「この顔は誰のものか」「その用途に同意があるか」「確認済みルートはどれか」「拒否されたら何を止めるか」です。あるルートは画像参照を受け付けても、実在人物の顔は拒否するかもしれません。あるサービスは確認済み顔を扱えても、それはそのサービスの同意・本人確認システムの範囲です。モデル性能と肖像利用の許可は別の問題です。

実在人物の顔で検討できる現在のルート

識別できる人物を扱うなら、プロンプトの工夫ではなく、同意、確認、素材状態、許容用途を説明できるルートを選ぶ必要があります。誰がルート所有者なのか、どのアカウントで確認したのか、素材が承認済みなのか、失敗時にどこへ問い合わせるのかを先に決めます。

ルート	支えられること	証明しないこと
BytePlus real-human asset library	Seedance 2.0向けの実在人物アセット処理。許諾招待、本人確認、素材アップロード、承認済みアセット、Asset ID利用を含む。	すべてのアカウント、地域、入口が任意の顔をそのまま受け付けるという意味ではない。
ComfyUI Seedance 2.0 Real Human	ByteDanceの一回限りの本人確認、Group ID / Asset ID、実在人物動画ワークフローを記載するパートナーノード。	ComfyUIのルートを示すもので、公開API全体の回避手段ではない。
HeyGenなどのプロバイダールート	プロバイダーが独自の同意、本人確認、データ処理を組み合わせて顔利用を提供する場合がある。	プロバイダーの主張はBytePlus、ComfyUI、他ルートの第一者証明ではない。
通常のSeedance生成	架空人物、識別不能な人物、一般的なキャラクター表現。	実在人物の肖像許諾システムではない。

同意招待から確認済みAsset IDまでのreal-human assetワークフロー

BytePlusのreal-human asset文書は、productionで使いやすい順序を示します。アカウント側で許諾招待を作り、本人または権利者が用途を確認し、本人確認を完了し、素材をアップロードして承認状態にし、Asset IDをModel Playgroundまたは動画生成APIで使います。重要なのは、顔が自由な画像ファイルではなく、同意、状態、用途、ルート所有者を持つ管理対象入力になることです。

ComfyUIのSeedance 2.0 Real Human文書も同じ考え方をワークフローとして示しています。ByteDanceの本人確認、アセット処理、Group IDまたはAsset IDが前提です。ComfyUIを使うなら、ルート名、必要な確認、アセット番号、サポート先を記録します。これを「すべての公開入口で実在人物の顔が使える」という話に広げないでください。

HeyGenはプロバイダールートの例として有用です。Seedance関連ページでは、同意と本人確認の仕組みを通じたverified human facesを主張し、公開APIの扱いとは区別しています。ただし、利用前にはその時点の規約、データ処理、返金、課金、サポート、アカウント資格を読む必要があります。プロバイダーの強い表現は、そのプロバイダー内の契約として扱います。

BytePlusのreal-human assetを使う順序

実在人物の顔を本番に入れるなら、順序は「許諾、本人確認、素材状態、生成」です。順序を飛ばすと、技術的な失敗だけでなく、同意と監査の失敗になります。

ルート所有者のアカウントで許諾招待を作成する。
俳優、従業員、顧客、権利者に用途を確認してもらう。
livenessなどの本人確認を完了する。
ルートの要件に沿って素材をアップロードし、承認状態を確認する。
承認済みAsset IDを、許諾された用途とルート内だけで使用する。
誰が、いつ、何の用途で、どのアカウントに対して許諾したかを保存する。

この流れは「自撮りを入れて試す」より遅く見えます。しかし、その遅さが安全性です。制作側には同意記録が残り、プラットフォームには確認境界ができ、開発者には失敗時に調べる素材状態があります。後で拒否が出た場合も、ルート、アカウント、アセット状態、拒否メッセージ、サポート先を順に見られます。

Asset IDを普通の参照画像リンクとして扱わないでください。確認済み実在人物アセットは管理対象の入力です。システムがプロンプト、元画像、生成動画、アセットIDを保存するなら、アクセス権、保存期間、削除手順、サポート担当も決めておく必要があります。

顔参照が拒否されたときの判断

顔参照の拒否は、フィルターを避ける合図ではありません。入力とルートの不一致を見直す合図です。

Seedance 2.0で顔参照が拒否されたときの安全な判断マップ

次の順序で分類します。

拒否された入力	行うこと	行わないこと
一般的なキャラクタースケッチ、識別不能な雰囲気参照	プロンプトを簡潔にし、実在人物を示す語を外す。	実在人物名、著名人風、本人らしさを加える。
自分の顔	実在人物確認に対応するルートへ移す。	自撮りを何度も切り抜き、加工し、通るまで試す。
俳優、顧客、従業員	書面同意、ルート資格、確認状態を確認する。	チャット上の許可だけでプラットフォーム利用を済ませる。
著名人または公人	停止するか、明確な架空人物に変える。	似た顔、同じ雰囲気、名前を出さない近似顔を頼む。
プロバイダーが確認済み顔を主張する	現在の確認、データ、返金、サポート条件を読む。	同じ主張をBytePlusやComfyUIにも適用する。
理由不明で繰り返し拒否される	非機密のテスト素材で再現し、ルート所有者へ問い合わせる。	検出を避けるための加工やプロンプトを探す。

最低限の記録には、ルート、アカウント、入力タイプ、人物が識別可能か、同意の有無、確認状態、正確な拒否メッセージ、安全なfallback、最終判断を含めます。これにより、通常の非対応、アカウント権限不足、素材状態不明、ポリシー拒否を分けられます。

公人と回避依頼は止める

BytePlusのcontent pre-filter FAQは、公人の顔、声、動画に似た出力をブロックする場合があると説明し、なりすまし、詐欺、欺瞞的なディープフェイクのリスク低減を目的にしています。ここで大切なのは、フィルターが万能ではないことです。検出されなかったことは、著名人や他人の顔を使ってよい証明にはなりません。

BytePlus Video Generation Model Servicesの条件は、安全フィルターの回避や迂回を禁止しています。productionでは、これは単純な停止ルールです。顔にグリッドを入れる、顔を分割する、検出信頼度を下げる、名前を伏せて似せる、何度も加工して試す、といった手順を公開作業にしないでください。

正当な業務目的があるなら、言い換えます。架空の人物、契約済みモデル、確認済み従業員、非識別キャラクターを使います。成果物が公人、同意のない顧客、混同しやすい似顔に依存するなら、生成に進めません。

開発者向けのproduction handoff

実在人物の顔生成は、単発のAPI呼び出しではなく監査できるワークフローとして設計します。実装がsubmit、poll、retrieveだけでも、受け入れ条件はもっと広いです。

Seedance 2.0の実在人物顔ワークフローのproductionチェックリスト

本番前に次を確認します。

確認項目	productionでの問い	残す証拠
ルート所有者	どのプラットフォームまたはプロバイダーが顔ワークフローを担うか。	URL、アカウント、規約、サポート先。
同意記録	誰が、何の用途で肖像利用を許可したか。	許諾記録、権利者確認、日付。
確認状態	アセットは確認済みか、単にアップロード済みか。	Asset status、Group IDまたはAsset ID、ルートメモ。
入力の扱い	顔写真、プロンプト、動画をどう保存するか。	保存期間、アクセス制御、削除手順。
テスト	非機密素材で同じルートを試したか。	テストプロンプト、想定結果、拒否時の挙動。
拒否時	顔が拒否された場合の安全なfallbackは何か。	分類手順、問い合わせ、ルート変更、停止判断。
課金と再試行	再試行や失敗分の費用を誰が負うか。	現在の課金説明、タスク記録。
停止ルール	受けない依頼は何か。	公人、なりすまし、無同意、回避依頼のルール。

日本語の現場では「自分の顔を入れたい」「顔検出を回避したい」「似ないから直したい」という言い方が先に出やすいです。これをそのまま実装タスクにせず、四つのカードに分けます。人物カードには本人、従業員、顧客、俳優、公人、架空人物を記録します。証拠カードには同意、本人確認、Asset ID、アカウントを記録します。ルートカードにはBytePlus、ComfyUI、プロバイダー、通常生成を記録します。失敗カードには拒否メッセージ、fallback、再試行費用、停止理由を入れます。

一般的なアクセス方法は Seedance 2.0アクセスガイドに分けて考えます。バージョン選択が問題なら Seedance 2.1 vs Seedance 2.0 を確認します。顔の判断では、肖像、同意、確認、拒否、停止ルールに集中します。

最初の安全なテスト

ルートが不明なら、最初から実在人物の顔を入れないでください。架空人物、合成参照、承認済みの内部テスト素材を使い、動き、構図、長さ、スタイルが目的に合うかを確認します。この段階では同意問題は解決しませんが、通常の動画生成の問題と顔ポリシーの問題を分けられます。

次に、許可された範囲で最小の実在人物テストをします。確認済みアセットを一つ、用途を一つ、短い出力を一つに絞ります。ルート、素材状態、プロンプト、設定、結果、拒否時の挙動、サポート先を記録します。成功時、失敗時、拒否時の扱いが分かるまで、顧客、従業員、俳優素材へ広げないでください。

高くつく失敗は、単なる生成失敗ではありません。同意が曖昧、プロバイダーの前提を誤る、サポート先がない、拒否画像を繰り返し上げる、削除や監査ができない、という運用の失敗です。ここを先に決める方が、あとからすべての動画を追跡するより安く済みます。

よくある質問

Seedance 2.0で自分の顔は使えますか？

選んだルートが実在人物確認をサポートしていれば、本人顔のワークフローにできます。自撮りをアップロードするだけでは不十分です。同意、確認、アセット状態、ルート記録を残してください。

従業員、俳優、顧客の顔は使えますか？

明確な許諾があり、real-human assetまたはverified likenessを扱えるルートでのみproductionに進めます。用途、権利者、確認状態、サポート先をまとめて保存します。

ComfyUIならSeedance 2.0で実在人物が使えるのですか？

ComfyUIはByteDance本人確認とアセット処理を含む特定のSeedance 2.0 Real Humanルートを記載しています。すべての公開入口が同じように使えるという意味ではありません。

HeyGenはすべてのSeedanceルートで顔が使える証明になりますか？

なりません。HeyGenはプロバイダー独自の確認済み顔ルートになり得ますが、その同意と本人確認の仕組みは他のルートに自動で移りません。

顔参照が拒否されるのはなぜですか？

識別可能な人物に適切な確認ルートがない、公人に似ている、同意がない、アカウントが非対応、参照方式が合わない、などが考えられます。まず顔とルートを分類します。

名前を出さなければ著名人風の顔は使えますか？

使うべきではありません。名前を伏せても肖像やなりすましの問題は消えません。公人、著名人、混同しやすい近似顔は停止するか、明確な架空人物に置き換えます。

顔制限を回避するプロンプトはありますか？

それは正しいワークフローではありません。拒否は分類、同意、確認、プロバイダー確認、または停止判断につなげるべきで、回避プロンプト探しにつなげません。

顔目的ならSeedance 2.1に変えるべきですか？

実在人物の確認問題を避けるためだけにバージョンを変えないでください。バージョン性能、アカウント入口、肖像許諾は別の問題です。ルート所有者の文書と同じタスクでのテストを分けて見ます。