1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Playwrightはあるのに、AIエージェントにChrome拡張やElectronのUI確認は気軽には頼めない

1
Posted at

AIに拡張機能を作らせると起きること

Chrome拡張をAIに作ってもらっています。Claude CodeでもCursorでも、コードを書くところまでは速いんですが、問題はその先です。

「ビルドしてブラウザにロードして、ポップアップ開いて、ボタン押して、コンソール見て」

これを毎回人間がやります。AIはコードを書けますが、書いたものが画面上でどう見えるかは確認できません。ボタンも押せないし、ログも読めない。結果として、人間がAIの目と手の代わりになります。

最初は「まあそういうもんか」と思ってやっていました。でもUI調整のフェーズに入ると地獄です。「ボタンの位置を右に20px」「フォントサイズを14pxに」みたいな修正のたびに、ビルド→ロード→スクショ→AIに貼って「どう?」と聞く。AIがコードを直す。またビルド→ロード→スクショ。このループが延々と続きます。

これはChrome拡張に限った話ではありません。ElectronアプリでもVSCode拡張でも、「ブラウザで普通に開けないUI」をAIに作らせると同じことが起きます。

WebアプリならPlaywrightで済むが、拡張機能やElectronだと話が変わる

普通のWebアプリやサイトなら、Playwrightで開いてスクショを撮ってクリックして、で完結します。AIエージェントに「Playwrightで確認して」と言えばやってくれます。

Chrome拡張でもPlaywrightは使えますし、公式ドキュメントもあります。ただ、セットアップが普通のWebとは違います。launchPersistentContextで拡張をロードして、Service WorkerのURLから動的にIDを取得して、chrome-extension://{id}/popup.htmlにアクセスする。popupは通常のページとはライフサイクルが違いますし、MV3のService Workerはアイドル状態になると停止するので、常駐プロセスのようには扱えません。人間が書くテストコードとしては問題なくて、ドキュメント通りにやれば動きます。

問題は、これをAIエージェントにやらせようとしたときです。エージェントには「ビルドして確認して」と言いたいだけなのに、まずPlaywrightのセットアップコードを書かせて、拡張固有のコンテキスト管理を理解させて、テストを書かせて、実行して、結果をパースさせることになります。確認したいだけなのに、やることが多すぎる。

Electronも似た状況です。PlaywrightにはElectron対応があって(experimental扱いですが)、electron.launchでアプリを起動すれば基本的なUI操作は動きます。ただ、Electronのdialog.showOpenDialog()などが開くOSネイティブダイアログは、DOM操作の外側なのでPlaywrightからは扱えず、モックを差し込む仕組みが要ります。メインプロセスとレンダラーの間のIPCを見たければ、監視の仕込みも自前です。Electronアプリの不具合はIPCの向こう側で起きていることが多いので、画面だけ見えても確認としては半分です。

VSCode拡張になると、そもそもPlaywrightの土俵ですらありません。VSCode自体はElectronアプリですが、拡張のテストは@vscode/test-electronでExtension Development Hostを立ち上げる、また別の世界です。コマンドを実行して、Problemsパネルや通知の状態を確認して、という操作をエージェントにやらせようとすると、今度はこの仕組みを一からセットアップさせることになります。

つまり、どのプラットフォームも確認する手段自体は存在します。Playwright MCPのように、AIエージェントからブラウザを操作するための公式インターフェースもあります。ただ、拡張のビルドとリロード、Service Workerの監視、ElectronのIPC、VSCode拡張のコマンド実行までを同じ操作モデルでまとめて扱えるものは、見つけられませんでした。手段はあるのにプラットフォームごとにバラバラで、AIエージェントが気軽に叩けるインターフェースになっていない、という方が正確だと思います。Playwrightや各公式ツールは実行基盤としては優秀なので、それらをAIが叩きやすいHTTP APIとしてラップするものがほしかった。見つからなかったので、作りました。

KamoXの設計

作ったのはKamoXというローカルHTTP APIサーバーです。Playwrightの代替ではなく、Playwrightや各プラットフォーム固有の処理をHTTP APIの後ろに隠すレイヤーだと思ってもらえればいいはずです。

