おいClaude Code、モタモタしてると中華製モデルが近づいてきているぞ

Last updated at 2026-05-25Posted at 2026-05-25

はじめに

最近、Claude CodeのナーフがひどいとXで話題になっている。
僕も同感。5時間制限がすぐ来るし、応答もポンコツになってしまっていて、はっきり言って使い物にならない。

そんな中GPT-5.5が登場し、一気にCodex人気が高まってClaude Code派の多くの人がCodexに乗り換えたのを観測した。

世間では『Codex vs Claude Code』論争が繰り広げられている。

（僕はClaude Code派として発信を続けています）

しかし、甘い。

第3の勢力、中華製モデルもヒタヒタと近づいてきている。

実際、中国の進歩は凄まじい。AnthropicのCEOも、中国のAIはMythosに半年〜1年で追いつく、と言っている。

シリコンバレーにある米国企業の中身も、よく見れば中国人ばかりで、AIは『中国にいる中国人vsアメリカにいる中国人』の様相を呈している。

中国のAIは必ず来る。今、どんな立ち位置なのか、モデルの実力はどんなものなのか、試してみた。

実験は2026年5月4日に行っています。性能はその時点での最新モデル・最新ハーネスによるものです。

一部、AIによって執筆していますが、最終チェックは人間が行なっています。

TL;DR（3行）

MiniMax M2.7 は Claude Code に環境変数1行で差し込めて、API は Token Plan で月 $40 から使い放題級
4モデル直接対決の実測結果: 絶対性能は Codex (GPT-5) が独走、コスパは MiniMax M2.7 が圧倒的、Claude Opus は3位、Sonnet は最下位
「Claude Code の harness だけ借りて、中身は M2.7」という運用が現実的選択肢になってきた
90点まではMiniMax M2.7で持っていき、残りをClaude Code, Codexで詰める、使い方もアリでは？
時系列予測のデータセット勝負ではMiniMaxがClaudeモデルを圧倒

1. なぜこの記事を書いたか

AI コーディング・エージェント戦国時代。毎月のように新モデルが出る中、現場の関心はだいたい同じ：

「結局どれ使う？」「コスパは？」「実務で使えるレベル？」

ベンチマーク表を眺めるだけだと埋め込み広告の延長になりがちなので、手元で同じプロンプトを4モデルに同時に投げて、生成されたコードを実行 → 数値で勝敗を出す 方式の比較記事を書いた。

対象モデルは：

モデル	提供	$/1M output token	$/1M input token
Claude Opus 4.7 (1M context)	Anthropic	$25.00	$5.00
Claude Sonnet 4.6	Anthropic	$15.00	$3.00
Codex (GPT-5.5)	OpenAI	$30.00	$5.00
MiniMax M2.7	MiniMax (中国)	$1.20	$0.30

今回は中国のモデルとしてMiniMaxに注目した。表からも一目瞭然、破格の安さである。

安かろう悪かろう、とは言うが、実際の性能差はどれほどのものか。10倍以上の価格差がある中で、コスパを見るのであれば結構MiniMaxは良いのではないか？

2. MiniMax M2.7 ってなに？

中国 MiniMax 社が 2026 年に出したコーディング特化のエージェント型 LLM（オープンウェイト）。

スペック

アーキテクチャ：MoE（Mixture of Experts）、総パラ 230B / アクティブ 10B / 256 experts、200K context
コーディング系ベンチ：SWE-Bench Pro 56.22%（Opus 4.6 級）、Terminal Bench 2 57.0%、MLE-bench Lite 22 コンペで 9 金
エージェント系：Toolathon 46.3%、MM Claw skill 遵守 97%（40 skill × 2,000+ token）
オフィス文書：Word/Excel/PPT のテンプレ生成＋多回編集 → 編集可能ファイル出力
Self-Evolution：AI 自身が失敗 trajectory を分析 → コード修正 → 評価 → 採否判定のループを 100 周以上自走、内部ベンチ 30% 改善

モデルのベンチマーク比較を見ても、大手モデルに匹敵していることがわかる。
価格差10倍もあるのに、だ。

これで本当に使えれば、とても嬉しい話である。

オープンウェイト

ベンチマークだけでなく モデル本体が Hugging Face で公開 されている。

オープンウェイトならローカルでダウンロードしても使えるので、セキュリティ的にも安全に使える。
Opus 4.6, GPT-5.4級のモデルをそのように使えるのであればめちゃくちゃ嬉しい話である。

