scenario-consistency

シナリオの一貫性

概要

「X 以外は、バリエーション 1 とまったく同じようにバリエーション 2 を作る」は、最も頻繁に求められるクリエイティブな依頼ですが、エージェントはシードを使おうとします。しかし、シードでは解決できません。一貫性は、モデルに与える情報によって実現します。安定性の低い順に、プロンプトのベースライン、参照画像、スタイル参照、コントロールマップ、トレーニング済みモデルがあります。同じ参照を動画でも使えば、キャラクターの一貫性を保てます。接続と基本的なループについては、scenario スキルを参照してください。トレーニングについては、scenario-model-training を参照してください。名前付きのキャラクターや小道具のライブラリと、そのシートの作成・登録については、scenario-identity-library を参照してください。ここに記載されている関連スキルが利用可能なスキルに見つからない場合は、ユーザーにインストールを依頼してください （npx skills add scenario-labs/skills --skill <name>）。無人で処理を続ける場合は、ツールスキーマに基づいて作業を進め、不足していることを明示してください。

クイックリファレンス

テクニック	保持される要素	労力	使用する場面
ベースライン＋差分プロンプト	アイデンティティ、構図、パレット	低	常に使用します。これが基本です
参照画像の入力	アイデンティティと世界観	低	シーンやアングルのセット
スタイル参照の入力	主題ではなく、レンダリングスタイル	低	アイコンセット、UI、イラストシリーズ
asset_detect コントロールマップ	ポーズ、ジオメトリ、構図	中	レイアウトを変えてはいけない場合
参照画像からの動画生成	動きの中でのアイデンティティ	中	キャラクターや製品を動かす必要がある場合
シードの再利用	1 枚の画像の正確な生成結果	低	単一の生成を再試行する場合
トレーニング済みモデル	固有のスタイル、または大規模なキャスト	高	参照画像では拡張に限界がある場合（下記参照）

Scenario が公開しているパイプラインのガイダンス：まず質の高い参照画像を 1 枚生成し、すべてのシーン生成で画像入力として渡し、参照画像スロットが最も多いモデルを優先してください。

ベースラインと差分のプロンプト

変更してはならないものをすべて書き出し、最後の節に唯一の変更を記述します。実行のたびにプロンプトをバイト単位で同一に保ち、その節だけを編集します。各アイテムに必ず含める変更（新しい衣装、ヘアカットなど）はベースラインであり、差分ではありません。まず主人公自身の差分として一度実行し、結果を新しい主人公として承認してから、それに合わせて一式を固定します。こうすることで、参照画像と列挙内容が同じ見た目を示すようになります。

具体的に列挙します。被写体の形状、カメラの高さと角度、フレーム内での被写体の大きさと位置、照明の方向、名前を付けた各サブ要素とその配置、名前または HEX で指定したパレット、埋め込みテキストです。まずベースラインを確認します（asset_display）。見ていない色合いは列挙できず、曖昧な基準ではずれが生じます。

承認済みのベースラインを参照画像として添付します。画像モデルでは referenceImages が一般的ですが、上限、必須かどうか、要素数は model_schema_get で確認します。また、モデルによってはこのフィールドが単一のスカラー値のファイルです。スカラー値の image と strength の組み合わせは img2img であり、参照スロットではありません。アイデンティティだけでなく構図も固定し、デフォルトの強度では単純な背景の参照画像がシーン全体の差分を上書きするため、シーンを一式作る場合は本当の参照フィールドが必要です。スキーマで array: true とされている場合に限り、単一のアセットでも ["asset_..."] のように配列で指定します。文字列だけを指定すると、気づかれないまま無視され、それを無視した状態で実行が成功します。各参照画像の役割をプロンプトに記述します。残りのスロットには、モデル上で承認済みのショットを使います。カタログツールの書き込みレーンを使ってコレクションとして整理し、search で filters={"collection_ids": [...]} を指定して取得します。一部のスタイル参照対応モデルでは、初回実行時に再利用可能なスタイルが生成されます。その ID は実行レスポンスやアセットではなく、完了したジョブの出力メタデータにあります（job_get に verbose=true を指定）。以降の実行では、画像の代わりにスキーマの ID フィールドにその ID を渡します。この2つのフィールドは排他的で、cost_impact が付いているのは画像フィールドだけなので、スタイルの生成費用が発生するのは一度だけです。同じ参照画像一式を毎回渡す前に、フィールドの説明を確認します。スキーマで両フィールドが任意とされている場合でも、初回の実行には画像が必要です。画像も ID もない状態では、モデルが実行を拒否します。

