scenario-identity-library

シナリオのアイデンティティライブラリ

概要

ゲームやブランドは、すべての画像で認識できる状態を保つ必要がある、キャラクターや小道具といった名前付きのアイデンティティを中心に展開します。このスキルは、そのライフサイクルを最初から最後まで管理します。ブリーフの聞き取り、ヒーロー画像の生成と合否判定、承認済みショットの名前付きコレクションへの保存、シートの作成、そして新しい画像用にライブラリを取り出すところまでを担います。画像ごとの仕組みは兄弟スキルにあるため、ここでは繰り返しません。接続と基本的な流れは scenario、参照画像を使って見た目を維持する方法は scenario-consistency、合否判定は scenario-quality-gate にあります。ここで名前を挙げた兄弟スキルが利用可能なスキルにない場合は、ユーザーにインストールするよう依頼してください（npx skills add scenario-labs/skills --skill <name>）。無人実行の場合は、ツールのスキーマを確認して進め、不足している点を明示してください。

クイックリファレンス

段階	仕組み	ルール
ブリーフ	聞き取りを行い、変更してはならない要素を列挙する	生成を始める前に実施
アンカー	ヒーロー画像を生成し、合格判定を通す	アップロードしたアートは生成を省略
ライブラリ	character: <name> または props: <name> という名前のコレクション	合格した画像のみ
シート	承認済みショットを Grid Maker で組み立てる	メンバーに変更があれば再作成する
再利用	collections_list の前方一致で検索し、メンバーは search で取得。参照画像は scenario-consistency に従う	後続のあらゆるセッションで使用可能

聞き取りからアンカーまで

生成する前に聞き取りを行ってください。回答は、後続のすべての画像で再提示する基準となる要素の列挙になります（scenario-consistency）。ここでの漏れは、後々のずれにつながります。対象が何か、シルエットとプロポーション、名前または16進数で指定するカラーパレット、識別の決め手となる特徴を2つか3つ（ひび割れたヘッドランプ、真鍮のバックルなど）、レンダリングスタイル、そして必要なアングルを確認してください。全身像だけでは、参照スロットがクローズアップを維持するための情報が足りません。そのため、クローズアップで撮影するアイデンティティには、正面から見た顔または特徴部分のクローズアップと、正確な真横からのビューも必要です。対話なしの実行では、タスクに記載された情報を使い、不足分を明示してください。すでにアートがあるユーザーは生成を省略できます。scenario-consistency に従い、ユーザーのイラストまたは写真をアップロードしたアンカーとして使います。

最初の実行前に、アイデンティティ全体で使う参照画像対応モデルを1つ選んでください（recommend を使い、その後 scenario-consistency のスキーマで確認します）。後続のすべてのビューはその参照フィールドを使うため、参照フィールドのないモデルは3つ目のビューで失格になるのではなく、ここで除外してください。ヒーロー画像として、無地の背景に描かれたニュートラルな全身像を生成し、その後 scenario-quality-gate に従って合否判定を行います。回数の上限は事前に固定してください（デフォルトは3回です）。そのスキルや合否判定の仕組みがない場合は、同じ上限のもとで、ブリーフにある要素の列挙に照らして確認してください。参照スロットは、余計なもののないアンカーで最も効果的にアイデンティティを切り分けられるため、フレーム内にはブリーフにないものを入れず、テキストも含めないでください。ヒーロー画像が、それ以降のすべての画像で参照するアンカーになります。

ライブラリは名前付きコレクションです

正確な名前を character: <name> または props: <name> として collection_create を実行し、続けてヒーロー用に collection_add_assets を実行します（カタログツール、書き込みレーンです。作成呼び出しに渡すのは名前とスコープのペアで、description フィールドはありません）。名前がレジストリキーです。コレクションは search の検索対象ではないため、後のセッションでは collections_list（読み取りレーン）をページングしてプレフィックスを照合し、search でメンバーを取得します（target="assets"、filters={"collection_ids": [...]} に、必要なビューの tags フィルターを追加します。これにより、登録済みシートが参照用の取得結果に混入しません）。採用判定がゲートになります。合格した画像だけを登録してください。以後の生成では毎回このプールを参照用の真実としてサンプリングするため、モデルに合わないメンバーが1つでもあると、その後の取得結果がすべて汚染されます。ビューはベースライン＋差分の方法で揃え、ビューごとに model_run を1回実行して、それぞれを判定し、合格したものをビュー名のタグ（asset_add_tags の hero、back など）を付けて登録します。そうすれば、後のセッションでメンバーを見分けられます。デザイン変更（新しい衣装、髪型、年齢）の場合は、ブリーフの列挙を更新し、以前のヒーローを基に新しいヒーローを作成します（scenario-consistency）。それを基にビューとシートを再構築し、次に取得する前に collection_remove_assets で古いメンバーを削除してください。削除しないと、1回の取得で両方のバージョンが参照フィールドに渡されます。

