scenario-ad-variants について
scenario-ad-variantsは、1つの提供素材から指定された編集バリエーションを作るスキルです。広告バリエーションを管理するエージェント向けで、各案の変更点と維持する要素を記録し、出力を追跡できます。
主な機能
- 011つの素材から個別に編集
- 02安定したラベルと案の記録
- 03正確なコピーと出力仕様
- 04決定論的な編集手順
- 05出力と音声の検証
活用シーン
- 01複数の広告フックの比較
- 02映像を保ってCTAを変更
- 03掲載先に合わせた短縮版の作成
- 04シーンを維持したオブジェクト置換
MCP 対応
Scenario MCP のワークフローでアセット確認、モデル探索、ジョブ送信、復旧を行います。動画編集、合成、フォーマット、テキストオーバーレイには関連スキルも使います。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ scenario-labs/ skills --skill scenario-ad-variantsインストール後、Claude Code で/scenario-ad-variantsを入力して読み込まれたか確認します。
詳細
シナリオ広告のバリエーション
概要
提供された1つの素材から、個別に指定した編集を順序付きで作成します。ブリーフで変更を指示されていない部分は維持し、すべての出力を同じ素材まで追跡できるようにします。製品の静止画から新しいストーリーボードを作成する場合も scenario-video-ads を使います。単一クリップの編集ユーティリティには scenario-video-editing を使います。接続、検索、送信、復旧には scenario を使います。ここに記載された関連スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください
(npx skills add scenario-labs/skills --skill <name>)。無人で処理する場合は、ツールのスキーマに基づいて進め、不足している点を明示してください。
不足している決定事項のみ確認します。素材、必要なバリエーション、正確な文言、出力先、実行時間、音声の方針、支出上限を確認してください。すでに提示されている回答は再利用します。合意した変数だけを変更する統制比較と、クリエイティブの探索を区別してください。依頼がない限り、選択肢を掛け合わせた全組み合わせのバッチは作成しないでください。
クイックリファレンス
| 依頼された変更 | 使用するルート | 固定するもの |
|---|---|---|
| フックの文言、CTA、エンドカード | scenario-text-overlay、続けて scenario-video-assembly | 元の映像、素材の音声、その他すべての文言 |
| 短縮版、カラーグレーディング、配置 | scenario-video-editing、scenario-formats | 合意した素材区間、シーケンス、主要な被写体 |
| 背景、衣服、オブジェクトの差し替え | 動画編集メンバーを検索したうえで scenario-video | 変更しない人物、動作、タイミング、素材の音声 |
| 新しいショットやコンセプト | scenario-video-ads | 元の素材を維持する編集ではなく、新しいクリエイティブです |
ブリーフを満たせる場合は、決定論的な操作を使用してください。ゲームプレイのキャプチャでは、生成的な背景の差し替えによって、ジオメトリ、UI、またはゲームメカニクスの挙動も変わることがあります。そのような出力を、ゲームプレイに忠実なものとして暗黙に扱わないでください。該当するピクセルの保持が必須であり、利用可能なルートで編集箇所を切り分けられない場合は、費用をかける前に制約を報告してください。生成的な保持プロンプトは検証を求めるものであり、保証ではありません。
素材とバリエーションの記録
素材の寸法、長さ、フレームレートを確認するために asset_get を読み込み、映像、既存のテキスト、カット、音声を調べてください。参照画像には、人物、製品、スタイル、差し替えのいずれかの役割を明示します。各バリエーションに一意のラベルを割り当て、元のアセット、意図した変更点、不変条件、正確な文言、出力仕様、音声の方針を記録してください。独立した各バリエーションは必ず元の素材から開始し、直前に生成したバリエーションから開始しないでください。ユーザーがその意図を示している場合、依頼された修正は選択したバリエーションを基に開始します。
各バリエーションの状態を簡潔に記録してください。状態は、ブロック中、計画済み、送信済み、保留中、失敗、検証済みのいずれかです。送信したジョブ ID、出力 ID、測定した特性、QA の結果も記録してください。説明文のプロンプトだけでなく、実際に送信したペイロードを保存します。レンダリング済みでもレビュー待ちの出力は、検証済みではありません。中断後も完了済みのバリエーションを保持し、保留中のジョブを待ってください。転送エラーが発生した場合は、再送信する前に scenario で状態を確認します。失敗したバリエーションのみ、元のラベルを維持したまま、残りの上限内で再試行してください。意図した変更点を変える場合は、見えない形で再試行するのではなく、改訂版を作成します。
生成的な編集では、依頼された変更、役割を指定した参照画像、維持する人物・テキスト・動作、素材のタイミングに基づいてプロンプトを作成します。ユーザー自身の言葉でニーズを記述して recommend を使い、続けて model_schema_get で、対応している動画入力、参照素材、長さ、音声コントロールを確認してください。他プロバイダーの長さやプロンプト文字数の制限を流用しないでください。求められた精度やメディア形式に対応していない場合は、同等性を約束せず、最も近い実現可能な方法を提案してください。
ゲームプレイから作成した3種類のフックの実例
依頼では、音声付きの15秒のゲームプレイクリップを使用し、9:16の書き出しをちょうど3種類作成するよう求められています。フックのテキストは冒頭の0〜2秒に表示し、「Hold the line」「One hit left」「Can you survive?」とします。ゲームプレイ、音声、尺、最後のエンドカードは変更してはいけません。元の映像には、すでに明確なフック領域があります。
asset_getで元データを取得し、内容を確認します。測定した画面比率、尺、フック領域が依頼に適合することを確認してください。平坦化された映像から既存のフックテキストを削除する必要がある場合は、クリーンな元データを依頼するか、覆い隠すパネルの使用について合意してください。無人で処理する場合は、すでに承認済みで、必要な表示内容をすべて維持できる場合に限りパネルを使用します。それ以外の場合は、クリーンな元データが必要な該当バリエーションをブロック扱いにし、独立して実行可能なバリエーションの作業を続けます。ブロックされたバリエーションに費用をかけたり、テキストを消すために新しいゲームプレイを生成したりしないでください。- 同じ元データと不変条件を使って、バリエーションA、B、Cを記録します。
scenario-text-overlayを使って、テキストだけが変更されるよう、配置とスタイルを一致させた正確なテキストカードを3種類レンダリングします。レンダリングしたカードをscenario経由でアップロードします。 scenario-video-assemblyに従います。Scenarioで唯一の決定論的コンポジターであるmodel_scenario-compose-videoに対してmodel_schema_getを実行します。各ペイロードでは、同じ元動画レイヤーとその音声を使い、合意したタイミングで各カードを画像レイヤーとして追加します。canvasMode: "custom"と数値のcanvasWidth/canvasHeightを設定し、durationMode: "custom"とduration: 15を設定します。映像全体を引き伸ばさずに保持できるよう、元動画レイヤーの文字列width/heightをキャンバスに合わせ、fit: "contain"を設定します。元動画と異なる画面比率では余白が生じます。クロップには承認が必要です。カードの文字列width/height、明示的な配置、fit: "contain"を設定します。スキーマで許可される整数の範囲内で、元映像の測定フレームレートに基づいてfpsを設定し、丸めが必要な場合はその旨を明示します。このコンポジターは0.1秒単位で秒を扱います。この仕様を超えるフレーム単位の正確なタイミングを約束しないでください。- 各ペイロードについて、
dry_run: trueを指定してmodel_runで料金を見積もります。送信と、予定している修正を、承認済みの上限内に収めてください。見積もりはペイロードや映像の検証ではありません。wait: falseを指定して送信し、各ジョブIDを保存してjobs_waitを使います。保留中のジョブのIDも保持してください。 - 書き出したすべてのバリエーションについて、フックの境界、ゲームプレイ全体、エンドカードを確認します。指定された終了点の直前、終了点、直後のフレームを確認してください。タイムラインのフィールドだけでは、レンダリングされた終了点が含まれるかどうかはわかりません。測定した尺と画面比率を元データと比較します。音声の同期と、末尾が完全に保たれていることを確認します。ジョブが成功していてもオーバーレイがない場合は不合格です。終了点の不一致を報告し、問題を隠すためにフックを黙って短縮しないでください。
- 指定された順序で、
asset_displayとasset_download経由でA、B、Cを納品します。バリエーションの対応表と測定したプロパティを含めます。修正に備えて、ペイロードと元データの参照を保持してください。これらは再構築用の手順であり、ネイティブの編集可能なプロジェクトではありません。
検証とよくある間違い
生成編集では、最初と最後のフレームだけでなく、コンタクトシートで全体を確認し、重要な変更の前後のフレームも確認してください。人物の同一性、元のテキストと指定されたテキスト、編集指定の対象外にあるオブジェクト、動作の連続性、音声を確認します。生成された音声が異なる場合、映像との同期が保たれている場合に限り、サポートされている組み立て方法を使ってソーストラックを復元してください。タイミングを変更した動作に元の音声を付けても、同期の問題は解決しません。ブリーフで音声が求められていない限り、無音のソースは無音のままにします。
- 1つのジョブが失敗したからといって、すべてのバリエーションを再構築すると、成功した作業が失われ、費用も重複して発生します。
- 音楽、カラーグレーディング、フックを同時に変更すると、コピーのみの比較ができなくなります。
- 指定された寸法や長さは、出力の実測値ではありません。
- 新しいビジュアル表現は、広告のパフォーマンスが向上した証拠ではありません。パフォーマンスの検証には、別途キャンペーン実験が必要です。
- ソースの再構築では、再エンコード後のバイト単位の同一性は保証されません。保持されたコンテンツと実測した同期を確認してください。ロスレス納品を約束できるのは、その方法が対応している場合に限られます。