OpenClawにおけるKimi K3とdshの比較：5/5タスク達成、9倍遅く、コストは48倍

かんたんに言うと: 自宅で運用しているエージェントソフトウェアに、Moonshot社のKimi K3推論モデルを組み込みました。そして、8月にDeepSeekのコーディングアシスタント（dsh）のテスト用として使用したのと同じ5つの小規模なコーディング課題を与え、同じ指示文に基づいてこのサイトのロゴのピクセルアート版を作成するよう依頼しました。結果として、5つの課題すべてに合格しましたが、DeepSeekの高速モデル上で動作するdshと比較すると、所要時間は約9倍、コストも約48倍かかりました（dshのその日の2回目の実行と比較した場合）。ロゴウィジェットの作成には3回の試行が必要でした。1回目は約9分間考え続けたものの、ウィジェットを生成しませんでした。2回目は動作するウィジェットを作成しましたが、誤ったフォルダに保存してしまい、報告する前に時間切れとなったため、後でようやく見つけることができました。3回目は、指示文を短くして「計画段階を省略する」と伝えたところ、無事に成功しました。

自分の環境で実装したい? おすすめの方法: この記事(またはURL)をLLM(Claude、ChatGPT、ローカルモデルなど)に渡して、同じ構成をあなたの環境に実装してもらってください。必要な情報はぜんぶ記事にあります。 LLMアシスタントが初めての方は、セットアップガイド(Claude Code、Cowork、Reasonix、DeepSeek)をどうぞ。

自分で用意するもの

Node.js 22.22.3以降、24.15以降、または25.9以降がインストールされているLinuxまたはmacOSのマシン（OpenClaw 2026.9.2が対応しているバージョン範囲です。私はFedora Atomicデスクトップ上でNode.js 24.18.0を使用しました）
platform.moonshot.aiから取得したMoonshotオープンプラットフォームのAPIキー（以下のベンチマーク全体で約53セントの費用がかかりました）
OpenClaw 2026.9.2以降で、Moonshotプロバイダープラグイン（@openclaw/moonshot-provider）が利用可能な状態であること

LLMに任せられること

OpenClaw用のMoonshotプロバイダープラグインをインストールし、MOONSHOT_API_KEYをゲートウェイから利用可能な状態にします。また、openclaw.json内でワーカーエージェントの主要モデルとしてmoonshot/kimi-k3を指定します。
5つの小さなタスクを、それぞれ新しいスクラッチフォルダと新しいセッションで実行し、`openclaw agent --json`から経過時間、トークン数、コストを記録します。
この記事からリンクされているピクセルアートロゴの指示書をそのままKimi K3に渡し、何回試行したかや費用がいくらかを報告します。

コピペで使えるプロンプト:

まず https://www.laserlloyd.com/ja/projects/kimi-k3-coding-agent-on-moonshot/ を取得して読んでください。このプロジェクトの詳細な手順・設定・注意点がすべて載っています。 まず、OpenClawのMoonshotプロバイダープラグインをインストールしてください（コマンド：openclaw plugins install @openclaw/moonshot-provider）。次に、openclaw.jsonファイルにAPIキーを記載せずに、ゲートウェイ側でMOONSHOT_API_KEYが利用できるように設定します。さらに、私のワーカーエージェントにおいては、プライマリモデルとしてmoonshot/kimi-k3を指定し、コストを抑えるためのフォールバックモデルも設定します。

その後、5つの小規模なタスクを実行してください。各タスクは、新しく作成したスクラッチフォルダ内で、新しい--session-keyを用いて実施する必要があります。各タスクの内容は以下の通りです：
1. 「PONG」と返信する。
2. FizzBuzzを記述し、実行する。
3. テストコードに触れずに、単体テストが通るように2つのバグを修正する。
4. 6つのモジュールからなるコードベースを150語以内で要約する。
5. 3つのファイルおよび関連するテスト内の関数名を変更し、テストが成功することを確認する。

各タスク実行時には、`openclaw agent --json`コマンドを用いて、経過時間、トークン使用量、コストなどの情報を記録してください。最後に、この記事からリンクされているピクセルアート形式のロゴ作成の指示書をそのまま使用し、15分間の制限時間内で作業を行ってください。

最終的に、各タスクの終了コード、経過時間、トークン使用量、コスト、そして失敗した試行内容もすべて報告してください。創造的な指示に対するタイムアウト状況も隠さずに報告してください。

