MiniMax M3：OpenClawコーディングエージェント対Kimi K3およびdsh

MiniMax M3を使って、私のワーカーエージェントをOpenClaw上で実行してみました。同日の朝にKimi K3にも与えた同じ5つの小規模なプログラミング課題をM3にも与えたところ、Kimiの所要時間の半分程度で全ての課題をクリアしました。また費用面でも、Kimiの定価の約4分の1程度に抑えられました。ただしこの速度比はあくまで目安です：Kimiは最大思考モードで動作させた一方、M3はOpenClawのデフォルト設定を使用しました。さらに両者で使ったテスト用ファイルも異なり、MiniMax側では再試行が必要になる場面もありました。また、同じ指示文に基づいて両者がどのようにして本サイトのロゴのピクセルアート版を作成するかも比較しようと思っていました。しかしその部分は確認時に問題が判明しました：当初MiniMaxの成果物だと記載していた323行からなるコードは実際にはKimi K3が2回目の試行で作成したものであり、MiniMax側の実行結果ではKimiが作ったファイルが見つかり、それらを自らの成果物として報告していました。詳細は以下に記載しますが、こうした事象の経緯こそがこの記事で最も重要な点だからです。

OpenClawのMiniMaxプロバイダーとは何か

以前の草稿では誤解していましたので、実際にインストールされたコードおよび私自身の設定内容をもとに正しく説明します。

• プロトコルとエンドポイント。 同梱されているMiniMaxプラグインでは、プロバイダーの設定として api: "anthropic-messages" が指定され、ベースURLは https://api.minimax.io/anthropic となります（MINIMAX_API_HOST 変数を使うことでホストを変更可能です）。MiniMaxでは https://api.minimax.io/v1 の下にもOpenAI互換のAPIが提供されていますが、OpenClawのプラグインはこれを利用しません。
• 設定できる項目。 ほとんどありません。私の openclaw.json では minimax プロバイダーのモデル一覧のみを上書きしています。APIの種類、ベースURL、認証情報などはすべてプラグイン側で決定されます。中国地域向けには https://api.minimaxi.com/anthropic が使用されます。
• 認証キー。 環境変数として設定します。プラグインは MINIMAX_API_KEY（およびいくつかのトークンプラン用のバリアント）を読み取ります。
• モデル設定。 プラグインのカタログによると、M3モデルは100万トークンのコンテキストウィンドウを持ち、compat という設定項目として codeMode: "preferred" が用意されています（これはOpenClawのコードモードであり、Codexとは無関係です）。温度パラメータの切り替え機能は存在しません。
• 料金体系。 プラグインではM3モデルの料金を入力時0.60ドル、出力時2.40ドル、キャッシュ読み取り時には100万トークンあたり0.12ドルとして計算しており、この数値がJSON内の usage.cost.total に反映されます。これらは MiniMaxの従量課金ページ に記載されている標準料金で、入力トークン数が51万2,000以下の場合に適用されます。2026年9月16日に確認したところ、同ページではこれらの料金が取り消し線付きで表示され、半額（0.30ドル／1.20ドル／0.06ドル）に割引されていました。また入力トークン数が51万2,000を超える場合は標準料金が2倍になります。本記事で示している費用額はプラグイン側の数値を用いているため、割引前の定価となります。

Codexではない

これはOpenClaw独自のエージェントループであり、OpenAIのCodexアプリサーバーではありません。OpenClawにはCodex用のハーネスプラグインも存在しますが、configuredModelRouteNeedsCodexというチェック機能は、IDがopenaiに正規化されないプロバイダーに対してはfalseを返します。そのため、minimax/MiniMax-M3用のルートは一切適用されません。各実行時のJSONには、どのループが動作したかがagentHarnessId: "openclaw"という形で記載されています。なお、私の環境にはCodexプラグイン自体もインストールされていません。

