MiniMax H3 Ref2VAの使い方|ComfyUIで画像・動画・音声を参照して動画生成

今回は「MiniMax H3」のReference to Video(Ref2VA)をComfyUIで使う方法を紹介します。前回の記事では、インプット画像1枚から動画を生成するImage to Videoを扱いました。本記事では、画像・動画・音声を混ぜて参照させるRef2VAを取り上げます。キャラクターの見た目・動き・カメラワーク・声・スタイルを、それぞれ別の素材から持ってくるという使い方ができるモードです。H3の基本的な仕組みやモデル構成については、前回の記事をご覧ください。
この記事で学べる事
- MiniMax H3のReference to Video(Ref2VA)の概要と、FL2VAとのチェックポイントの違い
- Ref2VAで参照できるファイルの上限と、ComfyUIノードのスロットの数え方
- 参照素材への役割の割り当て方と、<Subject N>などのラベルの使い分け
- ComfyUI公式テンプレート「MiniMax H3: Reference to Video」に必要なモデルと配置場所
- 音声付きの参照動画の繋ぎ方と、参照動画を24fpsに揃える方法
- ComfyUIが自動で付けるラベルと、その番号の決まり方
- ref_image_sizeとTurbo LoRAによる生成時間・品質の比較
- 高品質な動画を目指すDCAIカスタムワークフローの構成(💎会員限定)
- 6セクション形式のプロンプトの書き方(💎会員限定)
MiniMax H3のReference to Video(Ref2VA)とは
Ref2VA(Reference-to-Audio-Video)は、テキストに加えて、参照用の画像・動画・音声を渡して生成するモードです。前回の基本記事で扱ったImage to Videoは、最初のフレームを固定してその先を作るものでした。Ref2VAでは「この素材から見た目を」「この素材から動きを」「この素材から声を」という指定ができます。参照と生成結果の関係を、固定されたタスク名ではなく自然言語で書ける、というH3の設計思想がもっともわかりやすく表れているモードと言えるでしょう。
FL2VAとRef2VAは別のチェックポイント
最初に押さえておきたいのが、FL2VAとRef2VAはモデルファイルそのものが違うという点です。MiniMaxはH3-Baseを2つのタスク別チェックポイントとして公開しており、それぞれ対応するタスクが決まっています。
| チェックポイント | 対応タスク | 入力条件 |
|---|---|---|
| MiniMax-H3 Base FL2VA | t2va/fl2va | テキスト+任意の最初のフレーム・最後のフレーム、またはその両方 |
| MiniMax-H3 Base Ref2VA | ref2va | テキスト+参照画像・参照動画・参照音声 |
つまり、基本記事でダウンロードしたminimax_h3_fl2va_pruned_int8_convrot.safetensorsでは、Ref2VAは動きません。minimax_h3_ref2va_pruned_int8_convrot.safetensorsを別途ダウンロードする必要があります。ComfyUIのノードも、FL2VA系が「MiniMax H3 Image to Video」、Ref2VA系が「MiniMax H3 Reference to Video」と分かれています。
LoRAも、どちらのチェックポイントで蒸留されたものかを合わせる必要があります。🔗ComfyUI公式ドキュメントでは、フルビルドで学習したLoRAをプルーンド版に読み込むと、adaln関連のテンソルが形状不一致になりマージされないと説明されています。テンプレートが読み込むTurbo LoRAはadalnテンソルを持たないため、どちらのビルドでも読み込めます。
参照できるファイルの上限
Ref2VAに渡せる参照素材には上限があります。MiniMaxのモデルカードに記載されている仕様は以下の通りです。
| 種類 | 本数 | 1本あたりの長さ | 合計の長さ |
|---|---|---|---|
| 画像 | 9枚まで | — | — |
| 動画 | 3本まで | 2〜15秒 | 15秒以内 |
| 音声 | 3本まで | 2〜15秒 | 15秒以内 |
さらに、全種類を合わせたファイル数の上限が12です。画像を9枚使う場合、動画と音声は合わせて3本までです。
ここで押さえておきたいのが、「合計15秒」という制限は動画と音声それぞれに別枠でかかるという点です。画像には尺の概念がないので、そもそもこの制限の対象外です。3つの枠は独立しています。
- 画像の枠:9枚まで。尺の制限はありません。
- 動画の枠:3本・合計15秒まで。
- 音声の枠:3本・合計15秒まで。
動画の15秒は、複数のクリップで分け合う「予算」と考えるとわかりやすいでしょう。1本あたりの下限が2秒なので、組み合わせは次のようになります。
| 構成 | 合計 | 可否 |
|---|---|---|
| 5秒 × 3本 | 15秒 | ○ |
| 10秒 + 5秒 | 15秒 | ○ |
| 10秒 + 3秒 + 2秒 | 15秒 | ○ |
| 15秒 × 1本 | 15秒 | ○ |
| 10秒 × 2本 | 20秒 | ✗ |
たとえば10秒の動画をカメラワークの参照に使うと、動画の予算は残り5秒です。ただしキャラクターの見た目や表情の参照は、動画ではなく画像で渡すのが基本なので、動画の予算が減っても9枚の画像枠はそのまま使えます。動画の枠は「動画でしか表現できないもの」に使う、と考えるとよいでしょう。
✅参照動画は24fpsのフレーム列として扱われます。ノードはフレームレートを変換しないので、30fpsや60fpsの動画は24fpsに変換してから繋ぐ必要があります。解像度の扱いとあわせて、後述の「参照動画のサイズとフレームレート」で解説します。
ここで注意したいのが、ComfyUIのノード側の入力は、モデルカードの3分類と1対1になっていないという点です。MiniMaxH3ReferenceToVideoノードは4つの入力グループを持っており、参照動画に付いているサウンドトラックが独立したグループになっています。ノードのコードで指定されているスロット数の上限は以下の通りです。
| 入力グループ | 内容 | スロットの上限 |
|---|---|---|
ref_image | 参照画像 | 9 |
ref_video | 参照動画(24fpsのフレーム列) | 3 |
ref_video_audio | 参照動画の音声トラック(同じ番号の動画と対になる) | 3 |
ref_audio | 単体の参照音声 | 3 |
ref_video_audioが独立したグループになっている点を補足します。このノードには音声付きの動画を丸ごと受け取る入力がありません。ref_videoはフレーム列(IMAGE)、ref_video_audioは音声(AUDIO)で、それぞれ片方しか受け取りません。そして、ref_video_audio_0はref_video_0の音声、という番号での対応で結び付けられます。
✅同じ音声をref_audioに繋ぐこともできますが、その場合は「動画に同期した音声」ではなく「独立した音声素材」として扱われます。両者の違いと具体的な配線は、後述の「音声付きの参照動画の繋ぎ方」と「動画とは別の音声を参照したいとき」で説明します。
⚠️ノードに見えているスロットの数は、上限ではありません。参照系の4つの入力は、空いているスロットに繋ぐと次のスロットが1つ増える方式(ComfyUIのAutogrow)で作られています。空いているスロットに繋いでいけば、上の表の上限まで増やせます。
このとき、スロットの数とファイルの数は一致しません。ref_video_audioは参照動画そのものの音声トラックを入れる場所なので、動画1本が映像と音声で2スロットを占めます。つまり18スロットを全部埋めても、実際のファイル数は画像9+動画3+単体音声3=15ファイルです。
それでも参照ファイルの上限は合計12ファイルなので、15では超過します。しかもComfyUIのMiniMaxH3ReferenceToVideoノードは、合計12ファイルも合計15秒もチェックしていません。上限を超えてもエラーにならないので、合計12ファイルを超えないように自分で数える必要があります。
✅逆に、ノード側にだけある制限もあります。参照動画は、生成する動画自身のフレーム数まで切り詰められます。つまり、lengthが初期値の124フレーム(約5.17秒)のままだと、10秒の参照動画を繋いでも先頭の約5秒しか使われません。長い参照動画のカメラワークを丸ごと効かせたい場合は、生成する動画の長さも同じだけ伸ばす必要があります(10秒なら243フレーム)。また、参照動画の下限はモデルカードの2秒ではなく5フレーム(24fpsで約0.2秒)で、5フレーム未満はエラーになります。切り詰めの際も17k+5のグリッドに丸められます。
参照ファイルに「役割」を割り当てる
Ref2VAでもっとも重要なのが、どの素材を何のために使うのかを、プロンプトの中で言葉にすることです。ComfyUI公式ドキュメントでも、「それぞれの参照にジョブを割り当てる」「どの参照がショットのどの部分を動かすのかを明示したほうが、はるかに良く機能する」と書かれています。
割り当てられる役割は、たとえば次のようなものです。前のセクションで触れた3つの枠のうち、どれを消費するのかもあわせて整理しておきます。
| 役割 | 内容 | 主に使う素材 |
|---|---|---|
| 見た目(アイデンティティ) | キャラクターの顔・髪・服装・体型を保持します。 | 画像 |
| スタイル | 画風、色設計、ライティング、質感を引き継ぎます。 | 画像 |
| 表情・ポーズ | 表情や立ちポーズを指定します。 | 画像 |
| 構図・ショット設計 | 絵コンテやキャラクターシートとして、ショットの構図や順序を指定します。 | 画像 |
| 動き(モーション) | 人物や物体の動作を再利用します。 | 動画 |
| カメラ | カメラワーク、カット、リズム、時間構造を参考にします。 | 動画 |
| 声 | 声質や話し方を、特定の話者に割り当てます。 | 音声 |
| BGM・効果音 | 音楽のスタイルや効果音の質感を参考にします。音声をそのまま流用することもできます。 | 音声 |
この表の通り、静止画で足りる役割は画像で渡したほうが有利です。15秒という尺の予算を消費しないうえ、9枚まで使えます。動画の枠は、歩き方・手の動き・口の動き・カメラワークのように時間の流れがないと表現できないものに取っておくのが基本になります。
1つの素材に複数の役割を持たせる
予算をさらに節約できるポイントとして、1つの素材に複数の役割を兼ねさせられるという性質があります。MiniMax公式のプロンプトガイドには「1つのsubjectを複数の参照素材で定義してもよいし、1つの参照素材が複数のsubjectを提供してもよい」と明記されています。音声についても「1つの音声素材が複数の役割を果たす場合は、サブセクションを増やすのではなく1つの自然な文でその役割を説明する」とされています。
✅ここから登場する<Subject N>・<Video N>などのラベルは後述の「ラベルの使い方と<Subject N>との違い」で、subject_definitions・retention_analysisなどのセクションは後述の「プロンプトは3フィールドから6セクションへ」で詳しく解説します。
これがラベルの使い分けと連動しています。<Video N>は動画全体に関わる関係(編集元・継続元・カメラワーク・カット・リズム・時間構造)に使うラベルで、その動画に映っている人物や物体、動作を再利用する場合は<Subject N>側の扱いになります。同ガイドにも「<Video N>は素材や構造の出典を示すもので、被写体のラベルを置き換えるものではない」と書かれています。
つまり10秒のクリップ1本で、カメラワークの参照と人物の動きの参照を同時にこなせます。同じ素材を2本繋ぐ必要はありません。subject_definitionsの書き方としては、次のようなイメージです。
<Subject 1> is the woman whose appearance comes from <Picture 1> and whose walking motion comes from <Video 1>.
<Video 1> is the camera-movement and pacing reference for the target video.この例では、見た目は画像から、歩き方は動画から取りつつ、同じ<Video 1>をカメラワークの参照としても立てています。消費するのは画像1枚と動画1本だけです。
繋いだだけでは役割は決まらない
最後に、もっとも大事な注意点です。素材をノードに繋いだだけでは役割が決まりません。H3は参照素材を順番にラベル付けして受け取るだけなので、「<Video 1>のカメラワークを使う」「<Audio 1>の声質を<Subject 1>に当てる」といった対応関係は、すべてプロンプト側で書くことになります。Ref2VAのプロンプトにsubject_definitionsとretention_analysisという専用のセクションがあるのは、この割り当てを書き切るためです。
プロンプトは3フィールドから6セクションへ
基本記事で紹介した通り、T2VA・I2VA・FL2VA・L2VAのプロンプトは先頭の整列指示+3つのフィールドという構造でした。Ref2VAにはMiniMax公式から別のプロンプトガイドが用意されていて、6つのセクションで構成されます。
| セクション | 役割 |
|---|---|
subject_definitions | 参照する内容と、そのラベルを定義します。 |
summary | タスク種別・完成動画・主な参照関係を要約します。 |
retention_analysis | 参照内容が、どのように保持・転移・再利用されるのかを書きます。 |
detailed_description | 映像・動作・ショット・音・セリフを、再生順に書く本文です。 |
overall_soundscape | 環境音や動作音をまとめて書きます。 |
non_diegetic_music | 観客にだけ聞こえるBGMを書きます。 |
後半の3つは基本記事と共通の考え方です。大きく違うのは前半の3つで、「どの参照素材を何として使うのか」の定義と、「それを完成動画にどう反映させるのか」の宣言が、独立したセクションになっている点がRef2VAの特徴です。本文の名前もintegrated_multimodal_descriptionからdetailed_descriptionに変わり、全体のスタイル宣言は[Shot 1]の中ではなく[Shot 1]の前に1〜2文で置くことになっています。
✅6セクションの正式な書式、fully_preservedなどの関係マーカーの使い分け、タスク種別の組み合わせ方といった詳細は、後述の有料記事「6セクション形式のプロンプトの書き方」で解説しています。
ラベルの使い方と<Subject N>との違い
Ref2VAのプロンプトでは、参照素材を4種類のラベルで指し示します。ここを取り違えると、プロンプトが意図通りに読まれません。
| ラベル | 指すもの |
|---|---|
<Subject N> | 参照素材から抜き出した再利用できる見える内容です。人物・動物・物体・背景・衣装・エフェクト・スタイル・動作・表情などが対象になります。 |
<Picture N> | 参照画像そのものです。ショットの最初のフレーム、キーフレーム、最後のフレーム、構図のアンカーとして使う場合に立てます。 |
<Video N> | 参照動画そのものです。編集元・継続の起点・動画全体の時間構造の参照という、動画全体に関わる関係に限って使います。 |
<Audio N> | 参照音声です。単体の音声ファイル、または参照動画に付いている音声トラックを指します。 |
いちばん間違えやすいのが<Subject N>と他の3つの関係です。MiniMaxのプロンプトガイドでは、<Subject N>はファイルではなく「完成動画で実際に使われる内容の単位」と定義されています。たとえば参照画像から人物の見た目だけを借りるなら、<Picture 1>を独立した項目として立てるのではなく、<Subject 1>の定義の中で出典として引用します。
<Subject 1> is the young woman in <Picture 1>, with long dark hair, a blue cardigan, and a thin silver necklace.逆に、画像をそのままショットの最初のフレームとして使うなら、<Picture N>を独立した項目にします。
<Picture 2> is the first frame of [Shot 1], showing a woman seated beside a café window.1つの被写体を複数の素材から組み立てることもできます。見た目は画像から、歩き方は動画から、という書き方です。
<Subject 1> is the woman whose appearance comes from <Picture 1> and whose walking motion comes from <Video 1>.
参照動画に映っている人物や物体を再利用する場合も、<Subject N>側の扱いになります。<Video N>は素材や構造の出典を示すラベルで、被写体のラベルを置き換えるものではありません。また、ファイルに音が含まれているだけでは<Audio N>は立てません。音声を実際に使う、または参照するときだけ立てます。
✅<Video N>と<Audio N>の番号は種類ごとに独立しています。同じ動画ファイルが<Video 1>と<Audio 2>になることもあり、番号の一致・不一致は出典の対応関係を表しません。
ComfyUIのテンプレート「MiniMax H3: Reference to Video」を見てみる
いつも通りComfyUIを最新版にアップデートすることをオススメします。今回は🔗v0.38.0を使って検証しました。
ComfyUI公式ドキュメントによると、Text to Video・Image to Video・Reference to Videoの3つの基本テンプレートはComfyUI 0.30.0以降で動作します。
「MiniMax H3: Reference to Video」は、参照画像・参照動画・参照音声を組み合わせて動画を生成します。基本記事のImage to Videoテンプレートはノードがサブグラフにまとめられていましたが、Reference to Videoテンプレートはサブグラフを使わず、すべてのノードがトップレベルのキャンバスに並んでいます。KSamplerSelectやBasicSchedulerもそのまま見えるので、設定を変えるのは簡単です。
まずはテンプレートから「MiniMax H3: Reference to Video」のワークフロー例を確認しましょう。
テンプレート一覧を開き、左側メニューのFOUNDATIONからVideoを選択します。動画関連のテンプレートが表示されたら、「MiniMax H3: Reference to Video」を選びましょう。
テンプレートを開くと、不足しているモデルが表示されます。指示に沿ってダウンロードすれば、そのまま実行できます。✅よくわからない方は、次のセクションで詳しく説明しているので、そちらを参照してください。
ComfyUI公式ドキュメントは以下の通りです。
Ref2VAに必要なモデルのダウンロード
Ref2VAで差し替えが必要なのは、拡散モデルとLoRAの2つです。テキストエンコーダーと音声VAEは基本記事と同じファイルをそのまま使えます。下記のファイルを取得し、ComfyUI/models配下の指定フォルダーに配置してください。
| 種類 | ファイル | 基本記事との関係 |
|---|---|---|
| Diffusion Model | minimax_h3_ref2va_pruned_int8_convrot.safetensors | Ref2VA専用。新規ダウンロードが必要 |
| テキストエンコーダー | qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | 基本記事と同じ |
| 映像VAE | minimax_h3_video_vae_int8_convrot.safetensors | 基本記事ではfp16版を使用(後述) |
| 音声VAE | minimax_h3_audio_vae_fp32.safetensors | 基本記事と同じ |
| LoRA | minimax_h3_ref2v_turbo_4step_v0.1_comfyui_bf16.safetensors | Ref2VA専用。新規ダウンロードが必要 |
配置例:
ComfyUI/
├── 📁 models/
│ ├── 📁 diffusion_models/
│ │ └── minimax_h3_ref2va_pruned_int8_convrot.safetensors
│ ├── 📁 text_encoders/
│ │ └── qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
│ ├── 📂 vae/
│ │ ├── minimax_h3_video_vae_int8_convrot.safetensors
│ │ └── minimax_h3_audio_vae_fp32.safetensors
│ ├── 📂 loras/
│ │ └── minimax_h3_ref2v_turbo_4step_v0.1_comfyui_bf16.safetensors
✅映像VAEについて補足です。基本記事ではminimax_h3_video_vae_fp16.safetensorsを使いましたが、現在のテンプレートはT2V・I2V・R2Vのいずれもminimax_h3_video_vae_int8_convrot.safetensorsを指定しています。
「MiniMax H3: Reference to Video」用インプット素材
テンプレートで使用する参照画像は2枚です。ComfyUI公式ドキュメントからダウンロードできます。
-
red_superboy_on_city_roof.png:キャラクターの参照画像です。 -
mecha_dragon_lightning.png:スタイルと被写体の参照画像です。
「MiniMax H3: Reference to Video」のノードについて
基本記事と共通のノード(Load CLIP・KSamplerSelect・Resolution Selector・SamplerCustomAdvanced・VAEDecode・VAEDecodeAudio・CreateVideoなど)は、役割も設定もほぼ同じです。ここではRef2VAで変わる部分を中心に見ていきます。
MiniMax H3 Reference to Video
ワークフローの中心となるノードです。基本記事のMiniMax H3 Image to Videoノードと同じく、出力は条件付け(positive)と空のラテントの2つで、実際のデノイズはSamplerCustomAdvancedが担当します。入力は以下の通りです。
- clip:Load CLIPから受け取ります。
- vae:映像VAEです。任意入力になっていて、繋がない場合は参照画像・参照動画がテキストエンコーダーの条件付けだけに使われます。
- audio_vae:音声VAEです。こちらも任意入力で、繋がない場合は参照音声がテキストエンコーダーの条件付けだけに使われます。
- ref_image:参照画像の入力グループです。
ref_image_0から順に、最大9枚まで増やせます。 - ref_video:参照動画の入力グループです。
ref_video_0から順に、最大3本までです。24fpsのフレーム列で、2〜15秒が想定されています。 - ref_video_audio:参照動画に付いているサウンドトラックの入力グループです。最大3本までで、番号で対応します。
ref_video_audio_0はref_video_0の音声、という関係です。 - ref_audio:単体の参照音声の入力グループです。
ref_audio_0から順に、最大3本までです。 - prompt:6セクション形式のプロンプトを貼り付けます。
- width / height:Resolution Selectorから受け取ります。
- length:24fpsでのフレーム数です。デフォルトは124(約5秒)で、
17k+5のグリッドに切り上げられます。学習済みの範囲は約124〜362フレームです。 - ref_image_size:参照画像のリサイズ方法です。
matchとmaxから選びます(後述)。
✅参照系の4つの入力グループはAutogrow方式なので、最初に見えているスロットの数は上限ではありません。スロットの数とファイルの数の関係や、合計12ファイルの数え方は「2-2. 参照できるファイルの上限」で解説しています。
Image to Videoノードとの違いを整理すると、次のようになります。
| 項目 | MiniMax H3 Image to Video | MiniMax H3 Reference to Video |
|---|---|---|
| 対応タスク | t2va/fl2va | ref2va |
| 画像の入力 | first_frame / last_frame(各1枚) | ref_image(最大9枚) |
| 動画の入力 | なし | ref_video(最大3本)+ref_video_audio |
| 音声の入力 | なし | ref_audio(最大3本) |
| 音声VAE | 入力なし | audio_vae(任意) |
| 映像VAE | 必須 | 任意 |
| 参照画像のサイズ指定 | なし | ref_image_size |
ref_image_sizeについて
参照画像をどのサイズでモデルに渡すかを決める設定です。2つの選択肢があります。
- match(デフォルト):参照画像の総画素数を、生成する解像度の総画素数に合わせます。アスペクト比は保ち、縮小のみで拡大はしません。処理が軽くなります。
- max:短辺2048pxを上限として、それより大きい画像だけを縮小します。アイデンティティの再現性は上がりますが、速度は落ちます。
ノードの「Node Info」にあるref_image_sizeの説明によると、参照トークンはサンプリングの全ステップを通して処理に乗るため、maxにすると数倍遅くなる場合があります。まずはmatchから試すのがオススメです。
✅Turbo LoRAを使う場合はmatchが推奨されています。LoRAの配布元(lightx2v)は、蒸留時の学習でmatchを使っているため、推論でも同じリサイズ方針に揃えるべきとしています。
✅どちらのモードでも、ノードはトリミングをせず、縦横を32の倍数に丸めてリサイズします。そのため、参照画像を出力サイズに合わせて事前にリサイズする必要はありません。出力とアスペクト比が違っていても問題なく、むしろ出力サイズに合わせてトリミングすると、参照させたい顔や服が切れてしまうことがあります。元の画像をそのまま繋ぐのが安全です。
参照動画のサイズとフレームレート
参照動画にはref_image_sizeのような設定がなく、ノードが決まった方針でリサイズします。ここで注意したいのが、参照動画のサイズは出力のwidth / heightとは無関係に決まるという点です。
- 解像度:短辺768px、面積の上限768×1344pxという参照動画専用の基準に合わせて、アスペクト比を保ったまま縮小します。この基準より小さい動画は拡大せず、縦横を32の倍数に丸めるだけです。
- フレーム数:出力の
lengthに合わせて切り詰められます。詳しくは「2-2. 参照できるファイルの上限」で解説しています。 - フレームレート:変換されません。ノードは入力を24fpsのフレーム列とみなして処理します。
⚠️参照動画は24fpsに揃えてから繋いでください。30fpsや60fpsの動画をそのまま繋ぐと、ノードはそれを24fpsとして扱います。テキストエンコーダーに渡す2fpsのフレームも「12フレームごとに1枚」という計算で抜き出されるため、タイムスタンプと実際の映像の時間がずれます。
ComfyUI標準の「Load Video」には、フレームレートを変換する設定がありません。変換するには、次のどちらかの方法を使います。
- カスタムノードで読み込む:ComfyUI-VideoHelperSuiteの「Load Video (Upload) 🎥🅥🅗🅢」には
force_rateという設定があり、ここを24にすると24fpsに間引いて読み込めます。出力はフレーム列(IMAGE)と音声(AUDIO)に分かれているので、そのままref_videoとref_video_audioに繋げます。 - 事前に変換しておく:動画編集ソフトやffmpegで、24fpsに書き出してから標準の「Load Video」で読み込みます。
解像度は自動で縮小されるので、出力サイズに合わせる必要はありません。ただし、参照動画は短辺768pxまで処理に乗ります。出力が0.4メガピクセル(864 x 480)のような小さいサイズでも、参照動画のほうが重くなることがあります。VRAMや生成時間が厳しい場合は、参照動画を事前に縮小すると処理が軽くなります。
音声付きの参照動画の繋ぎ方
「2-2. 参照できるファイルの上限」で触れた通り、このノードには音声付きの動画を丸ごと受け取る入力がありません。ref_videoはIMAGE型(フレーム列)、ref_video_audioはAUDIO型で、どちらも片方しか受け取りません。そのため、音声付きの参照動画は1本のファイルを2つに分解して繋ぎます。
ComfyUIでは「Load Video」がVIDEO型を出力し、「Get Video Components」がそれをimages・audio・fpsなどに分解します。公式テンプレート「MiniMax H3 Fun ControlNet Union」でも、制御動画のフレームを取り出すのにLoad Video → Trim Video → Get Video Components → imagesという経路が使われています。同じ考え方で配線すると、次のようになります。
Load Video → Get Video Components ─┬─ images ─→ ref_video.ref_video_0
└─ audio ─→ ref_video_audio.ref_video_audio_0ポイントは番号を揃えることです。ref_video_audio_0はref_video_0の音声として扱われます。ノードの「Node Info」を開くと、ref_video_audioの入力の説明にも「Soundtrack of the same-numbered reference video(同じ番号の参照動画のサウンドトラック)」と書かれています。
2つの入力に分けても「1本の参照動画」です
「2-2. 参照できるファイルの上限」では、音声付きの動画1本が映像と音声で2スロットを占めると簡単に説明しました。では、入力を2つ使うと参照動画も2本分消費してしまうのかというと、そうはなりません。ペアで繋いだ映像と音声は、1本の参照動画として1つのまとまりに統合されます。
🔗ノードの実装では、ペアになった映像と音声はvideo_audioという1つのブロックとしてモデルに渡されます。さらにモデル側の処理で、この1ブロックの中で映像と音声が同じ時間軸を共有します。🔗実装のコメントにも「ブロックの音声行は映像行の直前に配置され、両方が同じカーソル原点を共有する」と書かれています。参照が占める時間も映像の長さと音声の長さの合計ではなく、長いほうの値です。
この「同じ時間軸を共有する」という点が、音声を正しい入力に繋ぐ意義です。どの音がどの瞬間の映像に対応しているのかが、モデルに伝わります。元動画の音をそのまま使う場合や、口の動きと声を合わせたい場合に効いてきます。
ただし、プロンプトで使うラベルは2つ付きます。映像が<Video 1>、その音声が<Audio 1>です。これは「2本分使った」という意味ではなく、1本の動画の映像と音声にそれぞれ名前が付く、ということです。MiniMax公式のプロンプトガイドにも「同じ参照動画が<Video 1>と<Audio 2>に対応することがある。番号が違っても、同じソース素材から来ていることを妨げない」と明記されています。1ファイルに2つのラベルが付くのは、公式の書式でも想定された形です。
整理すると、次のようになります。
| 観点 | ペアで繋いだとき |
|---|---|
| 使う入力スロット | 2つ(ref_video_0とref_video_audio_0) |
| 参照動画の本数 | 1本 |
| モデルに渡るブロック | 1つ(video_audio) |
| 参照が占める時間 | 1区間(映像と音声の長いほう。合計ではありません) |
| プロンプトのラベル | 2つ(<Video 1>と<Audio 1>) |
⚠️音声VAEを繋いでいないと、ペアになりません。audio_vaeが未接続だと音声のラテントが作られないため、ブロックの種類がvideo_audioではなくvideoに落ちます。<Audio j>のラベルだけが出て、時間軸の共有は起きません。vae(映像VAE)が未接続の場合は、その参照動画のブロック自体が音声込みでスキップされます。
動画とは別の音声を参照したいとき
ここまでは「参照動画に付いている音」の話でした。動画とは無関係の音声を参照したい場合は、ref_audio側に繋ぎます。声質の見本だけを渡す、BGMのスタイルだけを渡す、といった用途です。
この場合はaudioという単独のブロックになり、どの動画とも紐付きません。時間軸も映像とは別の区間に置かれるため、「この音はこの瞬間の映像のもの」という対応は生まれません。声質やBGMのスタイルのように、特定の瞬間と結び付かない参照に向いた形です。
2つの入力の使い分けは、次の通りです。
| 渡したい音 | 繋ぐ入力 | モデルへの渡り方 |
|---|---|---|
| 参照動画に付いている音 | ref_video_audio(動画と同じ番号) | 映像と1ブロックになり、時間軸を共有します。 |
| 動画とは無関係の音声 | ref_audio | 単独ブロックになり、動画とは紐付きません。 |
✅動画の音を使わないなら、ref_video_audioには繋がないでください。MiniMax公式のプロンプトガイドにも「通常の参照動画は、ファイルに音が含まれているだけでは<Audio N>を作らない」と明記されています。繋ぐと<Audio j>のラベルが出て番号を1つ消費するため、ref_audioに繋いだ音声の番号が後ろにずれます。
ラベルはComfyUIが自動で付ける
ここがRef2VAでいちばん誤解しやすいところです。<Picture 1>のようなラベルは、自分でプロンプトに書いて素材と結び付けるものではありません。ComfyUIがテキストエンコーダーに渡す段階で自動的に生成し、プロンプトの前に差し込みます。
ComfyUIのテキストエンコーダー側の実装には、組み立てられる並びが明記されています。
【t2va】
<prompt>
【fl2va】
"<Picture 1>: " <画像> ["<Picture 2>: " <画像>] <prompt>
【ref2va】リクエスト順に、種類ごとの1始まりの序数で
画像 → "<Picture i>: " <画像>
音声 → "<Audio j>: "
動画 → "<Video k>: " そのあと2フレームごとに "<T.T seconds>" <2フレーム分の映像>
そのあとに <prompt>ノード自体にもこの方針が書かれています。ノードにカーソルを合わせると、<Picture i> / <Video k> / <Audio j> reference conditioning for MiniMax H3. Use the same tags when prompting.と表示されます。「プロンプトを書くときは同じタグを使うこと」という指示です。
つまり、自分で書くプロンプトはこの自動生成されたラベル列のあとに続くだけです。ラベルと素材の対応はノードが決めてしまうので、プロンプト側はその番号に合わせて言及するのが正しい使い方になります。番号がずれると、意図した素材とは別の素材を指すことになります。
ラベルの番号はスロットの並び順で決まる
では番号はどう決まるのでしょうか。ComfyUIのノード実装では、参照素材は次の順序で並べられます。
- ref_imageの画像が
<Picture 1>から順に並びます。 -
続いてref_videoの動画が
<Video 1>から順に並びます。このとき、その動画のサウンドトラックの<Audio j>ラベルが、対応する<Video k>の直前に置かれます。 - 最後にref_audioの単体音声が並びます。
番号は種類ごとに1から振られます。ここで注意したいのが<Audio N>です。参照動画のサウンドトラックのほうが先に番号を取るため、動画の音声を1本使っている場合、単体で繋いだ音声は<Audio 1>ではなく<Audio 2>になります。
この並びは、MiniMax公式のサンプルでも同じです。モデルカードに載っているRef2VAの例は、H3-Context-IRに動画1本と音声1本(計2ファイル)を渡したときの出力です。
<Video 1> is the source video for the editing task.
<Audio 1> is the synchronized audio track of <Video 1>, providing the background music.
<Audio 2> is the voice timbre reference for <Subject 1>'s voice, containing a spoken male voiceover.渡した音声ファイルは1本だけですが、音声のラベルは<Audio 1>と<Audio 2>の2つ出ています。<Audio 1>が動画に含まれる音声、<Audio 2>が単体で渡した音声です。動画の音声が先に番号を取るという並びが、ComfyUIの実装と公式の書式で一致していることがわかります。
基準になるのはスロットの並び順です。ComfyUI公式ドキュメントのMultiframe Referenceのページでも、「<Picture 1>は最初のref_imageスロットに繋いだ画像、<Picture 2>は2番目」と説明されています。繋いだ時間の順ではなく、ref_image_0・ref_image_1……というスロット番号の順で並びます。
スロットの番号とラベルの番号は1つズレる
ここは見落としやすいポイントです。スロット名は0から、ラベルは1から始まります。入力名がref_video_0だからといって、プロンプトで<Video 0>と書いてはいけません。
| スロット名 | プロンプトで使うラベル |
|---|---|
ref_image_0〜ref_image_8 | <Picture 1>〜<Picture 9> |
ref_video_0〜ref_video_2 | <Video 1>〜<Video 3> |
ref_audio_0〜ref_audio_2 | <Audio 1>〜<Audio 3> |
つまりref_video_0に繋いだ動画が<Video 1>です。ComfyUIのテキストエンコーダー側の実装にも、ラベルの番号は「種類ごとに1始まりの序数」と明記されています。
ただし、ラベルの番号は「スロット番号+1」ではありません。正確には接続済みの素材の中での順番です。ノードの実装は未接続のスロットを読み飛ばすため、空のスロットは番号を消費しません。
たとえばref_video_0を空けたままref_video_1にだけ動画を繋いだ場合、その動画は<Video 2>ではなく<Video 1>になります。番号を数え間違えないために、スロットは上から順に埋めていくのがオススメです。
MiniMax公式のガイドとの違い
ラベルの扱いは、MiniMax公式のプロンプトガイドとComfyUIの実装で役割が分担されています。混乱しやすいので整理しておきます。
| ラベル | ComfyUIが自動で出すか | 備考 |
|---|---|---|
<Picture N> | 出す | ref_imageに繋いだ画像すべてに付きます。 |
<Video N> | 出す | ref_videoに繋いだ動画すべてに付きます。 |
<Audio N> | 出す | ラベルだけが入り、音声そのものはテキストエンコーダーには渡りません(後述)。 |
<Subject N> | 出さない | ノード側には存在しません。プロンプトの文章の中だけで定義するラベルです。 |
とくに注意したいのが次の2点です。
-
<Subject N>はノードと無関係です。ComfyUIが出すのは<Picture>・<Video>・<Audio>の3種類だけです。<Subject N>はsubject_definitionsの文章の中で、どの素材から何を取るのかを自分で宣言してはじめて意味を持ちます。 -
繋いだ画像には、必ず
<Picture N>のラベルが付きます。ComfyUIは画像を1枚ずつ<Picture 1>・<Picture 2>……と名付けてプロンプトに差し込むので、ラベルが付かない画像はありません。
2つ目については、MiniMax公式のガイドに迷いやすい記述があるので補足します。ガイドには次のように書かれています。
- 画像をキャラクター・シーン・衣装・スタイルの定義にしか使わない場合は、その画像に独立した定義行を与えず、対応する
<Subject N>の定義の中で出典として引用する。
これを読むと「<Picture N>を使ってはいけないのか」と思えますが、そうではありません。ガイドが言っているのはsubject_definitionsに定義行を何行書くかという話で、ラベルが付くかどうかとは別の話です。実例で見ると、はっきりします。
画像を2枚、次のように繋いだとします。用途はそれぞれ違います。
-
ref_image_0(<Picture 1>):女性の見た目を決めるための画像です。 -
ref_image_1(<Picture 2>):最初のショットの1フレーム目にそのまま使う画像です。
このときsubject_definitionsはこう書きます。2行ともMiniMax公式のガイドにある記述例です。
subject_definitions:
<Subject 1> is the young woman in <Picture 1>, with long dark hair, a blue cardigan, and a thin silver necklace.
<Picture 2> is the first frame of [Shot 1], showing a woman seated beside a café window.見比べると、違いは1点だけです。
-
<Picture 1>は自分の行を持っていません。<Subject 1>の行の中に、出典として登場するだけです。見た目を決めるためだけの画像なので、ガイドの言う「独立した定義行を与えない」書き方になります。 -
<Picture 2>は自分の行を持っています。1フレーム目という具体的な役割があるので、独立した定義行を与えます。
そしてどちらの画像にも、ComfyUIが<Picture 1>・<Picture 2>のラベルを付けています。<Picture 1>に定義行がないことと、ラベルが存在することは、両立しています。ガイドの指示は文章の書き方の話だと考えてください。
もう1つ、実装を見てわかる重要な点があります。参照音声の中身は、テキストエンコーダー(Qwen3-VL)には渡りません。実装のコメントにも「audio never enters Qwen」と書かれており、テキスト側に入るのは<Audio j>: というラベルの文字列だけです。音声そのものは音声VAEでエンコードされ、DiT側のペイロードとして渡されます。
つまりプロンプトを解釈する側のモデルは、その音声がどんな音なのかを聞いていません。「<Audio 1>は落ち着いた男性のナレーション」のように、どんな音声なのかを言葉で説明しておくことが、画像や動画の参照より重要になります。公式ガイドがsubject_definitionsで音声の役割を1文で書かせているのも、この事情と噛み合っていると考えられます。
参照動画の扱いにも偏りがあります。テキストエンコーダーに渡されるのは2fpsにサンプリングされたフレームで、2フレームごとに<T.T seconds>というタイムスタンプが挿入されます。DiT側にはフル解像度のラテントが渡るので、「意味の理解は粗く、映像としては細かく」という非対称な構成になっています。
If/Else Switch(model)とIf/Else Switch(Steps)
Turbo LoRAを使うかどうかを切り替えるノードです。「Boolean (Enable Lightning LoRA)」の値が両方のスイッチに繋がっていて、LoRAを有効にするとステップ数も同時に切り替わる仕組みになっています。
- OFF(初期値):UNETLoaderのモデルをそのまま使い、「Int (Full)」の
20ステップで生成します。 - ON:LoraLoaderModelOnlyを通したモデルを使い、「Int (Lightning LoRA)」の
4ステップで生成します。
Ref2VAのステップ数について
ComfyUI公式ドキュメントには、参照を使う生成ではステップ数を削るコストがとくに大きいと明記されています。理由は、参照トークンがサンプリングの全ステップに乗るためです。ステップ数を減らすと、その条件付けが働く回数自体が減ってしまいます。
ドキュメントの記述をまとめると、次のようになります。
- 4ステップ(Turbo LoRA ON)では参照がほとんど適用されないことがあるとされています。被写体のポーズや顔の角度が、クリップが進むにつれて参照から離れていく症状が挙げられています。
- 参照に忠実な結果が必要な場合は、Turbo LoRAのスイッチをOFFにして20ステップで回し、それでもずれる場合は25ステップまで上げることが推奨されています。
- シンプルな内容のショットは12〜16ステップでも成立します。
- 細かい模様や小さな物体が多いショットは、50ステップ付近まで改善が続くとされています。
- 音声は映像より遅く収束します。8ステップ(Turbo LoRA OFF)ではセリフと声質がもっとも弱い部分になり、12ステップ以上で実用的になるとされています。
Ref2VAでは速度よりも参照の再現を優先する場面が多いので、まずは初期値の20ステップで試すのがよいと考えられます。
「MiniMax H3: Reference to Video」の使い方
それではテンプレートを実際に使ってみましょう。
- 参照画像の読み込み:2つの「Load Image」に、素材の
red_superboy_on_city_roof.pngとmecha_dragon_lightning.pngを読み込みます。左側がref_image_0(<Picture 1>)、右側がref_image_1(<Picture 2>)です。 - 各モデルの読み込み:「Models」グループで、拡散モデル・テキストエンコーダー・2つのVAEが正しく読み込まれているかを確認します。
- プロンプトの入力:「Input Text (Prompt)」ノードにプロンプトを入力します。参照素材をラベルで指し示し、どの素材が何を担当するのかを書きます。
- 解像度と長さの指定:「Resolution Selector (Size)」でアスペクト比とmegapixels、「Float (Duration)」で秒数を指定します。テンプレートの初期値は16:9・0.4メガピクセル(864 x 480)・5秒です。
- 生成実行:「Run」ボタンで実行します。
しばらくすると、「Save Video」に生成結果が表示されます。
✅テンプレートの初期プロンプトは6セクション形式ではなく、スタイル宣言とCUT 1/CUT 2を並べた平易な英文になっています。<Picture 1>・<Picture 2>・<Audio 1>をラベルで指し示す書き方の例として読むとよいでしょう。なお、初期プロンプトは<Audio 1>に言及していますが、テンプレートの初期状態ではref_audioに何も繋がれていません。
✅ComfyUI公式ドキュメントでは、H3のテンプレートはBasicGuiderでサンプリングするためネガティブプロンプトが存在しないと説明されています。「字幕を入れない」のように不要な要素を名前で挙げると、その語がそのまま説明文として読まれてしまいます。Ref2VAではretention_analysisで各参照の扱いを宣言する形で範囲を絞るのが、筋のよい書き方と考えられます。
公式ワークフローの生成結果と比較
生成結果は以下のようになりました。本記事に掲載している動画は、すべてMiniMax H3で生成したAI動画です。音声はミュートしてあるので、聞きたい場合はミュートを解除してください。
生成速度の参考として、筆者環境(RTX3090)では、デフォルトの20ステップの生成に271秒(4分31秒)かかりました(SageAttentionは使っていません)。✅なお、テンプレートのように参照が画像のみの場合に比べ、参照動画を使うと生成時間が倍以上かかります。
以下は、ref_image_sizeの違いとTurbo LoRAを使った場合の生成時間の比較です。解像度はデフォルトの864 x 480を使い、すべて同じシードで比較しました。
| 設定 | ステップ数 | 生成時間 | 速度比率 |
|---|---|---|---|
| ref_image_size: match | 20 | 4分31秒 | 100% |
| ref_image_size: max | 20 | 6分10秒 | 136.5% |
| Turbo LoRA ON (match) | 4 | 1分13秒 | 26.9% |
| Turbo LoRA ON (max) | 4 | 1分39秒 | 36.5% |
以下が生成結果の比較動画です。✅比較しやすいように、生成した動画を並べて編集しています。音声はデフォルトの音声(画面左上)を使用しています。
品質面では、やはりTurbo LoRAを使った4ステップより、LoRAなしの20ステップのほうが高品質でした。また、Turbo LoRAではアーティファクトノイズが発生していました。
ここまではデフォルトサイズ864 x 480での比較でした。学習時の解像度1344 x 768で比較した結果は以下の通りです。✅速度比率は、デフォルトサイズのref_image_size: match(20ステップ)を100%とした比率です。
| 設定 | ステップ数 | 生成時間 | 速度比率 |
|---|---|---|---|
| ref_image_size: match | 20 | 20分11秒 | 446.9% |
| ref_image_size: max | 20 | 21分06秒 | 467.2% |
| Turbo LoRA ON (match) | 4 | 4分28秒 | 98.9% |
| Turbo LoRA ON (max) | 4 | 4分43秒 | 104.4% |
以下が生成結果の比較動画です。音声はデフォルトの音声(画面左上)を使用しています。
やはり、こちらのほうが動きや細部のディテールが豊かで、高品質になりました。ただし、こちらもTurbo LoRAではアーティファクトノイズが発生していました。
参考までに、50ステップのref_image_size: maxの結果は以下の通りです。
品質はやはりこれが一番ですが、生成に52分かかりました。デフォルトの4分31秒(271秒)と比べて約1,151%(約11.5倍)なので、トライ&エラーの多い作業には向いていないでしょう。
⚠️前述の通り、ComfyUI公式ドキュメントは参照を使う生成で4ステップまで削ると、参照がほとんど適用されないことがあると注意しています。参照に忠実な結果が必要な場面では、Turbo LoRAをOFFにして20ステップ(必要なら25ステップ)で回すのが基本です。また、音声は映像より遅く収束するため、セリフを含むクリップでは4ステップは厳しいと考えられます。速度が必要な構図探しの段階でTurbo LoRAを使い、本番は通常のステップ数で回す、という使い分けがよいでしょう。
MiniMax H3 Ref2VAの公式ワークフローをカスタムする
ここからはComfyUI公式の「MiniMax H3: Reference to Video」ワークフローを土台に、高品質な映像を目指した改良版を紹介します。カスタム内容は以下の通りです。
- Comfy kitchen attention実装:ComfyUIに標準搭載されたcomfy kitchen attentionを使い、SageAttentionと同等の速度で推論します。
- Veda Sparse Attention実装:Vedaの公式ノードを使い、アテンション計算を省略して推論を高速化します。✅Triton-windowsが必須です。
- 推論を2ステージ化:低解像度で高速に下書きを推論し、気に入った結果のみ高解像度化します。
- ラテントアップスケール:ラテント(潜在空間)アップスケーラーでアップスケールします。
- フレーム補完:フレーム補完ノードを使って、出力動画のフレームレートを引き上げられます。
- 動画生成時のライブプレビュー:生成中の様子をライブプレビューで確認できます。
- GGUF対応(オプション):低VRAM環境向けに、GGUFモデルへ切り替えられます。
✅有料記事内では、以下の内容を紹介しています。
- カスタムワークフローの使い方と生成結果:必須カスタムノードや追加モデルの準備から実際の操作手順までを解説しています。
- 6セクション形式のプロンプトの書き方:6つのセクションのそれぞれの正式な書式を順に解説しています。
ワークフローやインプット素材はPatreonで公開しています。有料サポーター様のみ閲覧・ダウンロードが可能です。
このカスタムワークフローで生成した動画サンプルがこちらです。以前のWan 2.2やLTX-2.3の記事で紹介したOpen poseを参照して生成しています。音声はミュートしてあるので、聞きたい場合はミュートを解除してください。✅動画はWEB用に縮小しています。
生成時間は下書き(6Steps 1344 x 768 24fps):約15分、仕上げ(2688 x 1536 48fps):約25分、トータル:40分43秒
参考までに、公式テンプレートのプロンプトとインプット素材を使って生成した結果が以下です。
生成時間は下書き(6Steps 1344 x 768 24fps):約4分、仕上げ(2688 x 1536 48fps):約8分、トータル:12分11秒
まとめ
本記事では、MiniMax H3のReference to Video(Ref2VA)の概要から、ComfyUI公式テンプレート「MiniMax H3: Reference to Video」を使った動画生成の手順までを紹介しました。
- Ref2VAは、テキストに加えて参照用の画像・動画・音声を渡して生成するモードです。
- FL2VAとRef2VAは別のチェックポイントで、Ref2VAには専用の拡散モデルとLoRAが必要です。
- 参照できるファイルは画像9枚・動画3本・音声3本までで、全種類を合わせた上限は12ファイルです。
- 動画と音声には、それぞれ別枠で合計15秒の上限があります。
- ComfyUIのノードは合計12ファイルも合計15秒もチェックしないため、自分で数える必要があります。
- 参照動画は24fpsのフレーム列として扱われるため、事前に24fpsへ変換してから繋ぎます。
- 素材を繋いだだけでは役割は決まらず、各参照の役割をプロンプトの中で言葉にする必要があります。
<Picture N>などのラベルはComfyUIが自動で付け、番号は接続済みスロットの並び順で決まります。- 参照を使う生成では、Turbo LoRAの4ステップより、LoRAなしの20ステップ(必要なら25ステップ)が推奨されています。
- 筆者環境(RTX3090)では、テンプレートの初期設定(864 x 480・20ステップ)で生成に4分31秒かかりました。
後半の有料記事では、Comfy kitchen attentionやVeda Sparse Attentionによる高速化、2ステージ推論、ラテントアップスケール、フレーム補完、GGUFに対応したDCAIカスタムワークフローや、6セクション形式のプロンプトの書き方についても解説しています。気になる方はぜひ本編もあわせてご覧ください。
最後までお読みいただきありがとうございます。
もし少しでも参考になったら、ぜひ「いいね」で応援してください!



