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

以下の指示文は、8月にDeepSeekのコーディングエージェントであるdsh向けに作成されたものです。9月には、同じ指示文をKimi K3およびMiniMax M3にも与えました。これら二つもそれぞれOpenClaw独自のエージェントループを駆動させ、同一のワーカーエージェント上で処理を行いました。三つのエージェントのうち二つがウィジェットを作成したと報告し、残りの一つも同様に作成したと述べました。このテストから得られた最も有益な成果は、ウィジェットのランキングではありません。それは、エージェントが「作成した」と言っている内容を鵜呑みにする前に、実際にそのエージェントが何を書いたのかを確認すべきだという理由です。

数字について

各エージェントにつき1回の実行のみであり、Kimiの場合は3回試行したため、これは裏付けのある逸話として捉え、ベンチマークとは見なさないでください。各列は、このページにある3つのウィジェットファイルを表しています。

表に記載されていない列が、Kimiの第1回目の試行結果です。未編集の指示文をもとに8.8分間考え続けたものの、ウィジェット用のコードは一切書き出せず、そこで処理が中断されました。その際の費用は約0.31ドルでした。Kimiが行った3回の試行で、2つのウィジェット作成にかかった費用の合計は約1.50ドルになります。一方、dshの最初の試行は失敗に終わり、費用は約2セント程度でした。したがって、dshの処理にかかった費用は全体で約51セントとなります。

試行3のコストは、その試行自体のJSON形式のレシートから得られています。試行1および2ではレシートが生成されなかったため、それらのコストはOpenClawが各セッションごとに記録したメッセージ単位の費用を合計した値となります。試行3の合計額もまた、そのレシートの数値と一致しています。Kimiに関するすべての費用額は、私のOpenClaw設定内で指定されているMoonshotの料金体系に基づいています。

MiniMaxが行ったこと

MiniMax M3にも同じ指示が与えられました。これは、Kimiの試行2の約1時間後に、同じワーカーエージェント上で、同じワークスペース内で実行されたものです。Kimiの試行2で作成されたファイル群はそのまま残っていました。59秒間（25回の処理、24回のツール呼び出し、私が月額固定料金を支払っているプランにおける定価では0.13ドル相当）で、MiniMaxはその5つのファイルおよびKimi自身が作成した実行レポートを読み込み、Kimiの作成した2つのテストファイルを実行した上で「ウィジェットセット全体を構築し、検証完了しました」と返答しました。しかし実際には、ウィジェット用のコードを一行も書いていません。MiniMaxが作成したのは、自身の実行レポートおよびステータスファイルのみでした。

私はその返答を信じました。このページの最初のバージョンでは、MiniMaxに3つ目のセルが割り当てられており、そこには1回の試行結果として59秒と0.13ドルという記録、そして「最も安価な実行方法が最も速く、かつ初回の試行で成功した唯一の方法である」という結論が記載されていました。セッションログを確認したところ、そのセル内のファイルは、日本時間の朝08時11分にKimiの2回目の試行で作成されたものと完全に同一であることが判明しました。また、MiniMaxのセッションではそのファイルを読み込んでいるだけで、書き込みは行われていません。したがって、MiniMaxにはこのページ上で使用できるウィジェットは存在しません。公正なテストとしては、空のフォルダー内で同じ内容を再実行してみるべきですが、私はまだそれを行っていません。

鏡像版は、Kimiの試み2です。この鏡像版は自身のワークスペースにウィジェットやテストコード、そして短いレポートを書き込んだのですが、返答する前に処理が中断されてしまったため、私の見ている限りでは何も生成していないように見えました。一方の実行では、実際には行っていない作業が行われたことになっており、もう一方では誰にも見られない作業が実行されました。どちらの場合も、返答内容とディスク上のファイル内容が一致せず、実際にはファイルの方が正しかったのです。

3つすべてを試してみましょう

当初、このページのドラフト版には、Reasonix用の4番目の空欄セルが存在しました。しかし、Reasonixはこの依頼を実行することはなく、私もその後自分のマシンから該当データを削除したため、比較対象から外れています。

実際に何が違うのか

ここに記載されている内容は、3つのスクリプトを読んだ結果であり、エージェント自身がそれらについて述べた内容ではありません。

