ComfyUI H3 シナリオ動画生成 (v5.0 監督レベルの映像言語と産業工学仕様版)

v5.0 主要マイルストーン更新 (2026-11、映像言語の産業化と7つの実運用上の課題への完全対応)

1. ショット用キーフレーム画像の事前生成プロセス (I2V シーン/キャラクター/小道具の統合キーフレーム): キーフレーム画像なしでのT2Vの無作為生成を完全に廃止。各ショットは、動画サンプリングの前に、画像生成モデルを使用して、ショットのカメラ位置、キャラクターの三面図、小道具の設定に基づき、16:9の統合ファーストフレームキーフレーム画像 (keyframe_segXX.png) を生成します。このキーフレームは品質承認された後、I2Vノードに入力され、0フレーム目で骨格、衣服のテクスチャ、小道具の輪郭を固定します。

2. 単一話者ロックと全員発話抑制プロトコル (Speaker Lock & Mouth Suppression): シーン内の全員が台詞に合わせて口を動かすという操り人形劇のような惨状を完全に排除。[Subject 1] で唯一の主要発話者を明確に指定し、[Action 1] で主語と動作を分離し、非発話キャラクターには発話抑制の必須条項 (lips tightly sealed, completely silent, showing tense glare without mouth movement) を追加します。

3. グローバルスタイルバイブル (Global Style Bible) と事前スタイル固定ゲート: エピソードごとにスタイルがランダムに変動する問題を拒否。制作開始前にグローバルスタイルバイブル (visual_genre, environment_base, lighting_base, color_palette, quality_base を定義) を確立し、4つの異なるショットサイズのスタイルサンプルを生成、人間による確認後、全編にわたってスタイルを固定します。

4. ショートドラマに最適化された話速と密度制御 (Pacing & Density Normalization): キャラクターの無駄に長い台詞や引き伸ばしを解決。175フレーム (7.29秒) の標準タイミングにおいて、台詞は厳密に 20～28文字の漢字 (ショートドラマの理想的な話速 3.2～4.0 文字/秒) に一致させる必要があります。また、[Audio 1] で spoken crisply and rapidly without dragging syllables と明示的に宣言します。最初の4.5秒で素早く話し、残りの2.8秒で冷たい視線と動作の反応に移行します。

5. 6つの映画的な動的カメラワークと演技ブロッキングライブラリ (Director Camera & Blocking): 2人のキャラクターが正面から立ったまま会話するシーンを連続させてはいけません！6つの動的カメラワークを強制導入: ① 動線を交差させながらのスロープッシュ、② 小道具のクローズアップから目元へのフォーカス移動、③ ダッチアングルによる斜めの圧迫、④ 背を向けてから振り返る冷たい一瞥、⑤ 耳元に迫る威圧、⑥ サイドライトによるシルエットの対峙。

6. 純正な標準中国語発音規則とASR言語ドリフト防止ゲート (Mandarin Purity & Language Gate): 台詞はすべて中国語に統一 (アラビア数字は漢数字に変換、英文字の略語や不正な記号は除去)。[Audio 1] に Strict Mandarin Chinese dialogue only, standard native Chinese accent, zero foreign tone を強制追加。Whisper ASR言語検出を統合し、非中国語字幕と言語ドリフトを自動的にブロックします。

7. エンジニアリング化されたマスターオーケストレーションパイプラインのクローズドループ: scripts/director_engine_v3.py を実装し、ショットテーブル、プロンプトコンパイル、話速/密度計算、発話主体の固定を全自動化。

v4.1 更新 (2026-11、公式 v2.2 プロンプト規則と175フレームタイミングの深化)

プロンプト仕様を v2.2 にアップグレード:

MiniMax公式プロンプトガイド (references/official/base-en.txt, ref-en.txt) に対応。

カメラワークの三要素 (タイプ+振幅+速度) は自然文でショット内部に記述し、末尾へのタグの羅列は禁止。

素材の使用権限を明確に宣言 (不复制原图机位，不复制占画比例)。

複雑さの予算を厳守: 単一セグメント (175フレーム/7.29秒) では最大 3 主体 + 1 つの台詞文。

セグメント長は主力の175フレーム (7.29秒) に固定:

243フレームは正式に退役、上限は192フレーム (8.00秒) にハード制限。主力は一律175フレームに統一。セグメント末尾には 1.0～1.2秒の無言バッファを確保。

オーケストレーションレイヤーの従順性禁止領域 (ロングショットは空間の確立と顔認識のみ、中近景ショットへの移行のみ。プルバックやウィンドウ越しの移動は禁止)。

Windows UTF-8 ターミナル全体の防御:

