変更点1 · 入力側

Music 3.0 は一言をセクション別仕様書に変更

原因が説明の粗さなら、説明を詳細にすれば良い。Music 3.0 は曲全体を1つのグローバルラベルで表現するのをやめ、時間軸に沿ってセクションごとに詳細を記述する構造化キャプション（Structured Caption）を採用。3つのブロックで構成されます：

この仕様書はどの程度詳細なのでしょうか？公式デモページの各曲には完全な説明が添付されており、英語だけで700語以上あります。以下は、そのうちの1曲（アーバンソウル）の実際の入力の一部で、「ボーカル詳細」の一部だけを取り出したものです：

Vocal Style: The delivery is marked by a conversational,
behind-the-beat phrasing... The bridge requires a dramatic
shift to a "whisper-singing" technique, utilizing heavy
vocal fry and breathy tail-offs to convey extreme proximity.

Harmony/Backing Vocals: The choruses are bolstered by tight,
three-part male harmony stacks... panned hard left and right
to envelop the lead.

注目すべきは、形容詞がすべて実行可能な具体性を持っていることです。「囁き」と言うだけでなく「ブリッジで」と指定し、「3声の男性コーラス」と言うだけでなく「ハードに左右に振り分けて」と指定しています。「感動的」「ハイレベル」といった実行不能な空虚な言葉ではありません。モデルが従えるのは、この説明自体がすでに設計図・施工指示書だからです。

変更点2 · 構造

歌詞の角括弧は実際の構造スイッチ

仕様書が各セクションの肉付けを管理するなら、曲全体の骨格は誰が決めるのでしょうか？答えは歌詞側にあります。

歌詞に [Intro]、[Verse]、[Pre-Chorus]、[Chorus]、[Post-Chorus]、[Bridge]、[Instrumental]、[Solo]、[Outro] のような角括弧のマーカーを書くと、モデルはそれを構造指示として実行し、曲のセクション数、順序、インストゥルメンタル箇所を決定します。「Verse」という単語を歌ったりはしません。ここがユーザーが最も間違えやすいポイントです：角括弧は実行可能な指示であり、歌詞本文は感情を伝えるだけで構造は伝えない。Aメロからブリッジ、サビへと展開させたい場合は、自分で歌詞にそのように配置する必要があります。

付属機能

公式が1000のテンプレートとリライトスキルも公開

しかし、一般の人が700語の専門的な仕様書を書くことはできません。これがこの入力形式の敷居となっています。公式の解決策はリライトシステムを用意することです。平易な言葉で書くと、専門用語を使った完全な仕様書に拡張してくれます。

このテンプレートライブラリは抽象的な概念ではなく、GitHubリポジトリに実際に置かれています：1000個のプレーンテキストテンプレートファイルが、18のジャンルファミリー（フォーク、EDM、ヒップホップ、ジャズ、メタル、ソウル・ゴスペル、東アジアの抒情歌、カントリー・アメリカーナなど）に分類されています。リライトロジック自体もAIエージェントのスキルとしてオープンソース化されており、1行のコマンドでインストールできます：

npx skills add MiniMax-AI/MiniMax-Music3 --skill music-caption-rewriter

その検索方法は、エージェント開発者にはお馴染みのものです。スキル内では、1000テンプレート全てをスキャンすること、データベース作成、ベクトル計算、外部API呼び出しが明示的に禁止されています。段階的に絞り込みます。まずジャンルルーティングテーブルを読み、1〜2のファミリーに絞ります。次にファミリーインデックスの簡易カードを比較します。最後に選択した最大3つのテンプレートのみを完全に読み込み、しかも3つには役割分担があります：

モデルをインストールする予定がなく、プロンプトの書き方を上達させたいだけの人にとって、この1000のテンプレートはそのまま参考にできる編曲プロンプトの資料庫となります。

メカニズム · 核心

2つのモデルが役割分担、一方は曲全体を記憶してもう一方は1フレームだけを処理

入力側の2つの変更点は説明しました。では、モデル内部はどうやって5分間を支えているのでしょうか？まず、音声がモデル内でどのように表現されるかを知る必要があります。

オーディオは言語モデルに直接渡すことはできません。まず、オーディオフレームという小さな単位に分割します（ここでは毎秒25フレーム）。各フレームはさらに8層のコードブックでエンコードされます（公式には残差ベクトル量子化＝RVQと呼ばれます）：第1層は16384個のコードワードを持つ大きな辞書で、このフレームの中核的な意味と構造（どのコード、どのセクション、何を歌っているか）を担当します。第2層から第8層はそれぞれ1024個のコードワードを持つ小さな辞書で、音の細部の残差（音色、倍音、空間感）を層ごとに積み重ねていきます。

2つのモデル：一方は曲全体を記憶、もう一方は眼前の1フレームだけを処理

音声の階層構造が分かれば、役割分担は自然に決まります。

なぜ分ける必要があるのでしょうか。80億パラメータの大規模モデルに、曲全体の進行と各フレームの倍音の詳細の両方を処理させると、無駄が多く混乱しやすく、注意力が2つのスケールに引き裂かれます。詳細を6億パラメータの小規模モデルに任せてフレームごとに補完させれば、大規模モデルは5分前の出来事を記憶することに専念できます。長期的な安定性と局所的な豊かさ、この両方を同時に確保するためには、この分割が必要なのです。

