2026.08.14 — 08.15
「繋ぐ」を確かめた2日間
この曲はMVの実験のために書いた曲です。最初と最後が結ばれる60秒ループを作りたい、 という動機が先にあり、そのために歌詞と曲を用意しました。だから記録の中身も、絵作りより 「カットとカットをどう繋ぐか」の検証が主になっています。
結果として、立てた仮説が3つとも覆りました。 そのぶん、確かなことが少しだけ分かった2日間です。
パイプラインの解説は MAKING OF — AIだけでMVを量産する、 量産の一日は 制作日誌 2026-08-12 にあります。
この2日の数字
| 完成した動画 | 4本（take1 / 全接続版 / motion context 6カット版 / 同 全編版） |
|---|---|
| GPU実費 | 約 $1.3 |
| 生成本数 | 46本（キービジュアル14枚は追加費用ゼロ） |
| 覆った仮説 | 3つ |
完成版（motion context・全編）。最後のカットが最初のカットと同じ構図に戻り、 地平に新しい鐘楼が立って終わります。
タイトルは 流転 ─ Amor manet。「流転」＝移ろうもの、 「Amor manet」（愛は残る）＝残るもの。 タイトル自体が曲の対比構造を持っています。 ラテン語は間奏で唯一「時間を超えて残るもの」を名指す場所なので、 そこをタイトルに据えると構造が締まります。
01カット設計 — 2度の作り直し
失敗1: ループを幾何学で閉じようとした
最初の設計は「円筒形の廃鐘楼を中心に、カメラが60秒で360°周回する」。 360°回れば必ず元の角度に戻るのでループは幾何学的に閉じる——理屈は通っていました。
10枚生成して並べたところ、塔の形は一致していたのにカメラ距離が固定されていませんでした。 テキストで「35m・目線の高さ」と書いても、生成側は毎回独立に構図を決めます。 この状態で補間させると、周回ではなく寄り引きのポンピングになる。
さらに根本的な問題として、承認済みのタイトル絵と全く関係のない世界になっていました。 ループ構造に気を取られ、タイトル絵から設計を導くという当たり前の手順を飛ばしていたのです。
失敗2: 統一を「場所の固定」と取り違えた
作り直しでタイトル絵の世界を全カットの共通枠にしたところ、今度は全10カットが同じ平原に なりました。灰の平原→尾根→平原→夕暮れの平原→黒い平原。定点のタイムラプスです。
分かったのは、統一とは画法とテーマの統一であって場所の固定ではない、ということ。 共通指定から「地平線を低く」「空が三分の二」を全部外し、 画法・色・粒子モチーフ・主題の4つだけに絞りました。
完成した10景
視点とスケールを意図的に振っています。目線→高空→地面→仰角→俯瞰→極端仰角→接写→宇宙→水平線→目線。
| # | 歌詞 | 場所と視点 |
|---|---|---|
| 1 | 灰になって | 廃墟の平原、地上目線（タイトル絵の世界） |
| 2 | 雨になって | 高空からの俯瞰。渦巻く嵐、その下に海と大陸 |
| 3 | 芽吹き 歌になって | 森の底。倒木と苔むした石像の顔から無数の芽 |
| 4 | そのとききっと | 廃墟の大聖堂内部。光柱、床一面の薔薇、花弁が音符となって昇る |
| 5 | そこにいる | 山上からの俯瞰。夜の大河と街、灯が川面に映って二重になる |
| 6 | Dies irae | 真下からの極端な仰角。崩れ落ちる神々の巨像 |
| 7 | Amor manet | 手のひらの近景。闇の中、両手が小さな灯を包む |
| 8 | すべては流転 | 宇宙的俯瞰。銀河の渦に鐘・王冠・神の顔・花弁・灰が混ざって流れる |
| 9 | 夜明けへ還る | 海の水平線。光の粒が海面に降りて波になる |
| 10 | 新しい灯になる | 平原、地上目線。1と同じ構図で、地平に新しい鐘楼 |
第6景を最大・最暗、第7景を最小・最微光にして隣り合わせました。 曲で最も大きな言葉（怒りの日）と最も小さな光（愛は残る）が並ぶ場所であり、 この60秒の芯にあたります。
02覆った仮説、3つ
まず前提を書いておきます。動画生成には8秒ほどの上限があるので、60秒のMVは 10本の短いカットを作って繋ぐことになります。この繋ぎ目を目立たなくするため、 「このカットの最後は、次のカットの1枚目と同じ絵で終わらせろ」と指定できる機能があります （終点画像の指定）。理屈のうえでは、これで隣り合うカットが滑らかに繋がるはずです。
10箇所すべての繋ぎ目で試したところ、7つが成立、3つが失敗しました。 失敗の形は「しばらく保持 → 途中でパッと切り替わる → また保持」。 滑らかに変化するのではなく、真ん中でカットが入ってしまいます。
仮説1
構図が近い2枚ほど繋がるはずだ
逆でした。失敗した3つは、キービジュアル間の距離が最も近い3つ。 成立した7つはすべて距離が遠い方でした。 ただしこの距離指標（画素差）は「両方とも暗い」を「似ている」と誤認するので、 指標そのものが妥当でない可能性が高い。 結論として、成否の予測変数はまだ分かっていません。
仮説2
「滑らかだが終点に届かない」という失敗形がある
存在しませんでした。途中経過でそう報告しましたが、 古いクリップを掴んだまま測っていたのが原因。 正しくは全10本が終点に到達しています（誤差0.1〜2.5%）。
仮説3
継ぎ目の差分が小さければシームレス成功だ
何も測れていませんでした。境界の差分が0.78%だったので成功と判断しましたが、 末尾が終点画像になっていれば境界は必ず小さく出ます。 判定はクリップ内部の最大フレーム間差分で行う必要がある （Δ>10%なら補間ではなく内部カット）。
なお、公開時に完成ファイルをシーン検出にかけたところ、 last_frame版からはちょうど3箇所のハードカットが検出されました。 失敗した3接続が、そのまま切り替わりとして残っていることが確認できます。
03転機 — 「似せる」のではなく「続ける」
転機になったのは、繋いだ映像の品質チェックでした。 大聖堂のカットでは花弁が舞い上がっているのに、そこから繋いだ次のカットでは 同じ花弁が落ちていく。舞い上がってから落ちるという、 誰が見ても不自然な仕上がりになっていたのです。
原因は明快でした。終点画像の指定は「次のカットの1枚目をこの絵にしろ」という指示でしかなく、 絵は似せられても、動きの向きまでは伝わりません。 各カットは独立に生成されるので、前のカットで上昇していた粒子が、 次のカットでは「落ちている粒子」として解釈されてしまう。
解決策として使ったのが Motion Context という仕組みです。 終点画像の指定が「完成した絵」を渡すのに対し、こちらは 前のカットの終わりぎわを、生成の途中段階のデータのまま次のカットへ引き継ぎます。 絵の見た目だけでなく「いま何がどっちへ動いているか」ごと渡すわけです。 引き継いだぶんは最後に切り落とすので、尺は変わりません。 「似せる」のではなく「続ける」——これが違いです。
同じ絵・同じ指示のまま、繋ぎ方だけを変えて比べました。 数値は映像内の動きを縦方向で測ったもので、マイナスが上昇・プラスが下降です。 繋ぎ目の前後で符号が変われば、そこで動きが反転しています。
| 接続 | 終点画像の指定 | Motion Context |
|---|---|---|
| s001→s002 | +0.00 → −0.11 反転 | −0.27 → −0.09 継続 |
| s002→s003 | −0.18 → +0.11 反転 | −0.32 → −0.27 継続 |
| s003→s004 | +0.41 → +0.02 継続 | −0.08 → −0.07 継続 |
| s004→s005 | −0.30 → +0.00 反転 | −0.57 → −0.12 継続 |
| s005→s006 | +0.01 → +0.03 継続 | +0.13 → +0.12 継続 |
向きが反転していた3箇所が、すべてゼロになりました。 品質チェックで見つかった大聖堂のカット（花弁が舞い上がったあと、次のカットで落ちていた）も、 上昇したまま次のカットへ入るようになっています。 s005→s006では両方とも下降しているので、向きを揃えているのではなく継承している ことが確認できます。
この方式では、1本目の終わりを2本目へ、2本目の終わりを3本目へ……と数珠つなぎに引き継いでいきます。 以下ではこれを「鎖」と呼びます。MV全編を1本の鎖として繋いだ場合 （10カット＝9つの繋ぎ目）でも、9接続中8つが成立。 灰の嵐から闇の中の灯へ移る、明るさが最も大きく変わる箇所でも繋がりました。
予期しなかった性質もあります。まったく同じ素材なのに、6カットだけ繋いだ版と全編を繋いだ版とで、 同じ箇所の運動の向きが逆になりました。つまり鎖は起点から伝播している。 各接続は独立しておらず、先頭カットの生成結果が下流すべての運動を決めているのです。 長い鎖では、先頭を1本撮り直すと、それ以降のすべてが変わります。
04最後に残った壁 — 17フレームの格子
運動が繋がるようになった映像を見直すと、繋ぎ目でわずかに動きが飛ぶ箇所が残っていました。 1フレームぶんほどのごく小さな段差です。測ってみると、 連結時に捨てているフレーム数と、段差の大きさが正確に相関していました。
原因は、生成側が出せる長さが飛び飛びだという点にありました。 鎖では前のカットから引き継いだぶんを切り落とすので、 実際に使える尺は17フレーム（0.708秒）刻みの値しか取れません。 つまり尺は連続した数値ではなく、0.708秒ごとの目盛り——本稿でいう格子——の上にしか置けない。 一方こちらは「この歌詞はここからここまで歌う」という曲側の区切りから尺を決めているので、 その値がちょうど目盛りに乗ることはまずありません。端数が必ず出ます。
エコシステム全体を調べましたが、歌詞優先を保ったまま鎖を繋ぐ実装は公開されていませんでした。 公開されている実装はいずれも尺を格子に丸め、 「曲の窓を納品フレームのタイムラインから逆算する」—— こちらの「歌詞が尺を決める」とは完全に逆の発想です。
到達した解
鎖はシーンの内側で閉じ、シーンの境界はカットにする。
シーンの境界は元々ハードカットなので、そこで端数を捨てても見えません。 シーン内部を分割して鎖にすれば、内部の繋ぎ目は端数ゼロで完全に連続する。 これなら歌詞ぴったりのカット割りを保ったまま、シーン内の運動を途切れさせず、 しかも生成尺の上限も超えられます。
05副産物 — 公式の歌詞タイミング
音声認識による強制アライメントは、歌詞テキストを音声に無理やり割り当てるので 一貫して0.15〜0.35秒早く出ていました。 Suno側のデータは生成元の真値で、行・単語のタイミングとセクション名、 さらにふりがな（芽吹（めぶ）き、流転（るてん）、灯（ひ））まで持っています。
該当曲の自動選択では一度つまずきました。最初は時間範囲の重なりで選ぼうとして失敗—— 60秒のHookは5分の曲のどこかと必ず重なるので、判別に使えません。 歌詞テキストの一致率で選ぶよう変えました。
06この2日で得た運用知見
- 繋がることと良いことは別。全接続を繋ぐとカットの切れ味が全部消えて緩一色になる。 変容の連鎖は繋ぎ、曲が断絶する場所（Dies irae）は切る
- latentはGPU上のディスクにあり、実行終了で消える。 鎖は1回の実行で通しで生成する必要があり、途中の1本だけをリテイクすることはできない
- 判定は代理指標に頼らず、必ず目視と併せる。 継ぎ目の差分で「成功」と誤判定したのが、この2日で一番の反省点
- 8連鎖しても画質の劣化は見えなかった。ただし劣化指標が極端な参照画像で破綻したため、 条件の揃う2本の比較にとどまる
パイプライン側では、中間ファイルの再利用条件も直しました。 切り出し済みクリップがあると再利用する作りだったため、 60.00秒の設計が59.50秒で出力される事故が起きていた。 フレーム数の一致と更新時刻の両方を見るようにしています。
制作環境: Suno（楽曲） / GPT-Image2・Codex CLI（キービジュアル） / MiniMax H3 + ComfyUI（動画生成） / RunPod（GPU） / 自作パイプライン（Python）