save→chrome://extensionsでリロード→console確認、これを何百回やったかわからない
Chrome拡張を作っていると、コードを直したあとに必ず同じ作業が発生しますよね。エディタでsaveして、`chrome://extensions`を開いて、対象拡張のリロードボタンを押して、ポップアップやservice workerのconsoleを開いて、エラーが出ていないか目視確認する。QR Sendを作っているときも、この一連の動作を数え切れないくらい繰り返しました。
地味に時間を食うんです。特にservice workerのログを見るためだけに`chrome://extensions`の「詳細」から「Service Worker」リンクをクリックしてDevToolsを別窓で開く、という手順が毎回挟まるのが面倒でした。1回1回は数秒でも、1日に何十回もやっていると馬鹿にならない時間になります。
これ、AIエージェントに直接やらせられないのかと思った
普段Claude Codeでコードを書いてもらっているので、「じゃあブラウザの操作自体もエージェントにやらせればいいのでは」と思うのは自然な流れでした。調べてみたら、Chrome DevTools チームが公式に`chrome-devtools-mcp`というMCPサーバを出していて、これがまさにその用途のものでした。
MCP(Model Context Protocol)はAIエージェントが外部ツールを呼び出すための共通規格です。`chrome-devtools-mcp`をClaude CodeなどのMCP対応ツールに繋ぐと、エージェントがブラウザのページ遷移・クリック・入力・スクリーンショット取得・console/networkログの取得・JavaScriptの実行などを、直接ツール呼び出しとしてできるようになります。「AIにブラウザを触らせる」という発想自体は目新しくないのですが、DevToolsチームの公式実装というのが安心材料でした。
接続してみましょう
導入は拍子抜けするくらい簡単でした。Claude CodeのMCP設定に以下を追加するだけです。
claude mcp add chrome-devtools npx chrome-devtools-mcp@latest
もしくは設定ファイルに直接書く場合はこうなります。
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["chrome-devtools-mcp@latest"]
}
}
}
これで再起動すれば、エージェントが使えるツールの一覧に`list_console_messages`や`list_network_requests`、`take_snapshot`、`evaluate_script`、`navigate_page`といったものが並びます。瞬殺ですね。npmパッケージを叩くだけでMCPサーバが立ち上がり、Node.js経由でPuppeteerがChromeを操作してくれる仕組みです。
拡張のリロードとconsole確認を任せてみる
ここからが本番です。実際にQR Sendのpopup.jsを直したあと、Claude Codeに「拡張をリロードしてpopupのconsoleにエラーが出ていないか確認して」と頼んでみました。すると、エージェントが`navigate_page`で`chrome://extensions`を開き、`take_snapshot`でページ構造を取ってリロードボタンの位置を特定し、`click`で実際にクリックし、`list_console_messages`でconsoleの中身を持ってきてくれました。
自分の手でやっていた一連の操作を、そのまま指示一つでやってくれる。これにはひっくり返りました。しかもエラーが出ていた場合は、そのままエージェントがスタックトレースを読んで原因箇所のコードまで見に行ってくれます。人間はエラーメッセージを読んでファイルを開いて…という工程を一切やらなくてよくなりました。
network周りも同じで、`list_network_requests`を使えば拡張がどのAPIにどんなリクエストを投げているか一覧で取れます。QR Sendのようにサーバー連携がある拡張だと、「リクエストは飛んでいるのにレスポンスがおかしい」系のバグ調査にそのまま使えて、これ、意外と使えます。
正直に言うと、拡張の読み込みだけは一工夫必要でした
ここは正直に書いておきます。`chrome-devtools-mcp`が自前で起動するChromeインスタンスには、未パッケージ拡張を直接読み込む専用オプションが今のところ用意されていません(2026年7月時点。今後のアップデートで変わる可能性はあります)。
なので私は、`–load-extension=<拡張のパス>`を付けて自分でChromeを起動しておき、リモートデバッグを有効にした状態で、`chrome-devtools-mcp`側から既存ブラウザに接続するオプション(READMEでは既存のブラウザインスタンスに繋ぐ方法として案内されています)を使う形にしています。オプション名は今後変わるかもしれないので、使う前に一度公式READMEを見ることをオススメします。ここだけは完全に自動化しきれていないのですが、リロード・console確認・network確認という一番面倒な部分がAI任せになっただけでも十分に楽です。
使ってみて感じたこと
正直、「AIにブラウザ操作させる」という話は目新しさだけでは終わらないなと感じました。console.logを目で追う作業そのものが減るので、デバッグの体感速度がはっきり変わります。エラーを見つけて、原因コードを読んで、直して、またリロードして確認する、というループが人間の手を介さずに一周してくれる感覚です。
もちろん万能ではありません。UIの見た目のズレなど人間の目でないと判断しづらいところは、結局自分でスクリーンショットを見て判断しています。それでも、地味で反復的な「リロードして確認する」作業をAIに渡せただけで、Chrome拡張の開発ループはかなり速くなりました。
QR Sendの導入自体について書いた記事はこちらにまとめています。Chrome拡張の個人開発をしている方は、`chrome-devtools-mcp`を一度試してみてください。設定は数分で終わります。


コメント