MiniMax H3とは｜2K・15秒・音声同時生成のオムニモーダル動画モデルを公開重みとAPIの差で解説

MiniMax H3 は、テキスト・画像・動画・音声が混ざった文脈を1つのモデルで受け取り、最大2K・15秒のステレオ音声つき動画を返すオムニモーダル生成モデルだ。2026年7月31日に発表され、8月3日に重みが公開された。

この記事ではLLMに特化して解説します。LLM全般の仕組み・比較・ローカル実行は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 をご覧ください。

MiniMaxは動画生成サービスHailuoで知られる中国のAI企業だ。同社は2026年6月にオープンウェイトのLLM「MiniMax M3」を発表しており、H3はその動画側の系譜にあたる。

H3の発表が注目されたのは、単に「高解像度の動画が作れる」からではない。入力と出力の両方でモダリティの境界を取り払った点にある。従来の動画生成モデルは「テキスト→動画」「画像→動画」のように入口が固定され、音声は別モデルで後から付けるのが一般的だった。H3は文章・画像・動画クリップ・音声クリップが混ざった文脈を1つのモデルで受け取り、映像と音声を同時に出力する。

この記事では、公式ブログ・Hugging Faceのモデルカード・ライセンス本文・API仕様書という一次資料に当たり、さらにHugging Face APIでリポジトリの実体を計測して、「公称」と「実際に手元で動く範囲」を切り分ける。

MiniMax H3で何ができるのか：4つの生成モードと参照12ファイル

公式APIドキュメントによれば、MiniMax H3は4つの生成モードを持つ。

・Text to Video：文章だけから映像と音声を生成する
・Image to Video：画像で開始フレーム・終了フレームを指定し、文章で動きを与える
・First / Last Frame：開始と終了の両方のフレームを指定する（画像0枚・1枚・2枚）
・Reference生成：画像・動画・音声を「参照」として渡し、スタイル・人物の同一性・動き・声を引き継がせる

実務でいちばん効くのは4つ目のReference生成だ。公式仕様の上限は参照画像9枚・参照動画3本（各2〜15秒）・参照音声3本、合計12ファイルまで。プロンプトは7,000文字まで、APIリクエストボディは64MBまでと定められている。

なぜこの上限が重要かというと、動画生成でいちばん壊れやすいのがカット間の同一性だからだ。同じキャラクターを別のショットで出したいのに顔が変わる、という問題は生成動画の実用化を長く阻んできた。参照画像を9枚まで渡せるということは、1人のキャラクターを複数角度から与えて固定できるということを意味する。音声を参照に渡せる点も同様で、声の同一性をカット間で保つ設計になっている。

出力側の仕様は次の通り。

24FPSという数字は映画の標準的なフレームレートに揃えたものだ。音声が「ネイティブ」であるとは、映像を作ってから別モデルで効果音を合成するのではなく、同じモデルが映像と音声を同時に生成することを指す。環境音・効果音・BGM・同期した台詞が対象になる。

音声駆動で口の動きを合わせるアプローチは以前からあり、InfiniteTalk：音声駆動で無制限長の会話動画を生成するAIフレームワーク のように音声を入力として映像を作る専用OSSも存在する。H3はその逆方向、つまり映像と音声をまとめて出力する側に踏み込んでいる。

参照12ファイルをどう配分するか

参照の上限は「合計12ファイル」という共有の予算になっている。画像9・動画3・音声3という個別上限はあるが、合計は12で頭打ちになるため、実務では何にファイル枠を割くかという配分の問題になる。

・人物の同一性を優先するなら、画像枠を厚く使う。正面・斜め・横といった複数角度のリファレンスを与えるほど、カット間で顔が破綻しにくくなる
・動きやカメラワークを引き継ぎたいなら、参照動画を使う。ただし参照動画は各2〜15秒という制約があり、後述のとおり課金上も生成尺とは別に加算されると報じられている
・声の同一性が要るなら音声枠を割く。H3は音声をネイティブ生成するため、参照音声で声質を固定できる点が他モデルとの差になる

