音楽を生成した後の、映像を完成させる仕事
AIで曲ができても、歌詞が読みやすいミュージックビデオが自動で完成するわけではない。文字を出す時刻、画面での動き、背景とのコントラスト、音声と映像の結合を、別々に整える必要がある。イノベトピアは10月2日、Sunoの楽曲をPythonとFFmpegで映像化した制作記録を公開した。
同記事の筆者が作ったのは、約2分52秒の横長版と、見せ場を切り出した約24秒の縦長版だ。歌詞の時刻が一行ずれていた失敗や、素材画像の修正、書き出し後の確認まで記されている。本稿はその制作記録と公式技術資料を基に、工程を独自に整理する。AI最前線が同じ楽曲や映像を制作・実測したという報告ではない。
先に三種類の素材と、その役割を分ける
必要な素材は、完成した音源、表示用の歌詞、映像の画像だ。歌を生成するための表記と、見る人に読ませる表記を同じにする必要はない。読み方を指定する目的でひらがなを使っても、画面では意味を取りやすい漢字交じりに戻せる。
ただし、最終的に歌われた言葉と、もとの歌詞が一致するかは音源を聴いて確認する必要がある。生成した音声が語を変えたり、繰り返しを増やしたりした場合、原稿を機械的に字幕へ流すだけでは不一致が残る。文字の正しさは、入力した台本ではなく、公開する音との照合で判断したい。
画像も同じだ。設定画が整っていても、全身像では手の向きや楽器の部品が変わることがある。元記事は、利き手やペグの数を修正した例を紹介する。細部を確認する基準を設定画と文章の両方で残すと、どこがずれたかを伝えやすい。
編集部の考察では、素材を確定する段階と、映像へ組み込む段階を分けることが大切だ。途中で画像や歌詞を差し替えるなら、その版に対応する字幕やタイミングも分かるようにする。ファイル名だけでなく、確定日と用途を記録しておけば、古い素材が戻る事故を減らせる。
歌詞の時刻には、何の瞬間かという定義が要る
元記事では、曲を聴きながら各行の歌い出しでキーを押し、時刻を記録する道具を使った。しかし初版の字幕は、歌より一行ずつ遅れた。記録された時刻が、その行ではなく次の行の歌い出しに対応していたためだ。
この失敗は、単に全体を数秒早めれば必ず直るものではない。行ごとの長さや間奏が違えば、一定秒数の補正と、一行単位の対応付けの修正は異なる結果になる。まず「この時刻は表示開始か、歌い出しか、歌い終わりか」を決め、記録した操作と一致しているかを確かめる必要がある。
元記事は行間の時刻差を調べ、長い空白がどの行の間に来るかを手がかりに、ずれを発見した。これは有用な検査方法だが、長い間隔がすべてミスとは限らない。間奏、伸ばす歌唱、未記録の行がある場合にも差は大きくなる。数字で候補を探し、最後は該当部分を聴くという二段階が必要になる。
作業用の表は、行番号、表示する歌詞、開始時刻、終了時刻、確認状態を持たせると扱いやすい。未記録をゼロ秒で埋めず、未確定として残す。最初の一行を推定で補う場合も、推定したまま公開せず、聴いて確認した状態を記録するのがよい。
拍に合わせた動きと、読みやすい表示時間は別
歌詞が拍に合わせて飛び込む演出は、曲のリズムを視覚へつなぐ。しかし、動きの開始が音に合っているだけでは、読む時間が足りるとは限らない。長い行や画数の多い漢字は、短い行と同じアニメーションを当てると読みづらくなる。
元記事では低音の立ち上がりからテンポを推定し、文字の動きを拍へ合わせた。ドラムが休む区間やテンポが変わる曲では、同じ推定がそのまま使えないことも説明する。楽曲全体へ単一のBPMを決め打ちするより、ずれが出る区間を確認できる構成が望ましい。
以下は編集部の演出上の考察だ。動く時間と静止して読ませる時間を分けると、勢いと可読性を両立しやすい。サビを強く見せたいなら、文字を荒らすだけでなく、大きさ、余白、背景の明暗で差を付ける。加工が強すぎて漢字の線が潰れる場合は、演出の迫力より意味を伝えることを優先したい。
また、白い髪や淡い服は明るい背景へ溶けやすい。素材単体で見栄えがよくても、合成すると輪郭を失うことがある。実際に使う背景、文字、人物を重ねた状態で確認する必要がある。
フォントは、利用条件と収録文字を確認する
無料で入手できるフォントでも、商用利用、再配布、改変などの条件は個別にある。Google FontsのDela Gothic Oneの説明のように、配布元の情報を確認する。ダウンロード先の紹介文だけで判断しないほうがよい。
利用条件が合っていても、歌詞に必要な文字がすべて含まれるとは限らない。欠けた文字が代替フォントに変わったり、空欄になったりすれば、書き出し後に気付くことになる。制作前に全文を表示し、特殊な漢字や記号を確認するのが効率的だ。
フォントのファイルとバージョンも素材の一部として残す。同じ名前でも環境が違うと字形や行送りが変わり、再書き出しで収まりが変わる場合がある。字幕や吹き出しと同様、文字の配置は実際の書き出し結果で検品する必要がある。
コマを描く工程と、動画へ圧縮する工程
Pythonの画像ライブラリで一コマずつ描き、FFmpegへ渡す方式では、描画とエンコードを分離できる。たとえば30フレーム毎秒で171.6秒なら、計算上は5,148コマになる。コマ数と時刻の対応を明確にすると、特定の場面を同じ条件で作り直しやすい。
FFmpegのH.264ガイドは、libx264の画質設定やエンコード速度との関係を説明する。CRFは固定ファイルサイズの指定ではない。画面の動きや複雑さが変われば、同じ値でも容量は変わる。元記事のファイルサイズを、別の曲の完成サイズとして予測してはいけない。
長い動画を短い区間へ分けて処理する場合は、区間ごとの解像度、フレームレート、符号化条件を合わせる。結合の公式資料も、再エンコードしない結合には条件があることを示す。つながったことだけでなく、境目で映像や音が欠けないかも確認する。
作業途中の静止画一覧は、全編を書き出す前の手戻りを減らす。静かな場面、サビ、背景が変わる場面、文字の長い行などを先に選び、代表的な失敗を早く見つける。完成後にしか分からない音との同期とは、役割の異なる検査である。
縦動画は、横動画を切るだけで終わらない
縦長の画面では、顔や文字の置き場所が変わる。横版の中央を切り出すだけでは、歌詞の両端や演出の対象が消えることがある。SNSのボタン、説明文、字幕が重なる位置も考え、画面内の安全な範囲へ重要な要素を置き直す必要がある。
曲の途中を抜き出すなら、冒頭の音が唐突に始まらないか、最後の余韻が切れないかを確認する。短いフェードは編集の手段になるが、歌い出しや子音まで消してしまわないようにする。音源にジャケット画像などが含まれる場合は、出力へ必要なストリームだけを選ぶことも重要だ。
字幕ファイルと、映像に焼き込んだ歌詞も区別したい。SRTなどの字幕は視聴者が切り替えられる一方、焼き込んだ文字は映像の一部である。両方を使う場合は二重表示を確認し、情報の重なりが読みにくくならないよう調整する。
ファイル検査と、作品の検査を両方行う
コマ数、時間、音声トラックの有無、解像度は機械的に確認できる。しかし、その結果が正常でも、歌と文字がずれていることや、漢字が読みづらいことは残りうる。最終動画を音付きで通して見る工程を、書き出し完了とは別に置きたい。
AIがコードを書き、静止画を確認できたとしても、その環境で音声付き動画を実際に見聞きできたかは別だ。確認できない工程を確認済みと扱わず、人が担当する部分を明示する。そのうえで、公開先の画面でも、音量、字幕、縦横の収まりを確かめる。
元記事はAI利用の表示、楽曲の権利、フォントの条件も確認した。YouTubeの開示案内やSunoの利用条件に関する説明は更新されうるため、制作時点のプランや素材の扱いを記録する。音源を持っていることと、希望する用途で公開できることを同一視しないようにしたい。
自作の制作工程は手間が増える一方、タイミング、文字、画面構成を個別に直せる。再利用するなら、特定の曲の数値をコピーするのではなく、素材の整理、時刻の検査、代表場面の確認、全編の試聴という工程を引き継ぐことが重要だ。
確認日：2026年10月18日。運営会社：RO合同会社の公式HP。
学習コースAI活用アカデミー
コース一覧を見る →
