前回の動画では、比較的制御しやすいパイプラインを試した。VeraがHeyGenで英語を話し、HyperFramesが中国語字幕とグラフィックを加える。フラッシュや停止は残ったものの、「タスクから成果物まで」の工程が一度は通ることを確認できた。
二つ目の目標はより難しい。16:9のゲーム用アクション映像を作り、雨の遺跡でPhase 1の騎士と石巨人の最後の攻防を描く。Bossを倒した騎士が力尽き、その後にVeraが灯りを携えて現れる。Seedanceの複雑な動作生成とカメラ能力を示しながら、将来は音声を差し替えてゲーム本編へ戻せる内容である必要もあった。
今回は完成映像に至らなかった。一日作業した段階で、制作を止めた。
良いフレームが一枚もなかったからではない。アクションの成立には、フレーム間の空間と因果関係が必要だからである。 そこが現在の工程で最も作業量が多く、最も不安定な部分だった。
第1ラウンド：三本とも再生できるが、一本も合格しない
最初の案は約30秒の短編だった。
- 騎士が巨人の攻撃をかわし、前転して膝を斬る。
- 衝撃で床が崩れ、騎士とカメラがともに落下する。
- 巨人を倒した騎士が倒れ、Veraが灯りを持って近づく。
すべての動画は生成に成功し、コーデック、フレームレート、音声トラック、輝度の検査も正常だった。最初の区間は騎士、巨人、全体の画風まで保持していた。しかし通常速度で見ると、問題は明白だった。拳が本当の脅威になる前に騎士が先に転がり、Bossへ近づいた後には一拍停止してから剣を振る。
二つ目の区間はさらに深刻だった。床は荷重、亀裂の伝播、石板の分離、支持の喪失を示さないまま、騎士だけが突然落下した。「剣を壁に刺して減速する」は壁を左右に斬る動作へ変わり、後半には石巨人が遠景へ再出現した。地面との接触も信頼できず、空中に浮いて見えた。
ここで初めて、「技術上の合格」と「演出上の合格」を完全に分けた。ファイルがデコードでき、黄色いフラッシュがなく、人物数がおおむね正しいことは、ファイルが壊れていないと示すだけである。なぜ人物が動くのか、いつ接触するのか、力がどこから生まれるのかまでは判定できない。
プロンプトの前に物語を修正する
自由落下はカメラワークを見せるためだけに加えたが、その結果、ゲームの物語まで勝手に書き換えていた。本来の論理は単純である。
騎士が石巨人を倒す → 疲労で倒れる → 戦闘後にVeraが現れる。
床崩落、異空間、黒い炎、その場で発明した新能力は存在しない。そこで第2版では技術展示のための要素をすべて削除し、同じBoss部屋、同じ180度軸、ゲーム本編へ戻せる一つの動作連鎖だけを残した。
同時に、優れた参考例である『望月剣舞』を分解した。画風は異なるが、プロンプトには明確な演出上の文法がある。
予備動作 → 接触点 → 素材の反応 → 回復 / 次の動作への構え
剣は単に「振られる」のではない。特定の瞬間に明確な位置へ命中し、その後に初めて対象が割れる。一つの動作が終わる時点の足位置、重心、剣の位置は、すでに次の動作の準備になっている。カメラも「旋回、前進、ローアングル」を独立して並べるのではなく、刃の軌道、重心、衝撃に従って動く。
これは「転がる、斬る、ひざまずく」と列挙するより、実際のアクション演出に近い。
画面がようやく安定するまで
動作を始める以前に、二体を含むキーフレームが問題になった。
騎士とBossの画像を同時にNijiへ渡しても、モデルはどの属性が誰に属するかを判断できない。兜、マント、鎧、大剣がBossへ混ざり、石巨人がもう一人の巨大な騎士になった。Editorで騎士だけを補うと、人物とBossが別々の画風に見え、衣装には依頼していない金色の背面記号やローブまで追加された。Character Referenceも厳密な局所アイデンティティ固定ではなく、画像全体へ影響した。
最終的な役割分担は、むしろ単純になった。
- Nijiは高品質な単体を担当する。 キャラクター、Boss、衣装、材質、シルエット、全体の美術言語を個別に完成させる。
- Image2は制御された合成を担当する。 承認済みの単体を同じ場面へ配置し、位置、比率、カメラ、継ぎ目を調整する。デザインを再発明させない。
Image2にも制約が必要だった。均一な高周波ノイズ、密集した微細亀裂、プラスチック状のハイライト、過剰なシャープ処理を生成しやすい。静止画の欠点が動画へ入ると、フレームごとに動くノイズになる。数回の修正を経て、冒頭の静止画マスターはようやく安定した。左に騎士、右にBoss、共通の地面と光の方向があり、画風もほぼ統一された。
つまり、今回は「画像を作れない」ことが問題ではない。画像は十分だった。失敗したのは、その画像に信頼できる時間を加える工程である。
第2ラウンド：早い回避を禁止した結果、その場で凍結した
BytePlusで行った最初の五秒テストは、「早すぎる回避」だけを修正するためのものだった。プロンプトでは、騎士は早く動かず、巨拳が危険線へ入るまで待たなければならないと繰り返した。
モデルは「動かない」を忠実に守ったが、戦術上の継続的な調整を理解しなかった。騎士は攻撃が顔の近くへ来るまでほぼ凍結し、ショルダーロールは判読できない。Bossの拳と腕は前景で巨大な岩へ膨張し、接触点を隠した。
次のプロンプトでは方針を完全に反転した。騎士は最初のフレームから前進し、フェイント、進入、前転、立ち上がり、斬撃へ移る。カメラも加速し、低く移動し、視差を作り、剣の力線を追う。八秒のプロンプトは非常に詳細だった。画風は壊れなかったが、緊張感は依然として足りなかった。
ここから、好ましくない結論が得られた。プロンプトが長くても、モデルの演出能力が高くなるとは限らない。 五秒から八秒の間に、足運び、誘導、追跡、打撃、前転、復帰、斬撃、Bossのひざまずき、カメラワーク、音響を同時に入れると、モデルは最も難しい中間工程を省略しやすい。
DreaminaとKling：複雑な経路と条件を揃えた比較
より強い動きを試すため、別の八秒経路も設計した。巨人の拳を完全に着地させ、騎士が接地した腕を走って上り、肩から胸の位置で一度斬る。
Dreaminaは大筋で経路を守ったが、騎士は機械のように歩き、攻撃には力がなかった。ファイルに音声トラックは存在したものの、明瞭で有効な動作音は聞こえなかった。Klingは以前、より機敏な登攀を生成したことがある。しかし今回は自動マルチショットを有効にすると、騎士が登っている途中で無関係な崖へ突然移動し、再びBossへ切り替わった後、同じ登攀を繰り返し、適当に一度斬って飛び降りた。
公平に比較するため、タスクを本当に閉じた五秒の単一動作へ縮小した。
- Bossが拳を上げる。
- 拳が危険範囲へ入る。
- 最後の瞬間に騎士が右前方へ前転する。
- 巨拳が騎士の離れた地面へ落ちる。
- 騎士はBossの内側で止まり、Bossへ向く。この回では反撃しない。
DreaminaとKlingには、同じ開始画像、同じ解像度、ほぼ同じプロンプトを使用した。このラウンドではDreaminaの方が良かった。動作順序がより完全で、騎士もBossの内側へ入ったように見える。Klingは場面を保持したが動きが鈍く、回避は明確な前転ではなく、低い姿勢での突進に近かった。
正直、Klingのこの二回の破綻には笑ってしまった。一度は登っている途中で別の山へ移り、もう一度は前転が低い突進になった。真面目な制作検証でも、ここはさすがに平静を保ちにくい。
最後の続きが根本的な問題を明らかにした
Dreamina R4の終端から比較的安定したフレームを一枚抽出し、さらに五秒の続きへ次の指示を与えた。
騎士は片膝での支持から直ちに地面を蹴って立ち上がり、左上への斜め斬りで石巨人の手前側の膝関節を捉える。刃が接触してから、岩が斬痕に沿って崩れる。
抽出フレームだけを見ると成功に近かった。騎士は立ち上がり、剣光が命中し、Bossの膝が光り、岩が割れ、巨人は重心を下げる。自動QAも「因果関係が連続している」と記録した。
通常速度で再生すると、問題は見過ごせなかった。
騎士は視覚上、Bossからまだ遠く離れている。踏み込み、突進、接近を行わず、その場で立ち上がっただけで剣が届いている。
これは今回、最も価値のある失敗だった。終端フレームからの続きは色と大まかな構図を保てても、隠れた三次元空間を正しく再構築するとは限らない。プロンプトに「直ちに命中」と書くと、モデルは合理的な接近動作を生成せず、距離そのものを削除する場合がある。
同時に、コンタクトシートは構図、アイデンティティ、色の確認には適しているが、動作の因果関係を認定するものではないと再確認できた。最終確認では、まず通常速度で全体を見て、その後に接触、支持、運動量、回復をスローで確認する必要がある。
なぜ無理に完成映像へ編集しなかったのか
これらは編集上の問題ではない。
- 早すぎる回避は、数フレームを削除しても現実的な反応にならない。
- 遠すぎる人物は、剣光を加えても距離を埋められない。
- 原因のない崖、瞬間移動、位置のリセットは、トランジションで隠せない。
- 音声トラックの存在は、効果音が明瞭で衝撃と同期していることを意味しない。
- 孤立した美しいショットを並べても、連続したアクションにはならない。
続けるなら、五秒ごとにキーフレーム、プロンプト、生成タスク、抽出フレームQA、通常速度QA、スロー再生QAを作り直し、終端フレームを次の区間の空間的な始点として扱う必要がある。この速度では、一週間をかけても短い映像がかろうじて成立する程度かもしれない。それは「自動制作」の検証ではなく、モデルの不確実性を人間の調整で埋める作業になる。
そのため、今回はHyperFramesへ進まず、失敗したショットを「完成」した短編として包装しなかった。
次の検証対象をFlovaにする理由
次にFlovaを評価するのは、すでに問題を解決したからではない。その作業単位が現在のボトルネックに近いからである。プロジェクト、絵コンテ、素材、モデル生成、最終成果物を一つのワークフローで管理し、Image2、Seedance、Klingを含む複数モデルを利用できる。
検証すべきなのは「もう一本動画を出せるか」ではなく、次の八点である。
- 崩落や異空間を勝手に追加せず、ゲームの物語に沿った絵コンテを先に提示できるか。
- ショット内の動作主体、応答側、接触点、実距離を区別できるか。
- ショットをまたいで、キャラクター、装備、Boss、地形、左右の軸を保持できるか。
- 静止画合成、単一ショットの動作、特殊ショットに異なるモデルを選べるか。
- Nijiの単体、Image2のマスター、動作参考が担う役割の違いを理解できるか。
- 次のcreditsを消費する前に、確認可能な絵コンテとタスク状態を提示できるか。
- 実際に聞こえ、同期した環境音と接触音を生成できるか。
- 新たなブラックボックスにならず、使用モデル、パラメータ、費用、失敗記録を保持できるか。
FlovaのCLIとAPIは接続済みだが、このプロジェクトをFlovaで生成した実績はまだない。本稿におけるFlovaは勝者ではなく、次に検証する仮説である。
今回、実際に残った成果
完成映像はないが、今後の既定ルールにできる項目は残った。
- Nijiで高品質な単体と画風を作り、Image2で制御された複数主体の合成を行う。
- 動画段階へ進む前に、アイデンティティ、衣装、装備、空間マスターを解決する。
- 五秒には一つの因果的な循環だけを置く。短い時間へ多くの動作を詰め込まない。
- すべての接触について、予備動作、危険線、接触点、素材反応、回復を明記する。
- カメラは抽象的な「映画的」表現を積むのではなく、力と重心に従わせる。
- 「音声トラックがある」と「効果音が機能する」を別々に検査する。
- 技術QA、抽出フレームQA、演出QAを分離する。
- 人間が通常速度で行う確認に最終拒否権を持たせる。
- 人間の調整コストが自動化の利益を上回ったら、生成を繰り返さずワークフローを変える。
最初のAIプレゼンター動画は、自動化した工程が最後まで通ることを示した。二つ目のアクション動画は、そこに必要な修正を加えた。工程が動くことと、その方向を続ける価値があることは同じではない。
今回は、止める判断そのものが成果だった。