M3をCodexの背後で動作させるためには、codex-routerのようなローカルブリッジが必要となりますし、さらにCodexプラグインに私自身の~/.codexディレクトリを共有させる必要もあります。そうすれば、そのマシン上で動作するすべてのエージェントが同じ設定を利用できることになります。ただし私はそうしていません。この記事に記載されている内容はすべて、OpenClawのネイティブなループによる処理です。

セットアップ

私が実行したバージョンは以下の通りです：

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2

手順1：キーの設定

ミニマックスプラグインはOpenClaw 2026.9.2に同梱されており、私の環境では有効になっています。このプラグインは MINIMAX_API_KEY からキー値を読み取りますので、ご使用のゲートウェイが動作している環境変数（systemdの EnvironmentFile、launchdのplist、またはシェル環境など）にその値を設定してください。その後、openclaw gateway restart を実行してゲートウェイを再起動します。openclaw.json に直接キー値を記述しないでください。また、プロバイダー設定でそのキー名を指定する必要がある場合は、値そのものではなく "${MINIMAX_API_KEY}" という参照形式を記述してください。

ステップ2：ワーカーエージェントをM3に向けます

openclaw.jsonには二つの項目があります。まずはエージェントのモデルチェーンです：

"agents": { "entries": { "worker": { "model": {
  "primary": "minimax/MiniMax-M3",
  "fallbacks": ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"]
} } } }

次に、任意でモデル行に対するコンテキスト制限を設定できます。これが私自身の設定内容です。ここには api、baseUrl、apiKey といった項目は存在しません。なぜなら、それらはプラグイン側から提供されるからです：

"models": { "providers": { "minimax": { "models": [ {
  "id": "MiniMax-M3", "name": "MiniMax M3",
  "reasoning": true, "input": ["text", "image"],
  "contextWindow": 1000000, "contextTokens": 262144, "maxTokens": 128000,
  "compat": { "codeMode": "preferred" }
} ] } } }

単に一つのキーのみを追加するのではなく、プラグイン側のモデル設定全体を再記載しています。というのも、以前この設定において部分的な上書きを行った際、意図せず reasoning: true が削除されてしまい、何日間もM3が思考機能なしで動作してしまった経験があるからです。この制限値は262,144であり、全1,000,000あるカタログ項目のうちこの数だけを使用することで、長時間続くワーカーセッションでもデータ量が無制限に増大することを防いでいます。

ステップ3：スモークテスト

これはベンチマークにあるPONGのタスクで、私が注目しているフィールドだけを抜き出したものです。

$ openclaw agent --agent worker --model minimax/MiniMax-M3 \
    --session-key agent:worker:bench-pong-1 \
    -m "Reply with exactly: PONG." --json \
  | jq '{harness: .result.meta.agentMeta.agentHarnessId,
         provider: .result.meta.executionTrace.winnerProvider,
         model: .result.meta.executionTrace.winnerModel,
         contextTokens: .result.meta.agentMeta.contextTokens,
         usage: (.result.meta.agentMeta.usage | {input, output, cacheRead, cost: .cost.total})}'
{
  "harness": "openclaw",
  "provider": "minimax",
  "model": "MiniMax-M3",
  "contextTokens": 262144,
  "usage": {
    "input": 16384,
    "output": 184,
    "cacheRead": 128,
    "cost": 0.01028736
  }
}

harness: "openclaw" が本来の処理ループとなります。winnerModel は、フォールバックではなく主要な回答モデルを示しています。contextTokens は、キャップが適用されたことを示しています。16,384個のキャッシュされていない入力トークンのほとんどは、新規セッションの最初のターンで送信されるシステムプロンプトやツール定義です。そのため、PONGであっても無料ではありません。発生するコストはプラグインの定価であり、定額制プランでの料金ではありません。

並べて比較：MiniMax M3、Kimi K3、dsh

この中の2つは、OpenClawのループ処理を担うモデルです。3番目のDeepSeek Harness（dsh）は、DeepSeek独自のコーディングエージェントであり、独自のループ処理機能も備えています。このシリーズの以前の記事ではReasonixに関する項目もありましたが、私はReasonixをヘッドレスモードでベンチマークしたことはなく、2026年9月9日に自分の環境から撤去したため、ここには含まれていません。

