ComfyUIの動画生成は、画像生成のworkflowに「時間軸（frame数）」と「frame列を動画ファイルにするEncode工程」が加わった構造です。Text-to-Video（T2V）は文章から、Image-to-Video（I2V）は1枚の画像を起点に複数frameを生成し、どちらも最後にCreate Video→Save Videoで1本にまとめます。最初は短尺・低解像度で1本通し、frame数・FPS・VRAM・時間の関係を自分の環境で記録してから広げます。
情報確認日：2026年8月22日（日本時間）
結論：画像生成＋時間軸＋Encodeと捉え、短尺で1本通す
責任範囲
- 動画workflowが画像workflowと何が違うかを、node構成の差として示す
- T2VとI2Vの違いは「入力画像の条件が増えるかどうか」として整理する
- Frames÷FPS＝秒数の関係と、latentの時間次元がframe数で決まる仕組みを説明する
- VRAMと生成時間が何に比例するかを機構から説明し、数値は自分で測る表を示す
- 生成・補間・Upscale・Encodeを別工程に分ける理由を示す
- 特定modelの最新手順や推奨値は書かず、ComfyUIの基本はComfyUIの使い方、測り方は生成速度を比較する方法、VRAM不足はVRAM不足の切り分けに任せる
動画Workflowは画像と何が違うか
公式tutorialのT2V／I2V workflow（2026年8月時点）を見ると、画像生成と同じ骨格に、3つの要素が足されています。「空のlatentが時間軸を持つ」「samplerの出力がframe列になる」「frame列を動画にEncodeする」の3つです。
- Load Diffusion Model / Load CLIP / Load VAE：動画用のmodel・text encoder・VAEを読む（画像と同じ役割）
- CLIP Text Encode：positive／negativeを条件に変える（画像と同じ）
- Empty Latent Video系node：width・heightに加えてlength（frame数）を持つ空のlatentを作る（ここが画像と違う）
- KSampler：時間軸を持つlatentをまとめてdenoiseする
- VAE Decode：latentをframe列（IMAGEのbatch）に戻す
- Create Video → Save Video：frame列をfps指定で動画にまとめ、mp4等で保存する（ここも画像と違う）
3と6以外は、画像生成で使っているnodeと同じ名前・同じ役割です。動画生成を「まったく別のもの」と構えるより、「空のlatentにlengthが付き、最後にEncodeが付いた画像生成」と捉える方が、workflowを読むときに迷いません。
| 要素 | 画像生成 | 動画生成 |
|---|---|---|
| 空のlatent | width・height・batch | width・height・length・batch |
| samplerの出力 | 1枚分のlatent | 時間軸を持つlatent |
| Decode後 | IMAGE 1枚（batch=1） | IMAGE frame数分（batchとして並ぶ） |
| 保存 | Save Image | Create Video（fps）→ Save Video（format・codec） |
| model | 画像用checkpoint | 動画用model＋対応するtext encoder・VAE |
T2VとI2Vはどう分けるか
T2VとI2Vの差は、「最初のframeを決める材料があるか」です。T2Vは文章だけから全frameを作り、I2Vは1枚の入力画像を起点の条件に加えて続きを作ります。公式tutorialでは、I2VのworkflowにLoadImageが上流に足され、空のlatentを作るnodeがI2V専用のもの（Wan系ならWanImageToVideoやWan22ImageToVideoLatentなど）に置き換わります。
Text-to-Video
- 入力：promptのみ
- 構図・被写体・画風をすべて文章で指定する
- 同じpromptでもseedで大きく変わる
- 向く用途：素材探し、アイデア出し
Image-to-Video
- 入力：起点画像＋prompt
- 被写体・構図は画像が決め、promptは「どう動くか」を担当する
- 入力画像の解像度・縦横比がlatentの条件に影響する
- 向く用途：決まったキャラクターや商品を動かす
I2Vで増える注意点は2つあります。入力画像のサイズと生成サイズの関係をmodelごとのtutorialどおりに合わせること、そして起点画像の権利を確認することです。自分で生成した画像をI2Vの入力にする流れなら、前段の画像workflowも同じリポジトリに残しておくと再現できます。
Frame・FPS・秒数はどう関係するか
動画の長さは、frame数をFPSで割った値です。生成側で決めるのはframe数（length）で、FPSはCreate Videoで「何枚を1秒として再生するか」を決める値です。同じframe数でもFPSを変えれば秒数が変わり、動きの速さも変わります。
秒数 = Frames ÷ FPS
例
25 frames ÷ 25 fps ≒ 1.0 秒
49 frames ÷ 16 fps ≒ 3.1 秒
81 frames ÷ 24 fps ≒ 3.4 秒
121 frames ÷ 30 fps ≒ 4.0 秒上の例は計算の関係を示すためのもので、どの値が良いかはmodelで異なります。frame数に「4n+1」のような数が並ぶのは、core nodeのEmptyHunyuanLatentVideoでlengthのstepが4、既定が25になっていることと対応します。このnodeはlatentの時間次元を((length − 1) ÷ 4) + 1（整数除算）で計算するため、lengthを4増やすとlatentの時間方向が1増える、という関係になっています。
FPSは生成後に変えられます。同じframe列を、Create Videoのfpsだけ変えて2本保存すれば、「秒数と動きの速さ」がFPSでどう変わるかをGPUを使わずに比べられます。
| 値 | どこで決まるか | 変えると何が変わるか |
|---|---|---|
| length（frame数） | Empty Latent Video系node | VRAM・生成時間・最大秒数 |
| fps | Create Video（既定30） | 秒数と動きの速さ。生成コストは変わらない |
| width・height | Empty Latent Video系node（step 16） | VRAM・生成時間・画質 |
| format・codec | Save Video（auto／mp4／mkv／webm） | ファイルサイズと再生互換性。生成結果は変わらない |
VRAMと生成時間はなぜ短尺から試すのか
画像生成ではwidth×heightがVRAMと時間を決めました。動画ではそこにlatentの時間次元が掛かります。frame数を増やすほど、samplerが一度に扱うlatentが大きくなり、VRAMも時間も増えます。解像度を上げれば同じく増えます。つまり動画は「面積×時間」の3軸でコストが決まり、画像より一段早く上限に当たります。
公式tutorialには、小さいmodel（Wan2.2の5B版）についてComfyUIのoffloadを使えば8GB VRAMで動く見込み、という趣旨の記述があります。これはそのmodelの案内であって、全動画modelの目安ではありません。自分の環境で何frame・何解像度まで動くかは、次の記録表で確かめます。
短尺1本でFrames・FPS・生成時間・Peak VRAMを記録する
- 使うmodelの公式tutorialのworkflowをそのまま開き、prompt以外は変えない
- lengthをnodeの既定値（またはtutorialの値）のままにし、解像度も既定のまま1本生成する
- 起動ログの「Prompt executed in」の秒数と、
nvidia-smiで取ったPeak VRAMを記録する - 問題なければlengthだけを1段階（stepの4刻みで数段）増やし、同じ記録を取る
- 次に解像度だけを1段階上げ、同じ記録を取る
| run | model | width×height | length | fps | 秒数 | 生成時間（秒） | Peak VRAM（MiB） | 結果 |
|---|---|---|---|---|---|---|---|---|
| 01 | 既定 | 既定 | ||||||
| 02 | 既定 | 既定＋4×n | ||||||
| 03 | 1段階上 | 既定 |
見るのは「lengthを増やしたとき」と「解像度を上げたとき」で、生成時間とVRAMがそれぞれどれだけ増えるかです。どちらかでmemory.totalに近づくなら、そこが自分の環境の上限で、それ以上は短尺を複数本作って後工程でつなぐ設計に切り替えます。測り方の詳細（ColdとWarmの分離、同一手法でのVRAM取得）は生成速度を比較する方法と同じです。
保存と後処理はどう分けるか
動画は生成だけで完成しません。frameを補間してなめらかにする、解像度を上げる、音声を付ける、配布用にEncodeし直す、といった工程が続きます。これらを1つのworkflowに全部入れると、生成に失敗したときに後工程までやり直しになり、どこが遅いかも分からなくなります。
| 工程 | 入力 | 出力 | 分ける理由 |
|---|---|---|---|
| 生成 | prompt（＋起点画像） | frame列（IMAGE batch） | 最もGPUを使う。ここだけ何度も回す |
| 補間 | frame列 | frame数が増えたframe列 | 生成を変えずに秒数・なめらかさを調整できる |
| Upscale | frame列 | 解像度が上がったframe列 | 低解像度で生成し、採用分だけ上げる |
| Encode | frame列（＋音声） | mp4等の動画ファイル | fps・format・codecは生成結果と独立 |
具体的には、生成workflowの出口でframe列をそのまま保存（画像連番、またはロスレス寄りの形式でSave Video）し、後処理用のworkflowではLoadVideo→GetVideoComponentsでframe列とfpsを取り出して続きを行います。core nodeのGetVideoComponentsはimages・audio・fpsを出力するので、前の工程のfpsをそのまま引き継げます。
保存したmp4／webmには、PNGと同様にworkflowとpromptが埋め込まれます。ただし動画編集ソフトで書き出し直すと失われることがあるため、生成直後のファイルは加工せずに残してください。
共通土台をどう作るか
動画modelは入れ替わりが早く、model固有の推奨値はすぐ古くなります。この記事で扱った内容のうち、modelが変わっても残るのは次の5点です。
- workflowの骨格：model読み込み→条件→時間軸付きlatent→sampler→decode→Create Video→Save Video
- T2V／I2Vの差は「起点画像の条件が増えるか」
- 秒数＝Frames÷FPS。生成コストを決めるのはframe数と解像度で、FPSは後から変えられる
- コストは面積×時間の3軸。短尺・低解像度から記録して上限を知る
- 生成・補間・Upscale・Encodeは別workflowに分ける
新しいmodelを試すときは、その公式tutorialのworkflowをこの骨格に当てはめて「どのnodeが置き換わったか」だけを見ます。専用のlatent nodeやtext encoderが変わっても、上の5点は変わりません。model別の手順は、この記事を親にした別記事で扱います。
よくある質問
画像生成用のcheckpointで動画は作れますか？
時間軸を持つlatentを扱えるmodelと、それに対応するVAE・text encoderが必要です。画像用checkpointをそのまま動画workflowにつないでも動きません。使うmodelの公式tutorialにある組み合わせから始めてください。
長い動画を作るにはframe数を増やせばよいですか？
frame数を増やすとVRAMと時間が増え、環境の上限に当たります。上限に近い場合は、短尺を複数本生成して後工程でつなぐか、補間でframe数を増やす設計を検討します。modelごとに扱えるframe数の目安も異なるため、tutorialの値から出発してください。
seedを固定すれば同じ動画を再生成できますか？
画像と同じで、seed・model・解像度・length・steps等がすべて同じなら近い結果になりますが、環境差で完全一致しない場合があります。保存した動画にはworkflowが埋め込まれるので、再生成の条件はそこから取り出せます。
まとめ
ComfyUIの動画生成は、画像生成のworkflowに時間軸付きのlatentとEncode工程が加わった構造です。T2Vは文章だけ、I2Vは起点画像を条件に加える違いがあり、秒数はFrames÷FPSで決まります。
VRAMと生成時間は解像度とframe数の両方で増えるため、公式tutorialの既定値で短尺1本を通し、lengthと解像度を1段階ずつ変えて記録してください。生成・補間・Upscale・Encodeを分けておけば、modelが変わっても同じ土台で続けられます。