MiniMax M3をOpenClaw用コーディングエージェントとして使用：Kimi K3およびdshを相手にした5つの課題、そして作成できなかったウィジェット

MiniMax M3が現在、OpenClaw上で私のワーカーエージェントを実行しています。今朝早くにKimi K3に与えたのと同じ5つの小規模なコーディング課題をMiniMax M3にも与えてみたところ、約Kimiの所要時間の半分で全課題を無事完了しました。また費用面でもKimiの定価の約4分の1という結果になりました。さらに、両者が同じ指示文に基づいてこのサイトのロゴのピクセルアート版をどのように作成するかも比較してみようと思っていました。しかしその部分は検証時に問題が判明しました。当初私がMiniMax M3の成果だと考えていたウィジェットは実際にはKimi K3が作成したものであり、MiniMax M3の実行時にはKimi K3のファイルが見つかり、それらを自らの成果として報告してしまったのです。詳細は以下に記載してありますが、なぜそうなったかという点こそがこの記事で最も重要な情報だからです。

OpenClawのミニマックスプロバイダーとは何か

以前の草稿では間違えていましたので、ここにインストール済みのコードと私自身の設定内容を記載します。

• プロトコルとエンドポイントについて。 同梱されている minimax プラグインでは、プロバイダーの設定に api: "anthropic-messages" が使用され、ベースURLとして https://api.minimax.io/anthropic が指定されています（MINIMAX_API_HOST 変数を使えばホストを変更可能です）。MiniMaxでは https://api.minimax.io/v1 の下にも OpenAI互換のAPIが提供されていますが、OpenClaw用のプラグインはそれを利用していません。
• プロバイダーは2つだけ、3つではない。 minimax がプラグインのメインとなるプロバイダーです。私の openclaw.json ではモデルリストのみを上書きしており、APIの種類やベースURL、認証情報などはすべてプラグイン側から取得されます。minimax-portal はプラグインが用意する2番目のプロバイダーID（OAuth対応版）です。私は手動で同じエンドポイントを指定し、長時間実行されるジョブ向けに100万トークン分のコンテキストも設定しています。minimax-cn は3つ目のプロバイダーというわけではなく、MiniMaxの中国地域向けに minimax の認証情報を別名で指定したものに過ぎません。そのエンドポイントは https://api.minimaxi.com/anthropic です。
• 認証キーについて。 これは環境変数として設定されます。プラグインは MINIMAX_API_KEY（およびいくつかのトークンプラン用変数）を読み取ります。私の minimax-portal 設定項目では、その値を文字列 "${MINIMAX_API_KEY}" として直接指定しています。OpenClawのシークレットストア内には MiniMax関連の情報は一切含まれていません。
• モデル設定について。 プラグインのカタログによると、M3モデルでは100万トークン分のコンテキストウィンドウが利用可能で、compat という設定項目として codeMode: "preferred" が用意されています（これは OpenClawのコードモードであり、Codexとは無関係です）。温度パラメータを調整する機能は存在しません。
• 料金について。 プラグインではM3モデルの料金を、入力時0.60ドル、出力時2.40ドル、キャッシュ読み出し時は100万トークンあたり0.12ドルと定義しており、この表がJSON内の usage.cost.total の値を決定します。私自身はまだ MiniMax公式の料金ページと照合して検証していません。

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
$ openclaw plugins list --json | jq '[.plugins[] | select(.enabled)] | length'
35

手順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の場合、実行時間は日本標準時07時46分から07時54分の間で、--thinking maxモードで実施されました。dshの数値は同一セッション内でのキャッシュ利用時の再実行結果です。MiniMaxの場合は日本標準時09時11分から09時14分の間に、OpenClawのデフォルト設定である適応型思考モードで実行されました。

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

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

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

表から読み取れること：

• すべてのタスクが成功した。 ディスク上の結果を確認しました。FizzBuzzの出力、pytestの合格、要約文の単語数など、すべて問題ありませんでした。
• MiniMaxはKimiよりも約2倍速く、定価ベースでは約4倍安かった（実行時間は159.2秒対309.9秒、費用は$0.125対$0.531）。Kimiは最大思考モードで動作していたためこの差が生じました。
• V4-Flash上のdshはMiniMaxよりも約4.5倍速く、同種のタスクにおいて約11倍安かったです。
• キャッシュが大きな役割を果たしている。 MiniMaxでは未キャッシュ入力トークン1つにつき5.2回のキャッシュ読み出しが行われました。定価ベースでは、キャッシュ読み出しは未キャッシュ入力よりも80％安くなっています。未キャッシュ入力として課金されていれば、同数のトークンで約$0.34かかっていたはずで、$0.125という実際の費用はこれよりも低額です。
• 再実行分は合計値に含まれていない。 MiniMaxによる12回のベンチマーク実行（失敗したものも含む）全体では、定価ベースで$0.28、実行時間は321秒となります。

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

