Chrome DevTools MCP はエージェントを既存の Chrome セッションに接続できますが、auto-connect はゼロコンフィグではありません。Google の現在のセットアップでは、Chrome 144 以降、実行中のブラウザでのリモートデバッグ有効化、--autoConnect フラグ、そして Chrome の Allow ダイアログでの手動クリックが必要です。これらの条件が満たされると、エージェントはそのプロファイルで開いているタブとサインイン状態を引き継ぎます。各前提条件を記載した公式のauto-connectガイド以及それが付与するプロファイル全体へのアクセス権です。Chrome DevTools MCP は外部制御のために別のブラウザを開く必要がありますが、ego (lite) はすでにそのブラウザであり、切り替えるスイッチも、繰り返しの承認も必要ありません。
Chrome DevTools MCPのトラッカーで最も要望が多かったのは、デバッグ機能ではありません。要望の中心はissue #140、つまり「ログイン状態を保ったまま、普段使っているChromeにエージェントを接続したい」というものでした。本ガイドでは、設定から落とし穴、制限まで順を追って解説します。
Chrome DevTools MCP Serverはどうインストールする？
公式サーバーは npm パッケージなので、Claude Code では1つのコマンドで設定できます。stdio 経由でローカル実行され、ホスト型アカウントや API キーは不要です。まず node --version を確認してください。パッケージ 1.9.0 は Node 20.19+、22.12+、または 23+ に対応し、古いランタイムは Chrome が起動する前に拒否します。その後、すべての Claude Code プロジェクトで使えるようユーザースコープに登録します。
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest追加後、Claude Code で /mcp を実行し、chrome-devtools が一覧に表示されることを確認してください。現在の公式リポジトリでは、MCP サーバーとスキルをバンドルした Claude Code プラグインも提供されています。ChromeDevTools/chrome-devtools-mcp マーケットプレイスを追加し、chrome-devtools-mcp@chrome-devtools-plugins をインストールして、Claude Code を再起動し、/skills で確認してください。以前の手動インストールが既に存在する場合は、プラグインをインストールする前に重複エントリを削除してください。Claude Code が 2 つのコピーを読み込むのを防ぐためです。
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins見落としがちなプライバシー設定が2つあります。MCPツールの使用統計は、Chromeブラウザのメトリクスとは独立してデフォルトで有効です。また、パフォーマンスツールはトレースしたページのURLをフィールドデータ取得のためGoogle CrUX APIに送信する場合があります。ポリシーでこれらのいずれも許可されない場合は、サーバー引数に --no-usage-statistics と --no-performance-crux を追加し、クライアントが実際に起動する設定でフラグを確認してください。
クリーンなローカル環境で何を検証した？
2026年9月10日、npm から chrome-devtools-mcp@latest を解決し、macOS 上で実行しました。解決されたバージョンは 1.9.0 です。Node 19.9.0 では起動前に終了して最小エンジン要件を表示しました。Node 22.12.0 と Chrome 152.0.7977.83 では分離ブラウザーを起動し、MCP プロトコル経由で複数の証拠を扱うデバッグタスクを完了しました。
| 確認 | 確認された結果 | これが示すこと |
|---|---|---|
--version | 1.9.0 | この日時点でテストしたパッケージバージョン |
| Node 19.9.0 | EBADENGINE で拒否された | 起動しないサーバーは、MCP接続エラーのように見えることがある |
| Node 22.12.0 | ヘルプ出力が完了しました | 現在のフラグはサポート対象のランタイム上で読み込まれます |
実行した複雑なテストタスク
4つの独立した欠陥を組み込んだ管理下の運用ダッシュボードを用意しました。同期実行される240msの集計処理、遅延するヒーロー画像、503を返す注文リクエスト、500を返すレポートエクスポートです。Chrome DevTools MCP 1.9.0 には、再読み込みのトレース記録、ページスナップショットからの［Generate report］ボタン特定とクリック、表示上の失敗とコンソールのソース位置・ネットワークのステータスコードの照合を行わせました。ローカルのテスト URL が任意のテレメトリー経路に入らないよう、利用統計と CrUX 参照は無効化しました。
LCP: 629 ms
LCP render delay: 627 ms
app.js:10 Orders API returned 503
app.js:18 export failed
GET /api/orders?range=30d 503
POST /api/export 500
トレースでは LCP が629ms、そのうち627msはサーバー応答時間ではなくレンダリング遅延と判定されました。壊れたワークフローについては、コンソールとネットワークの結果が一致しています。初期データ読み込みは app.js の10行目で HTTP 503、クリック後のエクスポートは18行目で HTTP 500 により失敗しました。この照合こそ DevTools MCP の実用的な価値です。スクリーンショットはユーザーに見える状態を証明し、トレースとリクエスト証拠は修正すべきエンジニアリング層を特定します。
Chrome DevTools MCP Serverのauto-connectはどう設定する？
3つのステップで、すべてコピー＆ペーストで完了します。前提条件: Stable チャンネルの Chrome 144 以降（Canary と Beta は設定でチャンネル名の指定が必要）、および任意の MCP クライアント。例では Claude Code を使用します。
ステップ 1: リモートデバッグを一度有効にします。 起動中の Chrome で chrome://inspect/#remote-debugging を開き、リモートデバッグをオンにします。これは auto-connect が利用するブリッジであり、これがないと他の操作はすべて機能しません。
ステップ 2: フラグを指定してサーバーを登録します。
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --autoConnectまたは、Cursor や他のクライアント向けの JSON ブロックとして:
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
}
}
}ステップ 3: トリガーして許可する。 エージェントに、開いている Chrome での操作を依頼します（例: 「現在のタブのスクリーンショットを撮って」）。Chrome はセッションの権限ダイアログを表示するので、[許可] をクリックすると、エージェントはタブ、拡張機能、アプリケーションの状態を含むライブブラウザ内で動作できるようになります。
| リスク | 関連する制御 | 重要な制限 |
|---|---|---|
| エージェントが無関係なサイトに到達する | --allowed-url-pattern | Chrome 149+ が必要。リダイレクトとサブリソースをテストする |
| 機密性の高いリクエストヘッダーがクライアントに返される | --redact-network-headers | リダクションはデフォルトでオフ |
| ツールテレメトリー | --no-usage-statistics | Chrome ブラウザのメトリクスに依存しない |
| トレース URL を CrUX に送信 | --no-performance-crux | フィールドデータの参照を無効化（ローカルトレースは無効化しない） |
接続後、auto-connect の本来の用途を試す最初の 3 つのプロンプト：
「現在のタブのスクリーンショットを撮って、見えた内容を説明して」（接続確認）、「パフォーマンストレースを開始して、このページをリロードし、LCPを遅らせている原因を教えて」（デバッグの成果）、「エクスポートボタンをクリックして今見たバグを再現して、コンソールエラーをソース付きで読み上げて」（ライブセッション診断。新しいプロファイルのブラウザでは不可能）。これらが機能すれば、完全なツールキットを利用できます。
動作を妨げる3つの落とし穴とは？
これらはすべて「接続できない」と表示され、有用なエラーは出ません。順番に確認してください。
1. デフォルトプロファイルのロック。 Chrome 136以降、デフォルトのChromeデータディレクトリに対してはremote-debuggingスイッチが無視されます。これは、攻撃者がリモートデバッグを利用してCookieを抽出する事例が確認されたため、Googleが行った変更です。Auto-connectの権限ダイアログによるフローが、実行中の個人用ブラウザへ接続する正式な経路です。手動ポート接続の場合は、次節で説明するように、非デフォルトの--user-data-dirを使用する必要があります。
2. 2つ目のChromeインスタンス。 手動の browserUrl ルートは、デバッグポートとカスタムデータディレクトリを指定して起動された Chrome プロセスを前提としています。別の Chrome プロセスがプロファイルを所有している場合や、アプリが既存のインスタンスを再利用する場合、フラグが意図したウィンドウに届かない可能性があります。テストインスタンスを閉じ、使い捨てプロファイルでドキュメント記載のコマンドを再実行し、MCP クライアントを起動する前にエンドポイントを確認してください。
3. ポートが実際には応答していない。 手動の browserUrl ルートが接続するには、ブラウザ側が到達可能である必要があります。http://127.0.0.1:9222/json/version にリクエストを送り、ブラウザのメタデータと WebSocket デバッガー URL が返ることを確認してください。自動接続の場合は、chrome://inspect/#remote-debugging と Chrome の権限ダイアログを再確認してください。Node が起動前に失敗する場合は、まずランタイムを修正してください。ブラウザのフラグではその層を修復できません。
拡張機能の競合にも注意が必要です。タブ管理やスクリプトブロックを行う拡張機能は、CDP セッションに干渉し、ランダムな不安定さのように見える問題を引き起こす可能性があります。タスク中に接続が切断される場合は、問題を報告する前に、タブ管理系の拡張機能を無効にして再試行してください。
auto-connectとremote-debugging-port方式はどう違う？
auto-connect が登場する前は、明示的なデバッグポートと専用プロファイルディレクトリを指定して Chrome を起動するのが標準的な方法でした。
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-debug-profile"
claude mcp add --transport stdio chrome-devtools \
-- npx -y chrome-devtools-mcp@latest \
--browserUrl=http://127.0.0.1:9222トレードオフは明確です。auto-connect は、セッションごとの権限ダイアログ付きで実際のプロフィール（実際のログイン状態、実際の拡張機能、ライブな状態）を提供します。一方、フラグ方式は、一度ログインすれば再起動後も維持され、ダイアログが不要で、ドキュメント化した実践者によればサンドボックス環境でもより安定する、独立したプロフィールを提供します。フラグ方式は Chrome 144 未満での唯一の選択肢でもあります。
並べて比較したので、ひと目で選べます：
| プロパティ | 自動接続 | デバッグポート + 専用プロファイル |
|---|---|---|
| ログイン情報の扱い | 実際に使っている通常のプロファイル | 一度だけサインインするセカンドプロファイル |
| Chrome バージョン | 144+ | 最近使用したChrome |
| セッションごとの手間 | セッションごとに権限ダイアログが表示される | フラグ付きで起動すれば不要 |
| 最適な用途 | 今見ているアプリの状態をそのままデバッグする | 再現可能な認証付きテスト。サンドボックス環境やCIに近い環境での実行に対応 |
基本的な衛生管理はどちらにも適用される。エージェントがアクセスできるプロファイルに銀行や個人メールを置かないこと。また、作業終了後はChromeを閉じてポートも一緒に閉じること。
複数ステップの作業中に既存のChromeセッションを維持するには？
Chromeプロセス、プロファイル、MCPサーバーは1つのセッションとして扱う。まずChromeを起動し、リモートデバッグを一度有効化して、エージェントが一連のステップを完了するまで同じウィンドウを開いたままにする。ナビゲーション、抽出、検証の間にChromeを再起動しないこと。Auto-connectは実行中のブラウザに再接続するが、従来の --remote-debugging-port ルートはデバッグ起動したプロセスが生きている間のみ有効である。
再現可能なセッションのためには、--user-data-dir で専用プロファイルを使用し、CIでMCPパッケージのバージョンを固定し、最初のツール呼び出しの前に小さなヘルスチェックを追加する。スクリーンショットを要求するか、現在のターゲットを一覧表示する。127.0.0.1:9222 からの応答はCDPエンドポイントの存在を証明するだけで、エージェントが正しいタブを操作していることは証明しない。タスクメモに安定したタブ識別子を保持し、主要なナビゲーションのたびにページURLを再確認すること。
エージェントは認証・ログインフローにどう対応すべき？
Chrome DevTools MCP はログイン後のページ操作は可能ですが、認証をバイパスする手段ではありません。通常のログインでは、承認されたサインインURLに移動し、人間がパスワードを入力するかパスワードマネージャーによる入力を承認するのを待ち、MFA、OTP、CAPTCHA、セキュリティキーのプロンプトでは一時停止してください。本人がチャレンジの成功を確認した後にのみ操作を再開してください。
最小権限の原則に従ってください：テスト用アカウント、限定されたオリジンの許可リスト、銀行や個人メール、無関係なタブを含まないプロフィールを使用します。サイトがSSOにリダイレクトする場合は、最終的なオリジンを記録し、操作を行う前にアカウントの身元を確認してください。本番環境の自動化では、サービスの公式APIまたはOAuthデバイスフローを優先してください。アクセス制御を回避したり、所有者が承認した範囲外でプライベートトークンを再利用したりしないでください。
複数のエージェントで1つのDevTools MCPセッションを安全に共有できる？
同じMCPサーバーに接続することは可能ですが、同じタブを同時に操作するべきではありません。ナビゲーション、フォーカス、クリックは共有状態であるため、Claude Code、Cursor、Gemini CLI、OpenCode が競合したり、互いのコンテキストを上書きしたり、意図しないアクションを承認したりする可能性があります。キューと単一のドライバーを使用するか、各エージェントに別々のタブを割り当てて所有権を明確にしてください。
権限ダイアログは人間による境界であり、自動承認スイッチではない。承認は常に対話的に行い、発信元と要求されたアクションを確認し、共有タスクが完了したらセッションを終了すること。エージェントが並行作業を必要とする場合、分離されたブラウザSpaceを使用することでフォーカスの競合を防ぎ、タスクごとのCookieとタブを独立してスコープできる。
WSLやDockerからWindows上のChromeに接続するには？
ChromeとそのCDPエンドポイントをホスト上で実行し、そのエンドポイントをMCPクライアントが動作する環境から到達可能にする。WSL2では、127.0.0.1が共有されていると想定せず、WSLから見えるWindowsホストアドレスを使用する。Dockerでは、ポートを明示的に公開またはルーティングし、MCPプロセスを同じネットワーク経路に配置する。エージェントを起動する前に、curlで /json/version に対してテストすること。
クライアントがローカルで動作する場合は、CDPを常にlocalhostにバインドする。コンテナがホストに到達する必要がある場合は、9222をLANに公開するのではなく、ファイアウォールルールと認証付きトンネルまたはプライベートネットワークを使用する。コンテナのNodeおよびnpxのバージョンがMCPの要件を満たしていることを確認し、auto-connectのchrome://inspect権限フローがヘッドレスコンテナ内ではなく、ホストのChromeで実行されることを忘れないこと。
ローカルAIエージェントはChrome DevTools ProtocolでBraveを操作できる？
BraveはChromiumベースであり、文書化されたremote-debuggingオプションを指定して起動するとCDPを公開するため、ローカルエージェントは専用のChromeプロファイルと同様に --browserUrl 経由で接続できることが多い。ただし互換性は保証されない。Chrome DevTools MCPが正式にサポートするのはChromeであり、Brave固有のシールド、プロファイルパス、バージョン差異によって動作が変わる可能性がある。
まず使い捨てのBraveプロファイルで検証すること: ターゲットの一覧表示、スクリーンショットの取得、無害なローカルページのクリック、コンソール出力の確認を行う。Chromeについて説明したCookie、拡張機能、権限のリスクを確認するまでは、日常使用のBraveプロファイルにエージェントを向けないこと。
DevTools MCPでLighthouseパフォーマンス監査を実行するには？
DevTools MCP のパフォーマンスツールを使用して、トレースを開始し、対象ページをリロードし、ネットワークが安定するのを待ってから、Lighthouse 形式のパフォーマンス証跡（LCP、CLS、INP、ロングタスク、ネットワークリクエスト）を収集します。各メトリクスと併せて、URL、デバイスまたはスロットリングプロファイル、キャッシュ状態、トレース時間をエージェントに報告させてください。これらが欠けるとスコアを再現できません。
有効なプロンプト例：「現在のページでパフォーマンストレースを実行し、コールドキャッシュで一度リロードし、メインスレッドの最長タスクを3つ特定して、各原因となったリクエストまたはソースを明示してください。」コードを変更する前に、ウォームキャッシュでも同様に実行してください。DevTools の証跡はページが遅い理由を説明するものであり、代表的なデバイスでの管理された Lighthouse CI 実行の代替にはなりません。
RooCodeやAnythingLLMでChrome DevTools MCPが失敗するのはなぜ？
サードパーティ製クライアントの障害のほとんどは、ブラウザプロトコルの違いではなく、クライアント設定に起因します。クライアントが同じ npx コマンドを起動し、--autoConnect または --browserUrl を一度だけ渡し、ローカルプロセスを生成する権限を持っていることを確認してください。次に、クライアントの MCP ログでサーバーの stderr を確認し、/json/version または Chrome の権限ダイアログを独立して検証してください。
RooCode では、現在のプロファイルでサーバーが有効であり、モデルポリシーでツール呼び出しが許可されていることを確認してください。AnythingLLM または Docker では、Node の利用可能性、ホストへのネットワークルーティング、Chrome プロファイルのファイルシステム権限を確認してください。クライアントと chrome-devtools-mcp を一緒にアップグレードし、問題をスクリーンショット呼び出しに切り分けてから、ナビゲーションやトレースを追加してください。
ブラウザのバグ情報をCursorやClaude Codeと共有するには？
DevTools MCP で簡潔な証跡パケットを取得してください：現在の URL とタイトル、スクリーンショット、関連する DOM またはアクセシビリティサブツリー、ソース位置付きのコンソールエラー、ステータスコードとタイミング付きの失敗したネットワークリクエスト。そのパケットを Cursor または Claude Code 用に貼り付けるか保存し、正確な再現手順とブラウザバージョンを含めてください。
より広範な接続モデルの比較については、エージェントが既存ブラウザに接続する方法を参照してください。DevToolsの深さよりも低コンテキストでの利用を優先する場合は、制御層を選定する前にPlaywright MCPとCLIを比較してください。
共有前に、Cookie、認証ヘッダー、個人データ、非表示フォーム値を編集してください。完全なHARダンプよりも、決定的なハンドオフの方が有用です。失敗したリクエスト、表示されたエラー、状態を証明する最小限のDOMフラグメントを保持してください。受け取ったエージェントは、元のタブを制御することなくコード修正を提案できます。
既存のChromeと独立したブラウザ、どちらを選ぶべき？
セットアップがすべて成功しても、ひとつの事実は変わりません。エージェントはあなたが使っているブラウザ上で動作するのです。同じウィンドウ、同じタブ、同じフォーカスを共有します。エージェントが操作している間はそのタブは占有され、あなたが入力している間はエージェントの邪魔になります。Auto-connectはデバッグセッション向けに設計されており、エージェントと交代で操作するのが自然です。バックグラウンドタスク（「私が書いている間に3つのダッシュボードから数値を取得して」）では、交代制そのものが問題になります。
ego (lite) はエージェントに専用の Space を提供するため、あなたのウィンドウはあなたのままです。
シェルコマンドを実行できるエージェントは、ego-browserスキルを通じて ego (lite) を操作できます。手動のデバッグポート設定も、chrome://inspectの手順も、セッションごとの権限ダイアログも不要です。同じCDP制御が組み込まれており、操作されることを前提に作られたブラウザを対象としています。
現実的な役割分担として、Chrome DevTools MCPには固有の強みがある作業（パフォーマンストレース、メモリスナップショット、ライブセッションのデバッグ）を任せ、日常的なログイン必須タスクは自分のウィンドウを占有しないブラウザに任せます。
この役割分担には測定による裏付けがある。ただし注記が1つ付く。Real-World Bench（実サイトに対する31タスクのスイート、同一モデル、同一の独立した判定者）において、こちら側で測定されたツールはMCPサーバー自体ではなく、公式CLIの兄弟版であるchrome-devtools-cliだった。その結果は31タスク中61.3%の完全成功に対し、ego (lite) は31タスク中93.5%だった。このスイートはstockanalysis.comのスクリーナータスクのような操作中心の作業であり、エージェントはTechnologyでフィルタリングし、テーブルをValuationビューに切り替え、指標を順番に取得する必要がある。診断の深さとタスク完了は異なる仕事であり、その数値の差は本ガイドの役割分担と同じ方向に分かれている。
Mac版 ego (lite) をダウンロード または、以下をお読みください Chrome DevTools MCP と Playwright MCP の役割分担。いずれも無料です。
FAQ
Chrome DevTools MCP を Claude Code に追加するにはどうすればよいですか？
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest を実行します。実行中のブラウザに接続する場合は --autoConnect を追加してください。Claude Code 内で /mcp により確認後、現在のタブのスクリーンショットを依頼します。
Cursor や他のエージェントでも自動接続は機能しますか？
はい、これはクライアントではなく MCP サーバーの機能です。npx コマンドを実行できる MCP クライアントであれば動作します。ブラウザ側には Chrome 144+ と remote-debugging の有効化という同じ前提条件があります。
エージェントをログイン済みブラウザに接続しても安全ですか？
この仕組みは、従来のポート開放方式（セッションごとの権限ダイアログ、ローカルのみのサーバー、Google へのデータ送信なし）よりも安全ですが、付与される権限は広範囲です。Cookie、ストレージ、開いているすべてのタブにアクセスできます。ロック解除したノートパソコンを貸すのと同様に扱ってください。信頼できるエージェントに範囲を限定したタスクを任せるのは問題ありませんが、銀行やメインのメールに触れる作業には不適切です。
エージェントが自分の Chrome を使っている間も、ブラウジングを続けられますか？
技術的には可能だが、現実的には不可。ウィンドウと操作の焦点は共有される。エージェントがナビゲートやクリックを行うと、それはあなたが見ているタブ上で実行され、あなたの入力が操作の途中に割り込む可能性もある。自動接続セッションは、ペアプログラミングと同様に「ドライバーは常に1人」という前提で使うのが最適で、デバッグには向くが、バックグラウンドでの作業には不向き。
ウィンドウを占有せずに、ログイン済みのサイトでエージェントを動作させることはできますか？
Chrome DevTools MCP では実現できません。ウィンドウの共有はその設計に inherent なものです。ego (lite) では、Spaces がエージェントに専用のワークスペースを提供するため、エージェントがログイン済みのタスクを実行している間も、あなたのウィンドウとタブはあなたのままです。
DevTools ルートは実世界のベンチマークでどのようなスコアを出すのか？
Real-World Bench（ego-browser-benchmark-framework リポジトリ）は、1つのモデルと1つの独立した判定者を用いて、5つのツールで実在サイトに対して31タスクのスイートを実行しました。測定対象は MCP サーバーではなく、公式 CLI の兄弟版である chrome-devtools-cli です。31タスク中61.3%が完璧に成功し、タスクあたりの平均モデルコストは $4.95 でした。このコストを完了したタスクのみに按分すると、$4.95 ÷ 61.3% = 完了タスクあたり $8.08 となり、測定した5つのツールの中で最も高額です。デバッグ中心の運用ツールキットとしては、ほぼ予想通りの結果であり、このガイドがバックグラウンドタスクを他のツールに委ねる理由でもあります。
