2026年9月4日 金曜日
AI時短ラボ
検証· 約13

MiniMax-H3の動画生成、「先頭と末尾」だけだった制約をComfyUIが外した──任意フレームに画像・音声を固定できるAddGuideノード

ComfyUIはv0.34.0で、動画生成モデルMiniMax-H3向けの新ノード「MiniMaxH3AddGuide」を追加した。実装したPR本文によれば、これまでComfyUI側の実装では先頭・末尾フレームにしかガイド(画像・クリップ・音声)を固定できなかったが、モデル本来が持つ連続時間軸上の任意位置指定能力を、そのままノードとして公開した。

MiniMax-H3の動画生成、「先頭と末尾」だけだった制約をComfyUIが外した──任意フレームに画像・音声を固定できるAddGuideノード
執筆・編集:
目次

動画生成モデル「MiniMax-H3」をComfyUI上で使う際、これまでは動画の先頭と末尾にしか、参照用の画像・映像・音声(ガイド)を固定できなかった。v0.34.0(2026年8月26日公開)で追加された新ノード「MiniMaxH3AddGuide」は、この制約を取り払い、動画のどのフレームにでもガイドを配置できるようにした。

3行まとめ

  • ComfyUI v0.34.0で追加された「MiniMaxH3AddGuide」ノードにより、MiniMax-H3の動画生成でガイド(画像・クリップ・音声)を先頭・末尾以外の任意frame_idxに固定できるようになった
  • PR #15439は2026年8月9日に作成、8月13日にComfyUI開発元本人(comfyanonymous)がマージ。3ファイル・7コミットで+141/-46行という小規模な変更だった(GitHub API確認)
  • ComfyUI公式ソースコードを直接読むと、クリップ長が「5・22・39……」に切り詰められる理由は17k+5フレームグリッド(24fps)で、既定の学習済み長は約124〜362フレーム(約5〜15秒)だと明記されている

ComfyUI側の実装上の制約であって、モデルの限界ではなかった

このノードを実装したPR #15439(2026年8月13日マージ)の本文には、変更の背景がこう説明されている。

"Currently MiniMax H3 implementation in Comfyui only allows keyframe guides at the first and last frame. The model itself is capable of addressing guides by position on a continuous time axis, so this removes that restriction and exposes it as a node."

(現状、ComfyUI内のMiniMax H3実装は、キーフレームのガイドを先頭と末尾のフレームにしか許可していない。モデル自体は連続した時間軸上の位置を指定してガイドを扱う能力を持っているため、この制約を取り払い、それをノードとして公開する)

つまり、モデル本体(MiniMax-H3)はもともと任意の時間位置にガイドを固定する能力を持っていたが、ComfyUI側の実装がそれを先頭・末尾の2点だけに制限していた、ということだ。今回の変更は、モデルの潜在能力をノードとして解放した、という位置づけになる。

frame_idxで位置を指定し、画像・クリップ・音声を組み合わせられる

PR本文には、新ノードの具体的な仕様が示されている。

"MiniMaxH3AddGuide anchors a guide at any frame_idx (negative counts from the end):

  • a still image
  • a clip (batches snap down to the model's valid clip lengths: 5, 22, 39... frames)
  • audio, anchored at the same position on the timeline
  • any combination, and nodes chain for multiple guides"

MiniMaxH3AddGuideは、任意のframe_idx(負の値は末尾からのカウント)にガイドを固定する。静止画像、クリップ(バッチはモデルが有効とするクリップ長——5・22・39……フレーム——に切り詰められる)、同じタイムライン上の位置に固定される音声、これらの任意の組み合わせに対応する。ノードを連結することで複数のガイドを設定できる)

「クリップ長が5・22・39……フレームというモデル固有の値にスナップする」という記述は、MiniMax-H3が任意の長さのクリップを受け付けるわけではなく、モデルのアーキテクチャ上決まった長さの倍数(あるいは特定の系列)でしか処理できないことを示唆している。この点はノード側で自動的に調整(切り詰め)される。

実際にComfyUI公式リポジトリのcomfy_extras/nodes_minimax_h3.pyを開くと、このスナップ処理の実体であるalign_frame_count関数と、コード内のツールチップ文言が確認できる。

"Duration snaps to the model's 17k+5 frame grid at 24 fps." "Frame count at 24 fps, snapped up to the model's 17k+5 grid (124 = ~5s; trained range is ~124-362, longer is untested)"

(長さはモデルの17k+5フレームグリッド(24fps)にスナップする。124フレーム=約5秒。学習済みの範囲は約124〜362フレームで、それより長い場合は未検証)

つまり「5・22・39……」という数列は、k=0,1,2…に対して17k+5フレームを計算した結果そのものであり、恣意的な値ではなくモデルの潜在表現の圧縮率(フレーム方向の時間圧縮)に由来する規則だとコード上確認できる。ソースコードにはこれ以外にも、音声側のレイテント周波数が40fps相当(AUDIO_LATENT_FPS = 40)であること、参照画像は短辺768px・面積上限768×1344pxにキャンバス調整されること(adapt_canvas関数)、モデルへの条件付けにQwen3-VL-32Bの隠れ状態が使われていることなども明記されている。

