ピクセルアート・ウィジェット対決：3人のコーディングエージェント、1つの課題、2人の制作者

以下の指示文は、8月に dsh 向けに作成されたものです。dshとは DeepSeek が開発したコーディングエージェントです。9月には、同じ指示文を Kimi K3 および MiniMax M3 にも与えました。どちらも OpenClaw 独自のエージェントループを利用し、同じワーカーエージェント上で順番に処理を行いました。3つのエージェントのうち2つがウィジェットを作成しました。残る1つは「作成した」と述べました。このテストから得られた最も有益な教訓は、ウィジェットの優劣を比較することではなく、エージェントが実際に何を書いたかを確認してからその発言を信じるべきだ、という点です。

数値の詳細

各エージェントにつき1回ずつ実行しましたが、Kimi は3回試行したため、これらはあくまで実例に過ぎません。ベンチマークとして扱うべきではありません。各列はこのページにある3つのウィジェットファイルを示しています（スマートフォンでは横にスワイプしてください）。

表に含まれていないのが Kimi の1回目の試行です。修正されていない指示文を与えられたところ、8.8分間考え続けた末にウィジェットコードは一切作成せず、途中で停止しました。その費用は約0.31ドルでした。Kimi の3回の試行で合計約1.50ドルを支払い、2つのウィジェットができあがりました。一方 dsh の失敗した1回目の試行では約2セントしかかからず、全体としては約51セントで済みました。

Kimi の費用は OpenClaw が定めるメッセージ単位の料金を合計したものです。3回目の試行分については、その合計額が実際の請求額と一致しています。計算方法や料金体系については Kimi に関する記事をご覧ください。

3つすべてを試してみる

本ページの初期版では、Reasonix 用の空欄セルも用意されていました。しかし Reasonix はこの指示文を実行しておらず、私もその後自身の環境から同エージェントを削除したため、比較対象から外しています。

実際に何が違うのか

ここに記載されている内容はすべて、3つのスクリプトを読み解いた結果であり、各エージェントが自ら述べた説明によるものではありません。

共通点。 3つとも指示文で指定された4色をそのまま使用しています。静止状態ではピクセルはロゴの青色付近に留まり、少しずれたピクセルだけがハイライト用の青からシアンへと光ります。また3つとも指示文で推奨されていた最初のクリック効果を実装しています。すなわちロゴがバラバラになった後、重力に従って元の位置へ戻る仕組みです。dsh および Kimi の2回目の試行分は指示文にある2つの案からこれを選びましたが、3回目の短縮版指示文ではこの方法のみが提示されていました。さらに3つとも prefers-reduced-motion をチェックし、タッチ操作にも対応しており、行数も約400行以内に抑えられています。

形状。 指示文では「半径0.82RからRまでのリング」および「約20度傾いたL字型」が求められていました。Kimi の3回目の試行分はこれを忠実に再現し（Math.tan(20 * Math.PI / 180)を用い、幹部は3セル幅）、点灯しているセル数も510個と最も少なくなりました。2回目の試行分では0.42（約23度）傾け、幹部を4.6セル幅にして602個となりました。dsh は0.453（約24度）傾け、4.2セル幅の幹部と0.80Rから始まるやや太めのリングを採用し、656個という最も大きな形状になっています。いずれも実物のロゴに完全に一致するには至っていません。

クリック時の挙動。 dsh では0.72秒間パルスが発生した後、各ピクセルがランダムなタイミングで元の位置へ戻るため、ロゴ全体が波打ちながら復元します。4つの壁すべてで跳ね返り、小さな動きしか伴わないタップはクリックとして認識されないため、スクロール操作では崩壊しません。Kimi の3回目の試行分では0.85秒間飛び回った後元へ戻る仕様で、ロゴが完全に復元するまでクリックを無視します。減速モード下でもクリックでパルスが発生し、ホバー時にもピクセルが押し出される点は、静的なロゴでホバー時のみ光るべきという指示文に反しています。2回目の試行分も0.85秒間飛び回った後1.0秒かけて戻り、床面でのみ跳ね返る仕様ですが、飛行中に新たなクリックがあれば再び崩壊します。

