vigen（AI動画制作支援）は何をしますか？

1つのアイデアや台本を、生成ツールに直接コピーして使える完全な動画制作プランに変換します。対象は映像制作の初心者です。絵コンテ、カメラワーク、照明、プロンプトエンジニアリングは本スキルが補完し、ユーザーは重要な確認ポイントでのみ判断します。

成果物：プロジェクトディレクトリ内の一連のファイル——台本、定義表（キャラクター/シーン/小道具/スタイル）、画像プロンプト、動画プロンプト、音声セリフ表、編集リスト。シリーズプロジェクトの場合、エピソード間のプロット状態ファイルも含みます。6つの課題を解決します：AI臭さの排除、4層の一貫性、アクションの物理的な妥当性、カメラワークとトランジションの表現力、プロットの完全性、モデルでの実行可能性。

本ファイルの位置づけ（読む前に理解すること）

本ファイルは「何をすべきか」のみを記述し、「具体的な書き方」は記述しません。 各ルールの完全な記述は1つの場所（下表）にのみ存在し、本ファイルは判断可能な要点とポインタのみを提供します。

⚠ 要点だけでは適切なプロンプトを生成できません——スロット、例文、パラメータについては、その「家」を読んでください。本ファイルの記憶だけで作業しないでください。

ルール帰属表（各ルールの唯一の家）

概念	家
骨格 A/B スロット、小道具6つの判定、L1-L4 グレーディング出力、参照画像6つのハード基準、参照画像取捨順序、秒単位のタイミング、禁止シーケンス、発声記述式、検証ルール	references/prompt-rules.md
4層の定義付け、スタイルバイブル、頭身分離、キャラクタールーティング、参照画像重み規律、ベース参照法、最小参照セット、声質自己抽出、シリーズ記憶、無効伝播	references/consistency.md
40のカメラワーク、8の生成側トランジション + 5の編集側トランジション、カメラ位置の意味、尺の区分、機能決定表、ピークと強調手段、リズムテンプレート	references/cinematography.md
16のスタイルライブラリ（Pixar 3D含む）、カラー基調パレット、スタイル抽出夢解読カード、プロジェクトスタイルの分離	references/styles.md
AI臭さの排除、テンションの4つの方法、表面2段階と形状制約、王朝ルール、テキストの物理化	references/realism.md
モデル能力、生成パス、参照画像上限、尺の上限	references/models.md
7大バグ自己チェック、フックとサスペンスの規律、ストーリー3層分離、GATE1.5ルール、ストーリーボード4コマ、フォームBカバレッジルール	references/screenwriting-craft.md
プラットフォームショートドラマ立ち上げ、グレードとエピソード数、40のジャンル、流派/感情契約、ユニットチェーン、6段階の証拠、ペイウォール、最初の3エピソード	references/short-drama-market.md
コンテンツコンプライアンス（届出分類/11のレッドライン/センシティブワード置換）——「プロンプトがブロックされる」とは別のレイヤー	references/content-compliance.md
否定的な単語の有効性は生成側の判断による	references/knowledge-index.md
00-06 ファイル構造と穴埋めスロット	assets/templates.md

重複は欠陥：同じルールが2つのファイルに書かれていると、遅かれ早かれ矛盾が生じます——V2.4で修正した「アクションの容量は尺に応じてスケーリングされる」は3つのコピーが存在したため、2つの古いコピーがV2.8まで漂っていました。重複を発見したら、帰属表にある家を保持し、残りはポインタに変更します。

ディレクトリ構造（Module Map — 必要に応じて読み、一度に全部読まない）

ファイル	いつ読むか
references/screenwriting-craft.md	フェーズ1a 脚本作成時は必読
references/short-drama-market.md	GATE0で「ナラティブ形態=縦型ショートドラマ」と判定された場合、一度に全部読む（プラットフォーム/グレード/エピソード数/ジャンル/流派/感情契約/ユニットチェーン/ペイウォール/最初の3エピソード）；映画的なプロジェクトでは読まない
references/content-compliance.md	縦型ショートドラマプロジェクトのフェーズ1a 執筆開始前 + GATE1.5前は必読（届出分類/11のレッドライン/センシティブワード置換）；映画的なプロジェクトでは読まない
references/prompt-rules.md	あらゆる画像/動画プロンプトを書く前（4つの基本的な認識を含む）
references/models.md	ニーズアンケート後にモデルを決定する時；モデル変更時
references/cinematography.md	絵コンテをデザインする時（カメラワーク/8の生成側トランジション+5の編集側トランジション/ショットサイズ/カメラ位置/照明オプションライブラリ/ピーク割り当て/ショット尺とリズム/縦型構図の安全ゾーン/7つのシーンタイプのショットシーケンス）
references/styles.md	フェーズ1 スタイル決定時
references/consistency.md	定義表（02）とショット間/エピソード間の一貫性問題の構築時
references/realism.md	人物/シーン/情景図プロンプト作成時
references/examples.md	完全な例を参照する必要がある時
references/knowledge-index.md	フェーズ1 スタイル/絵コンテ決定時にまずこのインデックスを読む——必要に応じて拡張知識を配置（FACSマイクロ表情/アクション/映画レベルのパラメータ/監督スタイル/マルチビュー/感情方法論/UGCテクスチャ/2D to リアル）、該当するシナリオがヒットした場合のみ対応ファイルを読む；アクションシーンプロジェクトはaction-combat.mdを必読。expressions.md の読み取りタイミングは早期化（V2.9）：フェーズ5を待たない——フェーズ2-4 で情景図の演技状態フィンガープリント/演技タイミングを書く時に読む（画面内の人物の表情と身体姿勢は画像側で既に発生している）；実戦の教訓：演技仕様をフェーズ5に延期すると、キャンバス上で演技タイミングを書く根拠がなくなり、独自に研究することになる
references/content-safety.md	プロンプトが審査でブロックされた後は必読——段階的な解決策を探す（表現レベルの解決策ライブラリ/構図レベルのパターンテーブル/二分法位置付け）。ハイリスクなテーマを書く前に「既に登録されているパターンに該当するか」のみをチェックする（同ファイルの第2節・第3節 + プロジェクト03仕様節）——リアクティブなグレードダウン（V2.9 ユーザー判断）：未登録の内容は通常通り書き、予防的な感度低下は行わない
references/execution-pitfalls.md	check.py がローカル/サンドボックスで実行できない時（第6節の処置）；またはユーザーが実行時の操作上の問題を尋ねた時；日常的なワークフローには含めない
assets/templates.md	プロジェクトファイル作成時

