この記事について（広告・アフィリエイトリンクはありません）
紹介しているソフトとモデルは、すべて無料で入手できるものです。
MiniMax H3 は1回の生成の長さに限りがあります。ComfyUI-MiniMaxH3-TimelineDirector は、短い動画を重ねながらつなぎ、長い動画を1回の実行で作るカスタムノードです。
作者の値「1536×832・29秒を約10分」を確かめ、継ぎ目を調べました。同じ解像度の約30.7秒は約7分で終わり、継ぎ目の数値上の段差も小さめです。ただし、全段に同じプロンプトを使うと話が繰り返されました。
H3 の基本は導入記事を見てください。
1536×832・約30.7秒は約7分で終わった（今回のテスト条件で）
| 出力 | 段数 | 2段階 | 全体 | VRAM ピーク |
|---|---|---|---|---|
| 960×544・約5.2秒 | 1 | なし | 300秒（読み込み込み） | 31.5GB |
| 960×544・約13.7秒 | 3 | なし | 115秒 | 31.3GB |
| 1536×832・約13.7秒 | 3 | あり（6+2） | 185秒 | 31.4GB |
| 1536×832・約30.7秒 | 7 | あり（6+2） | 422秒（約7分） | 31.3GB |
- 作者の「29秒で約10分」より短い時間で終わりました。RTX 5090 で十分に実用的です。
- 継ぎ目の位置で、フレーム差はほとんど増えませんでした。
- ただし全段に同じプロンプトを使うと、話が段ごとに繰り返されます。今回の動画では、数秒おきに同じカットに戻りました。
迷ったら、まず3段・低い解像度で動きを確かめてください。
試した環境
| 項目 | 内容 |
|---|---|
| GPU | RTX 5090（32GB）、ドライバー 621.01 |
| CPU / RAM | Ryzen 9 9950X3D / 128GB |
| OS | Windows 11 |
| ComfyUI | ポータブル版＋master 17ff1dcc（v0.43.0-26） |
| ノード | TimelineDirector 050226d（2026-10-21）。入れたのはこれだけ |
| モデル | H3 fl2va pruned int8 + Turbo 8 step、qwen3vl nvfp4、映像 VAE int8、音声 VAE fp32、潜在アップスケーラー |
| 段の作り | 1段 124 フレーム、重なり 22 フレーム、シード 42、euler、8 step |
| プロンプト | ラーメン屋台（2K 記事と同じ）を全段に共通で使用 |
custom_nodes に入れるだけ
custom_nodes に入れるだけです。カスタムノードの入れ方はこちらにまとめています。
cd ComfyUI/custom_nodes
git clone https://github.com/Songssx/ComfyUI-MiniMaxH3-TimelineDirectorモデルは H3 の標準のものです。2段階サンプリングには潜在アップスケーラーが要ります。
| ファイル | 置き場所 |
|---|---|
| minimax_h3_fl2va_pruned_int8_convrot.safetensors | models\diffusion_models |
| minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors | models\loras |
| minimax_h3_latent_upscaler_3d_conv_v1_bf16.safetensors | models\latent_upscale_models |
作者の例の JSON は、作者が別に作った統合モデルを前提にしています。下の JSON は標準のモデルに置き換えた最小の構成です。
- timeline_director_3seg_workflow.jsonComfyUI にドラッグして読み込みます（960×544、3 段、FL2VA + Turbo 8 ステップ。Global Prompt を自分の内容に変えてください）
画面から実行して、成功を確かめました（115秒）。
主なノードは3つ
| ノード | 役割 |
|---|---|
| MiniMax H3 Material Planner | タイムラインの編集。段の分け方を作る |
| Low-Memory Segment Video Sampler | 1段ずつ動画にしてつなぐ。長尺向け |
| Finite Segment Sampling | 全部メモリーに持ったままつなぐ |
段の長さは「5 + 17×n フレーム」、重なりも同じ条件です。合わないとエラーになります。今回は124フレーム、重なり22です。
継ぎ目はどうだった？
連続するフレームの差（明るさの平均差）を測りました。1536×832・30.7秒の動画です。
| 測った場所 | フレーム差 |
|---|---|
| 全体の中央値 | 4.44 |
| 段の切り替わり付近（102、204、306、408フレーム） | 4.46〜5.08 |
| 段の切り替わり付近（510、612フレーム） | 6.0〜6.1 |
| 7段目の途中（714フレーム。7段目は612〜735で、切り替わりではありません） | 約6.0 |
| カットの変わり目（最大） | 71.4 |
408、510、612 フレームの1つ手前（407、509、611）には、61〜71 の大きな差があります。次の節で説明する「同じ流れの繰り返し」のカットで、切り替わりの直前に重なっています。
段の切り替わりで、フレーム差はわずかに増えた程度でした。白く飛ぶようなものは、今回の数値と抜き出した画像では見つかりません。
ただし、動画全体を通して目で確かめたわけではありません。
同じプロンプトだと話が繰り返される
一番の注意点です。今回のプロンプトには「0〜1.5秒は鍋、次に屋台」のような時間の指定があります。全段で共通にしたところ、それぞれの段の中で同じ流れが再生されました。数値でも、大きな差のある場所が 102 フレームおきに並んでいます（338、440、542、644 など）。
これはノードの不具合というより、使い方の問題です。作者の説明でも、Global Prompt は段ごとのプロンプトがないときに全段で使われます。長尺で話を進めたいときは、段ごとに別のプロンプトを入れるか、時間の指定のない文章にしてください。今回は全段共通の1パターンしか試していません。
RTX 5090 以外の人へ
--reserve-vram は、OS などのために VRAM を残しておく設定です。960×544・3段で試しました。
--reserve-vram | 結果 | 全体 | VRAM ピーク（開始時からの増加） |
|---|---|---|---|
| 指定なし | 成功 | 115秒 | 31.3GB |
| 20（計算上の残り 約12.1GB） | 成功 | 123秒 | 14.5GB（約12.8GB） |
| 24（計算上の残り 約8.0GB） | 成功 | 125秒 | 10.4GB（約8.7GB） |
開始時からの増加（約12.8GB、約8.7GB）は、総 VRAM の 32,580MB から指定分を引いた残りより少し多くなりました。実際の 12GB・8GB の GPU では足りない可能性があります。今回はどの指定でも失敗していません。どこまで減らすと失敗するかは測っていません（未確認）。
VRAM 容量が少ない環境を想定した簡易テストです。実際の 8GB・12GB 搭載 GPU での動作を再現・保証するものではありません。 RAM は ComfyUI だけで約43〜46GiB 使いました。VRAM 不足の対処はこちらにまとめています。
商用で使うときの条件は？
- ノード：GPL-3.0 です。動画を作るだけなら、作った動画に GPL は及びません（一般的な解釈で、法的な助言ではありません）。ノードのコードを改変して配るときは、GPL の条件に従います。
- MiniMax H3：MiniMax H3 Community License です。EU・英国・韓国・米国は対象外、年商2,000万ドル超は別途の許諾が必要です。
よくある質問（FAQ）
Q. TimelineDirector で何秒まで作れますか？
作者の説明では VRAM、RAM、ディスク、ComfyUI の実行の制限まで、段は最大64です。今回は約30.7秒まで試しました。
Q. 作者の値のとおりの速さですか？
作者の 1536×832・29秒 約10分に対し、1536×832・30.7秒が約7分でした。条件は同じではありません。
Q. 継ぎ目は目立ちますか？
今回の数値では、切り替わりの位置のフレーム差はほとんど増えませんでした。全編の目視はしていません。
Q. カットが何度も戻るのはなぜですか？
全段に同じプロンプトを使うと、段ごとにそのプロンプトの流れが再生されます。段ごとのプロンプトか、時間の指定のない文章にしてください。
Q. カスタムノードは他にいりますか？
下の JSON の範囲では、これ1つです。Prompt Bridge などの一部の機能には Prompt Rewriter が必要です。
まとめ
- 1536×832・約30秒を7分で作れました（今回の条件で）。
- 継ぎ目の数値上の段差は小さめでした。
- 長尺では、段ごとのプロンプトの設計が大切です。
検証メモ
- 実行の回数：各条件1回です（960×544・3段は2回のうち2回目がキャッシュで0.2秒だったので除きました）。
- 最初の300秒：読み込みを含みます。ほかの実行より長いのはそのためです。読み込みだけの時間は記録していません（内訳未確認）。
- 全体の内訳：ノードの記録で、960×544・3段の115秒はサンプリング 99.1秒、
video_archive13.2秒、エンコード 1.7秒など。1536×832・7段の422秒はサンプリング 355.8秒、video_archive59.9秒、エンコード 3.4秒などです。最初の300秒はサンプリング 260.3秒、video_archive34.5秒、エンコード 4.1秒などです。 - バージョン：リリースの最新タグは v0.7.0 で、CHANGELOG には 0.8.0 以降もあります。作者の 52.6 秒の例は v0.6.0（2026-09-01）のリリースに付いています。
- 未確認のこと：動画全体の目視、音声の聞き比べ、参照動画や音声の固定、段ごとのプロンプト、低メモリのノードの RAM の削減幅、作者の統合モデル、実際の 8GB・12GB GPU。