dshの記事に掲載された「面白いテスト」とは、指示書に基づいて作成された、当サイトのロゴをピクセルアートで表現したウィジェットでした。私はKimiおよびMiniMaxにも同じ指示書を渡したかったのです。各モデルが受け取った指示書は以下の通りです：

概要：インタラクティブなピクセルアート版LaserLloydロゴウィジェット

LaserLloydロゴのピクセルアート版を作成してください（reference-logo.pngを参照）。白地に太い青色の輪（色番号#1f3f8f）があり、その中に斜めに交差する2つの大文字“L”が描かれています。左上の“L”の脚部は右下の“L”の幹の下に重なっており、まるで対角線上に積み重なっているかのような形状です。

納品物（すべてこのフォルダ内に入れること）

1. ll-pixel-logo.js — バニラJavaScriptのみで構成されたファイルです。依存ライブラリもビルド処理もネットワーク通信も一切不要です。任意のページで次のように記述すれば埋め込めます：<div class="ll-pixel-logo" data-size="320"></div> に加え <script src="ll-pixel-logo.js"></script>。このファイルはページ内のすべての .ll-pixel-logo 要素を探し、その中に <canvas> を生成します。レスポンシブ対応で、キャンバスのサイズはコンテナ幅に合わせて正方形になり、HiDPI環境でも鮮明に表示されます。window.LLPixelLogo.mount(el) という関数も用意してください。
2. index.html — 3種類のサイズでウィジェットを表示するデモページです。各状態でのインタラクションについて簡単な説明も付記します。
3. README.md — 埋め込み方法、利用可能なインタラクション、および使用できる data-属性などを記載します。

アート面の要件

• ピクセルグリッドは40×40のセルで構成します。手動でビットマップを描くことは禁止です（‘#’や‘.’で行ごとに記述するような方法は遅くて誤りも生じやすいため）。代わりに幾何学的な計算によりラスター化を行ってください。isLit(col,row)という関数を実装し、これが true を返すのは以下の場合です：(a)円環部分：中心からの距離が0.82RからRの範囲内、(b)2つの斜めに傾いた“L”の形。それぞれは2つの平行四辺形で構成され、幹部分は約20°だけ傾いています。左上の“L”の脚部が右下の“L”の幹の下に重なるように配置します。200ピクセル幅で見たときに参照画像と同じように見えるよう、いくつかの定数を調整してください。また、点灯するセルの情報はマウント時に一度だけ事前計算しておきます。
• カラーパレット：ロゴ用青色 #1f3f8f、ハイライト用青色 #2ea8ff、琥珀色 #ffb64a、シアン色 #00e6cf。背景は透明です。

インタラクション（本課題の肝心な部分です。楽しく感じられるようにしてください）

• マウスオーバー／タッチ移動時： ポインター付近のピクセルが物理的に反応します。例えば、流体や磁気的な反発力によりカーソルから遠ざかり、その後減衰しながら元の位置に戻ります。移動中は #2ea8ff または #00e6cf 色で光ります。requestAnimationFrameを用いて60fpsで滑らかに動作させ、処理がカクつかないようにしてください。
• クリック／タップ時： 何か魅力的で満足感のある効果を実装してください。例えば、ロゴ全体が多数のピクセルに分解されて重力や反発力により飛び散り、その後再び元のロゴ形状に戻る（約1.5〜2秒かかります）といった演出です。あるいは“レーザー”が走ってピクセルごとに光る火花を伴いながらロゴを描き直す効果も良いでしょう。連続したクリックでも違和感なく機能するようにしてください（アニメーション途中で中断させないこと）。
• 待機状態時： ごくわずかな動き（ゆっくりときらめいたり、たまにピクセルが光ったり）を加えてください。これによりウィジェットが“死んだ”ように見えないようにしますが、煩わしくならない程度に留めてください。
• prefers-reduced-motion: reduce 属性が設定されている場合は、静的なロゴのみを描画し、ホバー時の光り方も省略してください。
• マウスおよびタッチの両方に対応させてください。ページのスクロール操作を妨げないようにしてください。

品質基準

• コードは整然としており、適切なコメントが付記されていること。グローバル変数は LLPixelLogo のみとします。インデント幅は2スペース。全体の行数は400行未満であること。
• file://プロトコルからでも実行可能で、コンソールにエラーが一切出ないこと。ご自身でテストも行ってください。例えば小さなNodeスクリプトを作成するか、お手持ちの環境で構文チェックやモジュールの動作確認を行ってください（jsdomは利用不可ですので node --check コマンドを用いてください）。また、ビットマップデータについても単体テストを実施し、点灯しているセル数や円環および2つの“L”が適切な位置にあるかを検証してください。
• 最後に短いレポートを出力してください。作成した内容、埋め込み方法、および検証結果について記載します。