アイドル時の挙動。 dsh ではゆっくりと色が変化し、1.2～3.8秒ごとに琥珀色またはシアン色のピクセルが1～3個光ります。Kimi の3回目の試行分では各ピクセルの不透明度が脈打ち、0.2～0.6秒ごとに新たな琥珀色のきらめきが加わるため、最も賑やかな動作となっています。2回目の試行分では1秒間に約2回琥珀色またはシアン色のピクセルが点滅し、ポインタ付近のピクセルには柔らかな光輪が描かれます。

コード構造。 dsh では Widget というコンストラクタにプロトタイプメソッドが備わり、mount() が別途存在し、data-size、data-speed、data-static といったパラメータも用意されています。Kimi の3回目の試行分では Logo コンストラクタにプロトタイプメソッドがあり、2つの幾何学ヘルパー（inPara および makeL）を利用しており、data-interactive も設定されています。2回目の試行分にはコンストラクタが存在せず、createInstance() が単純なオブジェクトを返し、物理演算部分は独立した関数として実装されています。また Node モジュールとしてエクスポートされているため、ブラウザなしでもテストが可能となっています。同じモデルを使用しているにもかかわらず、構造面でほとんど共通点がないのです。

各ウィジェットが別々のフレーム内にある理由。 指示文には「すべての .ll-pixel-logo 要素を見つけ、その中にキャンバスを配置する」と記載されており、3つともまさにその通りに動作しています。ただし各エージェントはそれぞれ異なるプロパティ名で自身が配置したコンテナをマークし、共通の window.LLPixelLogo も上書きしてしまうため、3つのスクリプトを同一ページ上で動作させるとすべてのコンテナに3つのキャンバスが重なって表示されてしまいます。本ページの初版ではこの不具合がそのまま残っており、私自身もスマートフォン上で初めて気付きました。各ウィジェットごとに別フレームを用いることで、コードを一切変更せずに互いの干渉を防ぐことができます。

MiniMax の行動と今後の見通し

MiniMax M3 にも同じ指示文が与えられました。修正なしのままで、Kimi の2回目の試行から約1時間後に同じワーカーエージェント上で実行され、同一の作業領域を利用していました。この時点で Kimi の2回目の試行分ファイルがそのまま残っていました。59秒間（25回のやり取り、24回のツール呼び出し、月額固定料金制プランにおける定価ベースで0.13ドル）で MiniMax はこれら5つのファイルおよび Kimi 自身の実行レポートを読み込み、2つのテストファイルも実行した上で「全ウィジェットセットを作成・検証済み」と返答しました。しかしウィジェットコードは一切記述していません。作成されたのは自身の実行レポートおよびステータスファイルのみです。

私はその返答を信じてしまいました。本ページの初版では MiniMax 用に3つ目のセルが用意され、1回の試行で59秒、0.13ドルという記録とともに「最も安価な実行が最速かつ唯一の成功例である」という結論が示されていました。しかしセッションログを確認したところ、そのセル内のファイルはまさにその日の朝08時11分に Kimi の2回目の試行で作成されたものと完全に同一であり、MiniMax 側のログには読み込み記録しかなく書き込みは存在しませんでした。つまりこのページ上では MiniMax によるウィジェットは存在しないのです。公正なテストを行うためには、空のフォルダーで再度指示文を与えて実行する必要がありますが、私はまだそうしていません。

対照的な例として Kimi の2回目の試行分が挙げられます。こちらは自身の作業領域にウィジェット、テスト、および短いレポートを作成した後、返答する前に中断されてしまいました。私が見守っている限りでは何も生成していないように見えました。一方で MiniMax は実際には何もせずに報告だけ行っています。両者とも返答内容とディスク上のファイル状態が食い違っており、正しいのは後者であることが判明しました。

以上より、この指示文に基づいてウィジェットを作成したのは2つのエージェントのみです。dsh は2回試行し、約49セントの費用で1つの成功例を作り上げました。これは3週間前のことで、その時点では既に一度指示文を破っていました。一方 Kimi は3回試行して合計約1.50ドルを要し、2種類の正常なウィジェットを生み出しました。そのうち1つについては私が調査するまで気付いていませんでした。

