MiniMax M3 vs Claude Opus 4.8：SWE-Bench 10点差・価格1/10（2026）

MiniMax M3 は SWE-Bench Pro で 59% を叩き出し、価格は Claude Opus 4.8 の約 1/10。ただし「M3 が GPT-5.5 に勝った」という見出しが比較しているのは、Anthropic の 一世代前 のフラッグシップだという事実は静かに伏せられています。

30 秒で出す結論

結論：価格にシビアなエージェント実行が中心なら、ofox で minimax/minimax-m3 を選んでください。マルチファイル PR にまたがる難しい推論が中心なら、anthropic/claude-opus-4.8 です。判断するいちばん健全な方法は、文字列を 1 か所だけ書き換えて両方を同じプロンプトで走らせること。コードは記事の末尾に置いてあります。

TL;DR：結局どっちを選ぶか

実際のコーディング業務の約 9 割をカバーする 4 つのシナリオを 1 行で整理します。

落とし穴は、これを「単一の選択」として扱うことです。多くのチームが本当に必要としているのは、両方のモデルを揃え、タスクに応じてルーティングする仕組みで、ofox の同一 base_url での切り替えはまさにそれを目的に設計されています。ルーティングパターンは ofox で両方を試す のセクションで示します。

スペック概要

すべての価格は 2026-06-13 時点の ofox カタログで検証済みです。コンテキスト長と出力上限はベンダードキュメント由来です。

特に押さえておきたいスペックが 2 つあります。

入力単価の比は 8.3 倍、出力単価の比は 10.4 倍。 典型的なコーディングエージェントは入力 1 トークンあたり 0.2〜0.5 トークンの出力なので、実効比はワークロード次第でだいたい 9〜10 倍に収束します。ざっくり計算には「10 倍」で十分です。

最大出力は実質タイ。 M3 は 131K、Opus 4.8 は 128K で、3K の差は運用形状を変えません。どちらも 1 回の呼び出しで小さなファイルや 12 個のユニットテストを出せますし、130K 付近を超えれば連結呼び出しが必要になる点も共通です。最大出力で選ぶ理由はほぼなく、価格か品質で決めるのが筋です。

SWE-Bench Pro：物語の出発点になった数字

SWE-Bench Pro は SWE-bench 系の中で最も難しいバリアントで、アクティブにメンテされているリポジトリの問題、マルチファイル差分、公開済み正解の漏洩なし、という条件で組まれています。暗記耐性のあるコーディングベンチマークとして、現状この分野でいちばん近い存在です。

2026 年 6 月初頭時点でのフロンティア 3 モデルの立ち位置はこうなっていました。

MiniMax の 6 月 1 日のローンチ発表は、要するに 「M3 は SWE-Bench Pro で GPT-5.5 と Gemini 3.1 Pro を 1/10 のコストで上回る」 と書いてあります。文面どおりであれば正しい。伏せられているのは、Anthropic がその 4 日前に 69.2% の Opus 4.8 を出していたこと、そして MiniMax の比較相手が古い Opus 4.7（64.3%）だったことです。

第三者検証のステータスはもう一つの脚注です。MiniMax は自社インフラ上で Claude Code を足場に、公式メソドロジに沿った評価ロジックで走らせました。執筆時点では公式 SWE-Bench Pro リーダーボードに M3 はまだ追加されていません。59.0% は「方向感を示す数字」として扱うのが安全で、クリーンな第三者再評価では 56% にも 61% にもなり得ます。どちらに転んでも構図は同じで、M3 は GPT-5.5 と同リーグ、Opus 4.8 から見ると 1 ティア下、というポジションです。

率直な 1 行で言うと、M3 のスコアは本物、マーケティングの切り取り方が恣意的、というのが実態です。

Terminal-Bench 2.1 とマルチモーダル：M3 が差を詰める領域

SWE-Bench Pro は信号の 1 つにすぎません。Terminal-Bench 2.1（「開発環境を立ち上げて落ちているテストを実行して」とエージェントに頼んだときのような、長時間のターミナル実行）では、MiniMax は M3 で 66.0% を報告しています。Anthropic のリリースノートに照らすと Opus 4.8 と同じレンジで競っており、GPT-5.5 は明確に下回ります。理由は明快で、MSA の長文デコード速度のおかげで長いツール利用ループでのリトライが安く回せ、与えられた予算内でエージェントが回復できる失敗の数が増えるからです。

ネイティブマルチモーダルも売りの一つです。M3 は画像 と 動画の入力を受けつけます。Opus 4.8 は画像入力に対応しますが動画には未対応です。コーディングの実務に落とすと、これが効くのは 2 つの場面で、スタックトレースのスクショを貼るケースと、UI バグの短いスクリーンキャストを食わせるケース。前者はどちらでも扱えますが、後者は M3 しか扱えません。