12という数字は一見多いが、1カットあたりで使い切れる量でもある。連作カットで世界観を揃えるなら、どの参照を固定枠として毎回渡し、どれをカットごとに差し替えるかを先に決めておくと破綻しにくい。

公開された重みに何が入っていて、何が入っていないのか

ここが本記事の核心だ。「MiniMax H3がオープンソース化された」という見出しは各所で流れたが、公開されたのはモデル全体ではない。

Hugging Faceのモデルカードは、H3が3つのモジュールで構成されると明記している。

このうち公開されたのは②のH3-Baseだけである。モデルカードは①H3-Context-IRについて「今回のオープンソース公開には含まれない」、③H3-Regenerate-2Kについて「まだオープンソース化していない。準備ができ次第公開する」と記載している。

これは読み流しやすい一文だが、実用上の意味は大きい。手元の重みだけで出せる既定の解像度は短辺768pであり、宣伝されている2Kは③のモジュールが担っているからだ。

公式スクリプト自体がAPIを呼んでいる

推測ではなく、リポジトリに同梱された公式スクリプトがこれを裏づける。scripts/readme/ には「2Kを再現する手順」が生成モードごとに置かれていて、ファイル名がそのまま3段構成に対応している。

3本を順に読むと、処理の流れはこうなる。

・full-2k-t2va-h3-context-ir.sh … $MINIMAX_API_BASE/v2/h3_context_ir に Authorization: Bearer $TOKEN を付けてPOSTし、拡張済みプロンプトを受け取る
・full-2k-t2va-h3-base.sh … $SGLANG_DEPLOYMENT_URL/v1/videos すなわちローカルのSGLangへPOSTする。リクエストボディの target は "short_edge": 768
・full-2k-t2va-h3-regenerate-2k.sh … 生成された768pのMP4をBase64のデータURLにして $MINIMAX_API_BASE/v2/video_regeneration へPOSTする。ボディには "resolution": "2K"

つまり公式が示す「フル2K」の再現手順は、ローカル推論1回をMiniMaxのAPI呼び出し2回で挟む構成になっている。ローカルだけで完結する経路ではない。同ディレクトリには ...-by-directly-calling-open-platform-api.sh という、最初から全部APIで済ませる比較用スクリプトも並んでいる。

リポジトリの実体を数える

「498GB」という数字も公称ではなく、Hugging Face APIで実測した値だ。以下のコマンドで誰でも再現できる。

# リポジトリ全体のファイル数・サイズをディレクトリ別に集計する
curl -sL "https://huggingface.co/api/models/MiniMaxAI/MiniMax-H3?blobs=true" \
  | python3 -c "
import json,sys,collections
d=json.load(sys.stdin); size=collections.Counter(); n=collections.Counter()
for s in d['siblings']:
    k=s['rfilename'].split('/')[0] if '/' in s['rfilename'] else '(root)'
    size[k]+=s.get('size') or 0; n[k]+=1
for k,v in size.most_common():
    print(f'{k:16s} files={n[k]:4d} {v/1e9:8.2f} GB')
print('TOTAL %.2f GB' % (sum(size.values())/1e9))
"

2026年8月5日時点の実行結果は次の通りだった。

FL2VA/ と Ref2VA/ が各144GBで、これが2つのチェックポイント本体だ。加えてdiffusers形式の text_encoder/ transformer/ transformer_ref/ vae/ が同じ階層に並んでおり、同じ重みが元の形式とdiffusers形式で二重に置かれているため合計が膨らんでいる。用途に応じて片方だけ取得すれば実際のダウンロード量は抑えられる。

2つのチェックポイントの役割は次のように分かれている。

