コーディングエージェントとしてのMoonshot上のKimi K3：OpenClawへの組み込み、dshとのベンチマーク比較、そしてピクセルアート風のロゴウィジェットの作成を依頼する

私はOpenClawのワーカーエージェントを、Moonshot社が提供する推論モデルであるKimi K3に向けて設定し、8月にDeepSeek Harness (dsh)のベンチマーク用として使用した5つの小規模なコーディング課題を実行させました。Kimiはその全てをクリアしました。同じ日に、DeepSeek V4-Flashを用いてdshで同じ5つのタスクを再実行したところ、処理時間は約9倍長く（309.9秒対35.7秒）なり、費用も約48倍高く（0.531ドル対0.011ドル）なっていました。続いて、dshがウィジェット作成に使用したピクセルアートのロゴ作成指示書をKimiに渡してみました。Kimiは3回試行する必要がありました。1回目は指示書をそのまま使ったのですが、ウィジェットが一切生成されませんでした。2回目も同じ指示書を使ったところ、完全なウィジェットコードを誤ったフォルダに書き込んだものの、私が設定したタイムアウト時間に達してしまい、その旨が伝えられませんでした。そのため最初は気付きませんでした。3回目では指示書を短くし、「計画や検証の過程なしに一度だけでウィジェットファイルを作成せよ」と指示したところ、うまくいきました。

パスAとパスB、正直なところ

ここで紹介しているのはすべてパスAです。つまり、Kimi K3がOpenClaw独自のエージェントループを使ってMoonshotプロバイダー経由で処理を行う仕組みです。私の環境ではすでにそのプロバイダーの設定が済んでいたため、ワーカーをKimi用に切り替えるにはモデルの変更だけで済みました。

パスBでは、Kimiを実際のCodexアプリサーバーの背後に配置することになります。このアプリサーバーはOpenClawのCodexハーネスプラグインによって起動され（そのプラグインは@openai/codex 0.153.4を管理しています）、私自身はその実装を行っていません。また、この記事で紹介している内容もCodex経由では実行されません。その理由はプラグインのコードにあります。configuredModelRouteNeedsCodexというルートチェック機能が、正規化されたプロバイダーIDがopenaiでない場合には常にfalseを返すのです。MoonshotのプロバイダーIDはmoonshotとなるため、moonshot/kimi-k3というルートからはCodexランタイムへ到達できない仕組みになっています。

既知の回避策としてはcodex-routerが挙げられます。これはローカルなブリッジであり、Codexに対して127.0.0.1:4202上のエンドポイントを指し示し、そこからKimiへ処理を転送する仕組みです（READMEにも記載されています）。この設定がハーネス側に認識されるためには、プラグインのappServer.homeScopeを"user"に設定する必要があります。そうすると、OpenClawエージェントごとにCodexの状態が分離されるのではなく、ネイティブな~/.codex（または$CODEX_HOME）がハーネスと共有されることになります。私自身はこの仕様を受け入れて良いかまだ判断していないため、現時点ではパスBは理論上の選択肢に留まっています。

なお、パスAにも知っておくべき制限があります。各処理結果にはagentHarnessId: "openclaw"という項目が含まれ、これは他のOpenClawネイティブモデルと同じ形式です。ただし、Codexにおけるスレッド再開機能やCodex独自の圧縮処理、動的ツールブリッジ、さらにはアプリサーバー型の実行モデルなどは利用できません。これらが必要な場合には、パスBのみが選択肢となります。

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

以下は、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

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

• K3は常に推論処理を行います。 このプラグインではデフォルトで reasoning_effort: "max" が送信され、low、high、max も受け付けます。私は --thinking max を指定してベンチマークを実行しました。また、K3側でサンプリング設定（temperature、top_pなど）が固定されるため、これらは無視されます。私のモデル設定情報にも supportsTemperature: false と記載されています。「Reply with exactly: PONG.」という単純な指示でさえ、53個もの推論トークンを消費しました。
• 1Mトークンのコンテキスト長が謳われていますが、私は上限を設けています。 OpenClawのMoonshotカタログではK3のコンテキスト長が1,048,576トークンと記載されています。しかし私はモデル設定で contextTokens: 262144 と指定しており、これにより他のモデルと同様のタイミングでセッションが圧縮されるようになっています。実際には1Mトークンではなく256kトークン程度になる見込みです。
• コスト削減はキャッシュのおかげです。 各タスクの開始時には、システムプロンプトやツール定義として約15,000トークンが使用されます。最初の処理以降は、その大部分がキャッシュから読み込まれるため、コストは1百万トークンあたり0.30ドルとなり、通常料金の3ドルよりも大幅に安くなります。今回の名前変更タスクでは、キャッシュからの読み込みだけで157,952トークンにも達しました。

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

