CSSを1行直しては、手でChromeを開いて確認する。またちょっと直しては、またChromeを開く。個人開発でフロントを触っていると、この往復が地味に体力を削ってきます。QR SendのLPをClaude Codeに直させているときも、私が毎回タブを切り替えて見た目を確認していました。
実はこの往復、Claude Code自身にブラウザを持たせて肩代わりさせられます。今回は公式のChrome拡張機能を使って、「コードを直す→自分でChromeを開いて確認する→また直す」のループをAIに回させてみました。
これまでの確認方法とその欠点
これまで私がやっていたのは単純です。Claude Codeにコードを直してもらったら、自分でChromeを開いて`localhost`にアクセスし、目で見て「ここがズレている」「この色はおかしい」と伝え直す。この繰り返しでした。
スクリーンショットを自分で撮ってClaudeに貼り付ける方法も試しましたが、毎回手が止まります。ページの状態が変わるたびに撮り直しになりますし、コンソールのエラーまでは拾えません。結局「直す→見る→伝える」の「見る」の部分だけが人間の作業として残り続けていました。
似た名前のツールにchrome-devtools-mcpがありますが、あれは自分のChrome拡張機能そのものをリロードしたりデバッグしたりするための道具です。今回扱うのはそれとは別軸で、「作ったフロントの見た目や挙動を、動いているブラウザで検証させる」ための仕組みになります。
Claude Codeの公式Chrome拡張とは
公式ドキュメント（code.claude.com/docs/en/chrome）によると、これはClaude Codeと「Claude in Chrome」拡張機能を連携させ、CLIやVS Code拡張からブラウザ操作の能力を与える仕組みです。ビルドはターミナルで、テストとデバッグはブラウザで、というコンテキストの切り替えをなくす狙いで作られています。
Claudeが操作するのは新しく開いたタブで、しかも自分のブラウザのログイン状態をそのまま共有します。ログイン済みのサイトなら追加の認証情報なしでアクセスできる、というのは地味に便利です。ブラウザ操作は見える形のChromeウィンドウでリアルタイムに動くので、ログイン画面やCAPTCHAに当たったらそこでいったん止まり、人間に処理を委ねてくれます。
対応ブラウザはGoogle ChromeとMicrosoft Edgeで、Brave・Arc・Vivaldi・Operaなど他のChromium系ブラウザも検出して接続できるとドキュメントに書かれています。ただしWSL(Windows Subsystem for Linux)では非対応です。私はWindows環境で試しましたが、この記事の執筆時点でWindows固有の注意点（後述）もいくつかありました。
準備と有効化
では実際に有効にしてみましょう。まず前提として、Claude in Chrome拡張機能（Chromeウェブストアで配布）をインストールし、Claude Codeにログインしておく必要があります。ここが少し引っかかりやすいのですが、APIキーや長期トークン(`claude setup-token`)でログインしている場合はこの連携が使えません。Pro・Max・Team・Enterpriseのいずれかの直接契約プランでのログインが前提です。Amazon BedrockやGoogle Cloud、Microsoft Foundry経由の利用でも使えないので、その場合は別途claude.aiのアカウントが必要になります。
準備ができたら、以下のようにフラグを付けて起動します。
claude --chrome初回起動時は連携の説明ダイアログが出るので、Enterで進みます。私の場合はここで一度Chromeの再起動が必要でした。初回だけネイティブメッセージングホストの設定ファイルが作られ、Chromeがそれを読み込むのが起動時のタイミングなので、うまく検出されない時はChromeを再起動すると直ります。
毎回`–chrome`を付けるのが面倒なら、`/chrome`コマンドを実行して「Enabled by default」を選べば以後は自動で有効になります。ただしドキュメントには、常時有効化するとブラウザ用のツールが常に読み込まれる分コンテキストの消費が増える、という注意も書かれていました。私は普段は付けずに、フロントを触るセッションだけ`–chrome`を付ける運用にしています。
実際にフロント修正のループを回してみる
ではここからが本番です。QR SendのLPで、ボタンの余白がスマホ幅で崩れているのを直したいとします。これまでなら自分でスマホ幅にリサイズしたChromeを開いて確認していたところを、こう頼むだけで済みます。
localhost:3000 のLPをスマホ幅で開いて、
「送信する」ボタンの下の余白が詰まっていないか確認して。
崩れていたらCSSを直して、直った状態をもう一度見せて。Claudeは新しいタブを開き、ページを操作して状態を読み取り、必要ならコードを直してからもう一度開き直して確認する、というところまで一続きでやってくれます。コンソールのエラーも拾えるので、「見た目は直ったがコンソールに赤いエラーが出ている」というケースにも気づいてくれました。これまで私が毎回目でやっていた「直す→見る→また直す」のループが、そのままAI側で完結します。
コンソールログを読ませるときは、「エラー全部見せて」より「〇〇というエラーが出ていないか確認して」のように狙いを絞った方が安定します。ログは長くなりがちなので、これは公式ドキュメントにも書かれている通りでした。
もう一つ試したのが、Figmaのモックとブラウザの実装を見比べさせる使い方です。「デザインを見て実装が合っているか確認する」というのは、これまで自分の目で1ピクセルずつ見比べていた作業ですが、ドキュメントの想定用途にも「design verification」として名前が挙がっています。実際にQR Sendのボタンの角丸をFigmaの値に合わせる作業で使ってみました。細かい数値のズレまでは指摘してくれませんでしたが、「ボタンの左右で角丸の見え方が違う」という見た目の非対称には気づいてくれました。数値の厳密な検証まで任せるには、まだ人間の目を挟んだ方が安全というのが正直な感触です（ピクセル単位までは、と欲張らない方が良さそうです）。
演習としては、自分の手元のローカル環境で動いているページを一つ選んで、「スマホ幅で開いて、崩れている箇所があれば直して」とだけ頼んでみてください。指示を細かく書き込まなくても、Claudeがブラウザを開いて確認しながら直しにいく様子が見られるはずです。
権限の仕組みは正直に細かい
ブラウザを勝手に触られるのは怖いところですが、ここは権限の切り分けがちゃんとされています。ページを読むだけの操作（`read_page`、`get_page_text`、`find`、コンソールやネットワークログの読み取り、スクリーンショット撮影）は許可プロンプトなしで実行されます。一方でクリックや入力、ページ遷移、タブ操作、GIF録画のような状態を変える操作は、都度許可を求められる仕組みです。
ドキュメントによれば、読み取り系のツールでも`save_to_disk`のように状態変化を伴うオプションを付けると許可プロンプトの対象になる、という細かい挙動もありました。ここまで作り込まれていると、「見るだけのつもりが勝手にクリックされていた」という事故は起きにくそうです。
サイトごとにどこまで操作を許すかは、Claude Code側ではなくChrome拡張機能側の設定で管理する形になっています。触られたくないサイトがあれば、拡張機能の設定から絞り込む必要があります。
ログイン状態を共有する仕組みなので、Gmail・Google Docs・Notionのようにすでにログイン済みのSaaSでも、追加のAPI連携なしでそのまま操作できるとドキュメントに書かれています。フロント確認用に導入したつもりが、コミットログをもとにGoogleドキュメントへ進捗メモを書かせる、といった使い方にも流用できそうです。私はまだそこまで手を広げていませんが、次に試してみたい使い方の一つです。
Windowsで踏んだつまずき
正直に書くと、Windows環境ではいくつか固有の引っかかりがありました。ドキュメントのトラブルシューティング欄にも名前付きパイプの競合（EADDRINUSE）がWindows特有の問題として挙げられています。私の環境でも、Claude Codeのセッションを複数立ち上げていた時に接続が失敗したことがあり、片方を閉じたら直りました。
また、拡張機能のservice workerは一定時間操作がないとアイドル状態になり、接続が切れることがあるとも書かれています。私も長めの作業の合間で「ブラウザが反応しない」となった時があり、`/chrome`から「Reconnect extension」を選び直すことで復帰しました。この挙動そのものは、私のiPhone Push Bullet拡張機能を作っていたときに触れたMV3のservice worker周りの癖と似ていて、既視感がありました。
もう一点、この連携は執筆時点でまだベータという位置づけです。将来のバージョンで細かい挙動が変わる可能性はあるので、実際に導入する際は公式ドキュメントの最新版を確認することをおすすめします。バージョンによる挙動差もそれなりにあり、たとえばファイルアップロード機能や画面のディスクへの保存機能は、ある時点のバージョンから使えるようになったと明記されています。手元の環境で機能が見当たらない時は、まず`claude –version`でバージョンを確認するとよさそうです。
私が最初につまずいたのは、実はこのつまずき以前の話でした。長期トークンでログインしていたセッションで`–chrome`を付けても連携が有効にならず、しばらく原因が分かりませんでした。ドキュメントを読み直して、APIキーや`claude setup-token`の長期トークンでは仕組み上この連携が使えないと知り、Pro契約のアカウントで`/login`し直したら通りました。エラーメッセージだけでは気づきにくいところなので、同じ状況になった人は認証方法から疑ってみてください。ここ、地味に注意です。
フィードバックループがあると仕上がりが変わる
Claude Codeの作者であるBoris Cherny氏も、この拡張機能についてX（旧Twitter）で「Claudeに出力を検証する手段を与えることが、Claude Codeを使ううえで最も重要なコツだ」と述べていました。ブラウザという検証手段を持たせると、Claudeはコードを書いては確認します。そして良くなるまで反復してくれるようになる、という趣旨です（x.com/bcherny/status/2038454347156398333）。
これは私も実際に触っていて納得できました。人間が都度「ここがズレている」と指摘し直す従来のやり方より、Claude自身が見て気づいて直す方が、細かい調整の往復回数が減ります。もちろん最終チェックは自分の目でも行いますが、粗い段階の往復をAI側に任せられるだけで体感の負担はだいぶ違います。
まとめ
というわけで、Claude Codeの公式Chrome拡張機能を使うと、「フロントを直す→自分でブラウザを開いて確認する」という地味な往復をAI側に任せられます。`claude –chrome`で起動し、`/chrome`で接続状態や権限を確認しながら使う、という流れも一度覚えてしまえば難しくありません。読み取り系の操作は許可なしで動き、状態を変える操作だけ都度確認が入るという設計も、安心して使える理由の一つでした。
Windowsではservice workerのアイドル切断や名前付きパイプの競合など、細かいつまずきもありましたが、`/chrome`の再接続で大体は復帰します。フロント修正のたびに自分でブラウザを開いていた人は、一度`–chrome`を付けて試してみてください。ブラウザでテストコードを書かせたい場合はPlaywright MCP入門の記事も参考になるはずです。
コメント