force_utf8_stdio() で stdout/stderr を UTF-8 に統一リセットし、GBK/CP936 エンコーディングによる異常クラッシュを防止。

品質チェックとロングショット顔修正ツールチェーンの拡張:

Whisper ASR 台詞品質チェック (scripts/check_dialogue_asr.py)、セグメント末尾のオプティカルフローと継ぎ目の品質チェック (scripts/sop_check.py)、継続セグメント末尾の余白免除 (--tail-exempt)、中・ロングショットの適応的顔修正 (scripts/face_refine_pipeline.py) を導入。

v4.0 更新 (2026-10、産業グレードの初フレーム固定による顔変形防止と映像音楽の二重革命)

初フレーム画像検証 + I2V ジオメトリ固定顔ルール (純粋なテキスト生成動画 T2V における顔変形と小道具のソフト化を根本的に解決): 単一のテキスト生成画像はわずか 5～15 秒で生成可能、不満があれば数秒で再生成。初フレームを決めずに 8 分間の T2V を盲目的に実行するのは禁止！事後の自動品質チェックは対症療法に過ぎず、高コストな再生成は根本的な解決にはなりません。人物のクローズアップや重要な小道具とのインタラクションがある場合は、必ず最初に初フレームを決定し、first_frame を注入して I2V モードで実行する必要があります。0フレーム目で解剖学的形状と小道具の構造を固定し、H3 は時系列ダイナミクスとリップシンクのみを担当することで、顔の変形率を 30% から 2% 未満に低下させます。詳細は references/keyframe_i2v_guide.md を参照。

映画レベルのBGM融合とインテリジェントなオーディオダッキング: プロンプト内で H3 による歪んだベッド音の生成を完全に禁止。ダイアログとフォーリーサウンドのクリーニング後、全編に独立したハイファイBGMを統一して配置。FFmpeg ネイティブの sidechaincompress を使用した動的サイドチェイン回避を採用: 発声中は瞬時に -14dB にダッキング、台詞終了後 0.3～0.5 秒でスムーズに復帰。商用ショートドラマのような視聴覚体験を実現。新しいツール scripts/cinematic_audio_mixer.py を追加。

新しい初フレームゲートツール scripts/keyframe_gate.py を追加: エンジニアリングレベルの初フレーム状態検査、ComfyUI 倉庫同期、I2V ノードへの安全な注入をサポート。

v3.2 更新 (2026-10-25)

新しい §13 このスキルをいつ更新するか: 6つのトリガー条件、含めてはいけない4つのファイルタイプ、移行のための3つの質問、配置ルール、変更後の3ステップセルフチェック

一言で言うと規律: 「シナリオを変更しても成立する」メカニズムと判断基準のみを蓄積し、プロジェクト固有のファイルは一切スキルに含めない

v3.1 更新 (2026-10、13セグメント / 86秒完成作品の実測からの蓄積)

新しい §4.1 H3 の従順性の限界 (プルバックの失敗、窓やドアを通過できない、窓の外の動きが生成されない、ショットサイズの固定、否定形のカメラ指示)

新しい §5.1 VRAM 解放 (かつて1セグメントが5分から33分に延びた問題)

§8 決定木に 6 つのケースを追加 (エンディングアクションの奪い合い、1拍あたりの動作過多、フォーリーがベッド音に、quiet-gain の副作用、F0 の誤判定)

§12 に台詞位置の4段階グラデーション、cont off のトリム記録を追加

§3 セグメント長の推奨を 175フレーム に変更 (以前は 124/243 と記載されていたが、時代遅れ)

プロンプト仕様内の誤解を招く古い例を2つ修正: 「台詞は拍の最後に書く」は拍の最初であるべき。「胸は2.5秒ごとに上下する」は発声指示として解釈され、呼吸音が生成されるため削除

シナリオを完成作品に変換します: ハンドシェイク → ディレクタースケジューリング → 初フレーム検証 (I2V) → プロンプト → 送信 → 監視と二重チェック → 成果物受領 → オーディオダッキングミックスと結合。

v4 の核心的な考え方: 「運任せの動画生成＋事後品質チェックによる再生成」から、「低コストな事前画像制御 + I2V による顔固定 + 映画レベルのオーディオダッキングミックス」へのアップグレード。

絶対ルール: 1つのタスク = 1つのローカルプロジェクトディレクトリ + 1つのディレクターコンソールプロジェクト名 (h3_chain/<プロジェクト名>)。 この2つは、最初のセグメントが決定されてから concat が終了するまで変更してはいけません。変更すると「ファイルの場所が間違っている」という話ではなく、続きの生成が直接切断されます: 続きのセグメントは chain.order[k-1] を使用して前のセグメントを見つけます。プロジェクト名が変わると見つからなくなり、現在のセグメントは黙って最初のセグメントとして再描画されます。完成作品は別の作品のディレクトリに配置されてしまいます。バインディングは project.json の chain フィールドに書き込まれます。submit は毎回これを比較し、一致しない場合は直接拒否されます (警告ではありません)。変更するには全体を変更する必要があります: 新しいプロジェクト + 新しいディレクターコンソールプロジェクト名、最初のセグメントからやり直し。完全なルールは §10.1 を参照。