手順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 を記述する場合は、上記の例のようにオブジェクト全体を書き込む必要があります。

contextTokens: 262144 という行は、設定手順に記載されている上限値です。この値を引き上げると、セッションごとにキャッシュ読み取りにかかるコストや1ターンあたりのレイテンシーが増加することが予想されます。

ステップ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" がパスAの特徴となります。Codexアプリサーバーを経由した場合には "codex" と表示されます。winnerModel: "kimi-k3" は、その処理が実際にK3上で実行され、より安価なモデルにフォールバックしていないことを示します。reasoningTokens の数値は output 内でカウントされており（合計値は入力分＋出力分となります）、したがって53個の推論トークンは70という総数の一部となります。

並べて比較：OpenClaw上のKimi K3とdsh

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

	OpenClaw上のKimi K3（パスA）	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使用、2回目の実行時はキャッシュ有効）
ピクセルアート生成タスク（同じ指示内容）	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とは別会社であり、その結果については別途記事で紹介しています。

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

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

タスク	Kimi K3（パスA）	dsh V4-Flash（同日実行）	dsh V4-Pro（8月時点の歴史データ）	Gemma-4-26B（8月時点の歴史データ）
「PONG」と返信する（起動＋1回呼び出し）	✅ 6.1秒 · ツール0個	✅ 1.7秒 · ツール0個	✅ 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個（実行、書き込み。4ファイルにわたり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の料金率は私がOpenClawに登録した情報を基に算出されており、最新の料金はMoonshotの料金ページでご確認いただけます。dsh V4-Flashのコスト計算にはdsh記事と同じ最高料率が用いられています（DeepSeekの料金体系）。V4-ProおよびGemmaの行は同記事に記載された数値です。

この表から分かる点は以下の通りです：

• 全タスクで成功しています。 どのタスクにおいてもKimiが失敗することはありませんでした。バグ修正時にはテストコードに一切手を加えず、関数名変更時にも4ファイルに対してsedを1回実行しただけで、その後テストが問題なく通り、古い関数名をgrepで探しても何も見つからない結果となりました。
• Kimiは推論に多くの時間を費やしています。 K3は5つのタスクを通じてそれぞれ53、241、315、1,586、1,858個の推論用トークンを使用し（合計4,053個）、V4-Flash上のdshも同様に推論を行いますがその量は少なく、0、52、834、5、1,093個（合計1,984個）でした。Kimiの余分な時間の大部分は推論処理や追加手順に費やされているのです。
• キャッシュがコストに大きく影響します。 5つのタスク全体でKimiは91,470個の未キャッシュ入力トークンを送信し、355,328個をキャッシュから読み込んだため、入力トークンの80％がキャッシュ由来となりました。これらをすべて未キャッシュ入力として計算すれば、実行コストは0.53ドルではなく約1.49ドルになる計算です。
• 小規模な作業においてはV4-Flashが優れています。 35.7秒で全タスクを処理し約0.011ドルのコストで済むV4-Flashは、同じタスクを実行するKimiと比べて約9倍速く、48倍も安価です。関数名変更だけを見てもKimiは128.9秒と0.180ドルかかったのに対し、dshは12.3秒と0.0043ドルで済んでいます。

楽しいテスト：同じウィジェットの指示内容を、キミとdshで実行してみる

dsh氏の記事に掲載されていた「面白いテスト」とは、書面で与えられた指示に基づき、dsh氏がV4-Flashを使って作成した、当サイトのロゴを描いたピクセルアートのウィジェットでした。私はキミにも同様の指示書を修正せずに渡し、所要時間を計測しました。その指示書は以下の通りです。

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

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

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