私はOpenClawのワーカーエージェントを、Moonshot社が提供する推論モデルであるKimi K3に向けて設定し、8月にDeepSeek Harness (dsh)のベンチマーク用として使用した5つの小規模なコーディング課題を実行させました。Kimiはその全てを無事にこなしました。同日、DeepSeek V4-Flashでもdshを2回実行してみたところ、2回目の実行（キャッシュが有効な状態）では、Kimiは約9倍の時間（309.9秒対35.7秒）を要し、費用も約48倍（0.531ドル対0.011ドル）になりました。一方でキャッシュがない状態での初回実行（44.8秒、0.024ドル）と比べると、時間は約7倍、費用は約22倍の差が生じています。

次に、dshがウィジェット作成用に用意したピクセルアート風のロゴの指示書をKimiに渡してみました。3回試行する必要がありました。1回目では何も生成されませんでした。2回目では完全なウィジェットコードが誤ったフォルダに書き込まれたものの、私が設定したタイムアウト時間に達してしまい、最初は気付かないままでした。3回目は指示文を短くし、「計画段階を省略せよ」と指示したところ、無事に成功しました。下に示すウィジェットがその3回目の成果物であり、特にステップ2にある設定上のポイントが最も参考になる部分です。

ぜひお試しください。 Kimi K3が3回目の試行で作成したウィジェットです。マウスを重ねるとピクセルがポインターから遠ざかり、また元の位置に戻ります。クリックするとウィジェットがバラバラになって跳ね回った後、再び元の形に戻ります。タッチ操作にも対応しており、prefers-reduced-motion設定も適切に反映されます。

要約です：

概要： Moonshot社のOpenAI互換APIを通じて利用できるKimi K3であり、OpenClaw独自のエージェントループを駆動します。なおCodexハーネスはOpenAI経路のみを受け付けるため、このモデルはそちらでは利用できません（詳細は末尾に記載）。
セットアップ方法： Moonshotプロバイダープラグイン（@openclaw/moonshot-provider 2026.9.2）およびゲートウェイ環境変数としてMOONSHOT_API_KEYを設定します。モデル用にcompatブロックを記述する場合は、完全な内容を書き込む必要があります。不完全な記述だと推論の質に関する設定が無効になるからです。
ベンチマーク結果： 5つの課題すべてをクリアしました。Kimi K3は309.9秒・0.531ドル。一方V4-Flashではキャッシュ有効時が35.7秒・0.011ドル、キャッシュなしの場合は44.8秒・0.024ドルでした。
ウィジェット作成： 3回試行しました。1回目は8.8分後に中断され、コードが生成されませんでした。2回目では323行に及ぶコードが誤ったフォルダに書き込まれ、15分の制限時間に達してしまいました。3回目は指示文を短くし「計画段階を省略せよ」と指示したところ、7.4分・0.47ドルで完了しました。
費用とキャッシュ： Kimiが使用したプロンプトトークンの80％はキャッシュから取得されたものです。キャッシュがなければ同処理には約1.49ドルかかっていたことになります。
現状： このベンチマーク後、私はワーカーをMiniMax-M3に切り替えました。ただしKimi K3は今もレビューエージェントとして利用しています。

セットアップ：私が実行した環境について

以下は、2026年9月11日に私の環境で実行したコマンドと、その実際の出力内容です。

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2
$ openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'
{"id":"moonshot","enabled":true,"version":"2026.9.2"}
$ openclaw config get models.providers.moonshot.models.0.compat
{
  "supportsReasoningEffort": true,
  "supportsTemperature": false,
  "supportedReasoningEfforts": [
    "low",
    "high",
    "max"
  ]
}
$ openclaw config get models.providers.moonshot.models.0.contextTokens
262144

何かを実行する前に知っておくべき点が2つあります：