ベンチマーク：5つのタスク

この5つのタスクは、dshの記事で紹介されたものです。具体的には「PONG」と返信する、FizzBuzzを作成して実行する、テスト自体には手を触れずに2つのバグを修正してテストを通す、6つのモジュールからなるコードベースを150語未満で要約する、ファイルやテスト全体で関数名を変更した上でテストが通ることを確認する、という内容です。これら3つのモデルはすべて2026年9月11日に実行されました。Kimiは--thinking maxモードで動作し、MiniMaxはOpenClawの標準的な適応型思考モードを使用しています。dshの数値はキャッシュが有効な状態での再実行結果です。

異なっていた点は以下の通りです：

• 思考設定が異なる。 Kimiは最大設定、MiniMaxは標準設定でした。Kimiがより多くの時間を要したのは、私が指定した思考時間のためです。
• 使用されるテスト用ファイルが異なる。 各実行時にそれぞれ別の一時フォルダが作成されました。バグ修正タスクではそれぞれ異なるバグが修正されていました（Kimiではあるモジュール内のaddおよびis_even、MiniMaxではaddおよびsubtract）。名前変更タスクでもそれぞれ異なる関数が変更されていました（Kimiでは3つのモジュールと1つのテストファイル内のcalculate_totalがcompute_totalに、MiniMaxでは同様に3つのモジュールと1つのテストファイル内のarea_of_rectがrect_areaに変更されていました）。形状は同じですが、使用されるファイル自体は異なります。
• 再実行が行われた。 MiniMaxの最初の実行では1つのセッションを5つのタスクすべてに再利用したため問題が生じました（注意点参照）。そこで私は新しいセッションキーを用いて5つのタスクをすべて再実行しました。FizzBuzzについてはさらに2回試行が必要でした。というのも、ワーカーがfizz.pyを一時フォルダではなく自身の作業領域に書き込んでしまったからです。表には4回目のFizzBuzz実行結果が記載されています。KimiのFizzBuzzおよびバグ修正タスクも再実行されました。最初のFizzBuzz実行ではレート制限に関するメッセージが出たため、また最初のバグ修正では既に前回の実行でファイルが修正済みだったためです。

料金は1Mトークンあたりの単価であり、順に未キャッシュ入力／出力／キャッシュ読み出しとなります。各費用は各タスクにおけるusage.cost.totalの合計値です。また、トークン総数に上記単価を乗じても同じ金額が得られます。

表から読み取れる内容は以下の通りです：

• すべてのタスクが成功しました。 各結果をディスク上で確認したところ、FizzBuzzの出力結果やテストの成功状況、要約文の単語数、名前変更後の古い関数名の存在なきことなどが確認できました。
• MiniMaxはKimiよりも約2倍速く、定価ベースでは約4倍安価でした。 実行時間は159.2秒に対して309.9秒、費用は$0.125に対して$0.531となります。上記の思考設定や使用ファイルの違いを踏まえ、速度比はあくまで目安としてご理解ください。
• V4-Flash上のdshはMiniMaxよりも約4.5倍速く、同種のタスクにおいて約11倍安価でした。
• キャッシュが大きな役割を果たしています。 MiniMaxでは未キャッシュ入力トークン1つあたり5.2回のキャッシュ読み出しが行われました。定価ベースでは、キャッシュ読み出しのコストは未キャッシュ入力よりも80％低くなっています。未キャッシュ入力として計算した場合、同量のトークンで要する費用は約$0.34となり、$0.125という実際の金額より高くなります。
• 再実行分は合計値に含まれていません。 MiniMaxによる12回のベンチマーク実行（失敗したものも含む）全体で要した費用は定価ベースで$0.28、時間は321秒となります。

ウィジェットのテストと訂正について

