MiniMax は 2026 年 6 月 1 日に MiniMax M3 を発表した。公式紹介を見ると、M3 の位置づけは明確だ。コード、Agent、長文コンテキストのタスクを対象にしつつ、ネイティブマルチモーダル能力も備えている。
今回の発表で注目すべきなのは、単一のベンチマークスコアではない。MiniMax が次の三つの能力を一つのモデルにまとめた点だ。
- コードと Agent タスクの能力；
- 最大
1M tokensのコンテキストウィンドウ； - 画像と動画入力に対応するネイティブマルチモーダル；
- 将来的なプライベートデプロイとファインチューニングを見据えたオープンウェイト計画。
中国発モデルがコーディング支援、自動化ワークフロー、長文ドキュメント処理、マルチモーダル理解でどこまで進んでいるかを見ているなら、M3 は単独で確認する価値がある。
M3 の中心的な位置づけ
MiniMax は M3 を、コードと Agent のフロンティアモデル、1M コンテキスト、ネイティブマルチモーダルと説明している。
これらのキーワードは、実際の利用でよく出る課題に対応している。
- コードタスクは関数補完だけではなく、プロジェクトの読解、ファイル編集、ツール実行、エラー修正まで必要になる；
- Agent タスクでは大量のツール呼び出し履歴、ログ、中間結果が生まれる；
- 長い文書、長い動画、完全なコードベースにはより大きなコンテキストウィンドウが必要になる；
- グラフ、スクリーンショット、数式、動画フレームは、純粋なテキストだけでは理解しきれない。
そのため M3 は、普通のチャットや短文生成だけを狙ったモデルというより、「長い作業チェーン」のために用意されたモデルに近い。
1M コンテキストは MSA アーキテクチャから来ている
M3 は MiniMax 独自の MSA、つまり MiniMax Sparse Attention を使っている。公式説明では、MSA は長文コンテキストで従来の full attention が抱える計算量の急増を解決するための仕組みとされている。
簡単に言えば、full attention はコンテキストが長くなるほどコストが急激に増える。MSA は sparse attention と、ハードウェアで実行しやすい KV block アクセス方式によって、長文コンテキストでのスケーリングをしやすくしている。
公式によると、M3 API は最大 1M tokens のコンテキストをサポートし、最低 512K tokens を保証する。これは次のようなタスクで意味がある。
- 完全なプロジェクトや大きなモジュールを読む；
- 長い研究報告、契約書、ログ、ナレッジベース資料を処理する；
- 複数ラウンドの Agent 実行でツール呼び出し履歴を保持する；
- 長い動画やマルチモーダル資料を分析する。
ただし、長文コンテキストがあるからといって、すべてのタスクでウィンドウを埋めるべきではない。実際には、検索、分割、キャッシュ、タスク分解は依然として重要だ。1M コンテキストは複雑なタスクの上限を広げるものであり、エンジニアリング設計を置き換えるものではない。
コードと Agent が重点
公式レポートでは、M3 は複数のコードおよび Agent benchmark で次のスコアを示している。
| Benchmark | 公式スコア |
|---|---|
| SWE-Bench Pro | 59.0% |
| Terminal-Bench 2.1 | 66.0% |
| SWE-fficiency | 34.8% |
| KernelBench Hard | 28.8% |
| MCP Atlas | 74.2% |
これらの数字は参考になるが、ランキングだけで結論を出すべきではない。より重要なのは、MiniMax が M3 の学習と評価を、実際の協働に近い Agent シナリオへ寄せている点だ。
実際のコード作業は「一文で関数を生成する」ものではない。多くの場合、次の流れを含む。
- 要件を何度も確認する；
- 既存コードを読む；
- 変更計画を立てる；
- コマンドやテストを実行する；
- エラーに基づいて修正を続ける；
- 複数ラウンドのコンテキストで判断根拠を保持する。
M3 と MiniMax Code が同時に発表された理由もここにある。モデル能力は土台にすぎない。工程タスクを本当に完了できるかは、外側の Agent harness、ツール呼び出し、コンテキスト管理、検証フローにも左右される。
公式が示した長時間タスク
MiniMax はレポートで、実作業に近いケースをいくつか示している。
一つ目は論文再現だ。公式は M3 に ICLR 2025 Outstanding Paper の一つを独立して再現させた。M3 は約 12 時間連続で動作し、18 件の commit と 23 枚の実験図を生成し、主要な実験再現を完了した。
このケースのポイントは「論文要約ができる」ことではない。同時に次の能力を使っている点にある。
- 論文中の曲線、数式、図表を理解するマルチモーダル能力；
- 論文、コード、実験ログを同じタスクチェーンに入れる長文コンテキスト；
- 実行、実験、検証、修正を続けるコードと Agent 能力。
二つ目は CUDA kernel 最適化だ。公式は、直接実行できない Triton の骨組みから始めて、NVIDIA Hopper GPU 上の FP8 GEMM kernel を最適化するよう M3 に指示した。M3 は約 24 時間で 147 回の benchmark submission と 1,959 回のツール呼び出しを行い、ハードウェアピーク利用率を 7.6% から 71.3% へ引き上げ、9.4x の高速化を達成した。
このケースは、M3 が長時間の自律的な反復を重視していることを示している。普通のコード生成モデルは数回失敗すると止まりがちだが、Agent 型モデルにはフィードバックに基づいて方向を調整し続ける力が必要になる。
三つ目は M3 にモデルを自律的に訓練させるケースだ。PostTrainBench で、公式は事前学習だけが完了した四つの base model を M3 に渡し、12 時間以内にデータ合成、訓練、評価、反復を完了させた。最終的な M3 のスコアは 0.37 で、Opus 4.7 と GPT-5.5 には及ばないが、他のモデルを明確に上回った。
これらのケースは MiniMax 公式テストに基づくため、第三者の独立評価と同一視はできない。それでも、M3 の製品方向は見える。モデルを長時間動作し、検証可能で、フィードバックのあるタスクループに入れる方向だ。
ネイティブマルチモーダルの意味
M3 は、テキストモデルに視覚能力を後付けしただけのものではない。公式は、M3 が学習初期から混合モダリティで訓練され、データパイプラインを再構築して学習データを 100T+ レベルへ拡張したとしている。
開発者にとって、マルチモーダルの価値は主に次の場面にある。
- スクリーンショット、図表、数式、デザイン案を読む；
- PDF、論文、報告書、実験図を分析する；
- 長い動画の画面変化を理解する；
- デスクトップ自動化タスクで UI 要素を認識する。
MiniMax Code もこの方向を製品化している。公式によれば、MiniMax Code は M3 のマルチモーダル能力と computer use を組み合わせ、たとえば表計算ファイルの内容に基づいて複数アプリをまたいだ一括入力を行える。
MiniMax Code と Agent Team
M3 の発表に合わせて、MiniMax Code も更新された。公式は MiniMax Code を、M3 により適した Agent 製品として位置づけ、M3 の長文コンテキスト、コード、Agent、マルチモーダル能力を引き出すものとしている。
MiniMax Code の Agent Team は、大きなタスクを複数段階、並行、動的に調整可能なワークフローへ分解し、Producer + Verifier に似た対抗的ループで、生成、振り返り、修正を継続できる。
この方向は Claude Code、Codex CLI、opencode などと同じ大きなカテゴリにある。モデルが質問に答えるだけでなく、ローカルまたはクラウドの開発環境に入り、ファイルを読み、ファイルを編集し、コマンドを実行し、その結果に基づいて作業を進める。
MiniMax がより強調しているのは次の点だ。
- M3 の 1M 長文コンテキスト；
- マルチモーダルと computer use；
- Agent Team による長時間の自律実行；
- Token Plan による大きな利用枠。
Token Plan と API
MiniMax は今回 Token Plan も更新した。公式が公開した三つのプランは次の通り。
| プラン | 月額 | M3 月間枠 |
|---|---|---|
| Plus | $20/month |
約 1.7B tokens |
| Max | $50/month |
約 5.1B tokens |
| Ultra | $120/month |
約 9.8B tokens |
これらの枠はかなり大きく、高頻度のコード支援、バッチ処理、長文ドキュメント処理、マルチモーダルタスクに向いている。ただし本当に割に合うかは、利用可能地域、並行数制限、速度、安定性、コンテキスト課金、タスク成功率を見る必要がある。
API では M3 はすでに利用可能だ。公式説明で注目すべき点は次の通り。
- 入力長が
<=512K tokensの場合は標準価格； 512K tokensを超える場合はより高い長文コンテキスト価格；- thinking のオン・オフを切り替え可能；
- thinking オンは複雑な推論、Agent、長期協働に向く；
- thinking オフは応答が速く、会話やコード補完に向く；
standardとpriorityのサービスレベルに対応し、priority は高並行と安定したレイテンシ向け。
公式例のモデル名は次の通り。
|
|
エンドポイント例は次の通り。
|
|
M3 を既存のコードツールに接続する場合、まず確認すべきことは三つある。OpenAI-compatible の互換性、ストリーミング出力対応、ツール呼び出し形式だ。
オープンウェイトは注目だが、実際の公開を待つ必要がある
MiniMax は、M3 の重みを Hugging Face と GitHub でオープンソース化し、プライベートクラスタへのデプロイとファインチューニングをサポートするとしている。これは重要な点だ。
重みが本当に公開され、推論フレームワークの対応も順調なら、M3 は次のような企業シナリオに入る可能性がある。
- プライベートコードベース支援；
- 社内ナレッジベースと文書分析；
- 高感度データを扱う場面；
- 政府、企業、ローカルデプロイ；
- 低コストのバッチ Agent ワークフロー。
ただし、まだ具体的な情報を待つ必要がある。
- 重みサイズとライセンス；
- 量子化方案；
- vLLM、SGLang、llama.cpp などのフレームワーク対応；
- VRAM 要件；
- ローカルデプロイ時のマルチモーダルと長文コンテキストの実コスト；
- 完全な訓練またはファインチューニング用ツールチェーンの公開有無。
今の段階では注目してよいが、「オープンウェイト」がすでに本番投入可能な事実だと考えるのは早い。
先に試すべき人
M3 は次のようなユーザーが先に試すのに向いている。
- AI coding agent をよく使う開発者；
- Claude、GPT、Gemini の一部コードタスクを中国発モデルで置き換えたいチーム；
- 長文ドキュメント、長いコードベース、長いログの分析が必要な人；
- 自動化ワークフロー、MCP、agent harness を作っている開発者；
- バッチ処理のために大量の token 枠が必要な人；
- ローカルデプロイとオープンウェイトに長期的な需要があるチーム。
普通のチャット、短文リライト、簡単な Q&A だけなら、M3 を最優先で試す必要はないかもしれない。重点は明らかに、より重い Agent とエンジニアリングタスクにある。
私の見方
MiniMax M3 の今回の発表で一番面白いのは、路線の選び方だ。汎用チャットモデルと比べるだけでなく、コード、Agent、長文コンテキスト、マルチモーダルを、エンジニアリングワークフロー向けの一つのモデルとしてまとめている。
この方向は正しい。これからの AI プログラミングツールの競争は、モデルがコード片を書けるかどうかだけではなく、長時間タスクの中で計画、実行、検証、修正を続け、同時にコンテキストコストを抑えられるかを見るものになる。
ただし、M3 が主力ワークフローに入れるかどうかを決めるのは、より素朴な問題だ。
- API は安定しているか；
- 長文コンテキストの価格は制御可能か；
- MiniMax Code のツールチェーンは成熟しているか；
- OpenAI-compatible と主要 agent ツールとの適配はスムーズか；
- オープンウェイトは予定通り公開されるか；
- 第三者評価と実プロジェクトの体験が公式説明を支えられるか。
これらが今後うまく進めば、M3 は中国発のコード Agent モデルの中でかなり注目すべき存在になる。