この記事の目次
Claude CodeはChromeにつなぐと、何をしてくれる？
動作中のWebアプリを実際のChromeで開き、画面の挙動とコンソールの出力を見て、直して、再確認するまでの往復を任せられるようにする機能です。
ここでいうコンソールとは、Chromeの開発者ツールに表示されるエラーやログの一覧を指します。デバッグ(不具合の原因を探して直すこと)のたびに、ブラウザを開き直して操作し、コンソールを眺めてエディタへ戻る。この往復を、Claude Codeが自分のChromeのタブを見ながら進める形になります。
「画面とコンソールを見る往復」が指すもの
普段の流れは次のようになりがちです。コードを直す、ブラウザで再読み込みする、フォームを操作する、コンソールにエラーが出ていないか見る、原因を推測してまたコードを直す。何度も繰り返すと負担になりやすい作業です。
Chrome連携は、この「操作して観察する」側をClaude Codeに寄せるための仕組みです。コードを読むだけでは分からない、実際の画面での挙動を判断材料にできる点が違いです。
この記事で扱う範囲
扱うのは、自分のPCで動かしているWebアプリの確認とデバッグです。具体的には、前提条件の確かめ方、読み取りだけの接続確認、不具合を直す依頼の型、権限の考え方、つながらないときの切り分けを順に説明します。
データ抽出、Google Docsの操作、画面操作のGIF記録、複数サイトの巡回、ファイルのアップロードは対象外とします。目的が確認とデバッグである読者には必要が薄く、確かめる項目も増えるためです。
また、版や仕様が更新されうる項目(対応ブラウザ、バージョン、設定名、エラー文言など)は、固定して載せません。確認先は次の節の公式ドキュメントです。
自分の環境でつなげる？ 前提条件を先に確かめるには
つなぐ前に、使えない条件へ当たっていないかを確かめます。対応ブラウザ、必要なプラン、拡張機能とCLIの最低バージョンといった具体的な条件は、公式ドキュメントの前提条件を読んで判定してください。設定の名称や権限の項目、エラー文言など、以降の節で触れる細部の確認先も同じです。
公式の案内は Claude Code公式ドキュメントのChromeの項 にあります。プランの違いが気になる場合は、Claude Codeの料金とプランの記事で全体像を確認できます。
自分で確かめる最小チェック
公式条件の確認とは別に、手元で次の3点を先に確かめておくと、あとの切り分けが楽になります。
| 項目 | 確認方法 | 満たさないときの次の一手 |
|---|---|---|
| Claude Codeが起動できる | ターミナルでClaude Codeを立ち上げ、通常の質問に答えが返るか見る | インストールとログインを先に済ませる |
| Chromeが自分のPCで普段どおり使える | Chromeを開き、確認したいアプリのURLを表示する | アプリ側の起動(開発サーバーの立ち上げ)を先に行う |
| 公式の前提条件を満たしている | 公式ドキュメントの前提条件を上から読み、自分の環境と照らす | 満たさない項目があれば、その項目の案内に従う |
つながったかは、どうやって確かめる？
読み取りだけの依頼を1回出し、返ってきた内容を自分のChromeのタブと照らして確かめます。
最初にクリックや入力を伴う操作を頼む必要はありません。読み取りだけで済む確認から始めると、失敗しても画面の状態を変えずに済みます。
最小のセットアップ
ブラウザ拡張機能の導入とClaude Code側の設定は、公式の手順どおりに進めてください。起動時のオプションやコマンドは版によって変わりうるため、セットアップの節を上から順にたどるのが確実です。
読み取りだけの接続確認
Chromeで確認したいアプリのタブを開いた状態で、Claude Codeに次のように頼みます。
今Chromeで開いているタブのタイトルとURLを教えてください。
クリックや入力はせず、読み取りだけにしてください。返答の形は、おおむね次のようなものを想定します。実際の文言は環境で異なるため、あくまで形式の目安です。
現在のタブ:〈タイトル〉/〈URL〉成功の判定は単純です。返ってきたタイトルとURLが、自分のブラウザで開いているタブと一致していれば成功です。一致しない、返答が来ない、接続できない旨の返答が来る、のいずれかであれば、本記事の最後の切り分けの節へ進んでください。
VS Codeから使う場合
VS Code上でClaude Codeを使っている場合の連携方法は、拡張機能側の案内に依存します。手順は VS Code拡張機能の記事 と公式ドキュメントで突き合わせてください。
動作中のWebアプリの不具合を、どう頼めば直せる？
「再現する、ログを絞って読む、原因を特定して最小限直す、同じ操作で再検証する」を1回の依頼に入れ、止める条件と完了の条件も書いておくと、結果を判断しやすくなります。
以下は実績ではなく、型を示すための架空例です。
題材:送信しても何も起きないフォーム
ローカルの開発サーバーで動かしている問い合わせフォームの、送信ボタンを押しても何も起きない、という状況を想定します。アプリ自体の作り方は Webアプリ開発の記事 の守備範囲なので、ここでは動いているものの不具合調査に絞ります。
依頼文の全文案
localhostで動かしている問い合わせフォームの送信ボタンを押しても何も起きません。
次の手順で原因を調べて直してください。
1. Chromeで開いている自分のアプリのタブで、フォームにダミー値（名前：テスト太郎、メール：[email protected]）を入れて送信ボタンを押す。
2. コンソールは全文を読まず、エラーレベルのメッセージのうち「TypeError」または「Failed to fetch」を含むものだけを確認する。
3. 該当するエラーから関係するソースコードを特定し、原因を説明してから最小限の修正をする。
4. ページを再読み込みして同じ操作を繰り返し、同じエラーが出ないか確認する。
5. 2回直しても解消しない場合は修正を止めて、試したこと・見たエラー・疑う箇所を報告する。
本番URLや実在の個人情報は使わないでください。依頼文の設計意図
見るログを文字列のパターンで絞る形にしているのは、コンソールの全量を読ませると関係のない出力が混ざりやすいためです。依頼文の設計上の狙いを示した例で、この絞り方が常に最適という意味ではありません。
「2回で止める」という条件は公式の仕様ではなく、依頼の書き方の一例です。回数は作業に合わせて変えてかまいません。大切なのは、直らないまま修正を重ねさせず、一度人に戻す地点を決めておくことです。
期待する報告の形
報告は、次の6項目で返すよう頼むと読みやすくなります。
- 再現結果
- 見つけたエラーの要旨
- 原因の仮説
- 変更ファイルと差分の要約
- 再検証結果
- 未確認事項
完了判定
完了の基準は、依頼文に書いておきます。たとえば次の3つです。
- 送信ボタン押下後、コンソールに該当パターンのエラーが新たに出ない。
- 画面に送信完了の表示が出る。
- 変更したファイルと差分が報告されている。
3つが揃えば完了とし、1つでも欠けたら未完了として報告させます。
任せる範囲と人が見る範囲
| 作業 | Claude Code | 人 | 理由 |
|---|---|---|---|
| 再現操作、ログの絞り込み確認 | 任せる | 結果を読む | 手順が機械的なため |
| 該当コードの特定と最小修正 | 任せる | 差分をレビューする | 想定外のファイル変更を拾うため |
| 「直った」の判定 | 完了条件に沿って報告させる | 実際の画面で自分の目で確認する | 自己申告だけでは足りないため |
| 見た目・文言・業務上の正しさ | 任せない | 人が判断する | 要件は人の側にあるため |
| 送信の副作用(メール送信、データ書き込み) | 任せない | 人が確認する | ダミー運用でも副作用の有無は人が見る必要があるため |
Chromeは常につないでおくべき？ 必要なときだけでいい？
使う頻度と作業の長さで決めるのが現実的です。ブラウザ確認が毎回の作業に入るなら常時、たまにしか使わないなら必要なときだけ有効にする、という分け方になります。
起動時に有効にする設定の有無や名称は、版によって異なります。判断の軸としては、次の3点が目安になります。
| 判断軸 | 常時つなぐ側に寄る場合 | 必要なときだけ側に寄る場合 |
|---|---|---|
| 使う頻度 | ほぼ毎回の作業でブラウザ確認が発生する | 週に数回、特定の不具合調査のときだけ使う |
| 作業の長さ | 1回の作業が長く、確認と修正を何度も往復する | 短い単発の依頼が中心 |
| 使わないときの扱い | 使わない作業でも邪魔にならない | ブラウザに触れない作業が多く、つなぐ必要がない |
長く続けるセッションでは、コンテキストウィンドウの記事で扱う消費の考え方も、常時にするかどうかの判断材料になります。
ログイン済みのブラウザを触らせて、大丈夫？
利点は、自分がログインしたままの状態で動かせることです。同時にリスクも同じ場所にあり、ログイン済みの状態で操作が行われるため、触らせる範囲は自分で絞る必要があります。
生成AIに操作を任せる場面では、「何ができるか」より「どこまでをやらせないか」を先に決めるほうが安全です。
読者側でできる最小の守り
- 専用のChromeプロファイルを使う。 Chromeには利用者ごとに環境を分けるプロファイル機能があります。開発用の別プロファイルを作り、業務用や個人用のログイン状態と分けておくと、触れる範囲を狭められます。
- 本番環境や機微なサイトを開いたまま頼まない。 依頼するときは、確認したいアプリのタブ以外を閉じておきます。
- サイト単位の権限は必要最小限にする。 許可の設定の有無と内容は版によって異なるため、見える項目の範囲で絞ります。
- 権限モードを使い分ける。 Claude Codeには、操作前に確認を挟むモードなど、権限の動き方を切り替える仕組みがあります。権限モードの記事で挙げている各モードの違いを踏まえ、作業に合うものを選びます。
人が引き取る場面
ログインが必要なページやCAPTCHA(人間かどうかを確かめる画面)のように、画面が人の操作を前提としている場面では、自分で操作して先へ進め、その後の確認をClaude Codeに戻す、という分担が基本になります。
ページ内の文面に指示が紛れ込む可能性
開いたページに書かれている文面が、Claude Codeへの指示のように読める場合があります。個人利用のセキュリティリスクにも通じる論点です。信頼できないページを開いた状態で操作を任せるのは避けてください。
DevTools MCPやPlaywright MCPとは、どう使い分ける？
どちらが優れているかではなく、目的で決まります。自分が普段ログインしているChromeの画面で確認したいなら、Chrome連携から試すのが入口になります。別の手段で再現させたいなら、MCP系のツールを検討します。
MCP(Model Context Protocol)は、Claude Codeに外部ツールをつなぐための共通の仕組みで、設定の詳細はMCPの記事にあります。Chrome DevTools MCPやPlaywright MCPのような、ブラウザを扱うMCPサーバーも存在します。ツールごとの仕様は更新されやすいため、ここでの比較は目的の軸にとどめます。
選ぶ際の入口になる問いを表にします。
| 問い | Yesの場合に向く方向 | 次に見るもの |
|---|---|---|
| 自分が普段ログインしているChromeの画面で確認したいか | Chrome連携を試す | 本記事の接続確認 |
| 別のブラウザ環境で再現させたいか | MCP系ツールを検討する | 各ツールの公式ドキュメント |
| 繰り返し実行するテストにしたいか | テスト用の仕組みを検討する | MCPの記事と各公式情報 |
つながらないとき、何から切り分ける？
確認する順番を決めておくと迷いません。拡張機能が入っているか、バージョンは足りているか、認証とプランは条件に合うか、実行環境に制約がないか、再起動や再接続で戻るか、の順に見ます。
| 順番 | 確認すること | 見る場所 |
|---|---|---|
| 1 | Chromeに拡張機能が入っていて、有効になっているか | Chromeの拡張機能管理画面 |
| 2 | 拡張機能とClaude Code本体のバージョンが、公式の前提条件を満たしているか | 公式ドキュメントの前提条件 |
| 3 | ログインしているアカウントとプランが条件に合っているか | 公式ドキュメントと自分のアカウント設定 |
| 4 | 実行環境(OSや仮想環境)に、公式で案内されている制約がないか | 公式ドキュメント |
| 5 | Claude CodeとChromeを再起動し、もう一度読み取りだけの確認を行う | 本記事の接続確認 |
具体的なエラー文言は症状ごとに異なり、Claude Help Centerでも調べられます。症状が接続に限らず、起動やログイン全般にある場合は、エラー対処の記事やログインのトラブル対処の記事のほうが近道です。
まとめ:今日、最初にやることは何？
最初にやるのは、読み取りだけの接続確認を1回実行することです。
この記事の流れを3点にまとめます。
- 使える条件に当たっていないかを、公式の前提条件と手元の最小チェックで判定する。
- クリックや入力をしない、読み取りだけの依頼で接続を確かめる。
- 不具合の調査は、再現、ログの絞り込み、最小修正、再検証、止める条件、完了条件を1つの依頼にまとめて頼む。
ここまでの型は、読んだだけでは自分の仕事の画面にうまく当てはまらないことがあります。自分の手で使えるようになるために学べる場として、月額1,980円からの学習コミュニティ「AI駆動ラボ」があります。まずは、今日の接続確認から試してみてください。