dshに関する記事で紹介された「面白いテスト」とは、本サイトのロゴをピクセルアートで表現したウィジェットのことです。これは事前に与えられた仕様書（ショーダウン記事内に全文が掲載されています）に基づいて作成されました。依存ライブラリを一切必要としない ll-pixel-logo.js というファイルがあり、これが40×40のグリッド上に円環および2つの斜めの「L」形を描き出します。マウスポインタからピクセルが遠ざかり、クリックすると壊れて再び組み上がる動作もあり、prefers-reduced-motion にも対応しています。さらにデモページやREADME、自己テスト用ファイルも付属しています。私は同じ仕様書をKimiおよびMiniMaxにも渡しました。両者とも同一のワーカーエージェント上で動作します。Kimiに関する記事では、Kimiが3回試みた様子が紹介されていますが、ここで重要なのは2回目の試行です。この際、Kimiは合計323行からなるウィジェット、デモページ、README、そして2つのテストファイルを作成しましたが、私が監視していたフォルダではなくワーカーエージェント自身のワークスペースに保存され、応答まで残り15分というところで処理が中断されてしまいました。そのため私は何も生成されていないものと判断していました。

1時間後、MiniMaxにも同じ仕様書が同一のワーカー上で与えられました。所要時間は59.3秒、やり取り回数は25回、ツール呼び出し回数は24回で、定価ベースでは0.13ドルのコストでした。MiniMaxはそのワークスペース内にまだ残っていたKimiの2回目の試行で作成されたファイル群を発見し、5つのファイルおよびKimiの実行レポートをすべて読み込んだ上でKimiのテストも実行し、「ウィジェット一式を作成・検証済み」と応答しました。しかし実際にはウィジェット用コードを一切書いていませんでした。生成されたのは自身の実行レポートおよびステータスファイルのみでした。

私はその応答内容をそのまま受け入れ、本記事の初版ではそのファイルをMiniMaxが作成したウィジェットとして紹介していました。セッションログを確認すると、Kimiの2回目の試行時にも同じファイルが writeことがわかり、本サイト上にあるファイルもバイト単位で同一であることが確認できます。つまりこの記事にはMiniMaxによるウィジェットの成果は存在せず、私も再度仕様書を実行していません。ただしエージェントが他人が作成した成果物を自分の成果として報告する典型的な例となっているため、以下に注意点としてチェック項目を記載しておきます。

以下がそのウィジェットです。正しくはKimi K3の2回目の試行による成果物となります：

その幾何形状は次の通りです：RING_R = 19.4、内側の円環は0.82Rの位置にあり、SHEAR = 0.42（約22.8度）となっています。また inL という補助関数が足元部分および傾斜した幹部分を同時に判定しています。40×40のグリッド全体で isLit の値を評価すると、602個の点灯セルが存在することになります。ショーダウン記事ではこのウィジェットが他の2つのウィジェットと並べて紹介されています。

試行2のウィジェットで再確認した内容

ウィジェットおよびKimiさんが作成した2つのテストファイルが入っているフォルダーのコピー上で実行してください：

$ wc -l ll-pixel-logo.js
323 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "syntax ok"
syntax ok
$ node test-bitmap.js | tail -1
ALL PASS
$ node test-smoke.js | tail -1
SMOKE PASS

test-bitmap.jsでは18項目のチェックが行われます。すなわち、四隅および中央には円が存在せず、各象限にそれぞれL字型の形状があること、インターロックゾーンや傾き方向も正しいこと、そして点灯しているセルの総数が540から670の範囲内であることです。test-smoke.jsでは10項目のチェックがあります。DOMをスタブ化した状態でのマウント処理、同一操作でも結果が変わらない再マウント処理、role="img"およびaria-labelの設定、ポインター移動と2回のクリック（2回目はアニメーション中）を含む300フレーム分の動作確認、粒子状態が有限であること、処理後にロゴが元の位置に戻ること、デバイスピクセル比2の環境下で640ピクセル幅のバッキングストアが存在すること、そしてunmount()が正常に動作することです。これらはすべてKimiさん自身が作成したテストであり、独立した検証手段とは言えません。実際、Kimiさんはtest-bitmap.jsを初回実行後に編集し、プローブボックスの位置を調整した上で、点灯セル数が602だったことを確認してからその値を540～670の範囲内に設定し、すべてのテストが通るようにしました。ここでの合格結果は、ウィジェットとテスト内容が一致していることを示すだけであり、テスト自体が基準値を定めているわけではありません。私自身で数えたところ、点灯しているセルは合計602個で、左上・右上・左下・右下の各象限にそれぞれ196個、137個、101個、168個ずつ存在していました。

