scenario-moderation について
scenario-moderationは、Scenarioで生成がブロックされた原因を調べ、対処方法を選ぶスキルです。誤検知に対応するチーム向けに、プロバイダーのフィルター、チームのIP Detection、プラン制限、ブロックリストを区別します。
主な機能
- 01ジョブのエラーと費用情報の確認
- 02プロバイダーフィルターとIP Detectionの判別
- 03機能に応じた代替モデルの推薦
- 04代替モデルの費用見積もり
- 05プロンプトと音声の審査要因の説明
活用シーン
- 01画像や動画の生成拒否原因の調査
- 02誤検知に対する別プロバイダーのモデル試験
- 03チームのIP Detectionによるブロックの確認
MCP 対応
ScenarioのMCPツールを使ってジョブ、チーム設定、モデル情報を調べ、代替モデルの推薦、費用確認、試験を行う方法を説明します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ scenario-labs/ skills --skill scenario-moderationインストール後、Claude Code で/scenario-moderationを入力して読み込まれたか確認します。
詳細
Scenario の生成ブロック
概要
生成を停止させるゲートは3つあります。そのうち、プロンプトを読み取るのは2つだけです。コンテンツフィルターは Scenario ではなくモデルプロバイダー側で実行されるため、プロバイダーによるブロックは選択したモデルに固有のものであり、通常、同じプロンプトでもカタログ内の別のモデルでは通ります。IP Detection はチーム独自のゲートです。実行前にプロンプトと入力画像をスクリーニングし、組織の管理者が有効にします。モデルを切り替えても解除されません。プランとブロックリストによる制限は、プロンプトが判定される前にモデルを除外します。ブロックが発生したら、まずルーティングの問題として捉え、文言の問題として考えるのはその次にしてください。このスキルは、チームに作成する権利があるコンテンツに対する誤検知を扱うものです。プロバイダーが禁止するコンテンツを生成するためのものではありません。基本の流れについては scenario スキルを参照してください。ここで名前が挙げられている関連スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください
(npx skills add scenario-labs/skills --skill <name>)。無人で処理する場合は、ツールのスキーマに従って進め、不足している点を明示してください。
クイックリファレンス
| ステップ | 呼び出し |
|---|---|
| 実際のエラーを読む | job_id を指定して job_get を呼び出します。行には error と hint に加えて、modelId(除外するモデル)と cuCost(失敗した実行で請求された額)が含まれます。verbose=true を指定すると、そのジョブで実行された正確なプロンプトを含む metadata.input が追加されます。または、jobs_wait の行から error と hint を読み取ります |
| 請求額を確認する | まず job_get の cuCost を確認します。ポリシーによるブロックは通常返金され、失敗したジョブも補填されますが、モデレーションによって停止された xAI の生成は除きます(「シナリオ」を参照)。ただし、予約分がすぐに解放されるとは限らないため、後で start_date と end_date をそのジョブの日付に指定し、include=["usages"] を指定して usage を確認します。種類ごとの合計を読み取ってください(見出しの数値はプロジェクトの累計で、チームのゲートによるブロックは独立した IP Detection の行に表示されます)。請求が残っている場合は、job_id を添えてサポートに問い合わせます |
| チームのゲートを確認する | teams_list を呼び出します。チームの行には ipDetectionEnforcement が含まれます。disabled 以外の場合、知的財産権のリスクを理由とする拒否はチーム独自のポリシーによるもので、実行前に審査されています |
| 代替モデルを探す | 失敗したジョブの capability(テキストから画像へのブロックには txt2img、参照画像を使用する場合は img2img、静止画からアニメーションを生成するクリップには img2video)と、ユーザー自身の言葉を指定して recommend を呼び出します。コスト帯を維持するには、アセットあたりの失敗した行の cuCost より少し高めに max_cost_cu を設定します。また、recommend には除外引数がないため、失敗した modelId は自分でランキングから除外します |
| 代替モデルの料金を確認する | dry_run=true を指定して model_run を呼び出します |
| 同じ意図を再テストする | 候補ごとに model_run を1回実行します。モデルだけを変数とするため、プロンプトは変更しません |
| 4 つの失敗は似ていますが、表現の問題なのは最初のものだけです。プロバイダーによるモデレーションブロック、チーム独自の設定による IP 検知ブロック、403 Forbidden エラー(プランにそのモデルが含まれていません)、そしてチームが独自のブロックリストに登録したモデルです。何かを書き換える前に、エラーを確認してください。 |
正当なプロンプトがブロックされる理由
3 つの要因が重なると、それぞれ単独ではしきい値を下回ることが多くても、ブロックされます。
- 認識されやすいキャラクター。 自動フィルターは、認識したキャラクター名や特徴的な要素に反応します。IP の権利者が誰かを判断できないため、チーム独自のキャラクターも他者のものと同様にフラグが立ちます。
- 強度を表す表現。 規模やドラマ性を伝えるために選ばれた言葉(「特大の」「巨大な」「とてつもなく大きな」など)は、対象が小道具であっても、組み合わさると暴力的な表現と見なされます。
- 実在人物への類似性。 フィルターはプロンプト内の名前だけでなく、出力が公人に似ているかどうかも確認します。そのため、プラットフォーム自体が生成したキャラクターシートが、次回の実行では参照として拒否されることがあります。また、プロンプト内の有名人との比較(「ヘビー級チャンピオンのような体格」など)も、別の形で名前を挙げることになります。
2 つの要因があると、プロンプトはしきい値に近づきます。そのため、同じ意図でも、ある実行では通り、次の実行では失敗します。わずかな言い換えでしきい値を超えてしまうためです。プロンプトを書き換える上流の LLM ステップがよくある原因です。無関係な問題を解決するために強調表現を多用し、実行のたびにブロックを再び招きます。
フィルターの違いは価格ではなくプロバイダーによるものです
Scenario の公開コンテンツポリシーガイドでは、プロバイダーが次のようにランク付けされています。Google のモデル(Gemini、Veo)はブランドやキャラクターへの言及を最も多くブロックし、ByteDance、OpenAI、Ideogram、Hunyuan は中程度、FLUX と Recraft は最も寛容です。recommend はフィルターの厳しさではなく、測定されたパフォーマンスに基づいて順位付けするため、同じプロバイダーの代替モデルにも同じフィルターが適用されます。次の候補は別のプロバイダーから選び、失敗した行の modelId を確認して、どのプロバイダーだったかを把握してください。通常、ID を見ればプロバイダーがわかります。判別できない場合は、model_get(カタログ専用、読み取りレーン)で complianceMetadata.modelProvider を含むレコードを取得できます。
動画と音声のブロック
動画では、ブロックされた場合のコストが変わります。複数のプロバイダーはレンダリング完了後にモデレーションを行うため、拒否されたクリップはすでに最後までレンダリングされており、同じペイロードで再試行すると、再びレンダリングされます。ほかのことをする前に、失敗した行の cuCost を確認し、クイックリファレンスに従って課金額を確かめてから、上記のようにプロンプトは変えずにプロバイダーを切り替えてください。
音声トラックは個別に判定されます。音声対応の動画実行で OutputAudioSensitiveContentDetected が表示された場合、サウンドトラックがフィルターに引っかかったことを意味します。よくある原因は、除外指定に含まれている場合でも、楽器名やジャンル名を挙げることです。「音楽なし」や「遠くのギター」は失敗していますが、「室内の環境音、足音、単独の声」は通過しています。劇中音は肯定的に描写し、除外するものの名前は挙げないでください。クリップに音が必要ない場合は、無音をプロンプトで指定するのではなく、スキーマに音声フィールドがある場合はそのフィールドをオフにしてください(多くのファミリーでは generateAudio です)。
IP Detection はチーム独自のゲートです
Enterprise プランのチームは、プロバイダーのフィルターとは独立した Scenario 独自のゲートである IP Detection を有効にできます。実行前にプロンプトと入力画像を読み取り、組織管理者が有効にしたフィルター(架空のキャラクター、ブランドおよび商標、有名人の肖像、アーティストのスタイル、カスタムフィルター)と照合します。一致すると、知的財産のリスクを示すメッセージとともにジョブを即座に失敗させ、生成は行われず、生成コストも請求されません。スクリーニング自体には、スクリーニングした生成ごとに 1 CU、入力画像ごとに 1 CU が課金されます。ブロックされた場合も課金され、usage には独立した IP Detection の項目として報告されます。動画、音声、3D の入力は分析も課金もされません。この設定は teams_list 行の ipDetectionEnforcement として記録されます。値が disabled の場合、IP または著作権を理由とする拒否はすべてプロバイダーによるものです。有効レベルの違いは、チェック自体を実行できない場合にジョブを通すかブロックするかだけなので、文字どおりの値とその違いを報告してください。有効な場合は、エラーにどのゲートが示されているかを確認します。チームのゲートは知的財産のリスクを示し、プロバイダーのゲートはコンテンツポリシー違反を示します。どちらも記載されていない場合は、変更していないプロンプトを別のプロバイダー 1 社で一度実行してください。スイッチを切り替えるとプロバイダーのフィルターは通過しますが、チームのゲートはどのモデルでも再発します。チームのゲートでブロックされた場合は、ビジュアルで説明したデザインを使い、プロンプトにも入力画像にも保護対象のマークを含めずに、1 回だけ再試行してください(ブランドフィルターは、参照画像に表示されたロゴを名前と同様に読み取りますが、一般的な製品の説明はフラグされません)。再度ブロックされた場合は、これは呼び出しではなく対話の問題です。どのゲートが作動したかをユーザーに伝えてください。フィルターを管理するのは組織管理者で、ライセンスされた作業については単一のプロジェクトをスクリーニング対象外にできます。また、自身がライセンスを保有する知的財産で誤検知が続く権利者には、Scenario のアカウントマネージャーを通じたエスカレーション経路があります。完成した出力に付された著作権の警告はプロバイダーによるフラグであり、情報提供を目的とするものです。アセットは納品済みで、商用利用前に確認するかどうかはチームの判断です。
低コストな方法から順に復旧する
- プロバイダーを切り替えます。 通常、プロンプトの編集は不要です。変更していないプロンプトを、同程度のコストの別プロバイダー 2、3 社で実行します。それらで通過するなら、フィルターはコンテンツではなく、そのプロバイダーによるものです。
- 強さではなく比率でスケールを表現します。 「スタッフの肩の高さまで届く」や「刃は前腕とほぼ同じ長さ」といった表現は、暴力表現として判定されることなく、「巨大な」と同じアートディレクションを伝えられます。
- モデルに直接渡す入力では、認識可能な名前を和らげます。 プロンプトではデザインを説明し、代わりに参照画像でアイデンティティを伝えます。そのほうが見た目もよりよく維持できます(
scenario-consistencyを参照)。実在の人物との比較も同様に削除します。 - 上流のリライターに制約を加えます。 LLM ノードが最終プロンプトを作成する場合、その指示にステップ 2 と 3 を含めてください。そうしないと、次の実行で再びブロックされます。
そこで止めてください。すべてのプロバイダーが拒否し、正直な書き換えを 1 度試しても解消されないなら、フィルターは実際の問題を読み取っています。そのことを伝え、ユーザーに判断を委ねてください。すり抜けるものが見つかるまでバリエーションをひたすら試すのは、アートディレクションではなく回避です。
作業例:フラグが付いた武器の小道具
スタジオ独自のキャラクターの名前は Onyx で、「Onyx's oversized war hammer, huge spiked head」はフラグが付けられます。
- エラーを読みます。
job_getにjob_idを指定する(ジョブで実行された正確なプロンプトを確認するにはverbose=trueを指定する)か、jobs_waitの行にあるerrorフィールドとhintフィールドを確認します。モデレーションと記載されているため、これはプロバイダーのフィルターであり、プランの制限、チームのブロックリスト、IP Detection ではありません(teams_listにはipDetectionEnforcement: "disabled"と表示されます)。 - 失敗したジョブの
capability(ここではtxt2img)とユーザー自身の言葉を使ってrecommendを実行し、失敗したmodelIdとは異なるプロバイダーから候補を2つ選び、それぞれの料金をmodel_runとdry_run=trueで確認してから、変更していないプロンプトをそれぞれで実行します。1つが通れば完了です。フィルターの原因は最初のプロバイダーにありました。 - すべて拒否されたとします。名前を使わず、比率で一度だけ書き換えます。「振るう者の肩ほどの高さがあるウォーハンマー。スパイク付きの頭部は両手幅ほど」。参照画像を使って Onyx の見た目を引き継ぎます(
scenario-consistencyを参照)。 - それでもすべてのプロバイダーで拒否される場合は、そこで止め、フィルターが何に反応しているように見えるかをユーザーに伝えます。
よくある間違い
- 同じプロンプトを再試行する:しきい値付近のプロンプトは断続的に通るため、たまたま成功した再試行でも何も解決していません。動画ではその前にクリップ全体を再レンダリングします。
- 別のプロバイダーを試す前に文言を書き換える:文言の変更には時間がかかり、アートディレクションも損なわれます。モデルの切り替えは1回の呼び出しで済みます。
- 同じプロバイダー内で切り替える:同じプロバイダーの兄弟モデルはフィルターを共有します。次の候補は別のプロバイダーから選びます。
- 音声対応プロンプトでジャンルや楽器を除外するために名前を挙げる:音声フィルターが読み取るのは、その除外指定です。
- IP の所有権があればプロンプトが免除されると考える:フィルターは自動化されており、送信されたテキストと画像だけを認識します。
- IP に関する文言を含む拒否をすべて同じゲートによるものと考える:適用が有効な場合、まずエラーの文言でそれぞれを見分け、次にプロバイダーを1つ切り替えます。その方法で解消できるのはプロバイダーのフィルターだけです。チームのフィルターには管理者が必要です。
- ブロックを Scenario の不具合として報告する:ほかのプロバイダーでも拒否されることを確認してから、
scenario-reportで報告します。 - より高価なモデルならフィルターが緩いと期待して切り替える:料金とモデレーションの厳しさに関連はありません。
- モデル一覧が空なのをモデレーションの結果と考える:チームのブロックリストまたはプランの制限により、プロンプトが判定される前にモデルが一覧から除外されます。