見出し画像

空のフォルダから、CodexにMiniMax H3専用ComfyUIを構築してもらった


※この記事は2026年8月6日時点の環境をもとにしています。MiniMax H3とComfyUIは更新が速いため、導入時には最新の情報もあわせて確認してください。

私は普段からほぼ毎日、ローカルで画像や動画を生成しています。メインで使っているComfyUI環境もすでにあり、モデルやLoRA、カスタムノードを用途に合わせて組み込んである。

今回MiniMax H3公式モデルを試すにあたって、その既存環境にすべて追加してしまうこともできた。ただ、普段の環境と混ざるのは避けたかった。新しいモデルやVAE、実験的な高速化ノードを入れた結果、いつものワークフローに影響が出るのも困る。

もうひとつの理由は、MiniMax H3まわりの動きがあまりにも速いことだった。公開直後から、量子化モデル、軽量テキストエンコーダー、新しいVAE、高速化LoRA、Spectrumなどの高速化手法、低VRAM向けワークフローが次々と出てきた。ComfyUI本体側の対応も数日単位で進んでいて、情報を集めて理解し、自分ひとりで環境に反映し続けるのは簡単ではない。

そこで今回は、既存環境と共有しないMiniMax H3専用フォルダを作り、構築と検証をCodexに手伝ってもらうことにした。

私が最初に用意したのは、ほぼ空のフォルダひとつだけだ。

E:\000_MiniMaxH3_ComfyUI

このフォルダをCodexに渡し、ComfyUI本体、Python環境、GPU向けライブラリ、必要なカスタムノード、起動用バッチ、確認用スクリプトまで構築してもらった。モデル、テキストエンコーダー、VAE、LoRAのファイルだけは、手元にあるものを後から専用フォルダにコピーしている。

MiniMax H3を始めるハードルも急速に下がっている

MiniMax H3の動きが速いと感じたのは、新機能が増えているからだけではない。必要なハードウェアや利用方法についても、公開から数日のあいだに状況が変わってきた。

Xやコミュニティの投稿を追っていると、RTX 3060 12GBでMiniMax H3を動かした報告例まで見かけるようになった。もちろん、RTX 5080のようなGPUと比べれば時間はかかるし、システムRAM、仮想メモリ、SSD、量子化モデル、出力解像度などの調整も必要になる。それでも「最上位GPUがなければ起動すらできない」という段階から、かなり身近なGPUでも試せる段階へ進み始めている。

さらに、自分のPCに十分なGPUがない人向けには、Google Colab上へMiniMax H3を展開する公開例も共有され始めた。ローカルPCを持っていない人や、まず一度だけ試してみたい人にも入口が広がっている。

ただし、Colabは割り当てられるGPUやシステムRAM、利用時間に制限があり、無料枠ですべての構成が安定して動くとはかぎらない。モデル容量も大きいため、実際に使う場合は保存先、ダウンロード時間、セッション切断への対策が必要になる。それでも、ローカルPCか高額なクラウドサービスかという二択ではなく、試すための選択肢が増えているのは大きい。

今回のPC環境

GPU:NVIDIA GeForce RTX 5080 16GB

システムRAM:64GB

OS:Windows

Python:3.11.15

PyTorch:2.13.0 + CUDA 13.0

ComfyUI:公式master コミット 2eb6097

RTX 5080は16GB VRAMなので、巨大なMiniMax H3をそのまま常時VRAMに置くのは難しい。そのため、起動設定は --lowvram を使い、OS側に1GBを予約する構成にした。モデルの一部をシステムRAMに退避しながら動かすので初回ロードには時間がかかるが、専用環境としては安定して扱える。

Codexがインストールしたもの

最初に、既存のComfyUIとは分離したPython仮想環境 .venv が作られ、その中にRTX 5080向けのPyTorchとCUDA関連の環境が導入された。

主な構成は次のとおり。

項目 導入内容 Python 3.11.15 PyTorch 2.13.0+cu130 Triton for Windows 3.7.1.post27 SageAttention 2.2.0 comfy-kitchen 0.2.26 翻訳ライブラリ deep-translator 1.11.4

TritonとSageAttentionは、インストールして終わりではなく、RTX 5080上で実際にCUDAカーネルが動作するところまで確認した。SageAttentionは高速化の選択肢として使える状態にしてあるが、最終的なワークフローにすべての高速化を無条件で重ねたわけではない。高速化ノードは組み合わせによって画質や安定性が変わるため、ひとつずつ確認できる形にしてある。

導入した主なカスタムノードは以下のとおり。