⚠ references/_archive-suspended-claims.md は停止された主張のアーカイブです。どのフェーズでも読まないでください。その内容はルールの根拠として使用しません。 ⚠ references/learning-guide.md（自身の欠陥リスト/使用境界/資料吸収台帳）日常のプロジェクト実行ワークフローには含めません——①ユーザーが新しい学習資料を提供した場合 ②ユーザーがスキルの欠陥/境界/学習状態を尋ねた場合のみ読みます。その際は、その第1節の4ステップ学習法に従って処理し、台帳を更新します。

GATE0：ニーズ収集アンケート（トリガー後最初のステップ、すべての生成より先）

ユーザーに積極的に質問し、一度にすべて列挙します。ユーザーのメッセージで既に説明されていることは繰り返し尋ねません。

コンテンツソース：1つのアイデア / 大まかな台本（私が詳細化）/ 完全な台本（私が直接絵コンテ化）
単一エピソードかシリーズか：シリーズの場合は予定エピソード数、各エピソードが連続したプロットかどうかを尋ねる
目標尺：単一エピソード/単一作品のおおよその尺（15秒 / 30秒 / 60秒 / それ以上）
生成モデル：画像生成（デフォルト gpt-image-2.5）/ 動画（happyhorse-1.1 / MiniMax-H3 / その他）——尺と参照画像上限を決定し、Read references/models.md でユーザーに能力リストを提供；同時にベンダー/ゲートウェイを確認する（同名モデルでもプロバイダーが異なると能力が異なる可能性がある——ロック時に明記し、生成前に実測で探る、「能力実測優先」節参照）
アスペクト比：9:16 縦型 / 16:9 横型
音声：動画モデルの能力に応じて選択——happyhorse は内蔵音声を使用（音声参照なし）；H3・Seedance・ジモン系は内蔵音声または音色参照の自己抽出を使用；厳密な音色一致が必要か、直接出力に不満がある場合のみ cosyvoice でトラッキング（ルートの3択と試聴セグメントのタイミングは consistency.md 第4節参照）
（動画モデルが H3 の場合必ず質問）生成パス：プラットフォーム/App（H3-Context-IR 含む、例：Toonflow、ハイルー、公式API）→ 中国語骨格 A が直接使用可能；H3-Base に直接接続 → マッピングテーブルに従って構造化フィールドを出力する必要あり。判定は prompt-rules.md 生成パス判定節参照；パスが不明な場合、「IR含む」として扱い、04ファイルヘッダーにその旨を明記する
演技のトーン：抑制的（デフォルト——叙情的/ドラマチック/スリラー/正統派向け、表情の幅が小さい）/ ニュートラル（日常）/ 外向的（コメディ/誇張された感情表現）——FACE LOCKスロットと演技タイミングの幅の基準を決定する。実戦の教訓：これを尋ねないと、モデルはデフォルトで笑顔と誇張された表情を与え、毎回手直しが必要になる
ナラティブ形態とプラットフォーム（セリフの口径とエピソードのグルーピングを決定）：映画的（デフォルト——ショートフィルム/正統派/スタイライズドナラティブ）/ 縦型ショートドラマ（紅果・抖音の有料ショートドラマ）。縦型ショートドラマを選択した場合、さらに質問：
- プラットフォーム（紅果/抖音/その他）とグレード（標準 90~~120秒 / 長尺 150~~195秒 / 漫画ドラマ 60~90秒）
- 総エピソード数（60/80/100 または 30/40/50、カスタマイズ可能）とペイウォール（標準3段階 / プロモーション先行 / 壁なし広告収入分配）
- ジャンル（40のジャンルメニュー、short-drama-market.md 第3節参照）と流派（感情流/プロット流）
- 公安/司法/国家安全/民族/宗教/外交に関係するか（関係する場合、届出カテゴリー=第1類） → 縦型ショートドラマを選択後 Read references/short-drama-market.md、立ち上げ仕様を00（シリーズ）または01（単一動画）に書き込む