セッションログに記録された処理の順序は以下の通りです：

• Kimi、第1回挑戦（上記の課題内容）：8.8分間考えただけでウィジェット用コードは作成されず中断。費用は約0.31ドル。
• Kimi、第2回挑戦（同じ課題）：全323行からなる ll-pixel-logo.js やデモページ、README、テストファイルなどを作成し、テストも通るまで調整しました。しかし生成したすべてのファイルや実行レポートは私が監視しているフォルダではなく、ワーカーエージェント専用の作業領域に保存されたため、私からは何も見えませんでした。15分の時間制限に達した時点で応答がありました。そのため第2回挑戦でも成果物がないと判断していました。費用は約0.72ドル。
• Kimi、第3回挑戦（より厳格な制約付き：一度のツール呼び出しでファイルを作成すること、事前計画や node --check は不可）：7.4分で作業が完了し、目的のフォルダ内に397行からなるウィジェットが作成されました。費用は0.47ドルです。これがKimiに関する記事で紹介されているウィジェットです。
• MiniMax（同じ課題内容、1時間後に同一ワーカーエージェントを使用）：59.3秒で作業が終了し、25回の反復・24回のツール呼び出しを行い、定価ベースで0.13ドルの費用となりました。MiniMaxは共有作業領域に残っていたKimiの第2回挑戦時のファイル群や実行レポートをすべて読み取り、それらのテストも実行した上で「ウィジェット一式を作成・検証済み」と回答しました。しかし実際にはウィジェット用コードは一切書かず、生成したのは自身の実行レポートおよびステータスファイルのみでした。

私はその回答をそのまま受け取り、本記事の初稿では「MiniMaxによる最初の挑戦時のウィジェットで、1分未満で完成した」と記述しました。実際にはKimiの第2回挑戦セッション内の日本時間08:11に write 操作によりそのファイルが作成されており、本サイト上のファイルもそれと完全に同一です。したがってMiniMaxによるこの課題への成果物は現時点では存在しません。今後は空のフォルダ内で再実行を行う予定です。Kimiに関しては当初伝えた内容よりも良い結果が得られており、2回目の挑戦が成功していただけで、単にファイルを誤った場所に保存しただけだということになります。

以下がKimiの第2回挑戦時のウィジェットです。このページ上でも動作します。当初私が誤って「MiniMax製」と表記してしまったファイルそのものです：

最初の約30行は次の通りです：

/* ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Embed:
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * One file, no dependencies, no build step, no network requests.
 * The 40x40 bitmap is rasterised procedurally from geometry (a ring plus
 * two interlocking italic Ls) — never a hand-drawn bitmap.
 *
 * Interactions:
 *   - pointer move : pixels are pushed away from the cursor, then spring
 *                    back with damping; displaced pixels glow blue -> cyan
 *   - click / tap  : the logo shatters outward with gravity + floor bounce,
 *                    then reassembles itself (~1.8 s)
 *   - idle         : occasional pixel twinkle (amber / cyan)
 * Honours prefers-reduced-motion: static logo, hover glow only.
 *
 * Global exported: window.LLPixelLogo (also module.exports under node,
 * so the bitmap can be unit-tested without a DOM).
 */