K3は常に推論処理を行います。 このプラグインではデフォルトで reasoning_effort: "max" が送信され、low、high、max も受け付けます。私は --thinking max を指定してベンチマークを実行しました。また、K3側でサンプリング関連の設定（temperature、top_pなど）が固定されるため、これらの値も無視されます。私のモデル設定にも supportsTemperature: false と記載されています。例えば「正確に『PONG.』と返信せよ」という指示でも53個もの推論トークンが消費されるので、その分のリソースを考慮しておく必要があります。
1Mトークンのコンテキスト長が謳われていますが、私は上限を設けています。 OpenClawのMoonshotカタログではK3のコンテキスト長が1,048,576トークンと記載されています。しかし私はモデル設定で contextTokens: 262144 と指定しており、他のモデルと同様のタイミングでセッションが圧縮されるようにしています。この制限のため、実際には1Mではなく256k程度しか利用できません。この値を引き上げると、キャッシュ読み取りにかかるコストや各ターンごとのレイテンシも増加します。

手順：初心者から上級者まで

手順1から3を実行すれば動作するモデルが得られます。手順4と5は、私がその後に行ったことです。

手順1：プラグインをインストールし、キーを設定する

以下はOpenClaw公式のMoonshotドキュメントに記載されている手順です。私の環境では既にプラグインとキーが設定済みでしたので、最後の行のチェックのみ実行しました（その出力結果は上記のセットアップ部分に記載されています）。

openclaw plugins install @openclaw/moonshot-provider
openclaw gateway restart
openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'

このプラグインは MOONSHOT_API_KEY からキー情報を読み取ります。私はその値をゲートウェイサービスが読み込む環境変数ファイルに記載しており、openclaw.json にはキー情報は一切含まれていません。また、手順を丁寧に案内してもらいたい場合には openclaw onboard --auth-choice moonshot-api-key というコマンドも用意されています。デフォルトのエンドポイントは https://api.moonshot.ai/v1 であり、中国地域では https://api.moonshot.cn/v1 が使用されます（認証オプションは moonshot-api-key-cn です）。

このプラグインの対応カタログにはK3、K2.7 Code、K2.7 Code HighSpeedが含まれています。Kimi特有の仕様にも自動的に対応してくれます。例えばK2.7ではリクエスト内から thinking および reasoning_effort の両方を除外する必要がありますが、プラグインがそれを代わりに行ってくれます。環境変数名には注意が必要です。MOONSHOT_API_KEY はMoonshotオープンプラットフォーム用のキーです。一方で KIMI_API_KEY は別途提供されているKimi Codeサブスクリプション用のキー（kimi/kimi-for-coding）となります。

ステップ2：ワーカーエージェントの対象をK3に設定する

ベンチマーク実行時の私の openclaw.json の該当部分です。このとき、ワーカーエージェントの名前を worker と変更していました。

{
  agents: {
    entries: {
      worker: {
        model: {
          primary: "moonshot/kimi-k3",
          fallbacks: ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"],
        },
      },
    },
  },
  models: {
    providers: {
      moonshot: {
        baseUrl: "https://api.moonshot.ai/v1",
        api: "openai-completions",
        timeoutSeconds: 1200,
        models: [
          {
            id: "kimi-k3",
            name: "Kimi K3",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 3, output: 15, cacheRead: 0.3, cacheWrite: 0 },
            contextWindow: 1048576,
            maxTokens: 131072,
            contextTokens: 262144,
            compat: {
              supportsTemperature: false,
              supportsReasoningEffort: true,
              supportedReasoningEfforts: ["low", "high", "max"],
            },
          },
        ],
      },
    },
  },
}

ある落とし穴により、予期せぬ不具合が発生してしまいました。OpenClaw 2026.9.2では、モデルエントリ内の compat ブロックがプラグイン自体が持つ compat オブジェクトを上書きしてしまうのです。結合されるわけではありません。以前のバージョンでは supportsTemperature: false のみを記述していたのですが、そのせいでプラグインの reasoning-effort 機能が無効化されてしまっていました。もし compat を記述する場合は、上記の例のようにオブジェクト全体を記載する必要があります。

ステップ3：スモークテストと、それが返してくるJSON

各ベンチマークタスクでは、毎回新しいセッションキーを使ってこのような呼び出しが行われました。

openclaw agent --agent <your-agent-id> --model moonshot/kimi-k3 --thinking max \
  --session-key "<fresh-key>" --message-file prompt.txt --json > out.json

以下は、PONGタスクの保存されたデータから抽出した重要なフィールドです。

