MiniMax M2.1：事後学習におけるエージェントモデルの進化とデータ合成のフロンティア

MiniMax M2.1は、GitHubデータ駆動のSWE Scaling、Expert-in-the-LoopなAppDev、探索と進化によるWebExplorerといった革新的なデータ合成戦略と、Forgeフレームワーク、CISPOアルゴリズムを駆使し、実用性と堅牢性を兼ね備えたエージェントモデルの新たなフロンティアを開拓している。
LLM
AI
Author

Junichiro Iwasawa

Published

January 22, 2026

以前のブログ記事でも紹介したように、MiniMaxは今月初め、最新のフラッグシップオープンソースモデルであるM2.1を公開した。M2.1は、前世代のM2をベースに、事後学習（Post-Training）段階における大幅な最適化が施されている。

アーキテクチャとしてはMixture-of-Experts (MoE)を採用しており、総パラメータ数は約230B（2300億）、アクティブパラメータ数は約10B（100億）である。この設計により、推論効率を維持しつつ、エージェントシナリオにおいて実運用に耐えうる堅牢なパフォーマンスを実現している。

本記事では、M2.1の性能を支える核心技術である「データ合成戦略」と、それを支える強化学習アルゴリズム「CISPO」、そしてフレームワーク「Forge」について、技術的な観点から深掘りして解説する。

データ合成：エージェント能力の源泉

M2.1の進化において最も注目すべきは、その洗練されたデータ合成（Data Synthesis）パイプラインである。MiniMaxはこれを大きく3つのカテゴリに分類している。

  1. 実データ駆動型（Real-Data-Driven）： SWE Scaling（ソフトウェアエンジニアリング）
  2. 専門家駆動型（Expert-Driven）： AppDev（アプリケーション開発）
  3. 合成による長期的タスク生成（Synthetic Long-Horizon）： WebExplorer（検索・探索）

それぞれの戦略について詳細を見ていく。

1. SWE Scaling：GitHubを基盤とした検証可能なタスク生成

SWE Scalingの中核にあるのは、GitHub上の膨大なPull Requests (PRs) とCommitsを活用し、検証可能（Verifiable）なタスクを合成するというアプローチである。

データパイプラインの構築 単にGitHubのデータをクロールするだけではない。最も困難かつ重要なステップは、各PRに対して「実行可能なDocker環境」を構築することである。 通常、このプロセスはAgentにコードサンドボックス内でビルドを試行させ、エラーに応じて自己修正させることで行われる。しかし、言語やライブラリのバージョン依存性により完全自動化は困難であるため、MiniMaxでは専門家の知識を注入し、Agentの実行フローを最適化することで、信頼性の高い仮想環境を構築している。

タスクの多様化とルーティング PRはその性質によって分類（Routing）され、下流工程で異なる処理が適用される。

  • Bug Fix（バグ修正）： 最も標準的なシナリオ。F2P（Fail-to-Pass：修正前は失敗し、修正後は成功するテスト）とP2P（Pass-to-Pass：リグレッションを防ぐための既存テスト）を抽出する。モデル自身がAgentとしてサンドボックス内で修正を行い、これらのテストを用いて検証を行う。
  • Feature Addition / Optimization（機能追加・最適化）： これらはバグ修正とは論理が異なる。機能追加では新規に追加されたテストポイントを抽出し、最適化ではパフォーマンスの差異を検証するP2Pテストに焦点を当てる。

モデルベースの検証とタスク変換 さらに、PRの記述が不十分な場合はモデル自体を用いて問題記述を補完し、自己完結した問題へと昇華させる。また、データの再利用性を高めるため、以下のような変換（Transformation）も行われる。

  • Bug Injection: 正常なコードにバグを埋め込む。
  • Task Inversion (SWE-Test): 「バグを直す」タスクを「バグを検出するテストを書く」タスクに反転させる。
  • Code Review: 実行環境を必須としない静的解析タスクとして再構成する。

結果として、10以上の主要プログラミング言語をカバーし、SWE-benchなどのベンチマークにおいて多言語設定での顕著な性能向上を実現している。

2. AppDev：正解のない世界での評価

既存のリポジトリ修正（SWE）とは異なり、ゼロからのフルスタックアプリケーション開発（AppDev）では、事前にテストケースを定義することが極めて困難である。

Expert-in-the-LoopとAgent-as-a-Verifier この課題に対し、MiniMaxは「Expert-in-the-Loop」アプローチを採用している。フロントエンド、バックエンド、モバイル開発のスペシャリストがプロンプトや報酬の評価基準（Rubric）を設計する。 検証には「Agent-as-a-Verifier」という手法が用いられる。これは、検証用Agentがサンドボックス内にアプリをデプロイし、Playwrightなどのツールを用いて実際にアプリを操作・対話し、専門家が定義したRubricに基づいてスコアリングを行うものである。

この動的な検証プロセスにより、M2.1はLMArenaのCode Arenaリーダーボードのオープンモデルの中でトップランクを獲得している。

