scenario-storyboards

シナリオのストーリーボードとコミック

概要

コミックページを頼まれたエージェントが、あるモデルに「6コマのページ」を生成するよう指示しても、コマの形が不揃いで、主人公の顔がコマごとに変わり、セリフが文字化けした、修正できないページができてしまいます。生成単位はページではなく、常にコマです。まず脚本を書き、登場人物を固定し、同じ参照画像を使ってコマごとに1回ずつmodel_runを実行し、あとから文字を入れ、最後にページを組み立てます。接続方法と基本のループについては、scenarioスキルを参照してください。キャラクターの一貫性については、scenario-consistencyを参照してください。モデルごとの画像の仕様については、scenario-imageを参照してください。文字入れについては、scenario-text-overlayを参照してください。ここで名前を挙げた関連スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください（npx skills add scenario-labs/skills --skill <name>）。無人で処理する場合は、ツールのスキーマに従って進め、不足しているスキルがあることを明示してください。

クイックリファレンス

段階	実施内容
1. 脚本	生成を始める前にビート表を作成します。各コマについて、ショットサイズとアングル、動作、舞台、セリフを記載します。
2. 登場人物とスタイル	登場人物ごとに承認済みの代表画像を1枚用意し、スタイルを選びます（query="comic"を指定したsearchでスタイルLoRAが見つかります）。各基準を記録します。
3. コマ	コマごとに1回ずつmodel_runを実行します。バイト単位で同一の基準と、そのコマの指示節を使い、スキーマに従って参照画像を設定します。
4. レビュー	jobs_waitの後、文字を入れる前に、コマをまたいで同一性を確認します。
5. 文字入れ	scenario-text-overlayのカードとして作成したセリフ、キャプション、効果音を、文字のない絵に合成します。
6. 組み立て	ページレイアウトとコンタクトシート：scenario-video-assembly（Image Studio）でレイヤーを合成するか、scenario-image-editingのグリッドツールを使います。

ショットリストと同じ順序でコマにラベルを付けます。番号、ショットサイズ、アングル、レンズまたはカメラの動き、そして各キャラクターの画面上の位置と向きを含む動作です。絵を横一列に並べるのではなく、カバレッジとして構成します。まず全体を映すマスターショットで位置関係を示し、画面の向きが逆転しないよう軸の片側を維持し、緊張が高まるにつれてショットサイズを大きくし、インサートやリアクションでアクセントを付けます。

アニメーション向けのストーリーボードは、ステージ4で終わります。承認済みのコマは、各ショットが単独で成立する場合、画像から動画を生成するscenario-videoの最初のフレームとして使います（ショットごとに1つのクリップ）。動き自体をカットをまたいでつなげる必要がある場合、コマを個別にアニメーション化すると各コマで演技がリセットされます。そのようなシーケンスには、各ショットの終了ポーズを次のショットの開始ポーズにつなげるscenario-seedance-storyboardスキルを使います。

作例：6コマのコミックページ

1. ページの内容を表にまとめます。項目は、コマ、ショットサイズとアングル、レンズまたはカメラの動き、アクション、セリフ、キャプションです。アクション欄には、カメラに映るものだけを記載します。思考やにおい、過去の経緯はそのままでは何も映らないため、目に見える証拠かキャプションに置き換えます。セリフとキャプションはここに記載し、アート生成時のプロンプトには含めません。
2. キャストを確定します。主人公を生成またはアップロードし、承認されるまで調整します。人の確認なしで進める場合は、脚本内のキャラクター描写を承認の代わりとし、それに一致する候補を選んで続けます。主人公を asset_display で表示し、scenario-consistency に従って基本設定（形状、衣装、パレットを色名または16進数で）を列挙して記録します。
3. スタイルを決めます。target="models"、query="comic"、public=true を指定して search します。執筆時点では、公開カタログにコミックスタイルの LoRA が掲載されていました。選んだモデルをユーザーに確認します（人の確認なしで進める場合は、タスクの指示に従い、それがなければ返された順序の最初の結果を選びます）。次に model_schema_get を実行し、参照フィールドの名前、上限、カーディナリティを確認します。キャストに合う参照フィールドがありませんか？機能情報にアダプターが掲載されていても、スキーマに公開されていないことがあります。その場合はスキーマを優先します。主人公の生成には選んだモデルを使い、パネルには参照に対応したモデルを recommend で選びます。また、すべてのプロンプトに同じスタイルの記述を入れます。
4. 6回の model_run を呼び出します。各プロンプトには、スタイルの記述、キャラクターの基本設定、場所と時刻を含む設定の記述を入れます。これらは、同じ内容を共有するパネル間でバイト単位まで一致させます。さらに、そのパネルの節（ショット、アクション）と、「きれいなアート、文字なし、吹き出しなし」を加えます。設定の記述を抜かすと、基本設定を抜かした場合と同様に一貫性が崩れます。主人公の参照画像はスキーマの指定どおりに接続します。array: true の場合に限り、配列を使います。バッチ数のフィールドは同じプロンプトを繰り返すため、パネルごとの節を指定できません。
5. 6件のジョブに対して jobs_wait を実行し、pending_job_ids を指定して再度呼び出します。各パネルを主人公と照合して確認します。ずれがあれば、そのパネルの列挙をより具体的にして、必ず基本設定から再生成します。隣のパネルを元にしてつなげてはいけません。
6. scenario-text-overlay で文字を入れ、カードをレイヤーとして合成してページを組み立てます。その後、scenario-asset-analysis でパネルとページをコレクションに保存します。

よくある間違い

• 1回の実行でページ全体を生成する：1つのプロンプトから生成したパネルは個別に再生成できないため、1つのパネルの失敗でページ全体を作り直すことになります。
• プロンプトにセリフを入れる：生成された文字は崩れたり文字化けしたりするため、アートには文字を入れず、後からレタリングします。
• パネルを順につなげる：パネル3の生成にパネル2の出力を使うと、ずれが積み重なります。すべてのパネルを、承認済みの同じ主人公に基づいて生成します。
• 「前と同じキャラクター」と書く：呼び出し間で記憶は引き継がれません。毎回、基本設定の全文を記載します。
• 後半に続く変化（パネル4以降で新しい衣装にするなど）を、古い主人公に対するパネルごとの節として指定する：参照画像によって古い衣装に戻されます。最初の主人公を元に、変更点を記載して2人目の主人公を生成し、承認を得てから基本設定を書き直します。後半のパネルは、その主人公を基準にします。
• 未承認のパネルをアニメーション化する：画像の費用は安くても、動画の費用は安くありません。scenario-video-ads が絵コンテの価格を先に確認するのと同じように、費用のかかる工程には承認の段階を設けます。
• キャラクターが混ざる：1つのパネルに複数の主人公が登場する場合、プロンプトで各参照画像の役割を指定し、シーンを計画する前にスキーマの参照上限がキャスト数に足りるか確認します。その他の人物は一般的な外見にして、名前を付けません。見分けられる必要があるキャストだけに基本設定と枠を割り当てます。
• モデレーションでブロックされたアクションシーンを諦める：プロバイダーが武器や戦闘のパネルを拒否する場合があります（moderation_blocked）。そのパネルの節を調整して武器を目立たなくし、基本設定から再生成します。