アライメント義務（ハードゲート）：ユーザーのアイデア/台本を解析する際、矛盾、曖昧さ、重要な情報の欠落（登場人物の動機不明、プロットの衝突、尺とコンテンツ量の不一致、シーンの説明の欠落）を発見した場合 → 問題リストを作成してユーザーに質問し、自分で補完しない。アライメント後にフェーズ1aに進む。

アンケート回答とアライメント結論（スキル補完項目含む）は直ちに01の「GATE0 アライメント記録」節に書き込む——ファイルが真実であり、中断からの復旧は全てこれに依存する（効率義務節参照）。

プロジェクト構造：

単一動画プロジェクト：カレントワーキングディレクトリの <プロジェクト名>/（01-06 フラット）
シリーズ/マルチエピソードプロジェクト：<シリーズ名>/00_プロット状態.md（シリーズレベル、エピソード間で共有）+ <シリーズ名>/ep01/、ep02/…（各エピソードの独自の01-06）
同名ディレクトリが既に存在する場合 → 意図ルーティング（続編 / 対象修正 / フェーズやり直し）

ワークフロー（6フェーズ、台本先行）

GATE0 アンケート+アライメント → フェーズ1a 脚本作成 ─GATE1.5 台本確定─→ フェーズ1b 絵コンテ+定義 ─GATE1─→ フェーズ2-4 画像プロンプト → フェーズ5 動画+セリフ → フェーズ6 編集リスト →（シリーズ：00_プロット状態を更新）

各フェーズのフォーマットは：何をするか → 何を読むか → 何を生成するか。ルールの詳細は読むファイルにあり、ここでは繰り返さない。

フェーズ1a 脚本作成（GATE1.5 まではこれだけを行う） ユーザーのアイデア/大まかな台本を詳細なシーン台本に変換する。Read references/screenwriting-craft.md——その7大バグ自己チェックリストを1つずつ確認し、コンフリクトシーンは最初にシーンエンジンワークカードとエスカレーションの6つの質問（第1節・第4節）を確認し、エピソード分割ナラティブの場合は当該エピソードの決済（第1節・第5節の第5条）も確認する、エピソード/セグメント分割ナラティブの場合はフックとサスペンスの規律と知識公開状態も確認する；ユーザー素材を適応する場合は、ストーリー3層分離に従って記録する（GATE1.5で提示する際に「あなたの原文」と「スキル補完項目」を区別する）。 ナラティブ形態=縦型ショートドラマの場合：別途 references/short-drama-market.md + references/content-compliance.md を読み、screenwriting-craft 第1節・第9節フォームBカバレッジルールに従って書く（セリフは同ラウンドで直接提供/15秒4拍/エピソード内決済/強い画面密度/モノローグ枠）、台本の末尾に【当該エピソード決済】【当該エピソード中盤の小さなフック】（長尺用）【当該エピソードの章区切りポイント】を記入する；映画的なプロジェクトではこれらの2つのファイルを読まず、これらのフィールドも記入しない。成果物：台本を 01_プランと台本.md の台本節 + シーンのビート表 + 尺予算（screenwriting-craft 第1節・第8節）+ 自己チェック結果に書き込む。絵コンテは行わず、定義表は作成せず、プロンプトは一切書かない。 フェーズ1aでは絵コンテは未構築、「担当ショット番号」は未発生——check.py --partial の下で K13 はビート構造のみをチェックし、担当ショット番号はフェーズ1bで補完する。

GATE1.5 台本確定（ハードストップ——未確定で絶対に1bに進まない） チャットでプロット概要+キャラクター表+シーン台本全文+ビート表サマリー（いくつのビート/フックは何ビート目/予定尺 vs 目標）+7バグ自己チェック結果+未決問題を提示し、ユーザーに「台本確定後は絵コンテと定義に進みます；以降の台本変更=下流全てやり直し、今が修正コスト最小のタイミングです」と伝える。縦型ショートドラマプロジェクトの場合は、content-compliance 第6節のコンプライアンス自己チェック結果も添付する（届出/レッドライン/センシティブワード/フック強度）。ユーザーが不満な場合 → 修正して再提示し、ユーザーが明確に確定するまでループ；確定結論は01の「GATE1.5 台本確定記録」節に書き込む。ユーザーが完全な台本を持っている場合、「自己チェック+問題リスト」の提示に簡略化する（台本本文は再提示しない）が、自己チェックはスキップ不可——バグ4/5/7を発見した場合、黙って修正せずユーザーに注意を促す。 確定でロックするのはストーリーの骨格とプロットポイントリストであり、絵コンテ表ではない——絵コンテ表は生きたドキュメントであり、その後のショット追加/削除は意図ルーティングの生きた台本改訂による。

フェーズ1b 絵コンテ+定義 確定した台本を解析する（テーマ/尺/スタイル/感情）→ プロットポイントリスト → 絵コンテ → 定義表。

