MiniMax H3が「非公開」にした変換層を、有志が3つ独立に作っていた──H3-Context-IRを覗く
MiniMax H3の動画生成には、プロンプトを`integrated_multimodal_description`など固定スキーマの構造化ブリーフに変換する非公開のAPI「H3-Context-IR」がある。公式ドキュメントの中身と、この層を独自に埋めた3つのオープンソース実装(Apache-2.0のOpenH3-IR、そのComfyUIノード、中国語のマルチエージェント実装)を、それぞれ一次ソースから確認した。

目次
MiniMaxの動画生成モデル「MiniMax H3」には、プロンプトを送る前に挟む「変換層」がある。公式ドキュメントはこれを「H3-Context-IR」と呼び、実装は非公開だと明記している。この記事では、公式APIドキュメントが明かす変換の中身と、その非公開の層を独自に埋めようとした3つのオープンソースプロジェクトを、それぞれの一次ソースから確認する。
3行まとめ
- MiniMax公式の
/v2/h3_context_irエンドポイントは、プロンプトをintegrated_multimodal_description/overall_soundscape/non_diegetic_musicという3つのフィールドを持つ構造化ブリーフに変換する。実装は「非公開」と公式ドキュメントに明記されている- この層を独自に埋めた実装が、確認できた範囲だけで少なくとも3つ存在する。Apache-2.0ライセンスの
open-h3-ir(ローカルLLM対応)、そのComfyUIノードComfyUI-OpenH3-IR、DeepSeek/GLM+Qwen3-VL-32Bを使う中国語実装XINGSHEN2/minimax-H3-context-IR- MiniMax H3自体のコミュニティライセンスは、EU・英国・韓国・米国を「除外地域」としている点が
open-h3-irのREADMEで指摘されている。年商2,000万ドルを超える商用利用には別途MiniMaxの書面許可が必要という条項もある
公式APIが明かす変換の中身
MiniMaxの公式APIドキュメント(/docs/api-reference/video-generation-v2-h3-context-ir.md、curlで直接取得)は、H3-Context-IRをこう説明する。
H3-Context-IR deeply interprets multimodal context across text, images, audio, and video. It analyzes relationships among the inputs and between those inputs and the intended output, performs complex reasoning, and converts that understanding into a structured representation with richer semantic detail while preserving the user's original intent as much as possible.
(H3-Context-IRは、テキスト・画像・音声・動画にまたがるマルチモーダルな文脈を深く解釈する。入力同士の関係、および入力と意図された出力との関係を分析し、複雑な推論を行った上で、ユーザーの本来の意図をできる限り保ちながら、より豊かな意味的詳細を持つ構造化表現へとその理解を変換する)
そしてすぐ後にこう続く。
H3-Context-IR is a complex system and its implementation is not open sourced. This API can be used both to validate the official Full 2K-Workflow results and in production workflows.
(H3-Context-IRは複雑なシステムであり、その実装はオープンソース化されていない。このAPIは公式のFull 2K-Workflowの結果を検証する用途にも、実運用にも使える)
このエンドポイントは動画そのものは生成しない。テキスト・画像・動画・音声(text/image_url/video_url/audio_url)を組み合わせた入力を受け取り、task_idを返す。ステータスがsucceededになると、content.promptに変換後のブリーフが入る。公式ドキュメントに掲載されている実際のレスポンス例では、以下のような3段構成のテキストが返っている(抜粋)。
integrated_multimodal_description: [Shot 1] Cinematic, wide shot with a slow push in
on a female captain standing center frame...
overall_soundscape: Deep, resonant low-frequency thrumming of ship engines...
non_diegetic_music: Symphonic orchestral score, beginning with a slow, rising
brass and string crescendo...
つまりH3-Context-IRは、ユーザーの短いプロンプトを、ショットごとの映像描写(integrated_multimodal_description)・環境音(overall_soundscape)・劇伴音楽(non_diegetic_music)という3つの層に分けて書き直す変換器だ。レスポンス例にはusageフィールドもあり、あるサンプルでは入力5,664トークンに対し出力3,426トークン、合計9,090トークンを消費している。
公式APIドキュメントのOpenAPIスキーマ部分には、入力メディアの制約が数値付きで細かく定義されている。curlで取得したYAMLをそのまま表に起こすと次の通りだ。
| 入力種別 | 対応フォーマット | 単体ファイルサイズ上限 | 解像度・長さ | 点数上限 |
|---|---|---|---|---|
image_url |
JPG/JPEG/PNG/WEBP/HEIC/HEIF | 30MB | 幅高256〜5,760px、アスペクト比0.4〜2.5 | 先頭フレーム≤1・末尾フレーム≤1・参照画像≤9 |
video_url(参照専用) |
MP4/MOV(映像H.264/H.265、音声AAC/MP3) | 50MB | 幅高256〜5,760px、フレームレート23.976〜60fps | ≤3本、1本あたり2〜15秒・合計15秒以下 |
audio_url(参照専用) |
WAV/MP3 | 15MB | 1本あたり2〜15秒・合計15秒以下 | ≤3本 |
(出典: MiniMax公式APIドキュメントのOpenAPIスキーマをcurlで取得し表組みを日本語化)
このほか、リクエストボディ全体は64MB以下、durationは4〜15秒の整数のみ、ratioはadaptive/21:9/16:9/4:3/1:1/3:4/9:16の7種類から選ぶ仕様になっている。テキストのみのtext-to-video(t2va)ではratioの指定が必須でadaptiveは使えない一方、画像を使うimage-to-video(i2va)では常にadaptive扱いになり、他の値を指定してもエラーにはならず無視されるという。また、先頭/末尾フレーム指定(image-to-video)とreference系(reference_image/reference_video/reference_audio)は排他的で、同じリクエスト内で混在させることはできないと明記されている。サポートされる入力パターンはテキストのみ・画像+テキスト(先頭/末尾フレーム指定)・動画+音声リファレンスの3パターンで、画像は最大9枚までの参照画像を含められる。
open-h3-ir──ローカルLLMで同じブリーフを作る独立実装
この非公開の層を埋めようとしたのが、ruashots/open-h3-irだ。READMEはこの状況をこう表現する。
MiniMax open-sourced the model but not the stage that writes that document, saying only that "H3-Context-IR is critical to the quality of the final output" and that the way to get one is to call their hosted service. This is an independent open implementation of that missing layer, running on your own machine, with a dial on top of it.
(MiniMaxはモデルはオープンソース化したが、そのドキュメントを書く段階はしなかった。「H3-Context-IRは最終出力の品質にとって重要」とだけ述べ、それを得る方法はホスト型サービスを呼ぶことだとしている。これはその欠けている層の独立したオープン実装で、自分のマシン上で動き、その上に調整ダイヤルが付いている)
open-h3-irはOllama・llama.cpp・LM Studio・vLLM・ホスト型APIなど、OpenAI互換エンドポイントであれば何でも接続できる設計で、コンパイラ自体はGPUを必要としない(重みは接続先のエンドポイント側にある)とREADMEは説明する。CLI(h3irコマンド)・HTTPサービス・ComfyUIノードの3経路から使え、pip install open-h3-irでインストールできる。ライセンスはApache 2.0で、GitHubページで確認したスター数は初稿執筆時点(2026年8月27日)で34、加筆時点(2026年8月29日)のGitHub API実測では37に増えている。
READMEが強調しているのは「同じプロンプトでも、コンパイルするかしないかで結果が変わる」という比較だ。「雨の中、濡れた桟橋(gantry)に歩み出て、下に見える街に気づいて立ち止まる」という同一のリクエストを、素のままH3に送った場合とh3irを通してから送った場合を比べたデモが、README中の動画リンクとともに紹介されている。作者はこの違いを「モデルは問題なかった、言葉が問題だった」と表現している。
ComfyUI-OpenH3-IR──@でメディアを名指しして書く4ノード
open-h3-irをComfyUI上で使うための姉妹リポジトリがruashots/ComfyUI-OpenH3-IRだ。READMEによれば、このパックをインストールするとopen-h3-ir自体がComfyUIのPython環境にインストールされ、別サービスを起動する必要がなくなる(ComfyUI Managerで「OpenH3-IR」を検索してインストールするのが推奨ルート)。
提供される4つのノードは、メインの記述・duration・shot構成を扱う「OpenH3-IR Main」、画像・動画・音声をまとめて扱う「OpenH3-IR Media」、接続先LLMとH3ファイルの設定を行う「OpenH3-IR Setup」、カメラ・照明・演技・音のプリセットを再利用できる「OpenH3-IR Director」の4つ。特徴的なのは、@the-manのように@でメディアファイルを名指しして参照できる点だ。README冒頭の例を引用する。
@the-man crosses @desert while @dragon follows beside him.
He looks back and @speaks("You really came all this way?")
@speaks("...")で正確なセリフを固定できる、<Picture 1>のような番号管理をユーザーがしなくて済む、という設計になっている。
中国語版の独立実装──DeepSeek/GLM+Qwen3-VL-32Bの多段パイプライン
3つ目がXINGSHEN2/minimax-H3-context-IRだ。README(中国語)によれば、これは自然言語の要求と参照素材(画像・動画など)を受け取り、素材の用途と継承境界を解析した上で、視覚理解・素材間の関係推論・確定的な指示の結合・タイムライン編成・公式フォーマットへのレンダリングまでを行うエージェントだと説明されている。
アーキテクチャは、Intent Resolver(DeepSeekまたはGLM、ユーザーの明示的な指定を先に確定させる層)→ Qwen3-VL-32Bによる視覚知覚層(客観的な素材証拠のみを抽出)→ Context-IR Semantic Agent(DeepSeekまたはGLM、素材の役割・時系列・連続性を推論)→ Directive Binding Compiler(ユーザーが明示した要求をプログラムレベルで固定)→ Renderer/Auditorという5段構成。README本文は「モデルは理解と推論を担当し、重要なユーザー指示はプログラムレベルのコンパイルと検証でロックする。言語モデルが制約を『覚えている』ことだけに頼らないため」という設計思想を明記している。視覚分析の標準出力はmedia_analysis.v2という独自フォーマットで、音声トラックは現状Qwen3-VLの視覚層では分析されず、素材リストに保持されるだけだとREADMEは注記している。
3つの独立実装をGitHub APIで並べる
3つのリポジトリのGitHub API実測値(2026年8月29日)を並べると、規模も成熟度もかなり違うことが分かる。
| リポジトリ | スター数 | フォーク数 | ライセンス | 作成日 | 最終更新日 |
|---|---|---|---|---|---|
| ruashots/open-h3-ir | 37 | 5 | Apache-2.0 | 2026-08-12 | 2026-08-23 |
| ruashots/ComfyUI-OpenH3-IR | 19 | 1 | Apache-2.0 | 2026-08-22 | 2026-08-23 |
| XINGSHEN2/minimax-H3-context-IR | 0 | 0 | 表記なし(GitHub API上"license": null) | 2026-08-18 | 2026-08-28 |
(出典: GitHub API api.github.com/repos/{owner}/{repo} を2026年8月29日に実測)
3つとも2026年8月12日〜22日という10日間の幅に作成されており、MiniMax H3の公開後まもなく複数の開発者が独立にこの「非公開の変換層」を埋めようとしたことがうかがえる。XINGSHEN2版は最終更新が3つの中で最も新しい(2026年8月28日)一方、スター・フォークともに0でライセンス表記もない。ライセンスが指定されていないリポジトリは、GitHubの既定ルール上は著作権者に著作権が残り、他者が自由に再利用・改変してよいという意味にはならない点は、READMEを読むだけでは気づきにくい。
MiniMax H3自体のライセンスは日米欧を除外している
open-h3-irのREADMEには、この層の実装以上に読者にとって実務上重要な指摘がある。MiniMax H3本体のコミュニティライセンスについての注記だ。
MiniMax H3 is not licensed for use in the European Union, the United Kingdom, the Republic of Korea or the United States of America. Those are its Excluded Territories, and the grant is worldwide except for them.
(MiniMax H3は欧州連合・英国・大韓民国・アメリカ合衆国での使用がライセンスされていない。これらが「除外地域」であり、それ以外の地域では世界的に許諾されている)
加えて、商用製品のUIには「MiniMax H3」の名称を明示的に表示する義務(IV.2条)、年商2,000万ドルを超える商用製品はMiniMaxから別途書面での許可が必要(IV.1条)という条項もあると記されている。open-h3-irのREADMEはこれを要約に過ぎないとした上で、実際のMiniMax H3 Community License Agreement本文を読むよう促している。米国自体が除外地域に入っているという点は、MiniMax H3のライセンス条項を確認する前は把握していなかった。
中身を実行して比べたわけではない
この記事は、MiniMax公式APIドキュメント(OpenAPIスキーマ含む)、3つのGitHubリポジトリのREADME本文、GitHub API実測値を一次ソースとしている。open-h3-irやComfyUI-OpenH3-IRを実際にインストールし、README中の比較デモと同じプロンプトを自分の環境で流して結果を見比べる検証は行っていない。3つの独立実装がH3-Context-IRの出力をどこまで正確に再現できているか(公式のブリーフと構造・語彙がどれだけ一致するか)についても、READMEの主張以上の裏付けは持っていない。XINGSHEN2版の実際の出力サンプルも確認できていない。XINGSHEN2版にライセンス表記がないという事実はGitHub APIで確認したが、これが単なる記載漏れなのか意図的なものなのかは、作者本人に確認していないため分からない。Zenn検索では「H3-Context-IR」「open-h3-ir」いずれも0件(2026年8月27日実測)、Qiitaは今回のレート制限のため計測できていない。
関連記事: MiniMax M3──428Bパラメータ・100万トークン文脈のオープンウェイト中国モデル / MiniMaxが4モデル全部にセルフホストガイドを揃えていた / MiniMax Codeとは何か
感想・指摘はコメント欄へ。
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか?
AIについて聞きたいことはありますか?
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。