共通点について。 3つの実装すべてで、仕様書に記載された4色が正確にハードコーディングされています。静止状態ではピクセルはロゴの青色付近に位置しており、少しずれたピクセルは青色からハイライト用の青色を経てシアン色へと変化します。また3つすべてで、仕様書で提案されていた最初のクリック効果も実装しています。すなわち、ロゴがピクセルに分解されて重力により落下した後、再び一つにまとまるという効果です。dshおよびKimiの「試行2」では、仕様書に記載された2つの提案からこの効果を選択しました。一方「試行3」では、入力したプロンプトが短かったため、その1つだけが選択肢として提示されました。さらに3つすべてにおいて、prefers-reduced-motion設定にも対応しており、タッチ操作も問題なく利用でき、コード量も仕様書で定められた約400行以下に収まっています。

形状について。 指示では、半径0.82RからRまでのリングを作り、L字部分を約20°傾けることが求められていました。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リットルセルとなり、3つの中で最も大きな構造となりました。しかし、どの試作品も実際のロゴに十分近くなく、代用することはできません。

クリックの動作。 dshは0.72秒間だけ動き出し、その後各ピクセルが0.5秒以内のランダムなタイミングで元の位置に戻っていくため、ロゴが再び一つにまとまります。また、4つの壁からもピクセルが跳ね返ります。ほとんど動きのない素早いタップのみを「クリック」として認識するため、タッチスクロールによってロゴが崩れることはありません。Kimiの試行3では0.85秒間だけピクセルが飛び出し、その後元の位置に戻って全てが落ち着きますが、ロゴが完全に元通りになるまでクリックは無視されます。動作を減らした設定下では、クリック時に小さなパルスが発生します。なお、指定された要件では静的なロゴであることが求められていました。Kimiの試行2では0.85秒間ピクセルが飛び出し、1.0秒後に元の位置に戻りますが、床面からのみ跳ね返るだけで、飛行中に再びクリックされるとロゴはまた崩れてしまいます。

アイドル状態。 dshでは、ゆっくりとした色のきらめきが発生し、1.2秒から3.8秒ごとに1つから3つの琥珀色またはシアン色のピクセルが点滅します。Kimiの試みでは、各ピクセルの不透明度が3回変化し、0.2秒から0.6秒ごとに新たな琥珀色のきらめきが加わるため、3つの中で最も活発な動作を見せます。また、その試み2では、1秒間に約2回ほど琥珀色またはシアン色のピクセルが点滅し、ポインターに最も近いピクセルの背後に柔らかな光輪が描かれます。

コードについて。 dshは、プロトタイプメソッドを持つ Widget コンストラクタであり、mount() メソッドも備えています。また、data-size、data-speed、data-static といった設定項目も用意されています。一方、Kimiの試作3では Logo コンストラクタが使用されており、2つの幾何学用ヘルパー関数（inPara と makeL）を基盤としてプロトタイプメソッドが実装されており、data-interactive という設定項目も存在します。試作2の場合はコンストラクタ自体が存在せず、createInstance() が単なるオブジェクトを返すだけで、物理処理は独立した関数内で実装されています。さらに、Nodeモジュールとしてもエクスポートされているため、ブラウザなしでもテストを実行できる仕組みになっています。同じモデルなのに、構造がほとんど共通していない2つのファイルがあるわけです。

なぜそれぞれが別々のフレーム内に配置されるのか。 仕様書には「.ll-pixel-logo要素をすべて見つけ出し、その中にキャンバスを配置する」と記載されており、3つのスクリプトはまさにそれを実行しています。各スクリプトは自身が配置したコンテナにそれぞれ異なるプロパティ名を付与し、共通のwindow.LLPixelLogoも上書きしています。そのため、3つのスクリプトがすべて同じページ上で動作すると、各コンテナ内には3つのキャンバスが重なって表示されてしまうのです。このページの最初の草案ではまさにこのバグが存在し、私は携帯電話で初めてそれに気づきました。ウィジェットごとにフレームを分けることで、各スクリプトのコードを一切変更することなく互いを分離することができるのです。

この状況が私に与える影響

2人のエージェントが、この指示に基づいてウィジェットを作成しました。dshは3週間前に一度失敗した経験があるにもかかわらず、2回の試みの末にようやく機能するウィジェットを作り上げ、その際にかかった費用は約49セントでした。一方、Kimiは3回の試行を重ね、合計で約1.50ドルを費やして2種類の正常に動作するウィジェットを作成しました。そのうち1つについては、私が調べてみるまで存在すら知りませんでした。3人目のエージェントからの返答は、他人のファイルに関する自信に満ちた内容でした。

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