参照画像にはアップロードした画像も使えます。ユーザーのキャラクターアート、スケッチ、または製品写真を upload_asset と upload_asset_complete でアップロードし（scenario を参照）、承認済みの主人公と同じように参照フィールドに渡します。asset_describe（scenario-asset-analysis を参照）は、スタイルの要約（媒体、パレット、照明、構図、ムード）を返します。これを使って、列挙内容のパレットと照明の行を決めます。サブ要素の一覧は、目視で確認するか、列挙の見出しを指示として asset_analyze に渡して作成します（どちらもカタログツールです。asset_describe は dry_run で料金を確認します）。

一式の各アイテムには、それぞれ model_run が必要です。バッチ数フィールドでは同じプロンプトが繰り返されるため、アイテムごとの差分節を指定できません。チームの同時実行上限（scenario スキルの parallel-custom-jobs 行）内で、複数回に分けて起動します。429 で起動が拒否された場合、ジョブは作成されていないため、そのアイテムを省略せず、次の回に再度起動します。

被写体なしでスタイルを固定する

スタイル参照は被写体参照とは別のスロットで、対応している画像モデルは一部のみです。執筆時点では、あるモデルファミリーは styleReferenceImages で1枚から10枚の画像を指定し、少額の追加料金で非公開のスタイルを作成していました。ジョブの出力には再利用可能なスタイル ID が返され、以降の実行では画像の代わりに styleId として渡します（この2つは相互排他的です）。また、スタイルへの準拠度は styleMatch で precise または flexible を選択します。この機能で固定されるのはレンダリング、パレット、線の表現であり、キャラクターではありません。アイデンティティを保つには、被写体参照かベースラインの列挙内容と組み合わせます。recommend でユーザー自身の言葉によるスタイル要件を指定して対応モデルを探し、model_schema_get でフィールドを確認します。RGB の三つ組を受け取るパレットフィールド（colors）は制約ではなく、希望を示すものです。HEX 値もプロンプトに記載してください。

制御マップを使ったロック構造

マップを生成し、条件付け入力として渡します。変更対象となる属性については、マップを抽出しないでください。承認済み画像から作成したポーズマップを使うと、変更するよう求められたポーズが固定されます。ポーズセットでは、ターゲットポーズ画像から作成したマップを使うか、マップを使わないでください。

asset_detect は asset_id と、canny、depth、grayscale、lineart_anime、mlsd、normal、pose、scribble、segmentation、sketch から選ぶ modality を受け取ります（remove_background のデフォルトは true です）。カタログ専用で書き込みレーンに属します。ドキュメントページでは Analysis の下にまとめられていますが、scenario_tool_execute_write 経由で実行してください。

制御ブロック（controlImage、controlModality、controlStrength、controlStart、controlEnd）は、controlnet が capabilities に記載されているモデルでのみ使用できます。これを前提に計画する前に確認してください。対応していないモデルでは、参照画像を使用します。controlModality で指定できるのは canny、tile、depth、blur、pose、gray、low-quality です。マップを使えるのは canny、depth、pose のみで、grayscale は gray になります。controlStrength のデフォルトは 0.7 で、推奨範囲は 0.3～0.8 です。canny、depth、tile では 0.7 前後、pose、gray、blur では 0.8～0.9、厳密に固定する場合は 0.9 超にします。Strength は制御の強さを、controlStart と controlEnd は制御するタイミングを指定します。controlEnd を 0.65 前後にすると、序盤は構図を固定し、その後は制御を解除してプロンプトによるディテールの調整を可能にします。

動画全体で一貫したアイデンティティを保つ