MiniMax Music 3.0 公式アーキテクチャ図。下から上へ4層：最下部は入力（左の紫枠がStructured Caption、右の緑枠が歌詞）。その上がHybrid LMで、濃い青の横棒がグローバルモデル。各フレームの隠れ状態を出力し、C₀ を通じてローカルモデルへ渡り、C₁ から C₇ を層ごとに出力。さらに上の2つのfusion矢印が隠れ状態をSynthesis層へ送り、Flow-Matching と Flow VAE Decoder を経てオーディオを出力。右の赤い円は停止記号、灰色の四角は隠れ状態。出典：MiniMax公式発表ブログ。

メカニズム · 音質

最終段で圧縮をスキップ、息継ぎと余韻が残る

しかし、曲の良し悪しを最終的に決めるのはこの最終段階で、最も見落とされがちです。

一般的な方法：言語モデルが離散的なコードワードの列を出力し、デコーダーがそのコードワードに従って音声を再構成します。問題は「コードワード」、つまり量子化されている点です。本来連続的な音波が有限のグリッドに圧縮され、その過程で微妙な部分（息継ぎ、スライド、弦の余韻）が失われ、後からデコードしても取り戻せません。

Music 3.0 の方法：推論時に離散デコーダーを一切ロードしません。2つの言語モデルの最終層の連続的な隠れ状態（hidden state）＝コードワードに圧縮される前の高次元情報を融合し、24億パラメータのフローマッチングモジュールに直接送り、さらに1.23億パラメータのFlow-VAEで波形にデコードします。

Flow-VAE はゼロから作られたわけではなく、MiniMax 製の音声モデル MiniMax Speech からアーキテクチャを流用し、音楽のダイナミックレンジとスペクトル特性に合わせて再トレーニングされています。

効果

公式サンプル16曲、上海ジャズからゴスペルメタルまで

メカニズムの説明は以上です。残りの効果は自分の耳で確認するしかありません。これが今回の発表の唯一の証拠であり、ベンチマークも比較実験もなく、16曲のサンプルがあるだけです。以下の試聴台でスタイルタグをクリックして曲を切り替えられます。各曲には実際の入力説明が添付されており、「同じモデルでも、入力を変えれば全く異なる出力になる」ことを直感的に確認できます：

残りの7曲

公式ブログでは全16曲の音声が公開されていますが、そのうち第2曲と第11曲は入力説明と歌詞が完全に同一で、実際に重複していないのは15曲です。当サイトでは重複を除いています。全音声はMiniMax公式CDNからの直リンクです。

ライセンス

年間売上2000万米ドル未満なら、商用利用に許諾不要

良さそうだが、使ってもいいのでしょうか？今回の発表はタイトルに「オープンソース」とありますが、ブログ本文にはライセンスに関する記述が一切ありません。そのため、このセクションの内容は全てライセンス条文からのものです。

その名は MiniMax-Music3 コミュニティライセンス。全文7400バイトで、冒頭の文言はMITライセンスをほぼそのまま踏襲しています：無料使用、改変、再配布、商用利用が可能。追加条件は以下の4つのみです：

大多数の個人クリエイターや中小チームにとって、実際に対応が必要なのは最初の1条だけです。画面上にモデル名を表示することです。

地域排除条項なし

同じ会社が10日前に、全く異なる契約を発表しています。

契約の末尾には、このモデルの出自も明記されています。グローバルモデルはQwen3-8B（Apache 2.0ライセンス）を微調整したもの、拡散部分はStability AIのstable-audio-tools（MITライセンス）を改変、VAEはDescriptのオーディオコーデックDAC（MITライセンス）を改変したものです。

導入

8GB VRAMで動作、ただし公式自ら5つの制限を明記

ライセンスが許可されたなら、次はマシンのスペックです。この部分もブログには記載がなく、全てモデルカードにあります。

VRAM 3段階（シングルGPUの場合）

まず、この3段階がどの経路に対応するかを明確にします：diffusers を1枚のGPUで実行する場合です。公式推奨のサービス化パスは要件が異なるため、次の段落で説明します。

ComfyUI 側では、小容量VRAM向けに INT8 量子化バージョンのモデルファイルも提供されています。長い曲を生成する際には、チャンクデコードを有効にすることで、VRAM使用量をさらに抑えられます。

また、HuggingFace のモデルページには、コミュニティが作成した3つの微調整版と4つの量子化版がすでに公開されています。自分でフォーマット変換をしなくても、既製のものをダウンロードできます。

3つのデプロイ方法

公式が自ら明記した5つの制限

このリストはベンダー自身が作成したもので、どんな効果説明よりも価値があります：

最後のこの条項が、これまでの議論をすべて現実に引き戻します。この構造化キャプションによって「言ったことが守られる」確率は大幅に上がりましたが、それでも確率であって、楽譜を音源ライブラリに入力するような決定論的な実行ではありません。

2つのモデルが役割分担：一方は全体を記憶、もう一方は1フレームを処理

音声を毎秒25フレームに分割し、各フレームを8層のコードブックにエンコード。第1層が骨格を、残り7層が音色の詳細を担当。これらのフレームを2つの異なるサイズのモデルが順次処理します。

圧縮をスキップすることで、息継ぎとスライドが残る

音質を左右するのは最終段階ですが、最も圧縮の影響を受けやすい部分でもあります。

8GB VRAMで動作、ただしモデルカードに制限事項あり

ウェイトは公開され、VRAM要件も比較的低く、商用条件も寛容。今回の発表の境界は、MiniMax自身のモデルカードに記載されています。