1. ll-pixel-logo.js — 依存関係なし、ビルド不要、ネットワーク通信も不要なシンプルなバニラJSファイルです。任意のページで次のように埋め込めます：<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つで構成され、左上の「L」の脚が右下の「L」の幹の下に重なるように配置されていること。200pxサイズで参照画像と同じ見た目になるよう、いくつかの定数を調整してください。また、点灯するピクセルはマウント時に一度だけ事前計算しておくこと。
• 配色は以下の通りです：ロゴ用青色 #1f3f8f、ハイライト用青色 #2ea8ff、琥珀色 #ffb64a、シアン色 #00e6cf、背景は透明とします。

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

• マウスオーバー／タッチ移動： ポインター付近のピクセルが物理的に反応します。例えば、流体や磁気的な反発力によりカーソルから押し出され、その後減衰しながら元の位置に戻ります。変位中は #2ea8ff または #00e6cf へと光り輝きます。requestAnimationFrameを使って60fpsで滑らかに動作させ、カクつきがないようにしてください。
• クリック／タップ： 何か魅力的で満足感のある効果を1つだけ実装してください。例えば、ロゴ全体がピクセルに分解されて重力や反発力により飛び散り、約1.5〜2秒後に再び元の形に戻る処理、または「レーザー」が走査して光る火花と共にロゴを一ピクセルずつ再描画する処理などです。繰り返しクリックしても問題なく動作すること（アニメーション中に中断しないこと）。
• アイドル状態： ごくわずかなアンビエントな動き（ゆっくりとしたきらめきや時折のピクセルの点滅など）を加えてください。これによりロゴが死んだように見えないようにしつつ、煩わしくならない程度にしてください。
• prefers-reduced-motion: reduce が設定されている場合は、静的なロゴのみを描画し、ホバー時の光り輝きだけを維持してください。
• マウスおよびタッチの両方に対応させてください。ページのスクロールを妨げないようにもご注意ください。

品質基準

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

キミがどのように対応したか：

• 第1回目の試み（短縮版の指示書、編集なし）：8.8分で中断。ウィジェット用コードは一切作成されず、費用は約0.31ドル。 K3は参照用のロゴを確認し、幾何学的な形状やツールの使い方について考察したものの、最終的に成果物は一切作成されませんでした。dshの最初の試みも同様に失敗しています（10分間、頭の中でビットマップを描き続けただけ）。ただしその時点では手書きのビットマップも許可されていました。
• 第2回目の試み（同じ指示書を使い、新しいセッション）：完全なウィジェットが作成されたが場所が間違っていた。費用は約0.72ドル。 約8分後には323行からなる ll-pixel-logo.js を作成し、続いてデモページやREADME、2つのテストファイルも作成。テストを実行して合格するまで調整を行い、短いレポートも書き上げました。しかしこれらすべてはワーカーエージェント自身の作業領域に保存され、私のスクリプトが監視しているフォルダには入りませんでした。15分のタイムアウト時間に達する前に応答もなかったため、第2回目の試みでは何も成果が得られていませんでした。そこで私は約7分後から第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 K3のビルド版が実行されている様子です：

Kimiさんは、makeLという補助関数を使って、それぞれのL文字を2つの平行四辺形（傾いた胴体部分と足部分）から構成しています。また、isLit関数内でinParaという補助関数を用いて各点が条件を満たすかどうかを判定しています。さらに、リングの半径が0.82RからRまでであること、Math.tanを用いた20度の傾き、バネ定数や減衰係数といった調整用の定数もすべてファイルの先頭部分にまとめて記述しています。

Kimiさんが作成したファイル（397行からなる ll-pixel-logo.js、40行の index.html、そして79行の README.md）は、/assets/uploads/2026/09/kimi-codex/ から提供されており、指示書である BRIEF.md も同ディレクトリ内にあります。

比較用として、/assets/uploads/2026/08/deepseek-harness/ll-pixel-logo.jsから配信されているdshのウィジェットの最初の約30行をご覧ください：

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

この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.jsにてウィジェットファイルを読み込みました。その後、ファイル内にある isLit(col, row) 関数を呼び出し、40×40のグリッド上のすべてのセルについて点灯状態を調べ、四象限ごとに点灯セルの数を集計しました。その結果、合計510個のセルが点灯しており、左上が124個、右上が103個、左下が160個、右下が123個でした。
• マウント処理の確認。 同じくスタブ化されたDOM環境下で、ファイル内に window.LLPixelLogo というオブジェクトが定義されていること、またスタブ化された要素に対して mount() を呼び出した際にエラーが発生せずオブジェクトが返されることを確認しました。