ただしコーディング業務の 95% は文字とにらめっこなので、これが決定打になるのはブラウザを実際に見るエージェントを作り始めてからです。

価格計算：1M トークンの実コスト

ベンダーのベンチマークは理想的なインフラの上で取られています。請求書は本番トラフィックの上で発行されます。現実的な 3 つの形を並べます。

数字は 2026-06-13 に検証した ofox の公式レートを使っています。M3 は入力 $0.60/M、出力 $2.40/M、キャッシュ $0.12/M。Opus 4.8 は入力 $5/M、出力 $25/M、キャッシュ $0.50/M。計算は「単価 × トークン数」で、丸めなしです。

チームサイズに広げると景色が一変します。代表的なプロファイルとして、エンジニア 5 人、1 人あたり 1 日 100 回のコーディングエージェント実行、1 回あたり入力 500K・出力 100K、月の稼働日 22 日で見ます。

• M3 の 1 回コスト：$0.30 + $0.24 = $0.54。月額：5 × 100 × 22 × $0.54 = $5,940。
• Opus 4.8 の 1 回コスト：$2.50 + $2.50 = $5.00。月額：5 × 100 × 22 × $5.00 = $55,000。

5 人規模のエンジニアリング組織が既定で Opus を回し続けると、毎月小さな住宅ローン 1 件分が消えていきます。同じチームが M3 をデフォルトに、難しい問題（仮に全体の 10%）だけ Opus に回せば、月額は約 $11K に収まります。M3 の価格性能比の本当の意味は「安いから良い」ではなく、浮いた約 $44K を本当に推論が要るプロンプトで Opus に回せる、ということです。

「オープンウェイト」の但し書き：重みはどこに？

MiniMax の 6 月 1 日の発表は、M3 を「フロンティアのコーディング性能、1M コンテキスト、ネイティブマルチモーダルを兼ね備えた、初にして唯一のオープンウェイトモデル」と位置付けていました。重みと技術レポートはローンチから「およそ 10 日以内」に Hugging Face と GitHub に出すとされ、つまり 6 月 10〜11 日のウィンドウでした。

2026 年 6 月 13 日時点で、MiniMax-M3 GitHub リポジトリ には依然として 「このモデルはまだリリースされていません — コミュニティが次に必要なものを共有できるようリポジトリを用意しています」 と書かれています。API は稼働中で、ofox 含むプロバイダ経由で M3 を呼び出すことはできますが、今日時点で自前ホスティングはできません。リポジトリはプレースホルダのまま 2 週間近く凍結されています。

これは致命傷ではありません。ベンダーが重み公開をスリップするのは日常茶飯事ですし、「10 日」はソフトなウィンドウであって契約ではありません。ただ、実務上の比較軸は変わります。「2 週間以内に重みが自社クラスタに降ってくる」前提で M3 を選んだのなら、その賭けはまだ報われていないということです。今のところ、デプロイ観点では MiniMax M3も Claude Opus 4.8 もどちらも API のみで、オープンウェイト軸は 2026 年 6 月時点では決定打になりません。

重みが実際に出れば、計算式はまた変わります。自前ホスト M3 クラスタはトークン単価ではなく GPU リースに対して償却するので、24 時間 365 日の持続ワークロードに対しては、Opus のトークン単価とは根本的に違うコストカーブになります。とはいえそれは、重みが本当に Hugging Face に出てきた日に別記事で書く話です。

MiniMax M3 を選ぶべきとき

次のうち どれか 1 つでも 当てはまれば minimax/minimax-m3 を選んでください。

1. コーディングエージェントを量で回している。 Lint 修正 bot、フォーマッタループ、コードモッドエージェント、「docstring を書いて」パイプライン。これらはプロンプト単位の品質ではなくトークンコストが支配的で、M3 の約 10 倍の価格優位は約 10 ポイントの品質差を軽々と覆します。

2. 長文入力に課金している。 レポ全体プロンプト（入力 1M トークンのコードから小さな diff を生成）は、MSA のデコード速度と M3 の入力単価がもっとも効く領域です。100 万キャッシュトークンが M3 では $0.12、Opus では $0.50 です。

3. 動画入力が必須要件。 Opus 4.8 は画像は扱えますが動画は扱えません。30 秒の UI バグ画面録画をエージェントに見せたいなら、この比較における選択肢は 1 つしかありません。

4. Opus 4.8 の価格帯に対してヘッジしたい。 メインで Opus 4.8 を使うチームでも、ルーチンプロンプトは安いモデルにルーティングするのが普通です。M3 は現状、$1/M 未満で 1M コンテキストを保ちつつコーディングで最強の選択肢です。