$ jq '.result | {harness: .meta.agentMeta.agentHarnessId, model: .meta.executionTrace.winnerModel, usage: .meta.agentMeta.usage}' out.json
{
  "harness": "openclaw",
  "model": "kimi-k3",
  "usage": {
    "input": 15068,
    "output": 70,
    "reasoningTokens": 53,
    "total": 15138,
    "cost": {
      "total": 0.046254
    }
  }
}

harness: "openclaw"というのは、その処理がOpenClaw自身のループ内で実行されたことを意味します。一方、Codexアプリサーバーを通じて実行された場合は "codex" と表示されます。winnerModel: "kimi-k3"は、その処理が実際にK3上で実行され、より安価なモデルにフォールバックしていないことを示しています。reasoningTokensの数値は output 内にカウントされており（合計値は入力分＋出力分です）、したがって53個の推論トークンは70という総数の一部となります。

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

これらは、dshの記事で実行されたのと同じ5つのタスクです。各タスクはそれぞれ新しいスクラッチフォルダ内で、Kimiの場合は各タスクごとに新しいセッションが開始されます。私は同日にV4-Flash上でもdshを再実行しました。その際、スクラッチ設定ファイル内でdeepseek-v4-flashを指定しました。キャッシュが存在しない状態での最初の実行には44.8秒と0.024ドルかかりました。下記の列は2回目の、キャッシュがある状態での実行結果であり、私が得た中で最も速く、最もコストが低いdshの結果です。本記事内で特に断りがない限り、すべての比較においてこの数値が用いられています。プロンプトの文言は完全に同一ではありませんでした。dshは起動したフォルダ内で実行されるため、そのプロンプトには「現在のディレクトリ」と記載されていました。一方Kimiのプロンプトでは各タスクフォルダの絶対パスが指定されており、さらにバグ修正用のプロンプトとして「もしpytestが利用できない場合は、まず『pip install --user pytest』でインストールしてください」という記述も加えられていました（実際にはpytestは既にインストール済みで、Kimiはそのインストール処理を実行していません）。V4-ProおよびGemma-4-26Bの列は8月に公開されたdshに関する記事から引用したもので、再実行は行われておりません。経過時間とは、処理全体にかかった時間を指します。Kimiにおけるトークン数およびコストはOpenClawのJSONデータから、dshのそれらは自身のセッションログから取得しています。

タスク	Kimi K3	dsh V4-Flash（同日実行）	dsh V4-Pro（8月、過去データ）	Gemma-4-26B（8月、過去データ）
「PONG」と返信する（起動後、1回の呼び出し）	✅ 6.1秒 · ツール使用なし	✅ 1.7秒 · ツール使用なし	✅ 2.8秒	✅ 13.2秒*
FizzBuzzを記述して実行する	✅ 22.8秒 · 2つのツールを使用（記述、実行）	✅ 5.3秒 · 3つのツールを使用	✅ 8.4秒 · 2つのツールを使用	✅ 4.9秒 · 2つのツールを使用
ユニットテストが通るようにバグ2件を修正する（テスト自体は変更なし）	✅ 86.6秒 · 6つのツールを使用（実行、記述、編集）	✅ 11.3秒 · 7つのツールを使用	✅ 15.8秒 · 7つのツールを使用	✅ 10.4秒 · 8つのツールを使用
6モジュールからなるコードベースを要約する（150語未満）	✅ 65.5秒 · 10のツールを使用（読み込み、実行、記述）	✅ 5.1秒 · 7つのツールを使用	✅ 10.9秒 · 7つのツールを使用	✅ 12.1秒 · 7つのツールを使用
3つのファイルおよびテスト内の関数名を変更し、テストが成功することを確認する	✅ 128.9秒 · 9つのツールを使用（実行、記述。複数ファイルに対して`sed`を1回実行）	✅ 12.3秒 · 11のツールを使用	✅ 18.2秒 · 12のツールを使用	✅ 12.2秒 · 11のツールを使用
合計経過時間	309.9秒	35.7秒	56.1秒	52.8秒
トークン数：入力ミス／キャッシュ読み込み／出力（推論用）	91,470／355,328／9,990（4,053）	6,141／147,328／4,697（1,984）	41.4k／107k／3.2k	40.5k／237k／5.6k
コスト	約$0.531（100万トークンあたり$3／$15／$0.30）	約$0.011（100万トークンあたり$0.44／$1.32／$0.014）	約$0.072	$0（電力費のみ）