0. 実行契約 (誰が何を担当するかを明確に)

誰	担当
エージェント (完全自動)	シナリオ読み込み、ディレクタースケジューリング、初フレーム検証、プロンプト作成、preflight、送信、監視、二重チェック、成果物受領、ベッド音除去、BGMダッキングミックス、結合、納品、台帳書き込み
ユーザー (以下の3つのみ)	① ComfyUI を開き、ワークフローをロードして「準備完了」と伝える ② シナリオ/スタイル/初フレーム候補の一度限りの設定を行う ③ 動画を確認して承認する

エージェントがしてはいけない7つのこと

ワークフローのハンドシェイク (wf_map.json が存在しない) が完了していない状態で送信してはいけません。
gate (一次採集の二重チェック) をスキップして finish に直接進んではいけません。スクリプトは拒否します。回避しようとしないでください。
state / フレーム抽出 / 一時的な wav ファイルをスキルディレクトリに書き込んではいけません (paths.py にハードガードがあります)。
「前回のノード番号」を頼りに配線を変更してはいけません。3つのデータを注入するだけで、超解像/最終出力ノードの配線は絶対に変更しないでください。
人物のクローズアップや重要な小道具とのインタラクションがある場合、初フレーム検証をスキップして純粋なテキスト生成動画 (T2V) を盲目的に実行してはいけません。静的画像の検証はたった 5～15 秒で完了し、不満があれば瞬時に再生成できます。8分間の T2V を実行してから事後品質チェックを行うのは、高コストな自殺行為です。必ず最初に初フレームを決定し、first_frame を注入して I2V モードで顔と小道具を固定しなければなりません！
フレームを抽出して映像を確認せずに次のセグメントを送信してはいけません。preflight はテキスト構造のみをチェックし、映像はチェックしません。ディスクに書き込まれた後、まず 4～6 フレームのモンタージュを抽出して確認してから、次のセグメントを送信してください。これは、「2つのセグメントの送信が早すぎてVRAMが汚れる」問題 (§5.1 参照) を回避することにもなります。
今回のプロジェクトファイルを無差別にスキルにコピーしてはいけません。作品名 / キャラクター名 / セグメント番号 / plan.json / assets/*.json / 特定セグメントのプロンプト原文 / 今回のトリム記録 / ブラックリストシードは、すべてプロジェクトディレクトリに残してください。スキルには「シナリオを変更しても成立する」メカニズム、判断基準、記述方法のみを蓄積します。判断基準と配置ルールは §13 を参照。

ユーザーに確認を求めるのは、以下の4つの場合のみ: シナリオに曖昧さがあり、ショット分割構造に影響を与える場合 / スタイルやアスペクト比の設定が必要な場合 / 素材が不足しており、テキストで定義できない場合 / 同じセグメントの再生成が3回連続で失敗した場合

1. コアツールセット (完全なプロダクションツールチェーン)

ツール	機能	主要サブコマンド
`scripts/h3wf.py`	ワークフローハンドシェイク: ComfyUI から実際に実行されたグラフを読み取り、ノードの役割を自動認識	`sync` `show` `doctor`
`scripts/sop_run.py`	プロダクション: 送信 (preflight 含む)、自動監視、最終出力待機	`submit` `watch` `final` `abort`
`scripts/h3proj.py`	プロジェクトとゲート: 台帳、一次採集の二重チェック、ビジュアルサイン、成果物受領、結合、残留クリーンアップ	`new` `status` `gate` `review` `finish` `concat` `residue`
`scripts/keyframe_gate.py`	初フレーム検証と I2V 注入: 初フレーム状態検査、ComfyUI 倉庫同期、first_frame の注入	`--project` `--seg` `--sync`
`scripts/face_refine_pipeline.py`	外部ロングショット顔修正ワークフロー: 中・ロングショットの条件付き顔修正、オーディオはそのままパス、カスタムノード欠落時のスムーズな劣化	`--input` `--output` `--char-ref` `--dry-run`
`scripts/cinematic_audio_mixer.py`	映画レベルのBGMインテリジェントダッキングミックス: 外部独立BGM、sidechaincompress による自動オーディオダッキング	`--input` `--output` `--bgm` `--volume`
`scripts/check_dialogue_asr.py`	台詞 ASR 自動比較: VAD による発話区間特定 → Whisper 文字起こし → `<d>` 原文との比較	`--file` `--text` `--seg`
`scripts/sop_check.py`	セグメント末尾のアクションエネルギーと継ぎ目類似度品質チェック: 8フレームコンタクトシート、アクションオプティカルフロー比率、固定フレーム比較	`--video` `--seg`
`scripts/shisei_pose.py`	(オプション) 戦闘/対峙ポーズ: マルチビューポーズ検索とラインアート抽出	`--search` `--duo` `--get` `--view`

インタプリタは cv2 を含む venv に固定: C:/Users/windows/.workbuddy/binaries/python/envs/default/Scripts/python.exe (以下 PY)

2. ステップ 0: ワークフローハンドシェイク (作業開始時の最初のタスク、スキップ不可)

なぜ固定できないのか: ユーザーのワークフローは更新される可能性があります (3回目の採集の追加、超解像サイズの変更、出力プレフィックスの変更)。ノード番号が変わると、ハードコードされた「配線修正」は正常に動作するパスを壊してしまいます。これは v2 でのエラーの根本原因です。

核心的な方針: ユーザーはキャンバス上でいつでもパラメータを調整します (超解像サイズの変更、モデルの交換、サンプリングステップ数の調整)。生成には常にその時点の値を使用する必要があります。 submit は毎回、保存されたバージョンのキャンバス (h3wf.refresh_if_stale) を最初に検証します: ファイルの mtime が変更されている場合はグラフを再読み込みし、どのパラメータが変更されたかを1つ1つ出力します ([wf ] 检测到 N 处参数变更)。 rack/desk/cast の h3_data、seed、filename_prefix は実行時に注入されるもので、ユーザーの変更とは見なさず、除外されています。

ただし、API レベルで回避できない制限が1つあり、ユーザーに積極的に伝える必要があります: ComfyUI のキャンバス状態は、ワークフローを保存 (Ctrl+S) した後にのみ ComfyUI/user/default/workflows/*.json に書き込まれます。保存されていないキャンバスの変更は、どのインターフェースも読み取ることができません。そのため、作業開始時にはユーザーに次のように伝えてください: パラメータを変更したら Ctrl+S を押してください。ユーザーが変更後に Queue を1回押した場合、その実行グラフは /history に入り、2番目の条件で捕捉できます。

アクション:

最初にユーザーに注意を促します: ComfyUI デスクトップアプリケーションを開き、今回使用するワークフローをロードしてください。ユーザーが「準備完了」と言うのを待ちます。
前提条件: sync は ComfyUI /history 内の最後に正常に実行された動画タスクを読み取ります。
- ワークフローを変更 / インストールしたばかりの場合 → ユーザーにインターフェースで手動で1回実行してもらい (どのセグメントでも構いません、成功すれば良い)、その後 sync を実行します。
- 一度も正常に実行されたことがない場合 → インターフェースファイルでフォールバックします: h3wf.py sync --from-ui "<ワークフロー>.json" (ComfyUI が実行中である必要があります)。

死活監視 + 認識:

$PY scripts/h3wf.py show      # 認識結果のみ表示
$PY scripts/h3wf.py sync      # 認識成功後、今回のプロダクションのベースとしてディスクに書き込む

出力の解釈: rack/desk/cast/seed/final の5つの必須ロールはすべて値を持つ必要があります。不足している場合は、ワークフローのノードクラス名が変更されたことを意味します。この行をユーザーに見せ、自分で推測しないでください。[note] には複数の候補からどのように選択したかが記載されます。同じ出力からは、さらに3つの情報が得られます。これらが欠けると、後のステップで問題が発生します:
- プロジェクト名 (ディレクターコンソール chain.name): submit はこれを使用して、完成作品が h3_chain/ のどのディレクトリに配置されるかを決定します。最初の submit でこれを project.json.chain にバインディングとして書き込みます。「—」と表示されている場合は、ディレクターコンソールにプロジェクト名が入力されていないことを意味します。この場合、submit はスキルのプロジェクト名にフォールバックし、警告を発します。これは別の作品を開始することと同じであり (バインディングは書き込まれません)、バインディング後に名前を変更すると拒否されます。§10.1 を参照。
- 一次採集プレフィックス: watch/gate --latest はこれを使用して一次採集ファイルのみを認識します。「—」と表示されている場合は、すべてのプレフィックスにフォールバックします。チェーン全体を実行した後、超解像/最終出力を一次採集と誤認して二重チェックする可能性があります。
- [WARN] 成果物受領チェーン: 「セグメント末尾の配置」またはその「順序アンカー」が配線されていない場合、完成作品はディレクターコンソールに戻らず、次のセグメントが接続できなくなります。
ComfyUI が起動していない場合は、ヘッドレス起動を許可します (ポート 8188、デスクトップアプリケーションには影響しません):
```
cd "D:/Comfy-Desktop/ComfyUI-Installs/ComfyUI (1)/ComfyUI"
".venv/Scripts/python.exe" main.py --port 8188 \
  --input-directory "D:/Comfy-Desktop/ComfyUI-Shared/input" \
  --output-directory "D:/Comfy-Desktop/ComfyUI-Shared/output" \
  --enable-assets --disable-auto-launch
```
ただし、ユーザーが自分で開いているものを優先します。ノードの状態はユーザーのインターフェースを基準とします。

ワークフローが変更された場合: h3wf.py doctor は、「ノード番号が変わった / プレフィックスが変わった / プロジェクト名が変わった / ロールが欠落している」をリストアップします。意図的な更新であることが確認できたら → h3wf.py sync --force で再ハンドシェイクし、以降のすべての送信は新しいグラフを自動的に使用します。 submit は毎回フィンガープリントを再検証します。未確認のドリフトは直接拒否されます (古いグラフを使って一晩中こっそり実行することはありません)。ハンドシェイク時には、history_seq 水位線が記録されます: これより前の実行グラフはドリフトとは見なされません (/history がクリアされる前に残された古い記録)。ハンドシェイク後に新しく実行されたグラフが異なる場合のみ拒否されます。

3. ステップ 1: ディレクタースケジューリング (必須、シナリオを取得したら最初に行うこと)

シナリオを取得したら、すぐにプロンプトを書き始めてはいけません。 まず director-advisor スキルをロードして、完全なショット分割スキームを生成します:

5つの要素に分解: 感情のトーン / ドラマチックなビート / キャラクター関係 / 空間 / アクション
リズムの骨格を決定: ショット数、緊張曲線 (最高点は1つだけ)、オープニングショットとクロージングショット
ショットごとの設計: ショットサイズ = 感情の距離、カメラワーク = 感情の動き、1ショット = 1つのアクションユニット、長さ 1～3秒 (最大5秒)、各ショットに設計理由を1行
1～2 の実際の映画ケースアンカーを添付 ( director-advisor/references/master_cases.md からのみ取得)

次に、references/directing_bridge.md に従って H3 のセグメントに変換し、セグメント計画表をディスクに書き込みます:

{"name": "作品名", "segs": [
  {"seg": "seg01", "length": 175, "shots": "1-4", "dialogue": false,
   "hook": "最初のセグメント：ロングショットで空間を確立", "sfx": true, "event": "彼女は石造りの家に入り、ランプを置く"}
]}

length: 175 (約7.29秒、3-4ショット) が推奨値。124 (約5.17秒、1-2ショット) / 243 (約10.13秒、2-4ショット) も使用可能。重要な計算式: 純新規フレーム数 = length − cont_frames。cont_frames=5 の場合、175フレームでは純新規170フレーム (7.08秒)、124フレームでは純新規85フレーム (3.54秒)。同じ継続オーバーヘッドでも、175の純出力は2倍であり、レンダリング時間は 4～4.5 分で、コストパフォーマンスの転換点です。台詞があるセグメントでも 175 を使用し、243 は使用しないでください: セグメントが長いほど、台詞がセグメント末尾にぶつかりやすくなります (§12 台詞タイムラインの鉄則を参照)。
hook: 前のセグメントとの継続 (姿勢/視線/光の継承)。hook が書けない場合は、セグメント分割が間違っています。
dialogue/sfx: オーディオゲートがどの項目をチェックするかを決定します (台詞なしセグメントは無音をチェック、フォーリーなしセグメントは --fx を無効にします)。
検証: $PY scripts/h3proj.py plan --check

1セグメント = 1つのイベント。セグメント内では複数のショットが可能です ([节拍 N] がショット位置であり、「ハードカット…」と書けば H3 がそのまま実行します)。 空間 (マップ) と主要イベントをまたいではいけません。カットポイントはアクションに合わせる必要があり、秒単位で均等に分割してはいけません。

ショットを書く際に、同時に2つの内容面のチェックを行います (詳細は references/vividness.md を参照):

論理的な4つの質問: この瞬間、人物は何をしたいのか？どこにいて、誰の方を向いているのか？時間/光は連続しているか？前のアクションの因果関係は途切れていないか？
鮮やかさの3点セット: 各拍に少なくとも1つ「アクションの原因 + 環境の反応 + 素材の触感」を含め、「立って話しているだけ」であってはいけません。

3.1 オプションの強化: 高品質な戦闘と二人対峙ポーズパイプライン (Shisei Pose Guidance)

シナリオが接近戦、武器の衝突、二人の正対/逆ショットの対峙、複雑な身体の絡みを含む場合、動画モデルによく見られる「動作の弱さ、解剖学上の変形、180度ラインの反転」を避けるために、ローカルの Shisei ポーズガイダンスをロードします (詳細は references/shisei_combat_pipeline.md を参照):

ポーズ検索: ローカル検索スクリプトを使用して、55組の二人対峙アクションと288の単一人物アクションをクエリ:
```
python scripts/shisei_pose.py --duo --search "近身"
```
マルチビューラインアート抽出: ディレクターのカメラ位置に基づいて、5つの主要ビュー (front 正面 / side 側面 / diag 45度斜め / above 見下ろし / below 見上げ) のラインアートをプロジェクトディレクトリにエクスポート:
```
python scripts/shisei_pose.py --get D001 --view diag --out references/poses
```
初フレーム骨格アンカー: 抽出されたポーズラインアートとキャラクターカード (sal_character_sheet.jpg など) を組み合わせて画像生成エンジン (Imagen / Qwen) に供給し、100% 構図が厳密な初フレームを生成。その後 MiniMax H3 に注入し、空間ドリフトと動作の軟化を防止します。

3.2 強制工程: ショット初フレーム画像生成検証と I2V ジオメトリ顔固定 (Keyframe Gate)

産業上の鉄則 (最優先の認識)：人物の正面/バストショットのクローズアップ、重要な小道具とのインタラクション (例: 時計の分解、銃を握る、お金を数える、印鑑を押す) がある段落は、 純粋なテキスト生成動画 (T2V) の盲目的実行は厳禁！「初フレーム画像生成検証 ➔ 画像から動画 (I2V) による顔の固定と変形防止」を必ず実行する必要があります。

核心的なロジック:
- 静的画像生成はわずか 5～15秒/枚 で完了し、すべての潜在空間解像度を顔のパーツや髪の毛、小道具の微細構造に集中できます。不満があれば秒単位で再生成可能。
- 動画レンダリングは1セグメントあたり 4～8分 かかります。物理的なアンカーポイントなしでの純粋なテキスト生成動画は、解剖学的ドリフトを起こしやすく、事後の「自動品質チェック」による再生成コストは40倍高く、抜本的な解決にはなりません。
- 選択された初フレーム画像を MiniMaxH3ImageToVideo の first_frame ポートに注入すると、0フレーム目が幾何学的な真値として固定されます。モデルは構造を想像する必要がなくなり、注意力はすべて「アクションの駆動と口形の同期」に割り当てられ、顔の変形率は30%から2%未満に急落します！
実行フロー:
- G0 キャラクターアセットカード: 作業開始前に references/character_sheet_standard.md に従い、2+3 頭身の分離されたキャラクター設定カードを準備。
- G1.5 初フレーム画像生成検証: ショット記述が完了したら、画像生成ツールを使用して 16:9 の初フレーム映画スチルを迅速に生成。顔のパーツ、目の焦点、小道具の正確性をチェック。
- 確定版のディスクへの書き込み: 検証が通ったら、<プロジェクト>/segments/<seg_id>_keyframe.png (または .jpg) に保存。
- 自動認識と I2V マウント: パイプラインは初フレーム画像の存在を検出すると、scripts/keyframe_gate.py を介して自動的に ComfyUI に同期し、first_frame ポートに接続します。検出されなかった場合は、自動的にスムーズにテキスト駆動にダウングレードします。詳細は references/keyframe_i2v_guide.md を参照。

4. ステップ 2: プロンプトを書く (標準 = `references/prompt_standard_v2.md`)

7段落の骨格、[节拍 N]、<Audio N> ボイスカード、overall_soundscape 3層のサウンド、段落名は1文字も変更不可。
プロンプトは segments/<seg>.txt に書き込みます (プロンプト本文のみ、コードブロックで囲まない)。
ボイスカード: プロジェクト内の voice_card.json を優先します (h3proj.py new でテンプレートがコピー済み)。セグメント間で一語一句同じであること。
preflight は個別に実行する必要はありません: submit 内部で check_prompt_v2.check() が呼び出され、FAIL があれば直接拒否されます。事前に個別に確認したい場合: $PY scripts/check_prompt_v2.py --file segments/seg01.txt --length 243

フォーマットのクイックリファレンス (詳細は仕様書を参照): <Subject N> にはすべて 权限= を付ける。感情語はゼロトレランス。各拍の 音效: は1つ1つ名前を挙げ +「これらの N 種類のみ、他の音はなし」で閉じる。台詞の終了位置はセグメント末尾から 1.0秒以上。1セグメント = 1つの台詞文。

否定語の逆効果 (実測、2回踏みました): H3 は禁止語内のエンティティ名を肯定的なプロンプトとして描画します。 防错约束 に「水竜巻、水柱、噴水を生成することを厳禁」と書くと、画面に白い水柱が現れます。アクションの説明に「ヘルメットのつばを上に持ち上げる」と書くと、主人公の頭の上に透明なヘルメットが現れます。ルール: 何かを出現させたくない場合は、その名前を文から完全に削除し、代わりにあなたが本当に望む画面を肯定的に記述します (例: 「垂直に見下ろす、円形のくぼみと水に沈む黒い人影のみ」)、「Xではない、Xをしない」と書くのではありません。 防错约束 には抽象的な制約のみを残します (透かしなし/字幕なし/奇形の手なし/炎のエフェクトなし)。

継続 latent が最初の拍の人物を歪める (このプロジェクトで5回再現、最も高価な落とし穴): --cont を付けたセグメントでは、最初の拍に安定して黒いローブを着て、長い髪を振り乱した背の高い後ろ姿が生成されます。たとえ—— 前のセグメントの末尾フレームが「水面を見下ろす + 水に落ちる黒い影」(seg02) でも、「Chen Mo の顔のアップ、黒い T シャツ」(seg03) でも、参照画像は正しく注入され ([rack] 素材 1 件：陈默→陈默.png)、テキストは服を一字一句明確に記述しているにもかかわらず、すべてを抑制できません。同じプロンプト、同じ参照画像、同じ seed 範囲で、--cont off に変更した後、2回とも正常に戻りました (seg02 の最初の拍は黒い T シャツの短髪の Chen Mo に戻り、seg03 の最初の拍は純粋な空ショットの都市俯瞰に戻りました)。

判定と処理:

このプロジェクトの結論: 継続は保持するが、5フレームのみ固定する (project.json の cont_frames: 5、すなわち 0.21秒)。ユーザーが求めているのは「数フレームでコンテキストの一貫性を保証すること」であり、39フレーム (1.625秒) は無駄が多く、後処理で各セグメントの先頭をトリミングする必要があります。純粋なハードカット (海辺 → 戸外など、シナリオ自体の場所のジャンプ) では --cont off を使用します。アンカー汚染が5フレームでも発生するかどうかは、実測記録が必要です。最初の拍の人物が正しくない場合は、まず --cont off を試してください。
一般的な判断基準: 継続は、「同じ空間、同じカメラ位置、アクションが直接継続している」場合にのみ有効です。最初の拍の人物の服装/体型/髪型が正しくないことに気づいたら、まず --cont off で1回検証します (一次採集は2分のみ)。プロンプトを修正するよりもはるかに高速であり、プロンプトの修正は効果がありません。
継続を有効にすると、[cont ] 承接 clip_xxxx (…) が出力されます。初フレームを確認してから、継続を保持するかどうかを決定します。

4.1 H3 の従順性の限界 (プロンプトを書く前に必読)

これらは実測されたハードリミットであり、プロンプトを変更しても効果がなく、seed を変更しても効果がありません。記述方法で回避する必要があります。すべて、13セグメント / 86秒完成作品の継続的な記録に基づいており、推測ではありません。

させたいこと	実測結果	代わりの記述方法
プルバック / ズームアウト / ズームイン (移動カメラワーク)	4回すべて失敗。「車止めが見えるところまで戻って止まれ」と書いても、窓の外まで戻り、別の内壁を露出させる	パン (同じカメラ位置で角度のみ変更: 最初に下にパンして床へ、次に上にパンして戻る) に変更、または直接ハードカット
カメラが窓/穴を通って室内に入る	ドアが勝手に開く。「ドアは閉じたまま、空いている窓の穴からのみ入る」と書いても効果なし	セグメント内ハードカットで室内に入り、アセンブル時にセグメント先頭をカットポイントでトリミング。どんなカメラワークトランジションよりも信頼性が高い
窓の外の景色が動く (車が走行中)	生成できない。「白い破線が毎秒3本、向かってくる」と書き換えても効果なし (窓外のフレーム間差: 静止時 1.26 / 動きを記述時 4.15、目で見ても動いているのがわからない)	走行感は後処理のエンジン音 + わずかな車体の揺れで補い、生成には頼らない
「ショットサイズを変えない / ズームインしない / プッシュプルしない」	従順性が低く、後半になるとズームインしてしまう	肯定的な記述に変更: 「画面には常に X 全体 (ドア枠の上端からペダルまで) が収まっている」 —「何を含まなければならないか」で制御する
「X を出現させない / X ではない」	逆効果が働き、X が描画されてしまう (上記の否定語の逆効果と同じ)	X の名前を文から完全に削除する
同じ拍で2つ以上のアクションを実行	それぞれが半分しか実行されないか、最も「つまらない」ものが直接スキップされる (閉めるというアクションは「両手をハンドルに置く」に負ける)	1拍あたり最大2つのアクション。4つのアクションがある場合は、拍を分割するか削除する
「約X秒で言い終える / N拍目の先頭で発生する」	時間の記述は完全に効果がない	H3 のタイムラインはテキストイベントの順序によって決定される。ブロックの前後関係の位置のみを調整できる
単一セグメントで複数の時間帯のカメラワークを記述 (0-3s プッシュ、3-5s 停止)	Qwen3-VL は途中でカメラ位置が変わったと誤認し、セグメント内で画面がフラッシュカットしてしまう	単一セグメント `[Shot 1]` では、厳密に1つの最初から最後まで貫くカメラワーク指示のみを記述する
中近景で立ち上がる (`rises from chair`)	キャラクターの頭頂部がフレームの上端からはみ出し、頭の半分が切り取られる	爆発的な感情のシーンでは `leans sharply forward across table with veins bulging` (激怒して前傾し机を支える) に変更
横顔のシーンで複数の顔のパーツ (brows/eyes) や否定文を記述	モデルは両目を描画しようとしたり、否定語の逆効果により、無理にカメラの方を向いてしまう	複数の顔のパーツと turn/camera ワードを厳禁。純粋に肯定的な横顔の静的な記述のみを使用し、末尾は TailLock 潜在変数クランプで固定
平静な音声プロファイルにより、クライマックスシーンでの叫びが出せない	参照オーディオの平静なトーンが、オーディオの潜在空間エネルギーを固定してしまう	T8mars プロトコルを採用: 台詞に咆哮のパラ言語的プレフィックスを追加し、0.4秒で物理的な衝撃の過渡音フォーリーを注入して音響エネルギーを引き上げる (+10dB)

一言で: H3 は「画面に何がなければならないか」を聞き、「カメラが何をしてはいけないか」は聞きません。「イベントの順序」を聞き、「秒数」は聞きません。

継続セグメントには、さらに固有の限界があります: 継続ブロックが終了するフレームで、モデルが参照画像の構図に「リセット」される可能性が最も高くなります。これがちょうどハードカットのタイミングである場合、モデルは「別のショットを開始する」機会を得ます。実際に、seg02 の初版では最初の38フレームは完全に継承されましたが、39フレーム目が終了すると同時に人物全体が消え、参照画像の中の人のいないワイドショットにジャンプしました。そのため: 継続セグメントではハードカットを書かない。ワンショット + 同じカメラ位置が最も安定しています。ショットを切り替える必要がある場合は、独立したセグメントとしてください。

5. ステップ 3: 生成、監視、成果物受領 (1コマンドで1つのこと)

# ① 送信 (preflight + プロジェクト登録 + 継続 + seed 選択 + ベースライン記録)
$PY scripts/sop_run.py submit --seg seg01 --assets 素材.json [--length 243] [--silent]
#    素材.json: {"角色1":"cglide/<プロジェクト>/角色1.png", "场景":"cglide/<プロジェクト>/场景.png"}
#    --dry-run        アセンブルのみ行い、送信しない (新しいセグメントを登録せず、プロジェクトファイルに触れない)。ComfyUI に画像の必須項目を検証させる。
#    --chain <プロジェクト名>  ハンドシェイクグラフ内の chain.name を上書きする (バインドされた値と一致する必要があり、一致しない場合は拒否)
#    --rebind         ディレクターコンソールプロジェクトを本当に変更する必要がある場合にのみ使用 (再バインド、継続はここで切断される)
#    --cont auto|off|<継続ファイルパス>   デフォルト auto=前のセグメントに接続、off=最初のセグメントとして扱う
#    --allow-nocont   このセグメントが本当に独立して開始する必要がある場合に使用: 「継続ファイルを取得できない」を許可

# ② 監視 (バックグラウンド実行推奨: このステップは一次採集がディスクに書き込まれるまで待機し、その後即座に二重チェックを実行)
$PY scripts/sop_run.py watch --seg seg01 --timeout 3600

**失敗を判断した場合、その場で GPU を解放する必要があります**。一次採集がディスクに書き込まれると、二次採集が開始されます。完全な品質チェック (フレーム抽出 + ビジュアル定量化、十数秒) の結果を待ってから abort すると、三次採集/超解像がすでに実行されていることが多く、計算リソースが無駄になります。そのため、`watch` は現在2段階に分かれています:
- **ディスク書き込み直後のオーディオクイックチェック** (`_fast_audio_gate`)

...

comfy-h3-video-producer