シートは生成ではなく組み立てです

Scenario の Grid Maker は、承認済みの画像を1枚のシート画像にまとめます。id は固定のファーストパーティ製 model_scenario-grid-maker です（この用途では Scenario 唯一の決定的なツールなので、検出しても再特定するだけです）。model_schema_get でスキーマを確認してください。執筆時点では images（最大100件のファイル配列。アセットが1つだけの場合も配列に入れます）と、レイアウト用フィールド（columns、未指定時は件数から計算される rows、padding、backgroundColor、固定の cellRatio リスト。既定値は auto）を受け取ります。プロンプト用フィールドはありません。images 配列の並びがレイアウトになるため、読み順に並べてください。シート自体もアセットとして、判定を経ずに登録します（承認済み画像を組み立てるものであり、生成ではありません）。タグ（asset_add_tags で、たとえば sheet）を付けて登録し、メンバーが変わったら編集せずに再構築してください。ビュータグ付きのメンバーだけを取得し（単なるメンバーリストでは、古いシートがグリッドのセルになるため、決して使用しないでください）、collection_remove_assets で古いシートを入れ替えます。シートは人間向けであり、モデルのスロットが足りない場合に、ターンアラウンド全体を1枠に詰めた参照としても役立ちます。スロットに余裕がある場合は、個別の承認済み画像を優先してください。

実例：配達ロボットのNima

1. インタビューでブリーフを作成します。丸みを帯びたシルエット、銅の外装、ひびの入ったヘッドライト1つ、キャンバス地のサッチェル、セルシェーディング。ビューは正面、背面、左側面、斜め前です。
2. ブリーフに使われている言葉で recommend を実行します。model_schema_get で実際に参照フィールドがあることを確認し（なければ次の候補へ進みます）、ヒーローを model_run で生成します。model_run がアセットなしで job_id を返した場合は jobs_wait を実行し、scenario-quality-gate に従って判定して、合格するまで反復します。
3. collection_create "character: Nima" を実行し、ヒーローを collection_add_assets で追加して hero タグを付けます。
4. ヒーローを参照フィールドに入れ、ベースライン＋差分の方法で残り3つのビューを作成します。判定を行い、合格したらビュータグを付けて登録します。
5. ビュータグ付きのメンバーを使って Grid Maker を実行します（このセッションではすでにidを保持しています。登録直後のアセットは search インデックスに反映されるまで時間がかかることがあります）。images を [front, back, left, three-quarter] の順にし、columns: 4 を指定します。出力に sheet タグを付けて登録します。
6. 数週間後、「雨の路地にいるNima」を作成するときは、collections_list で character: Nima を見つけ、メンバーを search で取得します。hero タグ付きのメンバーと、モデルに合った画像2枚を参照フィールドに入れ、scenario-consistency に従ってプロンプトを作成します。

よくある間違い

• ヒアリング前に生成する：あいまいなブリーフは列挙できず、ライブラリにもそのずれが引き継がれます。
• ゲートを通していない画像を受け入れる：不合格の画像は scenario-quality-gate に従って再試行するか、取り込まれません。
• Grid Maker にプロンプトを入力したり、画像の生成を期待したりする：Grid Maker は入力された images を配置するだけで、それ以上のことはしません。生成はビューの実行で行います。
• シートを img2img の image として渡す：構図が固定されます（scenario-consistency）。シートを使えるのは、正規の参照スロットだけです。
• 自由なコレクション名を使う：Nima stuff は規約上見つけられません。character: と props: のプレフィックスが検索の取り決めです。
• ビューごとに異なるモデルを使う：参照の挙動はファミリーごとに異なります。スキーマで検証された1つのモデルで、アイデンティティ全体を維持します。