この結果をもとに各ウィジェットのランキングを作成するつもりはありません。各エージェントには1回ずつ実行機会が与えられましたし、dshの場合は初回失敗後に指示内容が修正されていました。また、Kimiの3回目の試みでは他の誰よりも短いプロンプトが用いられていました。私が得た教訓はあくまでプロセスに関するものです。手順や幾何学的ルールが明確に記載された指示さえあれば、能力のあるエージェントであれば最終的には機能するウィジェットを作成してくれます。どのエージェントが作成したかは、何を確認するかによります。次回この実験を行う際には、各エージェントに空のフォルダーを用意し、要約文を読む前にそのセッション内で書き込まれたファイル内容を確認することにします。

指示内容（全文引用）

以下がdshの2回目の試み、Kimiの最初の2回の試行、そしてMiniMax M3にも与えられた指示内容です。サイズは3,301バイトです。なお、dshの初回試行時には手書きビットマップも許容する旧版の指示が用いられていました。「ビットマップを手で描いてはならない」という一文が修正点となります。Kimiの3回目の試みでは、表に記載された指示内容を含む短縮版が与えられました。

# 指示：インタラクティブなピクセルアート風LaserLloydロゴ・ウィジェット

「reference-logo.png」に示されている通り、**LaserLloydロゴのピクセルアート版**を作成してください。白地の背景上に青色（#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`要素を探し出し、その中に``要素を配置します。レスポンシブ対応で、キャンバスのサイズはコンテナ幅に合わせられ、HiDPI環境でも鮮明に表示されます。`window.LLPixelLogo.mount(el)`という関数も用意されています。
2. `index.html` — 3種類のサイズでウィジェットがどのように見えるかを示すデモページです。各サイズでのインタラクションに関する簡単な説明も記載されています。
3. `README.md` — 埋め込み方法、インタラクションの内容、および使用可能なデータ属性などを記述したドキュメントです。

## アート面の要件
- 40×40ピクセルからなるグリッドを使用します。「ビットマップを手で描いてはならない」：「#」や「.」で構成される行を書くのは避けてください。そのような記述は処理が遅く、誤りも生じやすいためです。代わりに幾何学的なルールに基づきピクセルを生成してください。`isLit(col,row)`という関数を用意し、以下の条件で`true`を返すようにします：(a) 中心からの距離が0.82R以上R以下となるリング部分、(b) 2つの斜めの「L」文字。各「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`を実行し、DOMを使わずにビットマップの点灯ピクセル数をカウントする単体テストも行うこと）。リング部分および2つの「L」がそれぞれ正しい位置にあるかも検証してください。
- 最後に簡潔なレポートを出力すること。作成した内容、埋め込み方法、検証事項などを記載してください。

使用ソフトウェア環境

8月時点ではDeepSeek V4-Flash上でdsh 0.1.0-rc.7が用いられました。9月にはOpenClaw 2026.9.2上でKimi K3およびMiniMax M3がそれぞれエージェントループ内の同一ワーカーとして実行されました。このページでの検証内容は以下の通りです：3つのスクリプトすべてに対して<code>node --check</code>を実行し、各スクリプトが持つ<code>isLit</code>関数を用いて40×40グリッド上の点灯ピクセル数をカウントしました。ファイルハッシュとセッションログ内の書き込み内容を照合することで作成者も特定しています。さらに390、768、1280ピクセルの各解像度でヘッドレスChromiumによるテストも行い、各フレームごとにキャンバスを生成し、横スクロールが生じない状態でコンソールエラーが出ないことも確認しました。セットアップ方法やコスト算出法については下記のKimi関連記事をご参照ください。

関連記事：DeepSeek Harness（dsh）（指示内容および最初のウィジェットが生まれた経緯）、Kimi K3をコーディングエージェントとして利用した事例（Kimiによる3回の試行全て）、MiniMax M3をコーディングエージェントとして利用した事例（5つの課題からなるベンチマークおよびウィジェットの混同が生じた経緯）。