参照画像からの動画生成では、参照画像に写る被写体をアニメーション化します。最初のフレームで構図を固定することはありません。カタログには参照画像からの動画生成に対応する capability 値はありません。これらのメンバーには img2video のタグが付いているため、capability="img2video" を指定して recommend を実行し、「これらの画像と同じキャラクター」のように、ユーザー自身の言葉で一貫性の要件を伝えてください。そのうえで model_schema_get を確認し、複数スロットの referenceImages 配列があることを確かめます（執筆時点で上位メンバーのスロット数は7～9で、そのうち1つは最初の4つを超える有料スロットです）。動きを模倣する場合は、referenceVideo または referenceVideos スロットも確認してください（上限は3～15秒の範囲で、一部ではアップロード秒数ごとに課金されます）。配列を持つモデルがランキングにない場合は、動画モデルファミリーのスキル scenario-video に記載されているファミリー名を search してください。スロット数よりも、解像度と長さのほうが価格への影響は大きくなります。model_schema_get から両方の列挙値を読み取り、cost_impact の印があることを確認してください。また、動作全体が表示される最も安価な試作動画でアイデンティティを検証します。つまり、納品時と同じ長さで最も低い解像度を使います（短い動画では後半のずれが隠れるためです）。まず dry_run で試作動画と納品動画の両方の料金を確認してください（ある試作動画では、デフォルト設定の130 CUに対して80 CUと算出されました）。試作動画の検証に合格しても、検証できるのはレシピであって、その動画自体ではありません。納品用のレンダリングを出す前に、別途全体を確認してください。複数のファミリーでは、image（最初のフレームのアンカー）と参照配列は相互に排他的です。参照画像からの生成は追加料金なしで開始できますが、最初のフレームを固定する場合は別のメンバーを使います。スロットにはライブラリの素材を入れてください。scenario-identity-library に従い、基準となるヒーロー画像と、承認済みのキャラクター着用画像を2～3枚、個別の画像として使い、ターンアラウンドシートは使わないでください。ライブラリがまだない場合は、承認済みのヒーロー画像1枚だけを1つのスロットに入れるのが、最初の実行として有効です（公開されているパイプラインは、強力な参照画像1枚から始まります）。次のスロットには、上記の画像参照ループで承認された静止画のうち、キャラクターを明瞭に捉えた画像を使います（ニュートラルなポーズで、シーンの小道具がないものを選んでください。シーンの静止画をスロットに入れると、小道具とポーズも引き継がれます）。シートを切り抜いて使うことは決してしないでください。見た目ではなく動作をプロンプトで指定してください。スキーマによっては、アップロードした素材を順番で指定します（「Image 1 turns toward the camera, moving as in Video 1」など）。また、プロンプトの有無にかかわらず被写体が登場すると記載されているものもあります。いずれの場合も、キャラクターの特徴を改めて説明すると画像の指示と競合します。ファミリーごとの仕様とプロンプトの構文は、動画モデルファミリーのスキル scenario-video に記載されています。クリップ全体でアイデンティティを判定してください。asset_get は、無料で取得できるアセット ID として firstFrame と lastFrame を返しますが、ショットの途中から現れるずれはどちらのフレームにも現れないことがあります。そのため、クリップを出す前に model_scenario-video-to-image-seq でフレームを抽出して全体を確認してください（これは固定のファーストパーティ ID です。Scenario の決定論的な単一フレーム抽出ツールなので、検索してもこの ID が再確認されるだけです）。1秒あたり約2フレームが目安です（frameInterval は抽出間隔を表す元動画のフレーム数の整数値で、クリップの frameRate の半分に丸めた値です。24 fpsなら12です。動画は video に指定します）。あるクリップでは、不具合が11.0秒で現れたのに、ショットごとに1フレームだけ確認したところ、10.5秒時点では問題ないと判断されました。各フレームは、ベースラインで列挙した要素ごとに比較します。名前の付いたパーツが追加、消失、色変更、形状変更された場合はずれです。マントの揺れやアンテナの傾きのように、動作に合わせてパーツが動く場合はアニメーションなので問題ありません。

参照画像だけではスケールしなくなったら