項目 出典
動画フレームレート 24fps(FPS = 24 nodes_minimax_h3.py
クリップ長の規則 17k+5フレーム(5, 22, 39, 56…) nodes_minimax_h3.py
既定・学習済み長 124フレーム(既定値・約5秒)、学習済み範囲は約124〜362フレーム nodes_minimax_h3.py コメント
音声レイテントの周波数 40(AUDIO_LATENT_FPS = 40 nodes_minimax_h3.py
参照画像のキャンバス 短辺768px基準、面積上限768×1344px nodes_minimax_h3.py(adapt_canvas
条件付けに使う言語・視覚モデル Qwen3-VL-32Bの隠れ状態(トークン単位のモダリティタグ付き) nodes_minimax_h3.py 冒頭コメント
PR #15439 の規模 3ファイル変更・+141/-46行・7コミット GitHub API
PR #15439 の作成〜マージ 2026年8月9日作成 → 8月13日マージ(4日間) GitHub API

使用例:既存動画の続きを生成する/特定フレームに静止画を強制する

PR本文には、具体的な使用例も2つ示されている。

"Example: feed the first 22 frames of an existing video plus its audio into one AddGuide at frame_idx 0 and the model generates the continuation of both streams. Or put a still at frame 60 of 124 to force a it to hit that frame."

(例:既存の動画の最初の22フレームとその音声を、frame_idx 0の1つのAddGuideに入力すると、モデルは映像と音声の両方の続きを生成する。あるいは、124フレーム中の60フレーム目に静止画を配置することで、その位置に強制的にヒットさせることもできる)

前者は「動画の続きを生成する」という用途、後者は「動画の途中の特定の瞬間を、指定した静止画に強制的に一致させる」という用途だ。後者のような使い方は、たとえば「動画の中盤で必ずこのシーンを通過させたい」といった、ストーリーボード的な制御に応用できると考えられる。

既存のワークフローへの影響はない

PR本文は、後方互換性についても明記している。

"First/last anchors produce the same coordinates as before, so existing workflows are unchanged."

(先頭・末尾のアンカーは、これまでと同じ座標を生成するため、既存のワークフローに変更はない)

つまり、これまで通り先頭・末尾だけを使ったワークフローは、そのまま動き続ける。今回の変更は機能の追加であり、既存の使い方を壊すものではない、という設計だ。

同じリリースの近くにMiniMax-H3関連の他の修正も

このPRがマージされた前後のComfyUIのコミット履歴には、MiniMax-H3に関連する他の修正も複数見つかる。v0.32.0のリリースノートには「Optimize MiniMax-H3 VAE」(MiniMax-H3のVAE最適化)や「Fix VAEDecodeTiled crash on NestedTensor latents (MiniMax H3)」(MiniMax H3のNestedTensor潜在変数によるVAEDecodeTiledのクラッシュ修正)、「Fix peak memory issue with H3.」(H3のピークメモリ問題の修正)といった項目が並んでおり、ComfyUI側でMiniMax-H3対応の作り込みが継続的に進められていることがうかがえる。

モデルとツールの間に生まれるタイムラグ

筆者は動画生成AIをComfyUI経由で試したことはあるが、キーフレーム制御を先頭・末尾以外の任意位置で行うという発想には、これまで馴染みがなかった。「モデル自体はできるのに、ツール側の実装が制限していた」という今回のケースは、オープンソースのエコシステムでは珍しくない構図だと感じる。モデル提供元(MiniMax)とツール提供元(ComfyUI)が別組織である以上、モデルの能力とツールでの露出範囲には、常にこうしたタイムラグやギャップが生じ得る。

実際に動かした生成品質・速度のデータは確認できていない

クリップ長の数列規則(17k+5)と主要な技術定数はソースコードから直接確認できたが、このノードを実際に使った場合の生成品質や応答時間についての実測データは、公式情報源の範囲では見当たらなかった。ソースコードのコメントには「学習済み範囲は約124〜362フレームで、それより長い場合は未検証(untested)」と明記されており、この上限を超えた長尺動画でガイドを使った場合に品質がどう変化するかは、開発元自身もこの時点では確認していないことがコードから読み取れる。またMiniMax-H3モデル自体のライセンス条件(利用可能な地域・商用利用の可否)は、本記事の関連記事にある別記事で扱った内容であり、本記事ではPR本文とソースコードの範囲を超えては確認していない。

関連記事

シェア: ポスト はてブ

出典・参照資料

AIニュースの解説を動画でも

YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。

コメント

まだコメントはありません。最初のコメントを書いてみませんか?

AIについて聞きたいことはありますか?

質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。

質問箱を見る →

新しい記事をメールで受け取る

AIの新しい発表を、出典付きで整理して届けます。

関連記事