そして重要なのは、この一覧に2K再生成モジュールの重みが1つも存在しないことだ。2k を含むファイルはデモ動画（assets/*.mp4）と前述のシェルスクリプトだけで、モデルの重みはない。これが「2KはAPI側にある」ことの実測的な裏づけになる。

4つの技術要素：なぜこの3段構成になったのか

公式ブログは、H3を支える技術を4つ挙げている。3段構成の意味を理解するには、この4つを押さえておくと早い。

① Contextual Omni Representation。従来のキャプション付けは映像の内容を短く説明するだけだったが、H3では「与えられた文脈」と「生成すべき動画」の関係そのものを記述する方式に作り替えられている。公式の説明によれば、この記述はおよそ100Kトークン規模の推論を経て、平均で約4Kトークンに凝縮される。冒頭で見た①H3-Context-IRは、まさにこの処理を担うモジュールだ。手元の重みだけでは「プロンプトをそのまま渡す」ことしかできず、この凝縮された文脈記述が得られない、という差になる。

② H3-VAE。動画をトークン列に変換するトークナイザを再設計し、実効シーケンス長で4倍の効率を得たとしている。2Kという解像度を現実的なコストで扱えるようになった土台がここにある。動画は1秒あたり24フレーム、15秒なら360フレームで、これを素朴にトークン化すると系列長が爆発する。圧縮効率がそのまま生成コストに直結する領域だ。

③ H3-Omni Transformer。「理解」の処理と「生成」の処理を分離した構成で、これによりエンドツーエンドの学習スループットが約30%向上したとされる。前述の33B dense・単一ストリームというのは、このTransformerの構成を指している。

④ In-Context Regeneration。ここが3段構成の③にあたる部分で、設計として面白い。一般的な高解像度化は、生成済みの低解像度映像だけを入力にとる超解像モデルを後段に置く。H3はそうせず、元のマルチモーダル文脈をもう一度読み直したうえで2Kで生成し直す。単に画素を増やすのではなく、参照画像や参照音声を含む文脈を再度参照するため、細部の再現が文脈と整合しやすい、という理屈だ。

この④が未公開である、という事実は、単に「解像度が上がらない」以上の意味を持つ。文脈を読み直す再生成そのものがH3の設計上の売りであり、その部分がAPIの向こうに残っている。

MiniMax H3をローカルで動かす：構成と前提

公開されているH3-Baseの中核は、33Bパラメータのdense・単一ストリームTransformer（H3-Omni-Transformer）だ。MoEではなくdenseである点は、必要なメモリ量を見積もるうえで押さえておきたい。

モデルカードは、このうち約13BパラメータがAdaLN分岐にあり、推論時にはキャッシュできると説明している。この数字はリポジトリの設定ファイルから再計算して確認できる。

# transformerの設定を取得して AdaLN 分岐のパラメータ数を概算する
curl -sL "https://huggingface.co/MiniMaxAI/MiniMax-H3/raw/main/FL2VA/transformer/config.json" \
  | python3 -c "
import json,sys
c=json.load(sys.stdin)
per = c['time_embed_dim'] * c['adaln_out_features']
print('層数           :', c['num_layers'])
print('time_embed_dim :', c['time_embed_dim'])
print('adaln_out      :', c['adaln_out_features'])
print('AdaLN概算       : %.2f B' % (per*c['num_layers']/1e9))
"

time_embed_dim は2688、adaln_out_features は96768、層数は50。掛け合わせると 2688 × 96768 × 50 ≈ 13.0B となり、公式の「約13B」という記述と一致する。設定ファイルの実数から公称値を再計算できたので、この部分は裏が取れたと言ってよい。

同じ設定ファイルからは、hidden_size 5376・アテンションヘッド56・ヘッド次元128・FFN 14336という構成も読み取れる。

推論フレームワークはSGLang・vLLM・diffusers・ComfyUIの4つが案内されており、diffusersでは ModularPipeline.from_pretrained("MiniMaxAI/MiniMax-H3") で読み込む形になっている。公式のSGLangデプロイ例は4GPU構成を示している。

# 必要な系統だけ取得する（FL2VAのみなら約144GB）
huggingface-cli download MiniMaxAI/MiniMax-H3 \
  --include "FL2VA/*" --local-dir ./minimax-h3

# 取得後、2K再生成の重みが含まれていないことを確認する
find ./minimax-h3 -iname "*regenerate*" -o -iname "*2k*" | grep -v assets

498GBを落とさずに済ませる：再パッケージ版という現実解

公式配布はBF16で、しかも同じ重みが2形式で置かれている。ComfyUIの公式組織であるComfy-Orgは、これを実行に必要な単位へ再パッケージした Comfy-Org/MiniMax-H3 を公開している（2026-08-05時点で588 likes）。ここには量子化版も含まれており、必要容量が大きく変わる。

このファイル一覧からは、副次的にもう1つ分かることがある。H3のテキストエンコーダはQwen3-VL 32Bである——ファイル名がそう名乗っている。オムニモーダルな文脈理解の入口に、既存のVLMが据えられている構成だ。

容量の観点では、pruned fp8のdiffusionモデル（20.96GB）とnvfp4のテキストエンコーダ（15.69GB）、VAE（5.21GB）を組み合わせれば合計42GB程度になる。498GBを丸ごと落とす必要はない、というのが実務上の答えになる。ただし量子化による品質劣化は用途次第なので、まずBF16で基準を取ってから落としていく順序が安全だ。

量子化によってこの種のモデルを現実的なハードウェアに載せる工夫は活発で、BitNet｜Microsoftの1ビットLLM量子化フレームワーク のような極端な低ビット化の研究も進んでいる。上表の再パッケージ版は第三者（ComfyUI公式組織）による配布であり、MiniMax公式の配布はあくまでBF16である点は押さえておきたい。

MiniMax H3のライセンスを読む：地域・売上・表示義務

重みが公開されていることと、自由に使えることは別問題だ。H3はMiniMax H3 Community License Agreementという独自ライセンスで配布されており、これはOSIが承認するオープンソースライセンスではない。

条文で目を引くのは地域制限だ。第I条は用語をこう定義している。

・「Applicable Territory」＝ Excluded Territories を除く全世界
・「Excluded Territories」＝ 欧州連合、イギリス、韓国、アメリカ合衆国

つまり許諾の対象から米国・EU・英国・韓国が外れている。日本はこの除外リストに含まれていない。ライセンス本文は続けて、除外地域についても「各地域の法規制・コンプライアンス要件を継続的に評価しており、当該地域での展開に関心がある場合は個別ライセンスについて連絡してほしい」と述べている。

商用利用については2つの条件が定められている。

第VI条4項は利用者にとって有利な条項だ。生成した動画そのものの権利をMiniMaxが主張しないと明記されている。一方で、第V条5項は生成物を第三者に提供するサービスを運営する場合に、権利侵害や禁止用途を防ぐための技術的・組織的な安全対策の実装・維持・定期見直し、違反報告窓口の設置、違反判明時の是正までを求めている。ホスティング事業として提供するなら、この運用負荷は事前に見積もっておく必要がある。

なお付属のAcceptable Use Policyは20カテゴリの禁止用途を列挙しており、軍事利用、医療・法律業務への無資格利用、機械生成であることを明示しない配信などが含まれる。

他の動画生成モデルとの位置づけ：MiniMax H3は何位なのか

ベンダー自身のベンチマークだけで判断するのは危険なので、第三者評価を見る。Artificial Analysisのアリーナは人間の比較投票からEloスコアを算出する形式で、MiniMax自身も自社の順位を引用している。

2026年8月5日閲覧時点のスコアは次の通り。

読み方を整理する。H3は総合首位ではない。テキスト→動画・画像→動画のいずれもGoogleのGemini Omni Flashが上にいて、差はEloで15〜20程度だ。一方でH3は公開重みのモデルとしては全部門で首位であり、Video Editing部門では総合1位とされている。

「オープンな重みで、クローズドの最上位に手が届く距離まで来た」というのが、現時点で言える範囲の妥当な評価だろう。Artificial Analysisも「MiniMaxが重みを公開すれば、公開重みモデルとして群を抜く存在になる」という趣旨の評価を出していた。

主要モデルとの位置づけを整理すると次のようになる。

なお、生成動画の制御テクニックはモデルの性能とは別軸で効く。1回の生成で複数の表情やポーズを得る AI動画生成の新テクニック「2x2コラージュ」 のような手法は、参照画像を9枚渡せるH3のような制御面の広いモデルと組み合わせると効果が読みやすい。

MiniMax H3の料金と、どう使い分けるか

価格については、公式の一次資料が具体的な単価を出していない点を最初に断っておく。MiniMax公式ブログの記載は相対表現にとどまる。

・2K出力：「主流モデルの1/3未満」
・768p出力：「主流モデルの720pの半額未満」

具体的な数字として流通しているのは、OpenRouterなど再販・集約事業者の掲載値だ。2026年8月5日時点でOpenRouterは「from $0.13/second」と表示している。この単価なら15秒の2Kクリップで約$1.95になる。報道では768pが$0.09/秒とされているが、こちらは一次資料で確認できていない。公称値・報道値として扱うのが安全だ。

使い分けの判断軸は、結局のところ本記事で見てきた「3段構成のどこが要るか」に帰着する。

セルフホストを検討している場合、「498GBを落として4GPUを用意すれば宣伝どおりの2Kが出る」という理解は正確ではない。出るのは768pで、2Kにするには結局APIを呼ぶ。この一点だけでも、事前に把握しておく価値がある。

逆に言えば、768pで十分な用途ならH3-Baseの重みは十分に強力だ。音声を同時生成できる公開重みモデルは多くなく、参照12ファイルという制御面の広さも他に類を見ない。SNS向けの短尺動画、プロトタイピング、社内向けの説明動画といった用途なら、768p・15秒・音声つきという組み合わせは実用範囲に入る。

まとめ：MiniMax H3をどう捉えるか

事実を整理する。

・MiniMax H3は2026年7月31日発表・8月3日に重みが公開された、テキスト/画像/動画/音声を受けて音声つき動画を返すオムニモーダルモデルである
・第三者評価では総合2位・公開重みでは首位。首位のGemini Omni Flashとの差はEloで15〜20程度
・公開されたのは3段構成の中央（H3-Base、33B dense、BF16、実測498GB）のみで、プロンプト拡張と2K化はAPI側に残っている
・ライセンスはOSI承認のオープンソースではなく、許諾地域から米・EU・英・韓が除外され、年商2,000万ドル超は書面許諾、商用UIには名称表示義務がある
・価格は公式が相対表現しか出しておらず、$0.13/秒は再販事業者の掲載値

「オープンソースの動画生成モデルが2Kを出せるようになった」という要約は、正確ではない。正確には「オープンウェイトの動画生成モデルが、音声込みで768pを出せるようになり、2Kは引き続きAPIの向こうにある」だ。それでも、音声を同時生成できる公開重みモデルが第三者アリーナで総合2位に付けたことの意味は小さくない。

未公開のモジュールが今後公開されるかどうかは、この分野の勢力図に直接影響する。モデルカードは「準備ができ次第」としか述べておらず、時期は明示されていない。採用を検討するなら、まず768pのH3-Baseで自分のユースケースの品質を確かめ、2Kが要る部分だけAPIに寄せる、という順序が現実的だろう。

参照ソース

・MiniMax H3: An Open Model Breaking the Boundaries Between Tasks and Modalities（MiniMax公式ブログ） — 2026年7月31日発表。アーキテクチャ（Contextual Omni Representation、H3-VAE、H3-Omni Transformer、In-Context Regeneration）と相対価格の一次資料
・Open General Intelligence: MiniMax H3 Is Now Open Source（MiniMax公式ニュース） — 2026年8月3日の重み公開告知。公開範囲と未公開モジュールの明記
・MiniMaxAI/MiniMax-H3（Hugging Face モデルカード） — チェックポイント構成、33B/BF16、推論フレームワーク、full attention限定の記載、scripts/readme/ の再現スクリプト
・MiniMax H3 Community License Agreement — 適用地域・除外地域の定義、商用条件、使用制限、Acceptable Use Policy
・Text to Video Leaderboard（Artificial Analysis） — 第三者によるElo評価。2026年8月5日閲覧
・Comfy-Org/MiniMax-H3（Hugging Face） — ComfyUI公式組織による再パッケージ版。量子化バリアントの実サイズとテキストエンコーダの構成