参照画像を優先する方法は公開されている順序であり、コストも低いため、トレーニングの前に徹底してください。何百枚もの画像に同じキャラクターが登場する場合、4人以上のキャラクターを同じシーンに登場させる必要がある場合、または被写体にかかわらず毎回同じレンダリングスタイルが必要な場合は、トレーニングの効果が得られます。繰り返し登場するキャラクターごとに1つ、スタイル用に別のモデルをトレーニングしてください。両方を1つのモデルに担わせると、学習量の少ないほうに引っ張られてずれていきます。複数キャラクターのシーンは、同時生成ではなく合成してください。参照スロットでは注意が分散するため、各キャラクターをそれぞれ単独でベースラインに合わせて生成してから、scenario-image-editing の編集ワークフローで一緒に配置します。データセットのサイズ、ベースの選択、実行前の見積もりルールについては、scenario-model-training を参照してください。トレーニングしたモデルは、その ID だけでは実行できず（runs_as と run_with については scenario を参照）、ベースラインと差分を組み合わせたプロンプトも引き続き必要です。トレーニングによって簡略化できるのは列挙の手間であり、差分を明確にする規律ではありません。

スプライトシートやアニメーションフレームは難しいケースです。汎用画像モデルの隣り合うフレームは、比率、スケール、シルエットがずれてしまい、エンジンではそのずれが一度に明らかになります。1キャラクターのフレームは scenario-sprite-animation の動画レーンで作成します。フレームごとに生成するのではなく、1回のレンダリングでキャラクターの同一性を保てます。

実例：1体のマスコットの5つのポーズ

1. 承認済みのヒーロー（asset_hero）を asset_display で表示し、ベースラインを記述します。上記の「変更してはならない要素」の完全な列挙を使ってください。
2. タスクで使う言葉をそのまま prompt として recommend を実行します（名前が付いたファミリーを探す場合に限り search を使います）。参照画像スロットのあるモデルを優先してから、model_schema_get を実行し、参照フィールドの名前、上限、要素数、必須かどうかを確認します。スキーマに参照フィールドがなければ、その候補は除外します。ランキングに戻り、参照画像に対応する候補が見つからない場合（recommend はコミュニティのファインチューニングモデルを順位付けし、ファーストパーティモデルを見落とすことがあります）は、同系統のモデルスキル（scenario-gemini-image、scenario-seedream）からファミリー名を選んで search します。
3. 各ポーズにつき model_run を1回ずつ、合計5回実行します。同時実行数の上限を守り、wait=false で数回に分けて起動します。バイト単位で完全に同一のベースラインを使い、最後の節にポーズだけを記述し、スキーマの指定どおりの形式でヒーローを参照フィールドに指定します。array: true の場合に限り、["asset_hero"] を指定します。シードは使いません。コントロールマップも使いません。ヒーローからポーズマップを作ると、変更対象のポーズが固定されてしまいます。
4. 各回の実行枠が空くたびに次のポーズを起動し、5つすべて完了するまで、各回の実行後に pending_job_ids を指定して jobs_wait を再度呼び出します。それぞれをヒーローと比較して asset_display で表示します。ずれがあれば、出力を連鎖させるのではなく、列挙をさらに明確にします。

よくある間違い

• 2つのプロンプトを一致させるためにシードを使うこと。シードで再現できるのは1回の生成だけで、ほかの生成には何も引き継がれません。ひとまとまりの生成ではシードを設定せず、変更していないプロンプトを1回だけ再生成する場合に限って設定してください。
• 「前と同じ」と書くこと。呼び出し間で記憶は引き継がれないため、毎回ベースラインをすべて書き直してください。
• ひとまとまりの出力を次の出力につなげること。ずれが積み重なります。各項目を、同じ承認済みベースラインに固定してください。
• 1回限りの用途にトレーニングすること。1つのシーンに1人のキャラクターだけが登場するなら参照画像を使い、同じキャラクターが繰り返し登場する大規模なケースなら、上記のとおり、キャラクターごとに1つ、スタイル用に1つのモデルをトレーニングします。
• asset_detect のモダリティ名が controlModality の有効な値だと思い込むこと。
• ターンアラウンドシートを参照スロットに渡すこと。動画メンバーではグリッド自体がアニメーション化されます。画像モデルでは、このシートは整理・確認用の成果物であり、参照画像ではありません。スロットには、承認済みの個別ショットを指定してください。
• 参照画像から動画を生成するプロンプトで、キャラクターをあらためて説明すること。見た目は画像が伝え、プロンプトは動作、カメラ、タイミングを伝えます。