ツール利用回数とは、実際にツールが呼び出された回数のことです。Kimiの数値はOpenClawのJSONデータ内のtoolSummary.callsから取得しており、括弧内には使用されたツールの種類が記載されています。dshの数値はそのセッションログから得られています。※最初の呼び出しは、モデルがシステム上に読み込まれた直後に行われたものです。Kimiの料金率は私が作成したOpenClawnのカタログ記載の数値であり、OpenClawではこれをもとに各タスクのコストを計算しています。最新の料金情報については、Moonshotの料金ページをご確認ください。dsh V4-Flashのコスト計算には、dshに関する記事（DeepSeekの料金情報）で示されている最高料率が用いられています。V4-ProおよびGemmaの欄に記載されている数値も、同記事のデータに基づいています。

表の内容は以下の通りです：

すべての項目で5/5の評価。 これらのタスクはいずれもKimiにとって難しくありませんでした。PONGも求められた通りの結果を返しました。FizzBuzzも正しい15行を出力しました。バグ修正には、returnが欠けていたことと、== 1であるべきところを== 0にするという、たった2箇所の1行変更のみで済み、テストコードは一切変更せずに3つのテストすべてが合格しました。要約文も107語だけの段落で、6つある同一構造のfetch/transform/validateモジュールを正しく説明していました。名前変更作業では、4つのファイルに対してsedコマンドを実行しただけでテストメソッドの名前も変更され、その後4つのテストもすべて合格しました。私の指示ではフォルダ全体から空の結果を得るためのgrepを実行するよう求められており、そのフォルダ内には私自身が作成した指示文も存在したため、Kimiはそのファイルにも同様のsed処理を行い、返答の中でその旨を述べました。これらはごく小さな作業に過ぎず、複数ファイルにわたるリファクタリングのテストは行っておりません。
Kimiは思考に多くの時間を費やします。 K3は5つのタスクにおいてそれぞれ53、241、315、1,586、1,858個の推論用トークンを使用し（合計4,053個）、dsh V4-Flashも同様に推論を行いますがその量は少なく、0、52、834、5、1,093個（合計1,984個）でした。Kimiが費やす余分な時間の大部分は思考や追加的な処理に充てられているのです。
キャッシュがコストを抑えています。 Kimiが実行する各タスクでは、システムプロンプトやツール定義として約15,000個のトークンが最初から送信されます。5つのタスク全体でKimiは91,470個の未キャッシュ入力トークンを送信し、キャッシュからは355,328個のトークンを読み取りました（名前変更時だけでも157,952個）。つまり、使用されたプロンプトトークンの80％がキャッシュ由来であり、1百万トークンあたり0.30ドルという料金で処理されています。もし未キャッシュ入力として課金された場合、費用は約1.49ドルになるところを、実際には0.53ドルに抑えられており、キャッシュのおかげでコストが約3分の1になったのです。ただしこの0.30ドルという料金は、dsh V4-Flashにおけるキャッシュ読み取り料金である0.014ドルの約21倍に相当する高めの価格設定となっています。
小さな作業にはV4-Flashが最適です。 ウォームパス条件下では、dshは同じ結果を得るためにKimiよりも約9倍速く、かつ48倍安価で処理できました。コールドパス条件下でも約7倍速く、22倍安価でした。いずれの場合も得られる結果は同じです。名前変更作業だけを見ても、Kimiでは128.9秒と0.180ドルかかりましたが、dshでは12.3秒で0.0043ドルのみで済みました。

OpenClawにおけるKimi K3とdshの比較概要

どちらもファイルを読み込み、シェルコマンドを実行し、トークン単位で課金されるエージェントループです。ただし、開発元や操作方法は異なります。

	OpenClawにおけるKimi K3	dsh
開発元	モデル：Moonshot AI。エージェントループ：OpenClaw	DeepSeek（モデルおよびハーネス）、MIT
スクリプトから呼び出す方法	`openclaw agent --agent <id> --model moonshot/kimi-k3 -m "…" --json`	`dsh --profile headless "…"`
モデルの切り替え方法	`model.primary`を`openclaw.json`内で指定します	`~/.dsh/settings.yaml`を編集します
ヘッドレス環境でのベンチマーク（小規模なタスク5件）	309.9秒、約0.531ドル、5/5完了	35.7秒、約0.011ドル、5/5完了（V4-Flash使用。ウォームパス時の数値。コールドパスでは44.8秒、約0.024ドル）
ピクセルアート作成タスク（同じ指示内容）	3回試行し、そのうち2回で成果物が得られた。ここに示した結果は7.4分、約0.47ドルを要した	2回試行し、成功したケースでは25分、約49セントを要した
テスト時のバージョン	OpenClaw 2026.9.2、Moonshotプラグイン 2026.9.2	0.1.1-rc.2（開発者向けプレビュー版）

