AIにChrome拡張を作らせる — KamoXを作った理由と仕組み
AIはコードを書くが、見た目は確認できない
AIにChrome拡張を作らせていた時のこと。「ポップアップにボタンを3つ並べて、クリックしたら背景色が変わる拡張を作って」とお願いすると、コードは正しく返ってくる。manifest.jsonも、popup.htmlも、JavaScriptも。
でも実際にChromeに読み込ませてみると、ボタンが1つしか表示されていなかったり、ServiceWorkerでエラーが出ていたりする。AIはコードを書くことはできるが、自分でビルドして、ブラウザに読み込んで、画面を確認することはできない。つまり「書いたコードが正しく動いているか」をAI自身が確認する手段がない。
これの何が辛いかというと、人間が毎回その確認をやらないといけないことだ。ビルドして、Chromeにリロードして、画面を開いて、エラーが出てないかコンソールを見て。AIに書かせておいて、確認は人間が手作業。これではAIの得意な「試行錯誤を高速で回す」メリットが活きない。
AIの自己確認ループを作りたい
やりたいことはシンプルで、AIに「書いて、確認して、直す」のループを自律的に回してほしい。
ソフトウェア開発は本質的に「書く→確認する→直す」のサイクルだ。人間のエンジニアも同じことをやっている。コードを書いて、ビルドして、画面を見て、ダメなら直す。このサイクルを高速で回せる人が良いエンジニアだと言われる。
AIも同じはず。コードを書く能力は十分にある。でも確認する手段がないから、人間がループに介入しないといけない。AIが自分で結果を確認できれば、人間は最終結果だけ見ればよくなる。
Playwrightを使えばブラウザの自動操作はできる。でもChrome拡張の確認は通常のWebページとは勝手が違う。ServiceWorkerのデバッグ、manifest.jsonの検証、拡張のリロード。Playwright自体は拡張機能にも対応しているが、セットアップ手順が違うし、AIエージェントに毎回その手順を説明して実行させるのは重い。
そこで、Playwrightを内包しつつAIが叩きやすいHTTP APIとしてラップした。ビルドして、起動して、スクリーンショットを撮って、ログを取得する。全部HTTPエンドポイント1つで実行できる。AIはAPIを叩くだけで自己確認ループを回せる。
3プラットフォーム対応の設計
最初はChrome拡張だけだったが、使っているうちにElectronアプリもVSCode拡張も同じ問題があることに気づいた。FubakoをAIと一緒に開発している時に、ElectronアプリのプレビューをAIに確認させたい場面があった。VSCode拡張も、コマンドを実行してUIが正しく出ているかをAIに見せたかった。
3つのプラットフォームはそれぞれ起動方法も確認方法も違う。Chrome拡張はブラウザにロードして、Electronはプロセスを起動して、VSCode拡張はExtension Hostを立ち上げる。でも「ビルド→確認→ログ」というAPIの形は共通化できる。
プラットフォームごとの違いを内部に閉じ込めて、APIのインターフェースを統一した。AI側からは POST /rebuild、POST /check-ui、GET /logs が同じように叩ける。対象がChrome拡張でもElectronでもVSCode拡張でも、AIの呼び出し方は変わらない。
設計の判断としては、プラットフォーム固有の処理をアダプタパターンで分離したこと。各プラットフォームの起動・確認ロジックを独立したモジュールに切り出して、共通のHTTP APIで呼べるようにしている。新しいプラットフォームを追加する時もアダプタを書けば済む。
npmで公開した話
KamoXはnpmで公開している。npm install -g kamox で入る。
npm公開自体は技術的に難しくないが、AIエージェントが使うことを前提にすると設計の優先順位が変わる。まず依存関係を最小にしたい。AIの開発環境に何かが足りなくて動かないという状況を避けたい。Playwrightのブラウザバイナリもできるだけ自動で解決するようにした。
あとパッケージ構成はnpm workspacesにした。Chrome拡張用、Electron用、VSCode拡張用のパッケージを分けて、ルートパッケージがそれらをまとめる形。各プラットフォームのモジュールを独立して開発・テストできるようにしたかった。
CLIの引数設計も工夫した。AIがコマンドを組み立てやすいように、オプションは少なく、予測しやすくしている。人間向けのCLIなら「使いやすさ」の基準が違うが、AI向けなら「一貫性」と「予測可能性」が重要だ。
今の状態と今後
Chrome拡張、Electron、VSCode拡張の3プラットフォームに対応済みで、実際にAIと一緒に開発する時に使っている。このサイトのFubakoもKamoXを使ってAIがプレビューを確認しながら開発している。
まだ改善の余地はある。特にエラーメッセージの設計をもう少し考えたい。AIがログを見て「何が悪いか」を判断できるように、エラーの構造化をもっと整える必要がある。スクリーンショットも、全画面だけでなく特定要素だけ切り抜けるようにするとトークン消費を抑えられるはずだ。
追記(2026.07): この記事の後、ElectronとVSCode対応を大きく作り込んだ。IPCの監視、ネイティブダイアログのモック、VSCode専用のエンドポイント群など。詳しくはKamoXのElectronとVSCode対応を「使える」ようにした話に書いた。