プロットポイントリスト：確定した台本をプロットポイントに分割して01に書き込む（各行1ポイント）、絵コンテは100%カバーする必要がある——勝手なプロットの削除/変更を防ぐ
ビート担当：絵コンテ表の「担当ビート」列にB区間を書く（例 B4-B5）；1つのショットで複数のビートを担当可能、純粋なトランジション/空ショットは — と書く；ビートは重複なく漏れなく、順序はショット番号と一致する（A14/K13）
ストーリーボード4コマ分割（screenwriting-craft.md 第4節）：1つのショットは1つの質問にのみ答える；バッチで生成し、最初のバッチを先にチェックする
分割尺は予算に応じて区分（cinematography.md「ピークと強調手段」節 ③）：まずコンパクトな予算で分割し、デフォルトで上限まで埋めない；スローモーションは既に指名されたピークにのみ使用する
スタイル決定：Read references/styles.md → スタイル選択後すぐに全編のカラーベースを決定する（3-5の16進数カラーコード、シーン画像を生成する前に）
絵コンテデザイン：Read references/cinematography.md（カメラワークとトランジションの両方をデザインし、トランジション列は強制選択；カメラワークは物理パラメータレベルの5要素まで書く）；反先験的動作を特定し、絵コンテ表に注釈を付ける——これらのショットは情景図で姿勢をロックする。9:16プロジェクトは同第7節に従って縦型配置/安全ゾーンを設定する；シーンが第8節の高頻度タイプに該当する場合、シーケンス骨格を参照する（譲歩：戦闘は action-combat に従う、スローモーションはピークのみ/ラウンドはR4に従う、2人を上下配置に変更、縦型オープニングは情報を含む）
戦闘セクションは最初に手合わせ帳を作成してからショットを配置する（action-combat.md 第0節——台本に「2人が戦闘」とだけ書かれている場合、直接絵コンテに入ることを禁止する；ラウンド化後、決着手を指名=スローモーションの唯一の配置先）
成果物：01_プランと台本.md（絵コンテ節を追加）+ 02_定義表.md（Read references/consistency.md + assets/templates.md）
- 小道具は prompt-rules.md の6つの判定ルールに従って表に含める；シーンが ≥3ショットで使用されるか、正/反対のショットがある場合 → 4ビュー+ロケーションマップが必要；複数ショットのシーンはシーンマスターテンプレート（4方向アンカー+利用可能な配置アイテム）+各シーン開始時のポジショニングセンテンスを登録する。consistency 第0節のロックリストに従って表を構築する：衣装ロックグレード（デフォルト専用画像）、シーン「持続的に存在する要素」（観客/器具/マット/光色+カラーコード）、繰り返し登場する大型アイテムを登録、スタイル3点セット（バイブル全文+カラーコード+アイデンティティセンテンス）
- 衣装は「1セット1行」で表に含める：キャラクター定義フレーズはアイデンティティレベルの要素のみ残し、衣装説明は02衣装定義表に移す（consistency 第1節・衣装定義）；着替えプロジェクトでは各衣装セットに独立した定義フレーズと参照画像

GATE1（必ず停止） チャットでプランサマリー（選択したモデル含む）+ 各キャラクター/衣装/小道具の定義フレーズ全文 + 各シーンのデザイン意図 + 一貫性アンカー3-5 + スタイルバイブル全文 + カラー基調パレット（カラーコード+配置先） + ピーク-強調手段割り当て表（当該エピソードのピーク数、各ピークに何の手段を使用するか、対応するショット番号——cinematography「ピークと強調手段」節参照）を提示し、ユーザーの確認を待ってから続行する。定義フレーズとカラーパレットはその後のすべてのプロンプトに逐語的に含まれ、ここでの変更コストが最も低い。

フェーズ2-4 画像プロンプト 成果物 03_画像プロンプト.md。書く前に Read references/prompt-rules.md（4つの基本的な認識含む）+ references/realism.md + references/models.md；人物に感情的な演技/演技状態がある場合、同時に expressions.md を読む（V2.9 早期化——情景図の演技状態フィンガープリントはこの時点で書き、フェーズ5を待たない）。

最初にアセット参照マトリックスを構築する（各アセットがどのショットで参照されるかを登録、0参照なら生成しない——アセットの無駄を防ぐ；マイナーキャラクターに設定画像がない場合はチェーン参照で補完する；ユーザーが完成品アセットを指名した USER-LOCKED の例外は prompt-rules 第1節第4条参照）；マトリックス構築前に既存アセットを確認する——既存プロジェクト/キャンバスに同名アセットが既に存在する可能性がある（実戦の教訓：P05小道具を先に作成してから破棄した、P04が既に存在したため）、該当すれば再利用し再作成しない；01絵コンテ表の「入画小道具」列にアセットIDを書く——各ショットで識別可能な小道具/シーン大型アイテムは03マトリックスに対応するエントリがなければならない、なければアセットを補完するか、画面から削除する（ハードルール17）
人物人物↔シーン↔情景の相互参照を掛ける（それぞれ孤立して画像を生成しない）：情景図は必ずキャラクター定義画像+シーンマスター画像を参照する；同一シーンで異なる状態のショットは確定済みのベース参照画像を参照する；衣装/設定変更時は前のバージョンを参照して古い設定への逆戻りを防ぐ。実戦の教訓：ルールは書かれているが実際の生成時に相互参照が行われなかった → シーンの雰囲気がキャラクターを古い設定に戻し、傷が突如現れた。 3方向参照ルールと双方向スコープ宣言は consistency.md 第3節画像側参照
さらに5節を書く：人物参照画像（白背景3ビュー+顔クローズアップ、頭身分離は必ず2枚の画像として生成し、1枚の設定画像で済ませてはいけない；アニメ/国漫は4ビュー合成画像可、ハードルール12参照；若い人物は皮膚状態の標準センテンスを追加；高顔面浮動/マルチビュープロジェクトはオプションの単一アンカー派生パスを使用可能——0a 正面全身アンカーを修正、0b/側/背面/詳細はアンカー画像から派生、consistency 第3節参照）、衣装着替え参照画像（着替え/服裝セットプロジェクト、各セット1枚の0aと同様の白背景全身、テンプレートは templates 第1節第5条参照）、小道具参照画像（判定ルールに該当する小道具、複数状態を同一画像で生成後、切り抜いて単一画像にする）、シーン参照画像、情景参照画像
情景図は L1-L4 グレーディングで出力し、ショットごとに1枚ではない（1回の動画生成には1つのファーストフレーム位置しかない）——グレード判定と参照画像上限の取捨順序は prompt-rules.md 第1節第3条参照；テキストでロックできない方向/最終状態 → prompt-rules 0.10に従い REF-DIR-<ショット番号>/REF-TARGET-<ショット番号> 画像を追加する
最初のセット全体（3-5枚）を先に出力し、ユーザーに検収してもらってから量産する——画風/一貫性/構図が問題なければ続行；画像4点スキャン（同一世界/顔と衣装が設定画像と一致/ショットサイズが一致/余計な人がいない）。プロンプトを画像ではなく納品する場合：初回検収と画像4点スキャンはユーザーが生成後に実行；スキルは01検証記録に「未実行（画像なし）」とマークし、通過とマークしてはならない
生成後、特定のショットが基準を満たさない場合は後から画像を補完可能；ユーザーが参照画像を提供し「こんな感じ」と言った場合 → styles.md スタイル抽出（夢解読カード）に従って動的スタイルバイブルを生成してから画像を出力する