ComfyUI-KJNodes:各種ユーティリティとSageAttention関連

ComfyUI-SolAttn_triton:Sol-Attentionの実験用

ComfyUI-Spectrum-MiniMax-H3:MiniMax H3向けSpectrum高速化

AlekPet Custom Nodes:日本語入力を英語に変換する翻訳ノード

AlekPetのパッケージには多数のノードが含まれているが、今回は専用環境を複雑にしたくなかったので、必要な DeepTranslatorTextNode だけを読み込む軽量構成に調整した。

起動用の start_minimax_h3.bat と、Python・PyTorch・CUDA・GPU・モデル配置を検査する verify_environment.bat も作成されている。以降は起動バッチをダブルクリックするだけで、この専用ComfyUIを立ち上げられる。

私が配置したモデルファイル

モデル類は別環境と共有せず、専用フォルダにコピーした。配置やファイル構成を確認するときは、Comfy-OrgのMiniMax H3モデル配布ページも参考になる。

FL2VA用の拡散モデル

REF2VA用の拡散モデル

Qwen3-VL-32B系のMiniMax H3用テキストエンコーダー

minimax_h3_video_vae_int8_convrot.safetensors

minimax_h3_audio_vae_fp32.safetensors

MiniMax H3 Turbo LoRA

その他、用途別のLoRA

動画VAEと音声VAEは別ファイルなので、両方必要になる。映像だけでなく音声も生成するMiniMax H3では、音声VAEの入れ忘れに注意したい。

API形式のワークフローから不足ノードを復元

メインで使う予定のワークフローは、ComfyUIからAPI形式のJSONとして書き出したものを渡した。ファイル名にはダウンロード時の (2) が付いていたが、Codexは元ファイルを変更せず、次の名前に整理してコピーしてくれた。

video_minimax_h3_t2v.json

API形式でも、実行内容や依存ノードは確認できる。ただし通常のWorkflow形式と違い、画面上のノード位置やグループといったレイアウト情報は保持されない。見た目も含めて再利用したい場合は、通常形式もあわせて保存しておくほうがよい。

このAPI JSONでは、カスタムノードが見つからなかったために、2つのノード名と入力名が UNKNOWN になっていた。

DeepTranslatorTextNode

SpectrumApplyMiniMaxH3

Codexは残っていた入力値と接続関係から元のノードを特定し、カスタムノードを導入したうえで、JSON内の class_type と正式な入力名を復元した。最終的に20ノードすべてをComfyUIの object_info と照合し、未導入のノードがないことも確認している。

「4step」と書かれたTurbo LoRAを8ステップで使う

今回使った高速化LoRAは、ファイル名に 4step と書かれている。しかし、すでに他の利用者による検証で、4〜7ステップでは映像が崩れ、8ステップ以上で使う必要があるという情報が出ていた。

そのため、この環境ではファイル名やメタデータの「4ステップ」をそのまま採用せず、正式な検証条件を8ステップに固定した。これは今回あらためて4〜7ステップを検証し直して決めたものではなく、既存の検証結果を運用ルールとして採用したものだ。

最初のワークフローは10ステップになっていたが、最終的には指定どおり8ステップに変更した。

ここはかなり重要で、LoRAの名前に 4step と入っていても、現在の組み合わせで4ステップが実用になるとはかぎらない。モデル、LoRA、ComfyUI実装の更新状況を含めて判断する必要がある。

プロンプトもMiniMax H3向けに最適化

元のプロンプトは、浅い海に横たわる女性の静的な外見や光景を詳しく説明したものだった。ただ、動画生成では外見だけでなく、時間の流れに沿った動作、カメラ、物理的な変化、音まで明示したほうが扱いやすい。

そこでCodexが、MiniMax H3向けに次の3セクションへ再構成した。

integrated_multimodal_description:

overall_soundscape:

non_diegetic_music:

髪が水流で広がる様子、胸の小さな呼吸、手が水面を動いて波紋ができること、光の模様が移動すること、カメラがゆっくり寄ることなどを、5秒間で観察できる連続動作として追加した。環境音は浅い波、水音、風、遠くの海鳥に分けて記述し、不要な劇伴は N/A としている。

日本語で入力したい場合は、ワークフロー内のDeep Translatorノードで英語に変換してから、テキストエンコーダーに渡せる。なお、この翻訳処理にはインターネット接続が必要になる。

最初の動画は、全フレーム真っ黒だった

環境が完成し、1.0MPと0.7MPで5秒動画を生成したところ、処理自体は最後まで正常に終了した。しかし、できあがったMP4を再生すると映像が完全に真っ黒だった。

