前稿は一つの転換点で終わった。Dreamina、Seedance、Klingをショットごとに呼び出す方法では、時折美しい五秒を得られても、空間的に信頼できる一連のアクションにはならなかった。そこで同じ目標をFlovaに渡し、プロジェクト単位のプラットフォームが演出、Storyboard、素材、モデル、音、タイムライン、書き出しを統合できるか検証した。
Flovaは全工程を完走し、38.24秒の映像を納品した。しかし元の目標に照らして検収すると、このFlovaワークフローはなお失敗だった。
ここでいう失敗は、ファイルが壊れたことでも、生成されなかったことでもない。映像は再生でき、音があり、四つのショットと完全なタイムラインを持つ。失敗したのはより難しい層である。画面がプロンプトに書かれた動作を常に証明したわけではなく、キャラクター同一性は固定されず、修正操作が承認済みの画風を壊し、プラットフォーム自身の演出審査もそれらを安定して発見できなかった。
目標は書き出しではなく、連続して成立すること
物語は四つのショットに限定した。
- 騎士が石巨人の最後の攻撃軌道を抜け、脚の近くまで入る。
- 騎士が膝の岩の亀裂を実際に打ち、構造を失ったBossが片膝をつく。
- 騎士が胸部コアを処刑し、Bossが崩れ、騎士も力尽きる。
- 戦闘が完全に終わってから、Veraが提灯を持って入る。
総尺は37〜40秒の範囲を許容し、credits節約のためだけに無理に圧縮しない。映像は同じ雨の遺跡、同じPhase 1の騎士、純粋な岩石でできた同じBoss、そして承認済みのVeraの顔、衣装、提灯設定を維持しなければならない。
したがって、以下のいずれかが起きれば不合格とした。
- キャラクターがまだ移動していない距離から攻撃を当てる。
- 剣と標的部位の重なりが画面上で確認できない。
- Bossが突然、鎧を着た巨人に変わる。
- 武器や提灯が増殖する。
- Veraの同一性、衣装、提灯を持つ手が変わる。
- Niji由来の画風がプラスチック調CG、平坦なカートゥーン、高周波のデジタルノイズに変わる。
- プラットフォームがプロンプトだけを根拠に「命中」と報告し、画面には証拠がない。
この基準は「生成に成功した」より厳しい。だからこそ、その後の失敗には分析する価値がある。
分担：Flovaはプロジェクトの監督であり、単体モデルではない
今回はFlovaを別の文生動画APIとして扱わなかった。分担は次の通りである。
| 層 | 責任 |
|---|---|
| 人間の依頼者 | 物語、キャラクター素材、許容コスト、最終的な審美判断を確定する |
| Codex | 全体設計、素材整理、プロンプト境界、フレーム単位QA、コスト記録、納品を担う |
| Flova | 演出監査、Storyboard、ショット分解、モデルルーティング、プロジェクト素材、タイムライン、音、書き出しを担う |
| Seedance 2.0 | 四本の画像生動画と、動作・環境の原生音声を生成する |
| 画像モデル | Gate Bの主要要素、空間プレビズ、失敗後の修正を担う |
この区別は重要である。Flovaの価値は、独自のより強い動画モデルを持つことではない。継続する一つのプロジェクトを中心に、複数モデルと中間成果物を整理できる点にある。今回問うたのは、その整理能力が演出判断と品質検収まで担えるかだった。
第一段階：メディアを作らない演出監査は正しかった
Flovaの第一巡は、プロジェクト素材と以前の失敗記録だけを読み、メディアを生成せず、新たなメディア消費も発生させなかった。そこで以前の続き動画にあった核心的な問題を正しく指摘した。騎士とBossが画面上では明らかに離れているのに、騎士がその場で立ち上がるだけで斬撃を当てていた。問題は派手さの不足ではなく、三次元の空間関係がすでに破綻していたことである。
第二巡もテキストとStoryboardの層にとどまった。Flovaは外部から提案した六ショット案を機械的に受け入れず、四ショット、37〜40秒を維持した。
- Shot 1で最後の内向き回避を解決する。
- Shot 2では近接の体勢崩しとBossの片膝着地だけを扱う。
- Shot 3では処刑、死亡、力尽きるまでの心理的な連続時間を残す。
- Shot 4で初めてVeraを登場させる。
さらに、各ショット末尾の一〜二秒を次のショットのvideo referenceとして使い、「命中」を離れた火花ではなく、剣身と岩体の幾何学的な重なりとして定義した。
この段階はFlovaワークフローで最も信頼できた。曖昧なアクションの希望を、確認可能なショットごとの責任へ変換できていた。
Gate B：静止画の自己検査が最初に破綻した
メディア段階に入ると、Flovaは主要要素画像を三枚、空間プレビズを六枚生成し、初期消費は42 creditsだった。Shot 2の片膝フレームを合格と判定したが、人間が確認すると二つの重大な問題がすぐ見つかった。
第一に、Bossの頭部が巨大化した騎士の兜になり、面頬と金属輪郭が明確に現れていた。第二に、騎士の剣はすでに胸部の発光点へ触れ、十字形の閃光まで生じていた。Shot 2の終わりでShot 3の処刑を先に完了していたことになる。
最初の部分修正は28 creditsを消費した。兜と早すぎる接触は修正されたが、画像全体が再生成されたため、元の高精細な暗い質感は平坦なコンセプト画へ変わった。別のShot 4修正版には、剣形の武器が二本同時に現れた。
第二の修正ではさらに三候補を生成し、42 creditsを消費した。物体数はようやく概ね正しくなったが、画風のずれは続いた。Gate Bでは計112 creditsの画像生成を記録したものの、設定とマスター画風を同時に守る正式キーフレーム一式を得られなかった。
その後、Image2で原画像の局所修正を試した。兜を除去し、剣先と胸の距離を広げることはできたが、既知の高周波な砂粒とデジタルシャープネスが入った。エッジ保持型のノイズ除去は粒状感を弱めても、一度描き直された材質をNijiの筆触へ戻すことはできない。
最終判断は、これら中間画像の修正を続けることではなく、視覚上の権威を取り消すことだった。最初に承認したNiji合成画像へ戻り、それをShot 1における唯一の画風・同一性マスターとした。
Gate C：唯一のビジュアルマスターが第一ショットを改善した
Shot 1は承認済みマスターを用い、AACステレオの原生音声を伴う6.06秒のSeedance 2.0動画として生成した。騎士は外へ逃げず、巨腕が脅威を作ると内側へ移動した。前景の巨腕と追従カメラが圧迫を作り、最後はBossの脚の近くで止まる。
このショットは合格とした。ただしFlovaの自己評価にある「停止なし」ではない。冒頭の溜めと終盤のしゃがみはやや長い。もっとも、これらの停止は空間因果を壊しておらず、人物の呼吸を切り落とすのではなく、タイムラインで穏やかに処理できる。
Shot 1以降、後続ショットは可能な限り前ショットの末尾を継承した。これによって初めて、連続した近接アクションの鎖が成立した。
四ショットの結果：二本合格、二本条件付き不合格
Shot 2は8.06秒。脚の近くから始まり、Bossは最終的に片膝をつく。しかし膝の体勢崩し段階で胸部コアが早くから強く光り、剣と膝の岩の亀裂が接触した幾何学的証拠も明確ではない。画面は「Bossが跪いた」ことは示すが、「騎士が膝を打ったためBossが跪いた」ことを十分には示さない。
Shot 3は13.07秒で、全編でもっとも完成度が高い。騎士は近接状態から胸部コアを直接処刑する。Bossは消滅、浮遊、別の鎧巨人への変化ではなく、支持を失った岩体として重く崩れる。騎士はその後、剣にすがって跪き、力尽きるまでの時間が連続している。
Shot 4は11.05秒。騎士は跪いた姿勢から自然に横へ倒れ、その後Veraが背景から入る。Bossは生命のない岩の残骸のままである。物語順序は正しく、冷たい雨と暖かな灯りの対比も終結を作る。
問題は、Veraの顔、年齢感、衣装が権威あるキャラクターパックからずれたことだ。提灯も設定上の右手ではなく、画面上の本人の左手側に見える。新キャラクターが初めて入る場面では前ショットから同一性を継承できず、キャラクター参照画像だけではFlovaも安定して固定できなかった。
最終結果は次の通りである。
| ショット | 外部検収 |
|---|---|
| Shot 1：内向き回避 | 合格、テンポには留保あり |
| Shot 2：膝の体勢崩し | 条件付き不合格：接触証拠が弱く、胸部が早く発光する |
| Shot 3：処刑と力尽き | 合格 |
| Shot 4：Vera登場 | 条件付き不合格：同一性と提灯を持つ手がずれる |
プラットフォームの自己検査が最大の危険だった理由
Flovaは最終報告で四ショットすべてを合格とし、次の内容を明記した。
- Shot 2の剣身による幾何学的接触は合格。
- Shot 4でVeraが右手に提灯を持つことは合格。
- 全編に画風や同一性のずれはない。
フレーム単位の証拠はこれらを支持しない。Gate Bでも、巨大な騎士兜を持つBossを一度合格としていた。
これは、プラットフォームの「監督自己審査」が先行する文字上の意図に影響される可能性を示す。プロンプトに右手で提灯と書けば、まとめでも右手と報告しやすい。膝を攻撃と書けば、膝への接触を報告する。最終ピクセルを独立した証拠として常に再評価しているわけではない。
これは表現上の問題ではなく、自動化の危険である。上位エージェントが下位プラットフォームの自己評価をそのまま信頼すれば、誤りは各Gateを通過し、「全て合格」というラベルを付けたまま書き出しへ到達する。
したがって本検証の最重要結論は、「Flovaも悪い動画を生成する」ことではなく、次の一点である。
プロジェクト編成はプラットフォームへ委ねられるが、最終的な事実判断を同じ結果を生成したプラットフォームへ委ねてはならない。
技術的には完全、目標に対しては失敗
Flovaは完全なタイムラインを構築し、38.24秒の動画を書き出した。
- 1280 × 720。
- 30fps。
- H.264映像。
- AAC 44.1kHzステレオ。
- 異常な黒フレームは未検出。
- 末尾約1.25秒の無音は計画したフェードと一致。
技術的な合格と内容上の合格は分けなければならない。エンコード、音声トラック、尺、黒フレーム検査、書き出しタスクの成功は、納品物が完全であることだけを証明する。元の目標では四ショットすべてが同時に成立する必要があり、そのうち二本が不合格だったため、工程全体も失敗となる。
コスト：編成作業は減ったが、手戻りは消えなかった
Gate Bで観測できた画像消費は次の通りである。
- 初期九枚：42 credits。
- 第一修正二枚：28 credits。
- 第二修正三枚：42 credits。
- 合計：112 credits。
動画段階に入る前の残高は6,558 credits、Shot 1、Shot 2〜4、タイムライン、書き出し完了後は5,484 creditsだった。観測可能なメディア実行差は約1,074 creditsである。Shot 1は約144 credits、残る三ショット、タイムライン、書き出しの合計差は約930だった。
Gate Bと動画段階の間に、プロジェクトログでは説明できない50 creditsの残高増加があった。このため、全数字を架空の正確な総請求額として提示しない。確実に言えるのは、プロジェクト単位の統合でもメディア費用は消えず、誤ったキーフレームの修正が動画生成前からcreditsを消費し続けたことである。
Flovaが減らしたのは整理のコストである。同一プロジェクト内にStoryboard、素材、前ショット参照、音、タイムラインを保持でき、各モデルの結果を手作業で運ぶ必要がなくなった。最終検収は減らず、誤ったショットの再制作も避けられなかった。
失敗工程から残った再利用可能な原則
権威あるビジュアルマスターは一つだけにする
キャラクター、Boss、スケール、画風には明確な優先順位が必要である。「新しい」という理由だけで修正版が承認済みマスターを上書きしてはならない。
video referenceは説明の反復より信頼できる
Shot 1からShot 4までの空間連続性は、以前の手作業によるショット生成より明らかに良かった。主な改善は長いプロンプトではなく、前ショット末尾の継承から生まれた。
接触はピクセルで証明する
アクションプロンプト、離れた火花、結果状態は接触証拠の代わりにならない。剣身と標的部位が正しい瞬間に可視の遮蔽または重なりを作る必要がある。
新キャラクター登場前に同一性Gateを置く
Veraを直接長尺の動画生成へ入れるべきではなかった。より安全なのは、顔、衣装、比率、提灯、左右の手を検査して合格した入場用の一枚を先に作り、それを画像生動画へ使う方法である。
局所的な誤りを画像全体の再生成で直さない
Bossの兜、提灯を持つ手、重複武器は局所編集で扱うべきである。画像全体を再生成すると、承認済みの画風と同一性まで再び乱数へ戻る。
下位層の自己検査は手掛かりにとどめる
Flovaは検査項目の提案、報告整理、一部の問題発見には使えるが、自分自身の最終検収者にはなれない。上位層はなお抽出フレーム、物体数、音、元目標との対応を確認する必要がある。
結論
今回のFlova検証は、以前のショット単位生成より実際の制作システムに近づいた。先に分析し、計画し、ショットを生成し、参照を継承し、音を整理し、タイムラインを構築して映像を書き出せる。Shot 1とShot 3は、この構造が実質的な改善を生むことも示した。
しかし目標は、プラットフォームが動作することの証明ではない。キャラクター、動作、物語が信頼できる映像を得ることだった。Shot 2の接触因果とShot 4のVeraの同一性はなお失敗し、プラットフォームの自己検査はそれらを合格と報告した。したがって、この完全なFlovaワークフローは失敗事例として保存しなければならない。
次版で全てを捨てる必要はない。Shot 1とShot 3を残し、Shot 2とShot 4だけを作り直す。前者は膝への接触を固定し、後者は同一性検査を通過したVeraの入場フレームから始める。このV1そのものではなく、検証済みのプロジェクト構造と失敗判定基準こそ、残す価値がある。