フェーズ5 動画プロンプト + セリフ 成果物 04_動画プロンプト.md——prompt-rules.md 骨格セレクターに従う：デフォルト骨格 A（1セグメント複数ショット+トランジション）；骨格 B は fl2va、ワンカットのテンション、または複雑なシーンを複数の単一ショットセグメントに分割しユーザーが編集で結合する場合に使用する（01に理由を明記すること）。

ACTIVE REFERENCES 使えるものは全て使う（同一オブジェクトはまず唯一の権威で判断——同一オブジェクトの画像を並列で全て参照することはできない）、グループ化戦略とキャラクター最小参照セットは prompt-rules.md / consistency.md 参照
セグメント間のラストフレーム相互接続（V3.7 標準手順）：セグメントNの生成完了 → ユーザーにラストフレーム抽出を積極的に促す → セグメントN+1 独立したファーストフレーム位置があればそこに配置；混合参照（Ref2VA）の場合はキャラクター最小参照セットを優先し、ラストフレームはその後に配置する（キャラクター画像を押し出さない）、SCENE CONTEXT でそれを参照して継続する（全文は prompt-rules 骨格 A「セグメント間ラストフレーム相互接続標準手順」参照）。フレーム抽出はツールレイヤーであり、スキルは代行しない；すべてのセグメントの生成完了を待ってから一括抽出しない。ラストフレームが未出力の場合、PLAN-TAIL-<N> プレースホルダーを書き、通常通り生成する、抽出後 REF-TAIL-<N> をバインドし、ラストフレームを待って停止しない（E2と同様のヒトとマシンの並行処理）
H3 マルチ画像アライメントプロジェクト（オプション）：prompt-rules「生成パス判定・マルチフレームレシピ」に従い、各セグメントのカットポイントを秒単位で固定する；ベンダーがサポートしない場合は骨格 A ラストフレーム継続にフォールバックし、何度も再試行しない
戦闘ショットブロックは攻防ステートマシン7段階を使用する（3段階のアクション記述は書かない、action-combat.md 第7節参照）、非戦闘ショットブロックは3段階のアクション記述を使用する；決定的なアクションには秒単位のタイミング+演技禁止シーケンス+因果連鎖を追加
各セグメントに FACE LOCK 表情ロックと環境動的レイヤーを含める；各ショットの生成尺は models.md の上限に対してハード検証し、超過した場合は自動的に分割し、ラストフレームで継続する
成果物 05_音声セリフ表.md（セリフなしプロジェクトは簡略化ブランチで第⓪節のみ記入；セリフありルートは動画モデル能力に応じて選択——happyhorse は内蔵音声、H3 は音色参照の自己抽出が可能、厳密な一致が必要な場合のみ cosyvoice でトラッキング、consistency.md 第4節参照）
無声出力ルート（consistency 第4節「無声出力ブランチ」）：04動画プロンプトにセリフを書かず、口の動き/画外音デザインのみを書く（背中/横顔/口を閉じる/画外音のソース）；セリフ原文は05と01にのみ残し、TTSで後からトラッキングする
セリフには必ず感情を含め、「怒って言う」だけではいけない：各セリフに発声記述式をバインドする（前置き身分2段階 + 6パラメータ、8段階は全て必須）、アクション連鎖に埋め込み、独立した行としては書かない。実戦の教訓：感情ラベルのみを書く→生成される台詞に抑揚や速度の変化がなく、棒読みになる。 書き方と4つの禁止事項は prompt-rules 第3節第5条参照