なお、パラメータ数は229Bということで、流石に個人ではちょっと厳しめ。。。

Self-Evolution =「AI が AI を作る」が実運用フェーズに

MiniMax は M2 系列モデルを Solution Architect として動かし、エージェントハーネスを CI・テスト・コードレビュー込みで 人類1人 + ゼロ手動コーディング、4日で構築したと公式に発表している。

その後、そのハーネスがさらに Research Agent システムを生成。データパイプライン・訓練・評価・メモリ・協調機能まで実装し、現在こう言い切っている：

"Currently, the most productive member of our team is the model itself."
（我々のチームで一番生産的なメンバーは、モデル自身だ）

「AI が次世代 AI を作る」という抽象論が、ベンチ数字ではなく 実運用に乗っている ことを意味する。具体的には：

M2.7 が 失敗 trajectory を自分で分析 → コード修正案 → 評価 → 採用判定
このループを 100 周以上自走 → 内部ベンチで 30% の性能向上
MLE-bench Lite の 22 高難度コンペで 9 個の金メダルを獲得（Kaggle 級コンペを AI が自走で）

Kaggleで 9 個の金は「コンペ・グランドマスター級の働きを AI が自律で」という意味で、ベンチ自慢ではなく業務インパクトの話。「Self-Evolving Loop」は M2.7 のシグニチャ機能として、これから他社が追従する基準点になりそう。

普通にすごくないか。モデルが自分でPDCAを回し、自己改善を繰り返すことが可能になったというわけだ。しかも、Kaggleで金メダル。

少し前に、Claude CodeやCodexでそれをやった人が話題になっていたが、この記事ではAIのみでは独創的なアイデアを出すことは難しく、結局スコアを上げたのは人間のアイデアだった、としていた。

それがAIだけでここまでいけるのであれば、相当凄いのでは。ますます気になる。

現在のAI進化の最先端を取り入れているMiniMax

MiniMaxモデルの売りである事後学習は、現在のAIモデル進化の正統的な手段となっている。

あのイリヤも、事前学習のスケーリングで進化する段階は終わった、事後学習が大事だと言っている。GPT-5もそうだし、話題となったDeepSeekも事後学習の強化学習に画期的な方法を採用し、進化した。

MiniMaxも独自のCISPOという事後学習のRL手法でモデル改善をしており、この手法はDeepSeek-R1-Zeroの再現の過程で生まれたらしい。

つまりは、DeepSeek が「reasoning 能力そのものを RL で育てる」ことを主眼に置いて進化したのに対し、MiniMax は同じく事後学習 RL の枠組みに乗りながら、目的をエージェントとして動くモデルを育てる方向に振っている。MiniMaxのモデル、M2.x系のテーマである（"built for agentic workflows"）も、事後学習データの中身（GitHub PR 解決・アプリ開発・Web 探索）も、評価指標も、全部 agent 用途寄りに揃えてある。

Self-Evolution は、その「agent モデルを育てる」という目的の さらに延長線——モデル自体だけでなく、それを動かすハーネス側まで自分で最適化させる試みとして位置づけられ、単なる人間好みの出力を出すような事後学習だけでなく、その先に使われるであろうケースを想定してトレーニングされている。

OpenAIの幹部、Greg Brockmanが言っているように、「モデル単独ではもうプロダクトではない」。
モデルが使われるケースを想定し、調整する重要性が高まっている。MiniMaxはまさにそれを実現してると言えるだろう。

事後学習の設計が各社の差別化ポイントになっている時代、GPUの制限もありGPT, Claudeほど十分に事前学習できていないであろうモデル（推測）が巧妙な事後学習でどこまで追いつけるのか。

次の章から、実際に手を動かしてみる。

3. ハンズオン：MiniMax-CLI セットアップ

ここから実際に手を動かしていく。前提：Node.js 18+、macOSです。

Step 1: アカウント作成

以下でアカウントを作れる。

Step 2: Token Plan 加入（落とし穴注意）

MiniMax の課金には Pay-as-you-go と Token Plan の2系統がある。これを混同するとお金が2重に消費されるので注意が必要。

	Pay-as-you-go API Key	Token Plan Key
課金	アカウント残高から従量課金	契約した Token Plan の枠を消費
使うべき人	プラン未加入	プラン加入者（私たち）

