2026年4月から6月にかけて、中国系のオープンウェイトモデルが立て続けにフロンティア帯のコーディング性能で並びました。GLM-5.1、Kimi K2.6、そしてMiniMax M3。各社の公開情報では、この3つがいずれもSWE-Bench Proで50点台後半の値とされ、主要なクローズドモデルと同じ帯に並びました。その波の中で、コーディング・エージェント・100万トークンのマルチモーダルを1つにまとめた点で目を引くのがMiniMax M3です。
MiniMax M3とは、中国MiniMax社が公開した1Mコンテキスト対応のオープンウェイトMoEモデル。
「名前は聞いたが、結局なにがすごいのか」をはっきりさせるのがこの記事の役割。スペックの読み方、似たモデルとの違い、そして実際に使うときの判断軸まで、2026年6月時点の公式情報をもとに順に整理していきます。
- MiniMax M3は2026年6月1日公開の中国MiniMax社製オープンウェイトモデル。総パラメータ約428B・アクティブ約23BのMoE構成
- 最大100万トークンの長文を扱える点が最大の特徴で、長文効率は独自機構MSA（MiniMax Sparse Attention）で実現
- コーディング・エージェント・マルチモーダルを1モデルに統合。重みが公開されているため自己ホストという選択肢を取れる
MiniMax M3とは：一言で言うと
MiniMax M3とは、コーディング・長文処理・マルチモーダル入力を1つにまとめた、重みが公開されているMoE型の大規模言語モデルです。MiniMax社が2026年6月1日に公開しました。
ここでいうMoE（Mixture of Experts、混合エキスパート）とは、モデル内部に複数の「専門家ネットワーク」を持ち、入力ごとに一部だけを動かす構造のこと。M3の総パラメータは約428Bですが、1トークンの処理で実際に動くのは約23Bにとどまります。検索結果でも総約428B・アクティブ約23Bという数字が共通して挙がっており、巨大なモデルでありながら推論時の計算量を抑える設計になっています。
特徴を一言でまとめるなら「統合」。MiniMaxは公式blogでM3を、フロンティア級のコーディング、100万トークンの文脈、ネイティブなマルチモーダル（テキスト・画像・動画）の3つを併せ持つ初のオープンウェイトモデルだと位置づけています。これまでは「コーディングが強いモデル」「長文に強いモデル」「画像も読めるモデル」が別々だったところを、1つにまとめた点が新しいわけです。
そして重みが公開されている、いわゆるオープンウェイトであること。APIを叩くだけでなく、自前で借りたGPU上にモデルを置いて動かす道が開かれます。これが後半で触れる「自己ホストかAPIか」という判断につながっていきます。
基本スペックと仕組みをもう少し詳しく
MiniMax M3の基本構成は、総パラメータ約428B・アクティブ約23BのMoEに、最大100万トークンの文脈長とネイティブなマルチモーダル入力を組み合わせたものです。順に噛み砕いていきます。
MoE構成とアクティブパラメータの意味
要するにMoEとは、全パラメータを毎回フル稼働させず、入力に応じて必要な部分だけを呼び出す仕組みです。総パラメータが大きいほど知識の容量は増えますが、毎回すべてを計算すると推論が重くなります。そこでM3は約428Bの容量を持ちながら、1トークンあたりは約23B分しか動かさない形を取りました。
この「総量は大きいが、動くのは一部」という性質が効いてくるのが推論コストの面。応答の速さやGPUの使用効率は、総パラメータよりアクティブパラメータに近い感覚で効いてきます。一方で、モデル全体をメモリに載せる必要はあるため、保管に要するVRAMは総パラメータ側に引きずられます。このギャップは導入コストの章で改めて触れます。
コンテキスト長とマルチモーダル入力
コンテキスト長とは、モデルが一度に読み込める入力の長さのこと。M3は最大100万トークンを公称しています。日本語の文章なら数十万字規模、ソースコードならリポジトリ単位の読み込みも視野に入る長さ。長い設計書とコードベースをまとめて渡し、文脈を保ったまま回答させる用途で差が出ます。
マルチモーダルについては、公式blogが「画像と動画の入力に対応し、デスクトップコンピュータを操作できる」と記しています。テキストだけでなく画像・動画を最初から扱える、いわゆるネイティブマルチモーダル。学習の初期段階から複数モダリティを混ぜて訓練したとされており、後付けで画像対応を足した構成とは設計の出発点が異なります。
長文を支えるMSA（MiniMax Sparse Attention）の役割
MSA（MiniMax Sparse Attention）とは、長い文脈を効率よく処理するためにM3へ搭載された、独自のスパースアテンション機構です。100万トークンという長さを現実的な速度で扱えるかどうかは、ここにかかっています。
通常のアテンション（注意機構）は、文脈が長くなるほど計算量が急増します。すべてのトークン同士の関係を見ようとするためで、これが長文処理のボトルネックでした。スパースアテンションは、その関係づけを必要な範囲に絞り込むことで計算量を抑える考え方。MiniMaxの前世代モデルでも長文処理の効率化は重要課題で、M3ではMSAによって1Mコンテキスト時の速度を大きく改善した、と公式に説明されています。
公式blogは効果をこう説明しています。
at a context length of 1 million, M3’s per-token compute is just 1/20 that of the previous-generation model（文脈長100万トークンの地点で、M3の1トークンあたり演算量は前世代モデルの20分の1にとどまる）
出典: MiniMax公式blog https://www.minimax.io/blog/minimax-m3
あわせて、前世代のM2との比較で、入力処理（プレフィル）が約9倍、出力生成（デコード）が約15倍に高速化したと公表しています。長文を「読めるが遅い」ではなく「読めて速い」に寄せたのがMSAの狙いです。
ただし、スパースアテンションの高速化は計算の組み方やハードウェアの相性に依存しやすい面があります。MSAそのものの2段階の仕組みやKVブロックの分割といった内部構造は、技報（arXiv:2606.13392）に踏み込んだ別記事で扱っています。詳しくは姉妹サイトの解説記事「MiniMax MSAとは？長文アテンション計算を削減する2段階スパースアテンションを解説」を参照してください。本記事ではM3全体像に話を戻します。
MiniMax M3とKimi K2.6・GLM-5.1の違い
MiniMax M3、Kimi K2.6、GLM-5.1の違いは、提供元とライセンス、そして「何に統合の重心を置いたか」にあります。3つとも2026年4月から6月に重みを公開したオープンウェイトという点では同じ陣営です。
各社の公開情報では、MiniMax M3がSWE-Bench Pro（実際のソフトウェア開発タスクで性能を測るベンチマーク）59.0%、Kimi K2.6が58.6%、GLM-5.1が58.4%とされ、いずれも50点台後半の帯に並んでいます。ただし実行harnessや採点条件が異なるため、直接の横並びではなく同程度の性能帯として見るのが安全です。ライセンスは、GLM-5.1がMIT系として公開、Kimi K2.6はHugging Face上で modified-mit 表示（本文で条件確認）、M3はHugging Face上の表示が minimax-community（一般的なMIT/Apacheとは異なるオープンウェイト）です。
| 比較項目 | MiniMax M3 | Kimi K2.6 | GLM-5.1 |
|---|---|---|---|
| 提供元 | MiniMax | Moonshot AI | Z.ai |
| ライセンス区分 | minimax-community（オープンウェイト） | modified-mit（公式LICENSE本文で条件確認） | MIT系として公開 |
| 入手形態 | 重み公開 | 重み公開 | 重み公開 |
| 自己ホストのVRAM負荷 | 高（大型MoE） | 高（数百GB級の報告あり） | 高 |
| SWE-Bench Pro報告値 | 50点台後半 | 50点台後半 | 50点台後半 |
表のベンチ値には注意が要ります。これらの数字は異なるharness（ベンチマークの実行環境・採点条件）で取得されたもので、直接の横並び比較はできません。「どれも50点台後半」という帯感は参考になりますが、0.1点差を競う読み方は意味を持たない、という前提で見てください。
では、どれを選ぶか。コーディングに加えて100万トークンの長文と画像・動画入力までを1モデルで完結させたい場面なら、統合性を前面に出すM3が候補に上がります。一方で、ライセンスの明快さを最優先し、MITのまま自由に組み込みたいならGLM-5.1の素のMITが扱いやすい選択。Kimi K2.6は自己ホスト時の規模が数百GB級と報告されており、ここはハードウェアの余力との相談になります。
ライセンスと自己ホストが持つ意味
オープンウェイトであることの実利は、フロンティア級のコーディング環境を借りたGPU上に自前で立てられる点にあります。これにより、APIのフロンティア料金を払い続ける代わりに、レンタルGPUで同等帯の性能を運用する選択肢が生まれます。ただし「open weight＝完全に自由」とは限りません。重みの公開とライセンスの許諾範囲は別の話。商用利用や再配布の条件は、各モデルの公式ライセンス本文で確認する前提で考えてください。
実務でどう使われているか｜使いどころ
MiniMax M3の実務での使われ方は、コーディング支援・長文処理・エージェント・マルチモーダル入力という、本来は別ツールに分かれていた仕事を1モデルに寄せる形が中心です。
具体的には、リポジトリ全体や長い仕様書をまとめて読ませてコードを書かせる、複数ステップのタスクを自律的に進めるエージェントの土台にする、画像や動画を含む資料を読み取らせる、といった場面。100万トークンの文脈長は、長い設計ドキュメントとソースを一度に渡して、抜けのない回答を引き出す用途と相性がよい設計です。
導入時に分かれ道になるのが、APIを使うか自己ホストするか。判断軸はおおむね3つに集約できます。
まず量とコスト。利用量が読めて少なめなら、APIで都度払いするほうが手間もコストも軽くなります。逆に大量・継続利用が見えているなら、レンタルGPUで自己ホストして従量課金を平準化する判断が効いてきます。次にデータの取り扱い。機密性の高いコードや資料を外部の推論APIに送りたくない事情があるなら、自己ホストが選択肢に入ります。最後に運用負荷。自己ホストは数百GB級のVRAMを確保し、モデルの稼働を自分で面倒見る必要があり、ここを軽く見ると詰まります。
APIで使う場合、自己ホスト時はvLLMやSGLangを使うことでOpenAI互換の /v1/chat/completions 形式で呼び出せます。一方、MiniMax公式APIを使う場合は、公式ドキュメントに示されたMiniMax側のエンドポイント・認証方式に従ってください（OpenAI SDKのエンドポイントとは限りません）。下は自己ホスト時のOpenAI互換サーバ（vLLM/SGLang等）を呼ぶ最小イメージで、ベースURLやモデルIDは実環境の値に置き換えます。
from openai import OpenAI
# base_url / model は公式ドキュメントで要確認（下記は互換APIの呼び出しパターン例）
client = OpenAI(
api_key="YOUR_API_KEY",
base_url="http://localhost:8000/v1", # vLLM/SGLang等の互換サーバ例。公式API利用時はMiniMax公式手順に従う
)
resp = client.chat.completions.create(
model="minimax-m3", # 実際のモデルIDは公式で確認
messages=[{"role": "user", "content": "このリポジトリの設計上の問題点を指摘して"}],
)
print(resp.choices[0].message.content)OpenAI互換の利点は、特定ベンダーの独自SDKに縛られず、ベースURLの差し替えだけでプロバイダーを乗り換えられる柔軟さにあります。これはベンダーロックインを避けたい現場で評価されてきた発想で、自己ホストへの移行余地とあわせて運用の自由度を上げます。
導入・コストで押さえる点
MiniMax M3の導入コストは、API利用なら文脈長に応じた段階課金、自己ホストなら数百GB級のVRAM確保が中心の論点になります。順に見ていきます。
API側の料金は、2026年6月時点の公式情報では、入力512Kトークンまでが標準レート、それを超える長文入力には割増レートが適用される段階構造です。サブスクリプション型のトークンプランも用意されており、公式blogではPlusが月20ドルで約17億トークン、Maxが月50ドルで約51億トークン、Ultraが月120ドルで約98億トークンと案内されています。
自己ホストの壁になるのがVRAM。M3は総パラメータ約428Bの大型MoEで、量子化（モデルを軽量化する圧縮手法）をかけても保管に相当な容量を要します。同時期のKimi K2.6では量子化後でも数百GB級という報告があり、大型MoEを自前で動かす重さの目安になります。アクティブが約23Bだから軽い、と早合点しないことが肝心。動作中の計算は軽めでも、モデル全体を載せるメモリは総パラメータ側に引っ張られます。
なお、MSAのような高速化機構はハードウェアとの相性に左右されやすい面があります。自己ホストを本気で検討するなら、対応環境と必要な周辺構成を公式の手順で確認してから着手するのが堅実です。
まとめ
MiniMax M3は、2026年6月1日にMiniMax社が公開した、総パラメータ約428B・アクティブ約23BのオープンウェイトMoEモデルです。押さえどころは3点。最大100万トークンの長文を扱え、その効率を独自機構MSAが支えていること。コーディング・エージェント・マルチモーダルを1モデルに統合した点で、同時期のKimi K2.6やGLM-5.1と並ぶオープンウェイトの波の中にあること。そして重みが公開されているため、APIと自己ホストを選び分けられること。
理解を深める順序としては、まずM3の全体像（本記事）を押さえたうえで、長文効率の核であるMSAの仕組みを別記事で確認し、次に自分のタスク量とデータの機密性からAPIか自己ホストかを当てはめると、判断がぶれません。ベンチの数字はharness差で直接比較できない前提を忘れず、最終的には自分のコードと用途で試して相性を測るのが近道です。
| 提供元 | MiniMax（中国） |
|---|---|
| 公開時期 | 2026年6月1日 |
| パラメータ | 総約428B / アクティブ約23B（MoE） |
| コンテキスト長 | 最大100万トークン（標準レートは入力512Kまで） |
| 入手形態 | オープンウェイト（ライセンス詳細は公式要確認） |
| 主な用途 | コーディング・エージェント・長文処理・マルチモーダル入力 |
よくある質問（FAQ）
Q. MiniMax M3は無料で使えますか？
重みがオープンウェイトとして公開されているため、対応するハードウェアを用意すれば自己ホストで動かせます。API利用は有料で、2026年6月時点では入力512Kトークンまでが標準レート、超過分は割増です。月額のトークンプランも用意されています。
Q. MiniMax M3とKimi K2.6・GLM-5.1は何が違いますか？
3つとも2026年に重みを公開したオープンウェイトで、SWE-Bench Proの報告値は50点台後半と同帯です。提供元はM3がMiniMax、K2.6がMoonshot AI、GLM-5.1がZ.ai。ライセンスはGLM-5.1がMIT系として公開、K2.6はHugging Face上で modified-mit 表示、M3はHugging Face上の表示が minimax-community です。なおベンチは実行環境が異なり直接比較はできません。
Q. MiniMax M3を自己ホストするのに必要なVRAMはどれくらいですか？
総パラメータ約428Bの大型MoEのため、量子化しても数百GB級のVRAMを要する規模です。アクティブが約23Bでも、モデル全体の保管は総パラメータ側に依存します。実機要件はコンテキスト長やランタイム分も加わるため、公式の前提条件か実測で見積もってください。
参考資料
- MiniMax公式blog: MiniMax M3 発表記事
- Hugging Face: MiniMax公式モデルカード（MiniMaxAI）
- MiniMax Sparse Attention (MSA) 技術報告 (arXiv:2606.13392)