ここからCodexによる原因調査が始まった。

まず、MP4の破損やプレイヤー側の問題ではないかを確認した。動画はH.264として正常に保存されており、124フレーム、24fps、約5.17秒として読み取れる。ところが、全フレームのRGB最小値・最大値・平均値がすべて0だった。つまり、保存後に黒くなったのではなく、VAEから出てきた映像そのものが完全な黒だったということになる。

次に、以下の条件を順番に外しながら、短い診断用の動画を作った。

Spectrumを無効化する

Turbo LoRAを外す

別のFL2VAモデルに切り替える

カスタムサンプラーの別出力をVAEに接続する

どの条件でも黒画面は変わらなかった。

さらに、ローカルに診断用ノードを作り、サンプラー前後の潜在データを直接計測した。初期潜在はゼロだったが、サンプラー後はゼロではなく、NaNやInfもない正常な数値分布になっていた。つまり、モデルとサンプラーは仕事をしており、その後の映像VAEデコードで問題が起きている、というところまで絞り込めた。

VAEをFP32に固定すると完全な黒からは変化したが、今度は格子状のカラーノイズになった。これも正常な映像ではない。

原因は、安定版ComfyUIが新VAE形式に未対応だったこと

ここで「このVAEは最新のComfyUIでないと使えないのかもしれない」と考え、ComfyUI本体の最新版との差分を確認した。

当初入れていたのは安定版 v0.30.0 のコミット b1693ec だった。一方、公式masterにはMiniMax H3関連の新しい修正が追加されていた。

MiniMax H3のint8_convrot VAE対応 #15334

H3 VAEパラメータのデバイス変換修正 #15268

特に#15334は、今回使っている minimax_h3_video_vae_int8_convrot.safetensors を明示的に対象とした修正だった。公式の説明でも、int8_convrot量子化VAEへの対応を追加したとされている。

そこでComfyUIを公式masterのコミット 2eb6097 に更新し、フロントエンドやワークフローテンプレートなどの依存関係も更新した。

更新後、まず256×384・5フレーム・8ステップの短い動画で確認したところ、浅い水の中に横たわる人物、髪、水面、白い衣装が正しく描画された。黒画面も格子ノイズも消えている。その後、5秒・124フレームでも正常な動画を生成できた。

今回もっとも大きな教訓は、「モデルファイルを正しいフォルダに置いただけでは動かない場合がある」ということだった。新しい量子化形式のモデルやVAEでは、対応コードがリリースタグより後に追加されていることがある。エラーを出さずに黒画面やノイズを返す場合は、モデルやプロンプトだけでなく、ComfyUI本体の対応時期も確認したほうがよい。

最終的に完成した専用環境

最終構成では、次の状態まで確認できた。

既存ComfyUIと共有しないMiniMax H3専用環境

RTX 5080 16GB向けのLow VRAM設定

MiniMax H3の映像VAE・音声VAEを認識

Turbo LoRAを8ステップで使用

Spectrumノードを含むAPIワークフローを復元

日本語入力用の翻訳ノードを導入

MiniMax H3向けプロンプトテンプレートを保存

SageAttention、Triton、Sol-Attnを導入・動作確認

起動バッチと環境検証バッチを作成

黒画面の原因を潜在データまで調査し、ComfyUI更新で解決

参考として、同じプロンプト、同じシード、8ステップ、5秒指定で測定した結果は次のとおり。

設定 解像度 総処理時間 サンプラー時間 1.0MP 832×1248 300.692秒 234.991秒 0.7MP 704×1056 214.583秒 153.714秒

0.7MPでは総処理時間が約28.6%短くなった。ただ、この記事で一番残しておきたかったのは速度差ではない。空のフォルダから専用環境を作り、足りないノードを復元し、黒画面をデータで切り分け、新しいVAEに対応したComfyUIまで更新して、ようやく正常な動画にたどり着いた一連の流れのほうだ。

今回、私が用意したのはフォルダとモデルファイルだけで、環境構築、依存関係の導入、ワークフロー修復、検証、原因調査はCodexに任せた。ローカルAI環境はライブラリや量子化形式の組み合わせが複雑だが、実際のファイル、GPU、サーバーAPI、動画フレーム、潜在テンソルまで順番に調べていけると、「なんとなく動かない」状態から具体的な原因にたどり着ける。

同じMiniMax H3環境を作る人には、モデル名だけでなく、VAE形式、ComfyUIのコミット、ステップ数、カスタムノードの役割をセットで記録しておくことをおすすめしたい。

いいなと思ったら応援しよう!