以前このサイトで行った比較記事にはReasonixの項目もありました。私は2026年9月9日に自環境からReasonixを削除したため、今回は掲載していません。ただし7月に公開された記事は歴史的な記録として残っています。また、同じテストセットを用いてMiniMax M3も試してみました。MiniMaxはMoonshotとは別の企業であり、その結果については別途記事を作成しています。

面白いテスト：同じ仕様書で、Kimiとdshを比較

dshの記事で紹介された「面白いテスト」とは、本サイトのロゴをピクセルアート化したウィジェットであり、dshがV4-Flashを使って仕様書に基づき作成したものです。私はKimiにも同様の仕様書をそのまま渡し、作業時間も計測しました。要するに、求められていたのは以下の内容です。

シンプルな単一のJavaScriptファイル、ll-pixel-logo.jsです。外部ライブラリやネットワーク呼び出しは一切不要で、すべての .ll-pixel-logo 要素内にHiDPI対応のキャンバスを生成し、window.LLPixelLogo.mount(el)という関数も提供すること。さらにデモ用の index.html と README.md も作成すること。
手描きのビットマップではなく、手続き的に生成されるアート： 40×40のグリッド上に、isLit(col, row)という関数を使って環状領域（半径0.82RからRまで）および2つの斜めのL字型パターンを描くこと。各L字はそれぞれ2つの平行四辺形で構成される。
インタラクション機能： マウスポインタによる反発効果や復元動作、強いクリック反応、ゆっくりとしたアイドル時のアニメーション、減速モーション設定への対応、そして自己テスト機能（node --checkを用いたDOMを使わない点灯セルのカウント）も実装すること。

ピクセルアート・ウィジェット対決のページに、仕様書全文が掲載されています。

Kimiがどのように対応したかは以下の通りです。

第1回挑戦（仕様書をそのまま使用）： 8.8分で中断され、ウィジェット用コードは一切作成されず、費用は約0.31ドルでした。K3は参考となるロゴ画像を見て幾何学的な考察やツール選定について考えただけで、実際の成果物は書き出しませんでした。dshの最初の挑戦も同様に失敗しており（10分間頭の中でビットマップを描いていた）、当時の仕様書では手描きのビットマップも許容されていました。
第2回挑戦（改めて仕様書を使用）： 完全なウィジェットが完成しましたが、場所が間違っており、費用は約0.72ドルでした。8分ほど経過した時点で323行からなる ll-pixel-logo.js を作成し、続いてデモページやREADME、テストファイルも書き出し、テストが通るまで調整を行い短いレポートも作成しました。ただしこれらすべては私のスクリプトが監視しているフォルダではなく、ワーカーエージェント自身の作業領域に保存されていました。また、起動用スクリプトで設定した15分の制限時間内に応答があったため、私からは何も作成されていないように見え、そのまま第3回挑戦へ移行しました。
第3回挑戦（短縮版の仕様書と指示を追加）： 7.4分で3つのファイルすべてが完成し、費用は約0.47ドルでした。私は成果物として必要なアート部分やインタラクション機能を維持した上で、TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. という指示文を先頭に加え、テスト関連の記述は Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. という内容に書き換えました。このウィジェットにはポインタ反発機能やクリック時の破壊・再構成、アイドル時のきらめき効果、減速モーション対応も備わっています。私が行った検証内容は後述します。

以上3回の挑戦にかかった時間はそれぞれ8.8分、15分、7.4分で、費用は約0.31ドル、0.72ドル、0.47ドルとなり、2つのウィジェットを作成するのに合計で約1.50ドルかかりました。第3回挑戦の費用はその時点でのJSON形式の領収書から算出されています。第1回および第2回挑戦では領収書が発行されなかったため、それぞれのセッションにおけるOpenClawのメッセージ単位の料金を合算した値となっており、第3回分の総額もその領収書と一致しています。