フェーズ6 編集リスト 成果物 06_編集リスト.md（結合順序、各セグメントの頭と尾をそれぞれ0.5秒カット、トランジション実現方法は01トランジション列に対応、トランジションのオーディオ処理で背景音/効果音の唐突な中断を防ぐ、BGMは後で一括調整、カラーグレーディングのヒント；H3 プロジェクトは動画保存期限切れ前の転送に注意）。ショット尺は cinematography 第6節のベースラインに従う（骨格 A セグメント内では再カットせず、セグメントの頭と尾のみカット；骨格 B/単一ショットセグメントの場合のみベースラインでカット）；編集側トランジション（ディゾルブ/フェードイン・アウト/フラッシュブラック/ズーム/ワイプ）は06で実現し、04では該当カットポイントにハードカットを書く（カットポイントごとに、同じセグメントの他のトランジションを上書きしない）；縦型プロジェクトは別途安全ゾーン/オープニングフック/呼吸ポイントのチェックを行う。

シリーズプロジェクト追加：各エピソード完了後、強制的に 00_プロット状態.md を更新する（当該エピソードのプロット概要/キャラクター状態変化/小道具状態変化/当該エピソードのラストフレーム記述/未回収の伏線）——次のエピソード開始時に00を読み、前のエピソードのラストフレームも読み、長編ドラマでの細部の忘却を防ぐ。

全て完了後、チャットではサマリーのみを提供する（プロジェクトパス + 各ファイルの1行説明）、ファイル内容は繰り返さない。

報告規律（サマリーの固定フォーマット）：定量結果（いくつのセグメント/ショット/総尺 vs 目標尺/画像プロンプトの枚数）+ check.py 結果（全通過/どの項目が不合格でどう修正したか——ハードルール15） + OPEN 項目（どの項目がその場で検証不可か、バックフィル時期） + 保留画像リスト（PLAN プレースホルダー項目：どのショットがどの画像を待っているか、画像ができたら REF をバインドして確定後再読をトリガー） + プロジェクトパス + 不合格だった検証項目の指名（隠さない）。3つの虚偽報告禁止：①「画像を出力済み/動画を生成済み」と言わない（スキルが納品するのはプロンプトであり、画像ではない）②生成結果を見ていないのに「効果はとても良い」と言わない③ユーザー素材を引用する際に途切れたり不完全な場合、はっきりと伝え、全文を読んだふりをしない。

意図ルーティング（優先順位で判断）

対象修正：プロジェクトディレクトリが既に存在し、指示が特定のショット/ファイル/フェーズを指している → 該当ファイルの関連部分のみを修正し、残りは変更しない
続編：プロジェクトディレクトリが既に存在し、指示が曖昧（「続けて」）→ 01-06（シリーズ：00+現在のエピソード）の完了度を確認し、最初の未完了フェーズから続行；シリーズ続編 → まず00_プロット状態.mdを読む
新しいアイデア/新しい台本の全フロー：新しいアイデアや台本 → GATE0 アンケート → フェーズ1a から開始（GATE1.5 と GATE1 を経由）
生きた台本の改訂（ショット追加/削除/プロット変更）：プロジェクトが既に進行中（02 が凍結済み）+ ユーザーがショットの追加、プロットポイントの削除、特定セクションのプロット変更を要求 → 以下の局所リシャッフルを実行し、GATE1.5 を再実行せず、03/04 を全量書き換えない
フェーズやり直し：特定のファイルのやり直しを明確に要求 → 該当ファイルを再生成し、無効伝播ルールに従って下流をマークする（consistency.md 第6節）

生きた台本の改訂：局所リシャッフル（実戦の教訓——03 がこれにより2回全量書き換えられた）

実際の AI 動画制作は直線的ではありません：ユーザーは画像を見た後、ショットを追加したくなったり、1つのラインを削除したくなったり、特定のプロットを変更したくなったりします。GATE1.5 の確定でロックされるのはストーリーの骨格とプロットポイントリストであり、絵コンテ表ではありません——絵コンテ表は生きたドキュメントです。

局所リシャッフル4ステップ（影響を受ける部分のみを変更する）：

プロットポイントリストを変更する：該当行を追加/削除/変更し、改訂日と根拠（ユーザーの発言の要点）を注釈する——これが変更が必要な唯一の「上流」です
影響範囲を判断する：新しいプロットポイントがどのシーン/キャラクター/小道具に影響するか？→ 02 定義表は新しいエンティティが追加された場合のみエントリを補完する（既存の定義は変更せず、変更があった場合のみ無効伝播を実行）
ショット番号を挿入し、再シャッフルしない：安定ショット番号（下記）を使用して新しいショットを挿入し、既存のショット番号は一切変更しない——既存の03/04の内容は無効にならない
新しく追加/変更されたショットのプロンプトのみを書く：03/04の該当節に追加し、改訂日を注釈する；隣接するショットは「1拍変更で3拍連続読み」で再確認し、残りは触れない。既存ショットのプロンプトを変更する場合、セリフ/ショット番号/生成尺は凍結フィールドである——01から逐語的にセリフをコピーし、書き終えたら逐語的に読み返して照合する（ハードルール4）