単独で環状の領域（中心位置が0.82RからRの範囲内にあるセル、ここでR=19）だけでも510個中352個を占めており、残りの158個が2つの「L」字型部分に該当します。これらの補助スクリプトは私自身が作成したものでありKimi氏によるものではなく、単なる簡易テスト用です。実際のブラウザでの動作結果は、今お読みいただいているこのページそのものです。

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

• 「OpenAI互換」＝「Codexハーネス互換」ではない。 Moonshotの /v1/chat/completions はOpenClawプロバイダーとして問題なく動作しますが、CodexハーネスプラグインではプロバイダーIDが openai であるルートのみを受け付けます。もしCodexのスレッド再開機能や動的ツールブリッジがどうしても必要な場合、選択肢はパスB（Codexルーター・ブリッジ）のみとなります。上記のパスAとパスBの違いをご参照ください。
• K3は、たとえ単純な返答であっても必ず推論処理を行う。 「正確に『PONG』と返信せよ」という指示に対して53個の推論トークンが消費されました。これは設計上の仕様であり予測可能なことなので、その分のコストを見積もっておく必要があります。
• compatブロックはマージではなく置き換えとなる。 temperature パラメータを使用不可にするためにモデルエントリに compat を追加する場合、プラグイン側の reasoning-effort 関連フィールドも同様にコピーしなければなりません。そうしないとそれらが意図せず失われてしまいます。
• 1Mコンテキストという表記は宣伝用であり、私の制限値とは異なる。 カタログ上では1,048,576トークンと記載されていますが、私の設定では contextTokens: 262144 となっており、セッションは256k単位で圧縮されます。意図的にこの値を引き上げる必要があります。
• キャッシュ割引は実在しますが、適用される料金はフラッグシップレートである。 キャッシュからの読み取り時には100万トークンあたり0.30ドルが課され、これは dsh V4-Flash の0.014ドルと比べて約21倍にもなります。それでもキャッシュを利用することで無キャッシュ時の3分の1程度までコストを削減できました。
• 自由度の高い創作指示は推論モデルを停滞させ、タイムアウトが成功を隠してしまうこともある。 第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 は既に作成されており、正常に動作しました。再実行時には「既に作成・実行済みです」とのみ返答され、完了フラグも付きました。私のスクリプトでは各実行結果を同一ファイルに記録しているため、失敗した実行分の情報は上書きされてしまいましたが、その終了コードや最終メッセージはベンチマークを実施したセッションのログ内に残っています。表には新たなセッションで正常に完了した結果が記載されています。
• 他のハーネスで完了した実行結果からスクラッチフォルダをコピーしてはいけない。 dsh側ですでにバグ修正が済んでいたにもかかわらず、私はKimi用の修正用フォルダをdshの完了フォルダからコピーしてしまいました。その結果、Kimiの最初の修正実行ではファイルが既に直っていると判断され、単に検証だけが行われた形になりました。その後フォルダを初期化し新規セッションで再実行した際の結果が表に記載されています。また、dshは起動元ディレクトリ内で作業する仕様となっており、私の最初のスクリプトでは cd 操作を行わず誤った場所にファイルを書き込んでしまい、5つのタスクすべてを再実行する羽目になりました。
• どちらのウィジェットも参照用ロゴと完全には一致しない。 指示では200ピクセル幅でロゴとして見えるよう定数を調整せよとなっています。実際にリリースする前には、ストロークの太さや傾きなどを10分程度は調整する必要があるでしょう。

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

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

もう一つのパスである「Codexルーター」を介して実際のCodexアプリサーバーへ接続する仕組みについては、homeScope: "user"が何を共有するのかを十分に理解できるまで、まだ実装を見送るつもりです。それまでは、私の環境における「コーディングエージェントとしてのKimi」とは、他のOpenClawネイティブモデルと同様に、OpenClawのネイティブループを駆動する役割を担う存在ということになります。

関連記事：DeepSeek Harness (dsh)（今回のベンチマークや課題設定の出典となったツール）、MiniMax M3（2026年9月11日時点で私のワーカーエージェントとして使用しているモデル）、Reasonix（過去に使用していたが、2026年9月9日に利用を停止したモデル）、および私のAIエージェントたちの実際のコスト（各モデルの価格比較に関する記事）。