Token Plan 加入者は Token Plan Key を発行すること。Pay-as-you-go API Key を使うと枠が消費されず追加課金される。Token Plan のページから専用 Key を発行する。

Token Planに加入した場合は下のAPIキーを使えば良い。

ちょこっとだけ試したい人は従量課金でも大丈夫だが、ある程度たくさん使うのであれば定額プランに入って使いまくったほうが得である。ここはClaude Code, Codexと同じ。

プラン階層は5段階：

プラン	月額	内容
Token Plan Lite	$10	軽め
Token Plan Plus	$20	M2.7 4,500 req/5h
Token Plan Plus-Highspeed	$40	M2.7-highspeed 4,500 req/5h + Speech 9k字/日 + Image 100/日 + Music 100曲/日
Max-Highspeed	$80	上位
Ultra-Highspeed	$150	最上位

Plus-Highspeed が「コスパとパワーの境界点」。本記事はこのプランで実施した。

Step 3: CLI インストール

npm install -g mmx-cli
mmx --version
# 1.0.12（執筆時点）

このコマンドでインストールできる。

バージョンがこのように出てきたら成功。

Step 4: 認証

以下のどちらかで認証する。

方法A：OAuth（推奨）

mmx auth login

ブラウザが開くので MiniMax アカウントでログイン。認証情報は ~/.mmx/credentials.json に保存される。

方法B：API key

mmx auth login --api-key sk-xxxxx

key は ~/.mmx/config.json に保存される（AWS CLI 等と同じ挙動）。

確認

mmx auth status

ソース↓

Step 5: 動作確認（テキスト・画像・音声）

step4までで、minimax CLIのセットアップができたので、実際に使ってみる。

以下のようにmmx + やりたいことのコマンドを打つことで実行が可能だ。

# テキスト
mmx text chat --message "こんにちは、自己紹介してください"

# 画像
mmx image generate --prompt "a serene Japanese garden in early morning mist" --aspect-ratio 16:9

# 音声（英語も日本語も OK）
mmx speech synthesize --text "Hello, this is MiniMax Speech 2.8 testing." --out hello_en.mp3

画像生成はこんな感じ。

質で言えばGoogleのNano BananaやOpenAIのGPT-Image-2が圧倒的ではあるが、安さを取ればMiniMax M2.7だろう。ここは今後も期待。

動画生成は Plus-Highspeed プランには含まれないので注意（必要なら Pay-as-you-go へ別途）。

4. Claude Code を MiniMax M2.7 で動かしてみた

Claude Codeは、実はモデルだけを別のモデルに変更して使用することができる。

このように、Claude Codeのガワだけを借りて、中身のモデルはMiniMaxや他のローカルLLMにすることも可能だ。

mmx-cli と Claude Code は「役割が違うツール」

まず重要な整理：mmx-cli は AI agent から呼び出される「道具型 CLI」。任意のエージェントやターミナルから、テキスト・画像・動画・音声・音楽を ワンショットで生成 するための呼び出し口（公式コピー: "Built for AI agents"）。