約1時間後、同じワーカー上で動作するMiniMax M3が第2回挑戦で作成されたファイル群を見つけ出し、テストを実行した上で自身の成果物として報告しました。この経緯は MiniMax M3に関する記事に記載されており、Kimiが作成した2つのウィジェットもdshの作品と並んでピクセルアート・ウィジェット対決ページに掲載されています。

まずはKimiが作成した ll-pixel-logo.js の冒頭約30行を示します。

/*!
 * 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

Kimiは makeL という小さなヘルパー関数を用いて、2つの平行四辺形（傾斜した幹部と脚部）から各L字を生成しています。また inPara というヘルパー関数を isLit 内で使い、点が該当する領域に含まれるか判定しています。ファイルの先頭部分には環状領域の半径値（0.82RからRまで）、Math.tan を用いた20°の傾斜角、反発力や減衰率といった調整用定数がまとめて記述されています。作成されたファイル群（397行の ll-pixel-logo.js、40行の index.html、79行の README.md）は /assets/uploads/2026/09/kimi-codex/ から閲覧可能です。

一方、dshが作成したウィジェット（ソースコード、dshに関する記事でも一部紹介）も同様の手法で制作されています。両者とも幾何学的な計算に基づき環状領域および2つの斜めのL字を描画し、window.LLPixelLogo.mount 関数を提供しており、prefers-reduced-motion 設定にも対応しています。ただし定数値は異なっており、dshでは外側の環状領域半径が19.7、内側が0.80R、傾斜角は0.453（約24°）となっているのに対し、Kimiではそれぞれ19、0.82R、20°を採用しています。またKimi版の線幅はより細く、幹部や脚部は3セル分の厚さですが、dsh版では幹部が4.2セル幅、脚部が3.8セル高さとなっています。このためKimi版では510個のセルが点灯し、dsh版では656個が点灯することになります。どちらも参考となるロゴ画像とは完全には一致しませんが、一目見れば同一のマークだと認識できます。なおdshの第2回挑戦時にはNode用の単体テストやPlaywrightスクリプトも自発的に作成されていましたが、Kimiの第3回挑戦ではテストを行わないよう指示されており、実際にそれが守られています。

Kimiのウィジェットに対して実行した検証コマンド

2026年9月11日に、/assets/uploads/2026/09/kimi-codex/にあるこのページ用のコピーに対して、これらのコマンドを再実行しました：

$ wc -l ll-pixel-logo.js
397 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "node --check passed"
node --check passed

さらに2つの確認作業も行いましたが、それらは私個人用の検証であり、公開していない20行未満の小さなヘルパースクリプトを使って実施したものです。そのため、ここでは直接貼り付けられるコマンドではなく、その方法をご説明します：

点灯セルのカウント。 スタブ化されたDOM（何もしないキャンバスやwindow・documentオブジェクト）を用意した上で、Node環境でウィジェットファイルを読み込み、そのファイル内に定義されている isLit(col, row) 関数を呼び出しました。40×40のグリッド上のすべてのセルに対してこれを実行し、各象限ごとに点灯しているセルの数を集計したところ、合計で510個のセルが点灯していました。具体的には左上が124個、右上が103個、左下が160個、右下が123個です。
マウント処理の確認。 同じくスタブ化されたDOMを用いて、ファイル内で window.LLPixelLogo がオブジェクトとして定義されていること、またスタブ化された要素に対して mount() を呼び出すとエラーにならずにオブジェクトが返ってくることを確認しました。

中心から0.82RからRの範囲内にあるセルだけでも、510個中352個を占めています。残りの158個が2つの「L」字型部分に相当します。なお、これらのヘルパースクリプトはKimi氏の作ったものではなく私自身のもので、あくまで簡易的なテスト用です。実際のブラウザ上での動作確認結果が、今ご覧いただいているこのページとなります。

なぜこのモデルはCodexを通して実行されないのか

OpenClawには、実際の Codexアプリサーバー を起動するためのハーネスプラグインも同梱されています（このアプリサーバーは @openai/codex 0.153.4を管理します）。しかし本記事で紹介している内容はすべてCodexを通さずに実行されます。なぜなら、このモデルを受け付けることができないからです。つまり、configuredModelRouteNeedsCodexというチェック機能において、正規化されたプロバイダーIDが openai でない場合には常に false が返されるのです。MoonshotのプロバイダーIDは moonshot なので、moonshot/kimi-k3というルートは決してCodexランタイムに到達しません。「OpenAI互換」だからといって「Codexハーネス互換」であるとは限らないのです。

そのため、ここで紹介しているKimiモデルはOpenClaw独自の処理ループ内で実行され、他のOpenClawネイティブモデルと同じ挙動をします。Codexにおけるスレッド再開機能やコンパクション処理、ダイナミックツールブリッジ、あるいはアプリサーバーの実行モデルなどは利用できません。もしKimiでもこれらの機能が必要な場合、既知の回避策として codex-router を利用する方法があります。これはローカル側で動作するブリッジであり、Codexに対して 127.0.0.1:4202 上のエンドポイントを指し示し、そこからKimiへとリクエストを転送します（READMEにも記載されています）。この設定がハーネスに認識されるためには、プラグインの appServer.homeScope の値を "user" に設定する必要があります。そうすると、OpenClawエージェントごとにCodexの状態が分離されるのではなく、ユーザーのネイティブな ~/.codex（あるいは $CODEX_HOME）がハーネスと共有されることになります。私自身はこの仕様に納得しているわけではないため、まだ実装していません。

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

あいまいで範囲の広い指示だと推論モデルが停滞し、タイムアウトによって「成功した」ように見えてしまうことがあります。 1回目の試行では8.8分間考え続けたものの、ウィジェット用のコードを一切書き出せませんでした。2回目の試行では正常に動作するウィジェットコードが生成されたのですが、時間切れとなり、生成されたファイルが誤ったフォルダに保存されたため、これも失敗したように見えました。解決策としては、より簡潔な指示を出すことでした。例えば TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. といった具合です。また、保存先フォルダも明確に指定する必要があります。K3はこのような指示でも推論を行いますが、無限に計画を続けることはありません。終了ステータスがどうであれ、セッションで生成された内容やエージェント自身のワークスペースも確認すべきです。
エラー終了コードが出ても必ずしもタスクが失敗したわけではありません。ファイルを確認してみてください。 FizzBuzz処理の最初の呼び出しでは終了コード1が返され、「有効なモデルが見つかりませんでした」と表示された上で、最後に「⚠️ APIの利用制限に達しました。後ほど再度お試しください。」というメッセージが出ました。しかし実際には fizz.py は既に作成されており、正常に動作していました。再試行時には「すでに作成・実行済みです」と返答され、完了を示すメッセージもそのみでした。私のスクリプトでは各実行結果のJSONを同じファイルに書き込んでいたため、失敗した実行分のデータは上書きされてしまいました。ただし、ベンチマークを実施したセッションのログには終了コードや最終メッセージが残っています。表には後から行われた正常な実行結果が記載されています。
他のハーネスで完了した実行結果からスクラッチフォルダをコピーしてはいけません。 dsh側ですでにバグ修正が完了していたファイル群をコピーしてKimi用のバグ修正フォルダを作成したところ、Kimi側での最初の実行時にはそのファイルがすでに修正済みであると認識され、単に検証のみが行われてしまいました。正しいやり方は、未加工の元データからテスト用ファイルをコピーすることです。私はフォルダをリセットした上で新規セッションで再実行しました。表にはその2回目の実行結果が記載されています。

この結果が私に与えた影響

今回の5つのタスクにおいて、Kimi K3は正確な回答をしてくれましたが、処理速度が遅くコストも高かったです。一方で、小さな作業に関しては、V4-Flash上で動作するdshがほぼ同じ作業を、所要時間は約9分の1、費用は約48分の1で実行できました。このベンチマークの後、私はワーカーエージェントをKimiからMiniMax-M3へ切り替えました。一方でKimi K3は引き続き、私のレビューエージェントの背後に配置されたままでした。つまり、より慎重かつ正確な回答が求められる場面においては、多少コストがかかっても利用する価値があるのです。

関連記事：DeepSeek Harness (dsh)（今回比較に用いたツールであり、ベンチマークや課題内容の出典でもあります）、ピクセルアート・ウィジェット対決（3つのウィジェットを並べて比較した記事）、MiniMax M3（2026年9月11日時点で私のワーカーエージェントが利用しているモデルです）、そして私のAIエージェントにかかる実際のコスト：DeepSeekと他の大手APIの比較です。