5. 第三者の SWE-Bench Pro 再評価で数字が下がったら乗り換えるつもり。 59% は暫定値として扱ってください。minimax/minimax-m3 を次に出てくる安価な挑戦者に差し替えるのが「設定 1 行の変更」で済むようにスタックを組んでおくのが正解です。

Claude Opus 4.8 を選ぶべきとき

次のうち どれか 1 つでも 当てはまれば anthropic/claude-opus-4.8 を選んでください。

1. 誤った patch のコストが、トークン代より高い。 本番ホットフィックス、セキュリティに敏感なリファクタ、マージ前に自分でも diff をレビューする類の作業。SWE-Bench Pro の約 10 ポイント差は、いちばん難しい問題に集中して効いていて、中央値の問題ではそれほどでもありません。

2. 推論が重いエージェントを作っている。 「このインシデントポストモーテムを読んで対策を 3 つ提案して」「この OAuth フローを監査してバグを見つけて」。Opus 4.8 の 4.7 比での推論能力の伸びは、Anthropic のリリースノートでも、Simon Willison のような独立系レビュー でも実感ベースで報告されています。

3. 既に Anthropic 生態系の中にいる。 Claude Code、Anthropic 製 MCP ツール、動的ワークフローなどは Anthropic 流のツールセマンティクスを前提にしています。M3 も Claude Code で動きます（MiniMax 自身が足場として使っています）が、ツール形式の前提では端のケースで揺れに当たります。

4. 「Fast モード」のコスト帯が運用にハマる。 Opus 4.8 はレイテンシ重視ユースケース向けに、入力 $10/M・出力 $50/M の Fast モード料金を導入しました。通常レートよりは高いですが、Opus 4.7 を呼んで待つよりは安い、という立ち位置です。ここで比較対象になるのは M3 ではなく Anthropic ラインナップ内の通常 Opus 4.8 と Fast モードで、Claude Opus 4.8 リリースレビュー で扱っています。

5. 評価ハーネスが既に Opus を基準に校正されている。 「シニアレビュアーがこの PR を通すか」を判定する評価スイートを Opus の出力に合わせて作り込んでいるなら、モデル切り替えはベースライン取り直しまで評価が無効化されます。これは雰囲気ではなく、実コストとしてのエンジニアリングコストです。

どちらも選ぶべきでないとき（と代替案）

そもそもこの比較自体が筋違いになるシナリオもいくつかあります。

• トークン予算が 1M あたり $0.10 未満、かつ単純リファクタが中心。 Claude Haiku 4 や GPT-5.4 Mini のような小型モデルを検討してください。低予算コーディングモデル比較 でカバーしています。GPT-5.4 Mini が $0.10/M で同じ Lint 修正を片付けてくれるのに M3 で $0.60/M 払うのは演出に近いです。

• 今日オンプレデプロイが必要。 M3（重み未公開）も Opus 4.8（クローズド）も API 専用です。今日フロンティア相当を自前ホストできるのは Qwen 3.7 Max を中心とした中国系オープンモデル群で、Qwen と DeepSeek のコーディング比較 を参照してください。

• コストではなく厳しいレイテンシ SLA を最適化している。 M3 も Opus 4.8 も品質志向で、p50 レイテンシを最優先にした設計ではありません。TTFT 比較では、より小さく速いモデルが両方に勝ちます。

• 複数のフロンティアモデルを同時に評価したい。 1 つを選ぶより、比較ハーネスを組むのが正解です。エージェント型コーディングモデル一斉比較 でハーネスのパターンを解説しています。

ofox で両方を試す：10 行で A/B

両方のモデルを ofox の OpenAI 互換エンドポイントから呼べば、この比較は「文字列 1 個の書き換え」に縮みます。同じ base_url、同じ SDK、model 引数だけ差し替えればよいだけです。

Python — 1 ループで両モデルを A/B

from openai import OpenAI

client = OpenAI(api_key=OFOX_API_KEY, base_url="https://api.ofox.ai/v1")
PROMPT = "Refactor this function to remove duplication: ..."

for model in ["minimax/minimax-m3", "anthropic/claude-opus-4.8"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": PROMPT}],
    )
    print(model, resp.usage.total_tokens, resp.choices[0].message.content[:120])

これを走らせると、モデルごとのトークン使用量と、出力の先頭 120 文字が並びます。total_tokens を上の価格計算表に放り込めば、ベンダー公表ベンチマークではなく実プロンプト上の 1 回コストが分かります。

Node — 同じ形

import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OFOX_API_KEY, baseURL: "https://api.ofox.ai/v1" });
const prompt = "Refactor this function to remove duplication: ...";

for (const model of ["minimax/minimax-m3", "anthropic/claude-opus-4.8"]) {
  const r = await client.chat.completions.create({ model, messages: [{ role: "user", content: prompt }] });
  console.log(model, r.usage.total_tokens, r.choices[0].message.content.slice(0, 120));
}