3. WebExplorer：探索と進化による複雑性の創出

コーディング以外の一般的なエージェントシナリオ、特にWeb検索においては「Explore and Evolve」という戦略が採用されている。

  1. Exploration（探索）： AgentがWebを自由に探索し、情報豊富なシードとなる質問を生成する。
  2. Evolution（進化）： シード質問に対し、削除（Removal）、難読化（Obfuscation）、置換（Substitution）といった操作を行い、検索難易度を意図的に引き上げる。

例えば、「1950年ワールドカップのブラジル代表」という直接的な情報を、「独特なフォーマットで開催され、ノックアウトステージがなかったワールドカップ」といった曖昧な記述に変換する。これにより、単純な検索では答えに辿り着けず、マルチステップの推論と探索が必要な「Long-Horizon」なタスクが生成される。この手法により、M2.1はBrowsCompにおいてGPT-4.5に匹敵する性能を示している。

インフラストラクチャとアルゴリズム：Forge & CISPO

M2.1の成功は、強力なインフラとアルゴリズムの支えがあってこそである。

Forge：エージェント中心のトレーニングフレームワーク

MiniMaxは、内部開発フレームワーク「Forge」を使用している。これは、任意のAgentスカフォールド（足場）上での強化学習（RL）をサポートするように設計されている。 統合に必要なのは、前処理（preprocessing）、実行（execution）、後処理（postprocessing）、報酬計算（reward computation）の4つのインターフェースを実装することのみである。これにより、バイナリとしてのみ利用可能なブラックボックスAgentであっても、URLリダイレクトを通じてForgeの推論エンジンに接続し、ログを収集・学習に利用することが可能となっている。

CISPO：安定した強化学習のためのアルゴリズム

アルゴリズム面では、MiniMax M1で提案されたCISPOが引き続き採用されているが、M2世代に向けて重要な洞察と改良が含まれている。

PPOの課題とCISPOのアプローチ 一般的なPPO（Proximal Policy Optimization）では、クリッピングメカニズムによって、確率比が大きく変動したトークンの勾配がフィルタリング（無効化）される傾向がある。MiniMaxの分析によると、接続詞や「wait」といった思考のつなぎ言葉が頻繁にクリップされ、学習機会を失っていた。

CISPOは、REINFORCEスタイルの目的関数をベースにしつつ、Importance Sampling（重点サンプリング）の重み自体をクリップするというアプローチを採る。これにより、すべてのトークンに対して勾配が伝播することを許容しつつ、重みを制御することで最適化の分散を抑制する。

FP32精度の重要性 また、M1の開発過程において、混合精度学習（Mixed Precision）におけるFP32の数値精度の問題が特定された。LLMのHead（予測層）をFP32に戻すことで、学習時と推論時の整合性が大幅に向上し、報酬の安定的な上昇が確認されたという。これは、大規模モデルの強化学習における「悪魔は細部に宿る」好例である。

エージェントRLへの適応 M2世代では、ツール使用（Tool Use）を伴うマルチターン対話が前提となるため、外部環境からのノイズや異常な軌跡（Trajectories）が発生しやすい。これに対処するため、Multiple Importance Sampling (MIS) の導入や、統計的に異常な軌跡をフィルタリングするPPOベースのフィルタリング技術が組み込まれている。

新たなベンチマーク：VIBE, SWE-Review, OctoCodingBench

M2.1のリリースに伴い、包括的な評価を行うための3つの新しいベンチマークも公開された。

  1. VIBE (Visual & Interactive Benchmark for Execution): AppDevを対象としたベンチマーク。従来のLLM-as-a-judge（静的なスクリーンショット評価など）とは異なり、Agent-as-a-Verifierアプローチを採用。実行（コンパイル可否）、対話（機能的正しさ）、視覚（美的基準）の3次元で評価を行う。

  2. SWE-Review: 開発パイプラインにおけるコードレビュー能力を測定する。再現率（Recall）と幻覚率（Hallucination Rate）を考慮したメトリクスにより、多言語でのレビュー品質を評価する。

  3. OctoCodingBench: エージェント設定における指示追従（Instruction Following）能力を評価する。ユーザープロンプトだけでなく、システムリマインダー、ファイル内容、ツールスキーマなど、多様な情報源からの指示を正しく処理できるかを問う。

まとめ

MiniMax M2.1は、単なるパラメータ数の競争ではなく、検証可能なデータ合成パイプライン（SWE Scaling）、専門家の知見を組み込んだ評価系（AppDev）、そして計算精度レベルまで掘り下げた強化学習アルゴリズム（CISPO）の融合によって生まれた、実用的なエージェントモデルである。

特に、GitHubからの実データを用いたDocker環境の自動構築や、CISPOにおけるFP32精度の重要性といった知見は、今後のオープンソースモデル開発において重要な指針となるだろう。M2.1は、コード生成やエージェントタスクにおいて、プロプライエタリモデルに肉薄する性能をオープンなエコシステムにもたらしている。