MiniMax H3が「非公開」にした変換層を、有志が3つ独立に作っていたH3-Context-IRを覗く

【更新 2026年9月25日】初稿(2026年8月29日時点)で確認した一次ソースを再確認した。MiniMax公式APIドキュメントは、本文で引いた説明文と主な数値制約（ファイルサイズ・解像度・アスペクト比・duration・ratio）を突き合わせたところ、初稿の記述と同じだった。初稿がopen-h3-irのREADME経由で紹介したライセンス条項も、今回ライセンス本文を直接読んで一致を確認した。一方、3つのオープンソース実装はいずれもGitHub上のスター・フォーク数が増えた。コードの更新が9月も続いているのはXINGSHEN2/minimax-H3-context-IRだけで、READMEによれば内部アーキテクチャそのものが「v20」という別構成に置き換わっていた（後述）。変更点は該当箇所に時点を明記して反映した。

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対応、GitHub実測60スター・2026年9月25日時点）、そのComfyUIノードComfyUI-OpenH3-IR（同24スター）、DeepSeek V4.1 Flash等を使う中国語実装XINGSHEN2/minimax-H3-context-IR（初稿執筆後、READMEが「v20」と呼ぶ構成へ刷新）
• 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をそのまま表に起こすと次の通りだ。

(出典: 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、2026年9月25日の再実測では60（フォーク8）まで増えている。コード自体の最終更新(pushed)は2026年8月23日のまま変わっておらず、伸びているのはスター・フォーク数だ。

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」を検索してインストールするのが推奨ルート）。これはプロンプトを書き直す前段（H3-Context-IRに当たる層）を埋めるノードで、ComfyUI公式がv0.34.0で追加したMiniMax-H3向けノード「MiniMaxH3AddGuide」（生成時に動画の任意のフレームへ画像・音声などのガイドを固定するノード）とは別物だ。

提供される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>のような番号管理をユーザーがしなくて済む、という設計になっている。

中国語版の独立実装──1か月足らずでアーキテクチャが「v20」に刷新されていた

3つ目がXINGSHEN2/minimax-H3-context-IRだ。この実装は開発速度が特に速く、初稿(2026年8月29日時点のREADME)と更新確認(2026年9月25日時点の一次ソース)とで、中身の説明そのものが変わっている。両方の時点を分けて書く。

2026年8月29日時点: 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は注記していた。

2026年9月25日時点: README本文とdocs/CURRENT_CONTEXT_IR_WORKFLOW.mdを一次ソースとして再確認すると、上記の5段構成は「v20」と呼ばれる別のパイプラインに置き換わっていた。README自身が冒頭で「現在のブランチはv20の本番フローだけを残す」とし、「旧canonical IRコンパイラ、確定的Promptレンダラー、独立したディレクター最適化器、Codex実行パス、過去の実験用エントリは削除済み」と明記している。現在のドキュメントが説明する流れは8段階だ。①リクエスト(context_request.v1)の正規化・検証 ②resolve_intent（推論モデルがユーザー要求・素材参照・指示・知覚計画を解析。呼び出し側が解析済みの要求を渡せばスキップ可能）③ensure_perception（Qwenが素材を解析。視覚理解モデルはQwen3.8-27Bに変わっている＝旧Qwen3-VL-32Bから変更）④build_writer_evidence（証拠の整理） ⑤compile_prompt（v20のルールと執筆指示を連結） ⑥DirectChatRuntimeが/chat/completionsを呼び、モデルがcontent_plan・h3_prompt・uncertaintiesを一括出力（独立したdirector段階や意味修復段階は無い） ⑦transport_issuesが結果フィールド・素材番号・ショットの時間連続性・目標尺をチェック（プログラムは意味的な完全性までは検証しないとドキュメントは注記） ⑧軽量IR・生のプロンプト・H3リクエスト・診断ファイルを保存。

ただし「v20」はmainブランチのREADMEとドキュメントの呼び方だ。2026年9月25日にGitHubのブランチ一覧を見ると、main以外に34本のブランチがあり、v20〜v63の番号を付けたものが中心だった。いちばん新しい更新は9月24日だ。mainにも9月17日付で「Merge v33 workflow into main」というコミットがある。この番号とREADMEの「v20」がどう対応するのかは、今回読んだREADMEとドキュメントからは読み取れなかった。

推論モデルのデフォルトは、docs/CURRENT_CONTEXT_IR_WORKFLOW.mdによれば2026年9月13日の更新でDeepSeek公式APIのV4.1 Flash（呼び出し名deepseek-flash）に切り替わった。環境変数でGLMなどに切り替えられる点は8月時点と同じだ。視覚分析の出力フォーマット名media_analysis.v2も現在まで使われ続けている。音声については、現在のdocs/API.mdに/api/understand/audioというオプションのエンドポイントが記載されているが、「音声が非対応の場合はその制約を明示的に記録する」という仕様だ。今回読んだREADME・docs/CURRENT_CONTEXT_IR_WORKFLOW.md・docs/API.mdの範囲では、素材理解の説明は画像・動画（Qwen3.8-27B）だけで、音声トラックを標準で分析するようになったとは書かれていない。なお、このエンドポイント自体は2026年8月28日のコミット時点のREADMEにも「現状は本物の音声知覚モデルの設定が必要」という注記つきで載っていた。

3つの独立実装をGitHub APIで並べる

3つのリポジトリのGitHub API実測値(初稿2026年8月29日／2026年9月25日再実測)を並べると、規模も成熟度もかなり違うことが分かる。

(出典: GitHub API api.github.com/repos/{owner}/{repo} を2026年8月29日と2026年9月25日の2時点で実測。太字が9/25時点の数値)

3つとも2026年8月12日〜22日という10日間の幅に作成されており、MiniMax H3の公開後まもなく複数の開発者が独立にこの「非公開の変換層」を埋めようとしたことがうかがえる。9/25時点でも傾向は同じで、XINGSHEN2版は最終更新(pushed)が3つの中で最も新しく、かつ唯一9月に入ってからもコミットが続いている一方、スター・フォークは3つの中で最も少なく、ライセンス表記も引き続き無い（前述の通りアーキテクチャ自体が刷新されるほど活発に動いている）。他の2つ(open-h3-ir・ComfyUI-OpenH3-IR)はコード自体は8月23日から動いていないが、スターは1か月弱でそれぞれ1.6倍・1.3倍に増えている。ライセンスが指定されていないリポジトリは、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のライセンス条項を確認する前は把握していなかった。

【2026年9月25日追記】上記はopen-h3-irのREADMEによる要約経由の確認だったため、Hugging Face上のMiniMax H3 Community License Agreement本文（MiniMaxAI/MiniMax-H3リポジトリのLICENSEファイル）を直接取得し、一次ソースで裏取りした。除外地域の定義（"Excluded Territories" means the European Union, the United Kingdom, the Republic of Korea and the United States of America）、年商2,000万ドル超で別途書面許可が必要な条項、「MiniMax H3」の名称表示義務のいずれも、ライセンス本文の文言と一致していた。中国系AIモデル各社の料金・重み公開状況・ライセンス条件・データ保存先を横断比較した中国AIモデルまとめ【2026年9月版】にもMiniMax H3の項目がある。

中身を実行して比べたわけではない

この記事は、MiniMax公式APIドキュメント(OpenAPIスキーマ含む)、MiniMax H3 Community License Agreement本文、3つのGitHubリポジトリのREADME・関連docs、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は今回のレート制限のため計測できていない。2026年9月25日の再確認も同様にドキュメント・READMEの読み直しとGitHub API実測に留まり、XINGSHEN2/minimax-H3-context-IRの新アーキテクチャ(v20)を実際に動かして旧版と出力を比較する検証は行っていない。

関連記事: MiniMax M3──428Bパラメータ・100万トークン文脈のオープンウェイト中国モデル / MiniMaxが4モデル全部にセルフホストガイドを揃えていた / MiniMax Codeとは何か

感想・指摘はコメント欄へ。