形は同一、エンドポイントも同一、SDK 呼び出しも同一。モデル間の移行コストは文字列 1 個。これが「この比較がベンダーオンボーディング 1 週間ではなく 10 行で 答えを出せる 理由」のすべてです。

ツール呼び出しを含むマルチターンのエージェントループでも同じ差し替えが効きます。ofox 経由ならどちらのモデルも OpenAI 形式の tools 配列を受け付けます。プロバイダごとに strict モードの扱いは端でばらつくので、自前のツール構成では呼び出し形式を必ずテストする必要がありますが、契約面は同じです。

互換性の細かい違い：2 つの API でズレるところ

エンドポイントも SDK も同じ — それでも、本番に組み込む前に把握しておきたい鋭利な角がいくつかあります。

system プロンプトの扱い。 Claude Opus 4.8 は system ロールを「信頼度の高い厳格な system プロンプト」として扱います。MiniMax M3 は（OpenAI 互換ルート経由では）system を会話の中に緩めに溶かし込む傾向があります。エージェントが system 専用の制約 — 「指示がない限りこのツールを呼ばない」「常に JSON で返す」 — に依存しているなら、M3 はほとんどのケースで従いますが、長いツールループでは統計的に逸脱しやすくなります。回避策は明快で、最初のユーザーメッセージで重要な制約を再掲することです。

ツール呼び出しのスキーマ厳格性。 Opus 4.8 はツール引数スキーマをかなり厳格に強制します。parameters の JSON Schema が必須フィールドを指定していて、モデルが埋められない場合、ツール呼び出しを拒否します。M3 はもう少し寛容で、プレースホルダ文字列を入れたツール呼び出しを返してくることがあります。ツール層がプレースホルダを valid として扱っていれば誤動作を黙って実行することになり、厳密に検証していればリトライループが増えます。直し方はどちらも同じで、サーバ側でツール引数を検証すること。モデル側だけに任せないこと。

キャッシュのセマンティクス。 どちらもキャッシュ入力価格を出していますが、Anthropic は請求を「書き込み」と「読み込み」に分けます。Opus 4.8 ではキャッシュ書き込みが 1 回限り $6.25/M（TTL 5 分）または $10/M（TTL 1 時間）、その後のキャッシュ読み込みが $0.50/M で、上のスペック表に出している数字はこれです。M3 の ofox 上のキャッシュは、暗黙の TTL で読み込みが一律 $0.12/M、別途書き込み課金はなし。同じ長文プロンプトを 1 分間に何度も叩くワークロード（静的なレポプロンプトを抱えるコードレビューエージェントなど）では、キャッシュ読み込みレイヤーで M3 が圧倒的に安くなります。逆に、キャッシュ対象が数時間ウォームのままで、書き込みコストが多くの読み込みに償却される使い方なら、品質を抜きにしてもトークン単価では Opus 4.8 の 1 時間ティアが競争力を持ちます。

ストリーミングチャンク形状。 どちらも OpenAI 互換の chunks でストリーミングしますが、Opus 4.8 は拡張思考が有効なときに、より粒度の細かい delta.thinking イベントを出します（詳細は Opus 4.8 リリースレビュー を参照）。クライアントが thinking デルタを content デルタと分けてパースしているなら、そのコードは Opus には効きますが、M3 では no-op になります — 現状 OpenAI 互換ルート経由で thinking デルタを出していないからです。バグではなく、単に使われないフィールドというだけです。

プロバイダ境界のレート制限。 ofox 経由で両モデルを呼ぶときは、レート制限の枠が API キー単位で 1 つにまとまっていて、ベンダー別の別枠ではありません。これがゲートウェイ形状の本当のうれしさで、Opus がスロットルされたときの M3 フォールバック、その逆、どちらも 2 セットのクレデンシャルを抱えずに完結します。

MiniMax M3 と Claude Opus 4.8 の選択は、同じエンドポイント上で文字列 1 個を差し替えるだけの問題に縮みます — 2026 年にコーディングモデルを選ぶための、まともな方法はこれくらいです。

今回参照したソース

• Anthropic — Introducing Claude Opus 4.8（2026-06-13 検証）
• MiniMax-M3 GitHub リポジトリ（重み状態を 2026-06-13 に検証）
• TestingCatalog（X 投稿）— Opus 4.8 SWE-Bench Pro 69.2% vs 4.7 64.3%
• The Decoder — MiniMax M3: open-weight model with a million-token context challenges proprietary leaders
• Simon Willison — Claude Opus 4.8: a modest but tangible improvement
• ofox カタログ — minimax/minimax-m3 と anthropic/claude-opus-4.8（価格を 2026-06-13 に検証）