/rebuildでビルドとリロード、/check-uiでスクリーンショットとDOM情報とコンソールエラーをまとめて取得、/playwright/elementでボタンクリックやフォーム入力、/logsでログ取得ができます。

/check-uiはスクショの保存先パスに加えて、ページタイトル・本文テキスト・HTMLといったDOM情報、コンソールログ、ページエラーもテキストで返します。なのでAIはスクショ画像が読めなくても、テキスト情報からUIの状態をある程度判断できます。

{
  "success": true,
  "data": {
    "loaded": true,
    "screenshot": "/project/.kamox/screenshots/popup_1234567890.png",
    "dom": {
      "title": "Popup Title",
      "bodyText": "...",
      "html": "<html>...</html>"
    },
    "logs": [],
    "errors": [],
    "performance": { "loadTime": 240 }
  }
}

HTTP APIなので、ローカルでコマンド実行できるエージェントなら何でも使えます。AIが実際にやるのはこういう流れです。

# コード修正後にビルド
curl -X POST http://localhost:3000/rebuild
# UIを確認(keepOpenでpopupを開いたままにする)
curl -X POST http://localhost:3000/check-ui \
  -H "Content-Type: application/json" \
  -d '{"keepOpen": true}'
# 開いているpopupのボタンを押して動作確認
curl -X POST http://localhost:3000/playwright/element \
  -H "Content-Type: application/json" \
  -d '{"pageType": "popup", "selector": "#save-btn", "action": "click"}'
# ログを確認
curl http://localhost:3000/logs

プラグイン構造にした理由

Chrome拡張、Electron、VSCode拡張は、起動もデバッグ方法も全然違います。でもAIがやりたいことは同じで、ビルドする、画面を見る、ボタンを押す、ログを見る。違うのはその裏側の処理だけです。

なのでKamoXはプラグイン構造にしました。共通のAPIはコアが持ち、プラットフォーム固有の処理はプラグインに分けています。Chrome拡張ならCDP経由でService Workerのログを拾ったり停止したWorkerを起こす処理、ElectronならIPC監視やネイティブダイアログのモック、VSCode拡張ならコマンド実行やProblemsパネルの取得。そういう部分がプラグインに入っています。

kamox chrome --auto-build
kamox electron --entryPoint main.js
kamox vscode --project-path .

コマンド1つでサーバーが立ち上がるので、あとはエージェント側からcurlなりfetchなりで叩けば動きます。

AIが自分で確認して直すようになった

使ってみて一番変わったのは、AIに「localhost:3000叩いて確認して」と言えるようになったことです。

以前はCSS調整のたびに、人間がビルドしてブラウザで開いてスクショを撮ってAIに見せていました。今はAIが自分で/rebuildして、/check-uiでスクショとDOM情報を取得して、おかしければ/playwright/elementでボタンを押して動作確認して、/logsでエラーを拾って、コードを直します。毎回スクショを撮って貼る作業がなくなっただけでも、体感はだいぶ違いました。

完璧ではありません。KamoXはpopup.htmlを通常のページとして開いているので、DOMや見た目の確認はできますが、ツールバーから開いた本物のpopupのフォーカスや自動クローズの挙動までは再現しません。デザインとして良いかどうかの判断もまだ人間がやる必要がありますし、拡張機能固有の権限周りとか、プラットフォーム依存のハマりどころも残っています。ただ「人間がAIの目と手の代わりをやる」時間は明らかに減りました。

他にもkamox guideでLLM向けAPI仕様を出力したり、シナリオファイルで事前条件を定義する機能もありますが、正直なところ一番使うのは/rebuild/check-ui/logsの組み合わせです。

使い方

npmに公開してあります。グローバルインストールすれば、そのまま動くはずです。

npm install -g kamox
kamox chrome --auto-build

Chrome拡張・Electron・VSCode拡張の3モードを実装しています(VSCodeモードは現状Windows中心に検証しています)。MITライセンスです。

GitHub: https://github.com/iwabuchi404/kamox

https://frog404.work/log/2025-06-25-kamox/
https://frog404.work/log/2026-07-12-kamoxelectronvscode/

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?