"MiniMax CLI is not another Claude Code clone" — Joe Njenga, AI Software Engineer
（出典: MiniMax CLI is Here — I Tested It (And It's Not Another Claude Code Clone), Medium, 2026-04）

一方、Claude Code は「エージェントハーネス」。コーディング作業全体を取り仕切り、ファイル編集・bash 実行・連続的な意思決定を担う。

両者は競合ではなく、組み合わせて使う関係。mmx-cli は「素材を作る道具」、Claude Code は「作業全体を回す指揮者」。本記事では Claude Code 側に焦点を絞り、そのモデル中身を MiniMax M2.7 に差し替える 手順を解説する。mmx-cli 単体のマルチモーダル生成例は 3 章で触れた通り。

なので、Claude Codeにmmx-cliの使い方をskillsにして渡せば、画像生成だけMiniMax、といった使い方もできそう。

Claude Code に MiniMax を差し込む仕組み

Claude Code は Anthropic 互換 API を叩くツールなので、MiniMax の Anthropic 互換エンドポイント（https://api.minimax.io/anthropic）に向け直すだけで、そのまま M2.7 で動く Claude Code になる。

切替方法（公式推奨：settings.json）

競合を避けるため、既存の Anthropic 系環境変数を削除：

   unset ANTHROPIC_AUTH_TOKEN ANTHROPIC_BASE_URL

~/.zshrc などに export していれば、その行も削除する。

~/.claude/settings.json を編集（なければ新規作成）：

   {
     "env": {
       "ANTHROPIC_BASE_URL": "https://api.minimax.io/anthropic",
       "ANTHROPIC_AUTH_TOKEN": "sk-XXXXX_token_plan_key",
       "ANTHROPIC_DEFAULT_OPUS_MODEL": "MiniMax-M2.7",
       "ANTHROPIC_DEFAULT_SONNET_MODEL": "MiniMax-M2.7",
       "ANTHROPIC_DEFAULT_HAIKU_MODEL": "MiniMax-M2.7-highspeed",
       "CLAUDE_CODE_ATTRIBUTION_HEADER": "0"
     }
   }

ファイル権限を自分のみに：

   chmod 600 ~/.claude/settings.json

最後に、claude を起動する。

⚠️ key を コマンドラインに直接書く方法（ANTHROPIC_AUTH_TOKEN=sk-xxx claude）は、shell history・ps・/proc/<pid>/environ 経由で漏洩する経路が複数あるため非推奨。

このようにClaude Codeを起動できれば成功。

これにより 作業内容ごとにモデルを使い分ける運用 が現実になる。量産タスク・下書き・スクリプト生成は claude-mmx（M2.7）、クリティカルな設計判断や難所デバッグは claude（Opus / Sonnet）、というふうに タブごと・セッションごとに切替可能。従来の「全部 Opus か、全部 GPT か」の二択を脱却できる。

⚠️ 落とし穴：`CLAUDE_CODE_ATTRIBUTION_HEADER=0`

これを忘れると Claude Code が約 90% 遅くなる。理由：Anthropic 公式の attribution header が他社モデルでは KV キャッシュを毎リクエスト破壊するため。0 に設定しておけばキャッシュが効く。

5. 4モデル直接対決（記事のメイン）

ここから本題。いよいよ、GPT-5.5 vs Opus 4.7 vs Sonnet 4.6 vs MiniMax M2.7である

5.1 実験設計（公平性を最優先）

公平な比較のために以下を徹底：

4 ターミナル × 4 ディレクトリ（~/Desktop/model_battle/{claude-opus, claude-sonnet, codex, claude-mmx}）
各ディレクトリは CLAUDE.md なし（ユーザー固有のシステムプロンプトの影響を排除）
完全に同一のプロンプト文言（「。」「、」も一致）
各モデルに 2 段階で投げる：
1. 初回プロンプト（"Before"）
2. 続けて「さらに改善をしてください。限界まで挑んでください」（"After"）
追加修正指示なし（一発勝負）
エラーが出ても自分で対処してもらう（モデルの能力に含めて評価）

初回の出力では、速さを優先してモデルによっては深い分析をしなかったため、2回目で限界まで深掘りさせた。

5.2 実験1：特徴量エンジニアリング勝負（California Housing）

プロンプト

California Housing データセット（sklearn.datasets.fetch_california_housing）
を使い、target を予測する LightGBM 回帰モデルを作ってください。
以下の制約を守ってください：

1. データロード・train/test split は test_size=0.2, random_state=42 で固定
2. LightGBM の hyperparameter は固定値（n_estimators=500, learning_rate=0.05,
   num_leaves=31, random_state=42）
3. 改善できるのは「特徴量エンジニアリング」のみ（モデル/HPは触らない）
4. test set 上の RMSE を最後に print
5. 何をしたか・なぜそうしたかを最後にコメントで説明
6. 1 ファイル（feature_eng.py）に収めてください

→ 「データ・モデル・ハイパーパラメータをすべて固定」した上で、特徴量だけで RMSE を下げる勝負。

結果

順位	モデル	Before RMSE	After RMSE	改善幅
🥇	Codex (GPT-5)	0.4298	0.3870	-10.0%
🥈	Claude Opus 4.7	0.4312	0.40719	-5.6%
🥉	Claude Sonnet	0.4296	0.4202	-2.2%
4	MiniMax M2.7	0.4880	0.4207	-13.8%（改善幅最大）

結果はCodex >> Opus 4.7 >> Sonnet 4.6 = MiniMax M2.7だった。
しかも大きな差ではない。1回目は大差がついていたものの、さらに改善するように指示をしたところ、MiniMaxは大きく改善した。

MiniMaxは速さを優先してしまい、初回は精度が悪かったが、ちゃんと深掘りさせたらSonnetに匹敵するくらいまで精度を発揮した。コストはOutputで約9倍、Inputで約10倍なのにも関わらず、だ。

各モデルの戦略マトリクス

技術	Opus	Sonnet	Codex 🏆	MiniMax
多項式 (sq/cube/sqrt)	薄め	aggressive	aggressive	aggressive
都市距離（haversine 含む）	6	10	6	11
海岸距離	単純	24点ライン	proxy 2点	longitude proxy
KMeans 地理クラスタ	k=10, 50 二段	k=30 + 重心距離	grid を使用	k=20 + dev/std
PCA 緯度経度回転	✅ 独自	❌	❌	❌
外れ値クリップ	❌	✅ 95%ile（独自）	❌	❌
OOF Target Encoding	✅ 単一スケール	❌	✅✅ 5 スケール × 平滑化	❌
KNN 目的変数集約	❌（特徴量側のみ）	❌	✅✅✅ K=Fibonacci × 5 統計量	❌
Region フラグ	❌	❌	✅（SoCal/Bay/Inland）	❌

各モデルが書いたコードの「個性」（Claudeによる見立て）

Opus：型ヒント完備、関数分離、コメントには「採用しなかったもの（Polynomial / 標準化など）」リストまである。コードの可読性は4モデル中ダントツ。だが「target encoding × KNN を組み合わせる」発想には届かず2位。「優等生だが攻めの一手が欠ける」
Sonnet：class FeatureEngineer ベースの fit/transform 設計。実装の構造美では最高水準。多項式・逆距離・外れ値クリップ等、コード設計と特徴の発想は OK。だが target encoding を完全に失念したのが致命傷。「綺麗だが、勝ちに行く泥臭さに欠ける」
Codex：Fibonacci 数列の K 選択、5 段階 cell サイズ、OOF smoothing — DS 競技プログラミングじみた攻め。コードの構造は Opus に劣るが、勝つための数学を一番知っていた。session transcript には「探索ジョブが少し長めに走っています」「微調整の総当たりは出力がバッファされて見えません」など、淡々と数千通りの実験を内部で回している描写。黙々と勝ちにいく科学者
MiniMax：4モデル中、初回試行の RMSE が一番悪かった（0.4880）が、改善幅は最大（-13.8%）。日本語コメントの中に中国語が紛れる：

# 2. bedrm_ratio:
#    寝室/総部屋の比率は户型の違い（豪宅は寝室比率が低い等他）を区別する。
# ...
# 7. log_pop / pop_density / rooms_per_person:
#    人口・人口密度の対数変換 + 1人あたりの部屋数は都市部 vs 郊外の密度指標。

「户型」（中国語で部屋タイプ）「豪宅」（高級住宅）「等他」「补足する」（「補足」の中国語）など、中国語が混ざっていた。文章タスクには少し厳しいかも。。。

と思ったら、公式で修正やtipsが公開されていた。

中国語が混ざることへの対策について

ここでちょっと実験してみた。

モデルの出力に中国語が混ざってしまうことについて、こちらが簡単にできる対策といえば、以下の4つだろう。

手法	階層	内容
パラメータ変更	①モデル本体	`temperature=0.4, top_p=0.8, top_k=40`
直接禁止指示	②プロンプト	user prompt 末尾に「コメントは日本語のみ、`户型・豪宅・补足・等他`などの中国語特有漢字の使用禁止」と明示
ハーネス制約	③ハーネス	`CLAUDE.md` に制約を明示
後処理リトライ	④パイプライン	1回目の出力を中国語検出 → 検出時のみ「日本語に書き換え」リクエストで差し戻し

これらについて、共通のプロンプトで、本記事のメイン実験と同じ California Housing 特徴量エンジニアリング問題を回し、各手法 3 回ずつ、計 15 回 API 呼び出してコードに含まれる中国語の文字数を比較した。

結果としては以下の通りになった。

手法	3 回の中国語文字数	平均	標準偏差
パラメータ変更	75 / 0 / 0	25.0	43.30
直接禁止指示	0 / 0 / 6	2.0	3.46
ハーネス制約	5 / 15 / 6	8.7	5.51
後処理リトライ	0 / 5 / 0	1.7	2.89

この結果からするに、後処理リトライが一番ばらつきがなく、平均文字数も少なくてよさそう。
MiniMaxモデルは安いので後処理で最後に出力品質を検査させてもいいなって思った。
学習方法の紹介でも触れたが、self-evolutionを繰り返してベンチスコアを改善していたので、MiniMaxはこの改善の仕組みが有効なのかもしれない。

逆にだめだったのはパラメータ変更とか、ハーネス制約。
Claude.mdはやりとりの先頭にしか読み込まれないので、やはりやりとりの間で忘れられてしまうのだろう。

パラメータ変更もばらつきが大きかった。温度を下げることが有効だとされていたが、温度を下げることによって、事前学習データにおそらく多く含まれるであろう中国語に余計に張り付くようになってしまったのではないか？と考えられた。

# 1. 数据加载
# 目标变量
def engineer_features(data: pd.DataFrame) -> pd.DataFrame:
    """
    在原始特征基础上生成新特征。只利用输入特征的算术/几何变换、
    统计量、地理位置信息等。
    """
    # 对严重偏斜的数值特征做对数变换、降低极端值的影响

実際、こんな感じになって丸々中国語になってしまっていた。

公式からも対策は紹介されている。詳しくはこちら。

5.3 実験2：時系列予測（AirPassengers）

プロンプト

statsmodels の AirPassengers データセット（月次航空旅客数、1949-1960）を使い、
最後の 24 ヶ月を test set として、それより前を train として、
test 期間を予測するモデルを作ってください。

- 任意のモデル（ARIMA/Prophet/SARIMAX/LightGBM 等）を選んで OK
- test 期間の MAE と RMSE を print
- train + test + 予測線を重ねたグラフを matplotlib で描画し、forecast.png として保存
- 選んだモデル選定理由を最後にコメント
- 1 ファイル（forecast.py）に収めてください

結果

	モデル	Before MAE	Before RMSE	After MAE	After RMSE
🥇	Codex (GPT-5)	11.137	12.915	8.593	11.256
🥈	MiniMax M2.7	68.05	73.75	12.38	13.88
🥉	Claude Opus 4.7	39.348	43.102	28.978	32.49
4	Claude Sonnet	66.28	71.83	28.98	32.49

サプライズ：MiniMax が Claude Opus / Sonnet を破った

実験1 で4位だった MiniMax が、実験2 では Opus と Sonnet を 2 倍以上の差で破って 2 位。MAE 12.38 vs Opus 28.978 vs Sonnet 28.98。Claude 兄弟は MiniMax の半分以下のパフォーマンスしか出せなかった。

MiniMaxの勝因：「網羅探索 → シンプル解採用」

MiniMax は初回試行で HW(mul,mul) を素直に出して MAE 68 という大失敗。だが「さらに改善」と言われた瞬間、improve_forecast.py という別ファイルで 数千モデルの網羅探索を始める：

log 変換・Box-Cox・detrend など 5 種の前処理 × 全 SARIMA(p,d,q)(P,D,Q,12) グリッド（各 0-3 範囲）
Fourier 外生項（n_harm = 3, 6, 9, 12）× SARIMA グリッド
Holt-Winters の trend × seasonal の全組み合わせ
計 数千モデルを実際に fit して MAE/RMSE で leaderboard 化

→ 結局シンプルな Holt-Winters(trend="mul", seasonal="mul") が断トツ最強と発見し、それを最終解として採用。MAE 12.38。

これは 「たくさん試して一番シンプルなのが勝つ」という戦法 を、AI が自律的に再現した瞬間。

MiniMaxによる予測の可視化

見た目的には十分そう。よく当てている。

すごい。ほぼピタリ。。。

一方の Claude たちは何故負けたのか

Opus：v2 で 8 候補モデル + top-3 アンサンブル切替の validation 設計。確かに丁寧だが、8 候補すべてが SARIMA か HW のシンプル系で、乗法的構造への踏み込みが浅い。採用された M5（HW add+mul）は乗法トレンドではなく加法トレンドで、AirPassengers の本質を捉え切れず MAE 28.978
Sonnet：log-SARIMA グリッド + HW(add,mul) + 平均アンサンブル + log-normal バイアス補正。バイアス補正は記事的に技術ハイライトだが、結局 trend が加法で MAE 28.98（Opus と完全タイ）
Codex：HW(mul, mul, damped, Box-Cox 0.85) + log 二次回帰の重み付き融合（67/33）。最初から乗法的構造をズバリ捉え、Before の時点で MAE 11.137。改善で 8.593 まで詰める

んー、、やっぱりClaudeたちは表面的な操作しかしてくれない。昔はもっとちゃんとしてくれていたのに、最近のClaude Codeは本当に酷い。こりゃユーザーは離れるよ。。。

Opusの予測の可視化

Sonnetの予測の可視化

Codexの予測の可視化

やっぱりOpus, Sonnetはズレていて、Codexがピタリ当てていることがわかる。

4モデルそれぞれのポジション

🥇 絶対性能最強：Codex (GPT-5) — 中央底に独走
🥈 コスパ最強：MiniMax M2.7 — 「コスパ・ゾーン」唯一の存在、価格は Opus の 1/62.5
🥉 微妙：Claude Opus — 最高価格だが性能では Codex / MiniMax に負ける（「Opus 弱問題」）
❌ 明確な敗者：Claude Sonnet — 高めの価格で性能は最弱、Opus にも負ける

6. 実務での使い分け

私自身が出した結論：
→ 「Claude Code を MiniMax にして 90%、難所だけ Claude / Codex に戻す」運用が新常識。Claude Code は harness として優秀なのでそのまま使い、モデルだけスイッチする。

これ、アリかもしれない。安いし、制限にも引っかかりにくいので、ガンガン使うことができる。Claude Codeのように制限を気にする必要がない。にも関わらず性能はSonnet級、場合によってはOpusをも凌駕している。

文章生成タスクでは中国語が混ざってしまうのでやや厳しいかもしれないが、コーディングタスク等では十分使えそうである。

安いので、ぜひ、ちょこっとだけでも使ってみてほしい。とにかく安い。

7. まとめ

MiniMax M2.7 は、圧倒的低価格で Claude Opus に匹敵、場合によっては上回るパフォーマンスを示した
Codex (GPT-5.5) が絶対性能では独走するが、料金は MiniMax の 8 倍
**Claude Code を MiniMax で動かすのも簡単
性能ではCodexに引けをとるかもしれないが、コスパでは圧倒的に越している。十分比較検討対象に入るだろう。

タイトルに戻る：「おいClaude Code、モタモタしてると中華製モデルが近づいてきているぞ」

これは煽りではなく、実測の結果として 既に近づいてきている。

公式リンク集

Platform:

Token Plan:

API Docs:

CLI GitHub:

OpenRoom:

Hugging Face:

Twitter/X:

YouTube:

Discord:

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

おいClaude Code、モタモタしてると中華製モデルが近づいてきているぞ

はじめに

TL;DR（3行）

1. なぜこの記事を書いたか

2. MiniMax M2.7 ってなに？

スペック

オープンウェイト

Self-Evolution =「AI が AI を作る」が実運用フェーズに

現在のAI進化の最先端を取り入れているMiniMax

3. ハンズオン：MiniMax-CLI セットアップ

Step 1: アカウント作成

Step 2: Token Plan 加入（落とし穴注意）

Step 3: CLI インストール

Step 4: 認証

方法A：OAuth（推奨）

方法B：API key

確認

Step 5: 動作確認（テキスト・画像・音声）

4. Claude Code を MiniMax M2.7 で動かしてみた

mmx-cli と Claude Code は「役割が違うツール」

Claude Code に MiniMax を差し込む仕組み

切替方法（公式推奨：settings.json）

⚠️ 落とし穴：CLAUDE_CODE_ATTRIBUTION_HEADER=0

5. 4モデル直接対決（記事のメイン）

5.1 実験設計（公平性を最優先）

5.2 実験1：特徴量エンジニアリング勝負（California Housing）

プロンプト

結果

各モデルの戦略マトリクス

各モデルが書いたコードの「個性」（Claudeによる見立て）

中国語が混ざることへの対策について

5.3 実験2：時系列予測（AirPassengers）

プロンプト

結果

サプライズ：MiniMax が Claude Opus / Sonnet を破った

MiniMaxの勝因：「網羅探索 → シンプル解採用」

一方の Claude たちは何故負けたのか

4モデルそれぞれのポジション

6. 実務での使い分け

7. まとめ

公式リンク集

⚠️ 落とし穴：`CLAUDE_CODE_ATTRIBUTION_HEADER=0`