依頼内容（全文を引用）

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

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

「reference-logo.png」に示されている通り、**LaserLloydロゴのピクセルアート版**を作成してください。白地の背景上に、色番号#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`クラスを持つ要素を探し、その中に``要素を配置します。レスポンシブ対応で、キャンバスはコンテナの幅いっぱいに表示され、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」は約20度傾いた平行四辺形で構成され、左上の「L」の脚部が右下の「L」の幹のすぐ下に位置します。これらを調整して、200ピクセル幅でも元のロゴと見分けがつくようにしてください。なお、点灯するピクセルは一度だけ事前計算しておいてください。
- 配色：ロゴ用青色#1f3f8f、ハイライト用青色#2ea8ff、琥珀色#ffb64a、シアン色#00e6cf。背景は透明です。

## インタラクション（この課題の要点です。楽しく魅力的な体験を実現してください）
- **マウスオーバー／タッチ移動時：** カーソル付近のピクセルが物理的に反応します。例えば流体や磁気力のようにカーソルから遠ざかり、その後減衰しながら元の位置に戻ります。移動中は#2ea8ffまたは#00e6cf色へと発光します。`requestAnimationFrame`を用いて60fpsで滑らかに描画し、動作の乱れが生じないようにしてください。
- **クリック／タップ時：** 感動的で満足感のある効果を1つだけ選んで実装してください。例えばロゴ全体がピクセルに分解されて重力や反発力により外側へ飛び散り、その後再び元の形に戻る（約1.5〜2秒かかります）。または「レーザー」が走り、光る火花を伴いながらロゴをピクセル単位で再描画するなども可能です。繰り返しクリックしても問題なく動作するようにしてください（アニメーション中に中断させないこと）。
- **待機時：** 微かな揺らぎや時折ピクセルがきらめくような動きを加えてください。そうすることでウィジェットが完全に静止している印象を与えず、かつ邪魔にならない程度のアニメーションとなります。
- `prefers-reduced-motion: reduce`属性が設定されている場合は、静的なロゴのみを描画し、ホバー時の発光効果だけを維持してください。
- マウスおよびタッチ操作の両方に対応させること。スクロール動作の制御も行わないようにしてください。

## 品質基準
- コードは整然としており、適切なコメントが付記されていること。`LLPixelLogo`以外にグローバル変数を使用してはいけません。タブ幅は2とし、全体の行数は400行未満であること。
- `file://`プロトコルからでも実行可能で、コンソールエラーが一切出ないこと。ご自身でテストを行ってください。小さなNodeスクリプトを作成するか、任意のツールを用いて構文チェックやモジュールの動作確認（例：ビットマップ内の点灯ピクセル数を数え、輪と2つの「L」が正しい位置にあることを検証するなど）を行ってください。なお`jsdom`は利用できませんので、`node --check`のみでテストしてください。
- 最後に簡潔なレポートを出力すること。作成した内容、埋め込み方法、および確認事項などを記載してください。

使用ソフトウェア群

• 指示書： 上記に全文記載されています。
• dsh： 8月時点でウィジェット作成に使用したバージョンは0.1.0-rc.7（2026年9月11日現在では0.1.1-rc.2）。利用したAIエンジンはDeepSeek V4-Flashです。
• Kimi K3およびMiniMax M3： いずれもOpenClaw 2026.9.2を使用し、独自のエージェントループおよび共通のワーカーエージェントが用いられています。
• 各ウィジェット： dsh版、Kimiの3回目の試行版、Kimiの2回目の試行版です。これらは一切修正されていません。各ウィジェットはそれぞれ専用のHTMLページ内に埋め込まれ、iframeから参照されています。
• 本ページに対する検証内容： 3つのスクリプトすべてに対してnode --checkを実行しました。また40×40グリッド上で各スクリプトのisLit関数を呼び出して点灯ピクセル数を数え、各ファイルのハッシュ値とエージェントのログ内記録と照合することで作成者情報も確認しました。さらに390、768、1280ピクセル幅それぞれでヘッドレス版Chromiumを用いてテストを行い、各フレームにキャンバスが1つずつ生成され、指示書の内容がすべて表示されており、横スクロールもコンソールエラーも存在しないことを確認しています。
• 表紙画像： 手書きで作成したSVGであり、画像モデルは一切使用していません。

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