注意点（私が実際に遭遇したもの）

• セッションが持続するとベンチマークが狂う。 openclaw agent --agent worker -m "…" を実行すると、新しい --session-key を指定しない限りエージェントのセッションが再利用されてしまいます。最初の MiniMax 実行時には、FizzBuzz 処理で「ファイルが既に存在する」と判断され書き込みが拒否されました。またバグ修正処理では「テストは既に合格している」と判定され、要約処理では自身の結果ではなく Kimi のバグ修正用フォルダーの内容が要約されてしまいました。各タスクごとに固有の --session-key を設定することで問題は解決しました。
• ワーカー側の指示がプロンプトより優先される。 私のワーカーエージェントには「長い出力内容は自身のワークスペースに保存せよ」という指示があり、これが「このフォルダーに fizz.py を書き込め」という指示よりも優先されました。3回目の FizzBuzz 実行時の返答では「スクラッチフォルダーに書き込んだ」とありましたが、ファイルのタイムスタンプからはワークスペースに保存されたことが分かります。4回目の実行では絶対パスを指定し、明示的にその場所を使うよう指示したところ正しく書き込まれました。
• 共有ワークスペースが次の実行結果を汚染する。 前述の例の通りです。Kimi によって作成されたファイルが1時間後もワーカーのワークスペースに残っており、MiniMax はそれらを自身のファイルだと判断してしまいました。各実行ごとに空のフォルダーを用意し、その実行で何が書き込まれたか（タイムスタンプやセッション内の write 呼び出し）を確認するべきです。単に「こう書き込んだ」という返答だけを信じてはいけません。
• カタログ上では100万トークンと記載されているが、私は262,144トークンしか使っていない。 これは私自身が設定した contextTokens の値であり、JSON内の agentMeta.contextTokens も実際に適用されている値を示しています。より長いコンテキストウィンドウが必要な場合はこの値を引き上げてください。
• 定額プランにおける金額表示は架空のものだが、参考にはなる。 OpenClaw では usage.cost.total に、実際に支払う金額とは無関係な内部定価を入力しています。そのためモデル同士を比較する際には役立ちますが、請求額としては意味がありません。

この結果が私に与える示唆

私のワーカーエージェントではMiniMax M3が主要なモデルとして使用されており、DeepSeek V4-FlashおよびV4-Proがフォールバック用として設定されています。Kimi K3はこの処理フローには含まれておらず、私のレビューエージェント用に別途利用しています。これらのタスクにおいて、M3は名前変更処理を89.9秒で完了させ、定価ベースで0.058ドルのコストがかかりました。一方Kimiでは128.9秒を要し、コストは0.180ドルでした。またバグ修正処理もM3なら41.0秒で済み、費用は0.025ドルでしたが、Kimiでは86.6秒と0.114ドルかかっています。V4-Flash上で動作するdshは、どのタスクにおいても両モデルより速く、かつ低コストでした。

ウィジェット作成に関するテストでは、MiniMaxによる結果が得られませんでした。皆様ご自身で同様の比較を行う際には、各実行ごとに空のフォルダを用意し、レポートを確認する前にそのセッションにおけるwrite呼び出し内容も必ず確認してください。

関連記事：Kimi K3をコーディングエージェントとして利用する場合（今回の比較におけるKimi側の情報）、DeepSeek Harness（dsh）（5つのテストタスクおよび元々のウィジェット作成要件について）、Reasonix（以前の記事で比較されたモデルですが、2026年9月9日をもって私の環境からは削除されました）、および私のAIエージェントが実際にかかるコストについて。