(function () {
  'use strict';

  /* ---------------- palette ---------------- */
  var BLUE  = [31, 63, 143];    // #1f3f8f logo blue
  var HI    = [46, 168, 255];   // #2ea8ff highlight blue
  var AMBER = [255, 182, 74];   // #ffb64a
  var CYAN  = [0, 230, 207];    // #00e6cf

Kimiの第3回挑戦版、つまりKimi記事内で紹介されているバージョンは以下のように始まります：

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Self-contained vanilla JS: no dependencies, no build step, no network.
 * Embed on any page with:
 *
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * Every .ll-pixel-logo element gets a <canvas> mounted inside it at load.
 * Programmatic API: window.LLPixelLogo.mount(el) -> instance.
 *
 * Art: 40x40 pixel grid, rasterised procedurally from geometry (ring + two
 * interlocking italic Ls). Interactions: pointer repulsion with spring-back,
 * click/tap shatter-and-reassemble, idle shimmer/twinkle, reduced-motion
 * support. Mouse and touch. No scroll hijacking (all listeners passive).
 */
(function () {
  'use strict';

  // -- constants ------------------------------------------------------------
  var VERSION = '1.0.0';
  var GRID = 40;                                // logical grid: GRID x GRID cells
  var BLUE   = [31, 63, 143];                   // #1f3f8f logo blue
  var HILITE = [46, 168, 255];                  // #2ea8ff highlight blue
  var AMBER  = [255, 182, 74];                  // #ffb64a twinkle amber
  var CYAN   = [0, 230, 207];                   // #00e6cf max-displacement glow

  var CENTER = GRID / 2;                        // grid centre coordinate (20)
  var R_OUT = 19;                               // ring outer radius (cells)
  var R_IN = 0.82 * R_OUT;                      // ring inner radius
  var SLANT = Math.tan(20 * Math.PI / 180);     // ~20 deg italic shear

そしてdshウィジェット、すなわちdsh記事冒頭部に掲載されているものは次の通りです：

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 * Vanilla JS, zero dependencies, no network requests, works from file://.
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 * Auto-mounts on .ll-pixel-logo elements; window.LLPixelLogo.mount(el) too.
 * Knobs: data-size, data-speed, data-static.
 */
(function (global) {
  'use strict';
  // ---- 0. palette -----------------------------------------------------
  var BLUE = [31, 63, 143];      // #1f3f8f — logo blue
  var HI = [46, 168, 255];       // #2ea8ff — hover / repulsion glow
  var AMBER = [255, 182, 74];    // #ffb64a — twinkle spark
  var CYAN = [0, 230, 207];      // #00e6cf — deep glow
  // ---- 1. art: procedural 40x40 raster (no hand-drawn bitmap) ----------
  // A cell is lit when it belongs to the ring or to one of the two slanted
  // interlocking Ls. Each L is two parallelograms (stem + foot), described by
  // top-left (ax,ay), width w, height h, sheared by SLANT (bottom edge shifts
  // left): TL=(ax,ay) TR=(ax+w,ay) BL=(ax-SLANT*h,ay+h). The upper-left L's
  // foot runs right and tucks under the lower-right L's stem, like the ref.
  var GRID = 40;                 // cells per side
  var RING_R = 19.7;             // outer ring radius (cells)
  var RING_IN = 0.80 * RING_R;   // inner ring radius (reference ~0.808R)
  var SLANT = 0.453;             // shear of stems/feet (~24deg)
  var LETTERS = [
    { ax: 15.0, ay: 5.2, w: 4.2, h: 10.6 },   // upper-left L: stem
    { ax: 10.2, ay: 15.8, w: 15.0, h: 3.8 },  // upper-left L: foot
    { ax: 24.7, ay: 13.8, w: 4.2, h: 14.7 },  // lower-right L: stem
    { ax: 18.0, ay: 28.5, w: 15.0, h: 3.8 }   // lower-right L: foot
  ];

これら3種類の実装はいずれも幾何学的な計算により円環と2つの斜め“L”を生成しており、window.LLPixelLogo.mount 関数を提供し prefers-reduced-motion にも対応しています。私は40×40のグリッド上で各セルに対し isLit を評価することで点灯しているセル数を数えました：

• Kimi、第2回挑戦：RING_R = 19.4、内側境界は0.82R、SHEAR = 0.42（約22.8°）となっており、脚部と傾いた幹部分を一度の判定で処理する inL ヘルパーが用いられています。点灯セル数は602個です。
• Kimi、第3回挑戦：R_OUT = 19、内側境界も0.82R、SLANT = tan 20°（約0.364）となっており、幹と脚部を返す makeL ヘルパーが利用されています。点灯セル数は510個です。
• dsh：RING_R = 19.7、内側境界は0.80R、SLANT = 0.453（約24°）となっており、4つの文字情報を格納した LETTERS 配列が用いられています。点灯セル数は656個です。

どのデザインも参照用のロゴと完全に一致しているわけではありませんが、仕様書では200ピクセルサイズでロゴとして見えることのみが求められており、3つすべてがその条件を満たしています。いずれかをリリースする前に、定数の設定に10分程度費やすつもりです。

試行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フレーム分の処理、粒子状態が有限であること、処理後にはロゴが元の位置に戻ること、devicePixelRatioが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 呼び出し履歴）を確認するべきです。単に「書き込んだ」と言っている内容だけでは不十分です。
• エラー終了コードが出てもタスクが失敗したとは限らない。 Kimi での実行時、最初の FizzBuzz 呼び出しは終了コード1で終わり、「勝利モデルなし」と表示され、「⚠️ APIレート制限に達しました。後でもう一度お試しください。」というメッセージが出ました。しかし実際には fizz.py は既に作成されており、そのファイルは正常に動作しました。完了したことを示すのは再試行時のレスポンスのみでした。終了コードではなくファイルの有無を確認すべきです。
• カタログ上のトークン数は1,000,000だが、私は262,144しか使っていない。 これは私が設定した contextTokens の値であり、JSON内の agentMeta.contextTokens も実際に適用されている値を示しています。より長いコンテキストウィンドウが必要な場合はこの値を増やせばよく、minimax-portal の項目を使って必要な時だけ設定変更を行っています。
• 定額プランにおける金額表示は実際には存在しないが、参考にはなる。 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エージェントが実際にどれくらいのコストを要するか。