安定ショット番号ルール（ハードゲート）：ショット番号は一度割り当てられたら決して再シャッフルしない。挿入にはサフィックス式を使用する——S3 と S4 の間にショットを追加する場合 S3a と書く（または01絵コンテ表に「S3a（v2 追加）」行を追加）、S4 を S5 に変更しない。理由：再シャッフルすると 03 のアセット参照マトリックス、04 のセグメント、キャンバス/生成側の既存ノードが全てずれる。実戦のコスト=03の全量書き換え。廃止されたショットは絵コンテ表で ~~S3b~~（v3 廃止） とマークし、行番号は保持して行を削除しない。

セグメントベースの生産ユニット（V2.9——ユーザーが口述で1セグメントずつ行う実際のリズム）：局所リシャッフルはショットレベルです；ユーザーが追加するのが完全なプロットセグメントである場合（新しいプロットを口述→情景図グループ→動画ノード→検収→次のセグメント）、生産ユニットは「セグメント」であり「ショット」ではありません。以下の最小クローズドループに従い、GATE1.5 を再実行せず、絵コンテ表を全量リシャッフルもしません：

セグメントをリストに追加：新しいセグメントのプロットポイントを行ごとに01プロットポイントリストに追加する（改訂日+ユーザー口述の要点をマーク）、セグメント番号と安定ショット番号（サフィックス式）を割り当てる
既存アセットを判断：該当セグメントが触れるシーン/キャラクター/小道具をまず02と03のアセットマトリックスで確認する——既存の定義と参照画像は直接再利用し、新しいエンティティが追加された場合のみ定義エントリを補完/新しいアセット画像を出力する
セグメント内自己完結型生産：該当セグメントの情景図グループ（L1-L4 グレーディングに従う）→ 動画セグメントプロンプト（骨格 A）→ セリフ（01から逐語的にコピー）——一通り終えたら check.py --partial を実行し、通過したら自動的に次のセグメントに進む；バッチ（すべてのセグメント）完了後、一括報告（定量結果+check結果+不合格項目の指名）。参照画像が未生成の場所には PLAN-<ID> プレースホルダーを書き、通常通り生成する（停止規律 E2 参照）、画像を待って停止しない
セグメント検収後の同期：検収通過 → 01絵コンテ表に該当セグメント行を追加、03/04に該当セグメント節を追加、02は新しいエンティティがある場合のみ変更；ラストフレーム記述は該当セグメントのレコードに書き込む（次のセグメントの SCENE CONTEXT 接続アンカー）

6フェーズとの関係：セグメントベースはフェーズをスキップするのではなく、フェーズ2-6 をセグメント単位でスライスして実行する——定義（02）と台本骨格（01プロットポイントリスト）は全プロジェクトレベルであり、セグメント内では該当セグメントの画像/動画/セリフ/編集項目のみを行う。最初のバッチのショットは依然として「最初のセット全体を出力してユーザーに検収してもらってから量産する」を守る。

改訂記録：各ラウンドの改訂を01に1行の変更記録として追加する（何を変更したか/影響範囲（ショット番号・プロットポイント・フェーズ）/影響ファイル/ユーザーの発言の要点）、履歴節を書き換えない——01の改訂軌跡自体が中断からの復旧の根拠である。単一書き込みポイント（V2.9）：変更記録は01にのみ書く；00/02には変更履歴を重複して記録しない——02はフィールド自体のみを変更（定義エントリの更新）、00はエピソード完了時にのみプロット状態を更新する。3箇所全てに書くと検索性が悪く、必ず1箇所の更新が漏れる。

生成側変更の書き戻しリスト（V3.7）：キャンバス/生成側でプロンプトを変更した後、3箇所に書き戻し、逐語的に確認する——①04該当セグメントブロック ②05セリフ（該当する場合）③01絵コンテ表（尺/接続/改訂記録）；OPEN 項目をクローズ、PLAN/REF バインディングを更新。手動での二重書き込みは漏れやすいため、書き戻し後 check.py --partial を実行する。

キャンバス/生成側をソースとするプロジェクト（ユーザーがツール内で直接変更する）

Toonflow のようなキャンバスで生成を実行する場合、ユーザーはしばしばキャンバス上で直接プロンプトを変更したり、ノードを移動/削除したりします——この場合、キャンバスが実行側の事実であり、01-06 は決定ソースです。両者の関係：

リアルタイム同期は追求しない（実戦：「同期」と呼びかけてようやく追いつく、しかも毎回の同期は無駄）→ バッチ遅延同期に変更する：1ラウンドの生成が一段落した時点で集中同期を1回行い、同期内容は「サマリーカード」（ノードID + 1行の状態 + ドキュメントとの差分ポイント）として書き、全文を逐語的に書き戻さない
競合裁定：キャンバスとドキュメントが一致せず、ユーザーがキャンバス上で既に確定している場合 → キャンバスを優先し、ドキュメントは差分を記録し決定を更新する（キャンバスをドキュメントに戻すのではない）
確定マーク：ユーザーがキャンバス上で自ら作成した「確定画像を別保存して汚染を防ぐ」ノードは有効なプラクティスです → ドキュメントのアセットマトリックスに確定マークノードIDを登録し、再生成時に上書きしない
ノードIDは表を参照し、推測しない（V3.7）：キャンバスノードIDの唯一のソースはプロジェクト対照表（02/03アセットマトリックス、キャンバスサマリーカード）です；エージェントは記憶や類似度に基づいてIDを推測・創作してはいけません。表にない場合 → 停止して表を確認するかユーザーに尋ね、未登録のIDに接続/操作しない（実戦：IDを推測すると間違ったノードに接続したり、バッチ全体が静かに実行されなかったりする）
ref番号=接続作成順序（V3.15 修正）：通常の追加は新しい番号（ref7/ref8）を追加するだけで、既存の順序を乱さない——プロンプトは画像参照順序表に追加するだけでよい；「途中挿入により既存のrefを再シャッフルする必要がある場合」のみ、すべての既存入力線を削除し、最終順序で再接続する。どちらの場合も、04画像参照順序表は同期して変更しなければならず、{{ref N}} と用途宣言の1対1対応を逐一確認する（古いキャンバスでは v21/v22 の挿入位置がずれていた実戦事例あり）
生成側が全文再送しかできない場合のバージョン管理（V3.9 実戦；現在のキャンバス setPrompt）：生成側に部分編集機能がなく、再送前に現在のプロンプトをバージョンサマリー（バージョン番号+変更点）として保存し、01の変更記録に書き込む；再送後、04ドキュメントと比較し、コンテキスト記憶で現在のバージョンを判断することを禁止する（間違ったバージョンを持ち込む=セグメント全体のやり直し）。キャンバスソフトウェア変更後もこの規律は保持され、具体的な操作は新しいツールに合わせて書き直す。
同期トリガー：ユーザーが「同期」と言った時、または1ラウンドの生成が終了した時、またはフェーズ5/6に入る前——3つのトリガーポイント、それ以外の時間は同期しない

能力実測優先（実戦の教訓：GATE0でロックした「H3動画でセリフ直接出力+音色自己抽出」メイン案が、ゲートウェイ版H3がオーディオをサポートしていないために直接無効になった）：GATE0でロックした能力リストは計画の根拠であり、保証ではない——生成前のツール側の実際の使用可能な能力を優先する；メイン案が無効になった場合、代替ルートに切り替え（音声→cosyvoiceトラッキング）、01/02に切り替え理由を記録し、既にサポートされていないと判断した能力を何度も再試行しない。チェックポイント化（V2.9）：GATE0でモデルをロックする際、ベンダー/ゲートウェイを明記する（同名モデルでもプロバイダーが異なると能力が異なる可能性がある——moma と apiMart の H3 generateAudio は一方が拒否し他方が受け付ける）；生成前に、現在のベンダーに対して主要能力を実測で探る（オーディオ直接出力/参照画像数とサイズ/尺上限）、既に登録されているベンダー差異は models.md「ベンダー差異メモ」節を確認し、実測結果がメモと矛盾する場合は、当該実測結果を優先し、バックフィルする。

単一ポイント変更再確認規律（1拍変更で3拍連続読み）：任意のショット/ビートを変更した後、前後1拍ずつを必ず再読みし、3つのことを専用にチェックする——人物位置（ポジショニングセンテンス/ロケーションマップは成立するか）、小道具の手持ち状態（前のショットで左手にあったものが、このショットで右手にあってはいけない）、誰がその場にいるか（エキストラはデフォルト0のまま成立するか）。書いている時は空間状態が頭の中にあるが、変更している時はそこにない——連続読みしない=瞬間移動が発生する。

変更前にまず自己復唱（V2.9 実戦の教訓 + V3.0 で自己証明に格下げ）：ショット微調整（カメラ位置/ショットサイズ/構図/持ち手方向などの指示）でプロンプトを変更する前に、まず一文で自分が理解した構図を復唱する（「私の理解：真上からの俯瞰、彼女は彼の右隣に並んで座り、2人には接触がない」）と01の変更記録に書き込む；口頭での曖昧さリスト（正面/横顔/わずかに見上げるなど）に該当し、かつコンテキストで曖昧さを解消できない場合にのみユーザーに質問する。曖昧さ解消は cinematography 口頭曖昧さリストに従う。復唱1文のコスト ≈ 0、やり直し1ラウンドのコスト = 1回の生成 + 1回の待機——自己復唱は 95% の理解のずれを書き出す前に防ぎ、真の曖昧さのみを質問に昇格させる
情景図確定で再読をトリガー（V2.9——「1拍変更で3拍連続読み」を事後対応からデフォルトアクションに変更）：任意の情景図/ファーストフレーム図が確定した時（変更後の再確定を含む）、その画像を参照する全ての動画セグメントの該当ショットブロックを必ず再読し、セグメントごとに画面記述と新たに確定した画像が一致するかを確認する（姿勢/持ち手/位置/服装）——一致しないショットブロックはその場で変更し、生成失敗を待たない

同様に：音景もアクション指示である——音景に「銅鈴が衝突時に炸裂する」と書けば、動画は本当に衝突を演じる；画面変更は3箇所を同期して変更しなければならない（ショットブロック画面記述/AUDIO音景/01絵コンテ表）、カット変更は隣接カットを読まなければならない（位置は連続状態である）。

効果が不十分な場合のフォールバック階段（特定ショットの生成失敗/品質が悪い場合、順番に試行）： 階段に入る前に、生成可能性をチェックする（prompt-rules 0.7）：失敗兆候リストに該当する場合（3ステップ以上の手の動き/推測語/否定形アクション/2主体が同一オブジェクトで正確に力を加える）→ まず書き換え5法で実現方法を変更し、シーンは変更しない

… [以下省略のため途中で切れています]

vigen（AI動画制作支援）