技術 約13分で読めます

Chrome DevTools MCPが既存ブラウザセッションへの接続に対応

Chrome DevTools MCP AI Security

コーディングエージェントにブラウザのデバッグを任せる場面が増えている。Chrome DevToolsのMCPサーバーはその橋渡し役だが、これまでは専用ユーザープロファイルでChromeを起動するか、リモートデバッグポートに明示的に接続する必要があった。通常の開発作業で使っているChromeをそのまま使えないのが地味に面倒だった。

今回追加された --autoConnect オプションはこの制約を取り除く。既存のChromeセッションを起動したまま、MCPサーバーがその接続を要求できるようになった。

Chrome DevTools MCPとは

Chrome DevTools MCPは、ChromeのDevTools機能をModel Context Protocolのツールとして公開するMCPサーバーだ。内部的にはChrome DevTools Protocol（CDP）を使い、WebSocket経由でブラウザと通信する。Claude Code、Gemini CLI、Cursor、Windsurfなどのコーディングエージェントと組み合わせることで、エージェントがChromeを直接操作・検査できるようになる。

具体的にエージェントが実行できる操作は以下のようなものだ。

  • URLへのナビゲーション
  • DOM要素の検査と操作
  • ネットワークリクエストの確認
  • ページ内でのJavaScript実行
  • スクリーンショットの取得
  • コンソールエラーの確認

「この要素のスタイルがおかしい」「このAPIリクエストがエラーを返している」といった問題をエージェントが自律的に調査し、修正案を提示してくれる。

なぜCLIではなくMCPなのか

ブラウザ操作をAIに任せるだけなら、Vercel Labsのagent-browserのようなCLI経由のアプローチもある。実際「MCPはコンテキストウィンドウを食うからCLIで十分」という意見は根強い。2026年3月にはPerplexityのCTO Denis YaratsがMCPからCLI/APIへの移行を発表し、Y CombinatorのCEO Garry TanもMCPの代わりにCLIを構築する方針を示した。

コンテキストコストの現実

MCPサーバーはツール定義をプロンプトに展開するため、多機能なサーバーほどトークンを消費する。この問題は定量的に検証されている。

指標MCPCLI差
GitHub操作（93ツール定義）約55,000トークン約200トークン275倍
Intune準拠タスク（50デバイス）約145,000トークン約4,150トークン35倍
コンテキストの推論利用率約64%約95%-

MCPでは3〜4回のツール呼び出し後に多段階推論が破綻するケースが報告されている。ツール定義がコンテキストウィンドウの末端に重要な情報を押し出してしまうためだ。mcp2cliのようなMCPをCLIに変換するツールも登場しており、「トークンコストを96〜99%削減できる」と謳っている。

それでもGoogleがMCPを選んだ理由

一方で、MCPをCLIの上位互換と見るのは誤解だ。MCPは「共通プロトコル」であって、特定のCLIツールとは設計思想が異なる。

比較軸CLI（agent-browser等）MCP（Chrome DevTools MCP）
統合方式エージェントがシェルコマンドを実行プロトコル経由でツールを呼び出し
エージェント間互換エージェントごとにコマンド解釈が異なる共通スキーマで全エージェント対応
ツール発見エージェントがヘルプを読んで把握サーバーがツール一覧を構造化して提供
コンテキストコスト低い（必要なコマンドだけ）ツール定義分のトークンを消費
双方向性標準出力の解析に依存構造化レスポンスで返却

CLIはコンテキスト効率が高い反面、エージェントが「何ができるか」を事前に知る手段がない。agent-browser --help を読ませるか、使い方をシステムプロンプトに書く必要がある。MCPならサーバーがツールスキーマを宣言的に提供するので、エージェントは接続した時点で利用可能な操作を把握できる。

GoogleがDevToolsの統合にMCPを選んだのはこの点が大きい。CLIだとClaude Code用、Gemini CLI用、Cursor用と個別に対応する必要があるが、MCPなら1つのサーバーで全エージェントに対応できる。ChromeはWebMCPでもAnthropicのMCPとは独立した「ブラウザ上のMCP」を仕様化しており、MCPをエージェント間の共通言語として位置づける方針が一貫している。

実際の使い分けとしては「CLIをデフォルトにし、MCPの特定の保証が必要な場合にフォールバックする」方向に傾いている。DevTools MCPはまさに「MCPでないと困る」ケースだ。ブラウザのデバッグセッション管理、リアルタイムのDOM変更通知、複数タブの状態管理など、単純なコマンドの入出力では扱いきれない双方向の通信が必要になる。

—autoConnectが実現すること

--autoConnect オプションをMCPサーバーに渡すと、MCPサーバーは --channel パラメータ（デフォルトはstable）で識別されるユーザーデータディレクトリから、ローカルで実行中のChromeインスタンスにリモートデバッグ接続を要求する。

セッション再利用

既存のブラウザセッションをそのまま使えるため、認証済みのページをデバッグする際に再ログインが不要になる。開発中のサービスにログイン済みの状態で、エージェントにそのまま作業を引き継げる。ダッシュボード画面のバグを修正しながらエージェントに実際の表示を確認させる、といった使い方が自然にできる。

DevTools UIとの連携

DevTools UIでアクティブになっているデバッグセッションにアクセスできる。ネットワークパネルで選択中のリクエストや、Elementsパネルでハイライト中の要素を、エージェントがそのまま調査できる。人間が「このネットワークエラーを見て」と指定する代わりに、DevToolsで該当リクエストを選択した状態でエージェントに渡すだけでよい。

想定されるユースケース

Googleが公式ドキュメントで挙げているのは開発中のデバッグだが、実際にはもっと広い使われ方が見込まれる。

認証済みWebアプリのテスト自動化

ステージング環境にSSOでログインした状態で、エージェントにE2Eテストを走らせる。従来はテスト用のサービスアカウントを用意するか、Playwrightで認証フローを自動化する必要があったが、--autoConnect なら人間が普通にログインした後のセッションをそのまま渡せる。

OpenClawからのブラウザ操作

OpenClawは2026年3月13日のアップデートで「Live Chrome session attachment」機能を追加した。ログイン済みのChromeブラウザセッションにOpenClawエージェントを直接接続できる機能で、内部的にはChrome DevTools MCPを使っている。

OpenClawのブラウザ制御は3つのモードを提供している。

モード方式用途
Extension RelayChrome拡張経由で既存タブを制御ログイン済みセッションの操作
OpenClaw-managed隔離されたブラウザインスタンス自動化タスク
Remote CDPCDP直接接続分散クラウドデプロイ

Extension Relayモードは --autoConnect と同じ思想で、人間がログインした状態のブラウザをそのままエージェントに渡す。SlackやDiscordと連携しているOpenClawインスタンスに「このURLの表示を確認して」と投げれば、ブラウザを開いてスクリーンショットを取って返す、といった使い方だ。GitHub Issue #16567ではネットワークキャプチャやLighthouse監査の統合リクエストも出ている。

ただしこれはセキュリティ的にはかなり危うい話でもある。OpenClawのエコシステム自体がサプライチェーン攻撃の標的になっていることを考えると、悪性スキルがDevTools MCP経由でブラウザセッションにアクセスするシナリオは現実的だ。Snykの監査ではClawHubの3,984スキルのうち1,467（36.82%）にセキュリティ上の問題があり、76件が悪性と確認されている。悪性スキルがExtension Relayモード経由でログイン済みセッションのCookieやトークンを抜くのは、技術的に容易だ。

セキュリティ設計と残る懸念

リモートデバッグはデフォルトで無効になっている。有効化するには chrome://inspect/#remote-debugging を明示的に操作する必要があり、接続要求ごとにChromeが許可ダイアログを表示する。セッション中はブラウザ上に「Chrome is being controlled by automated test software」バナーが常時表示される。Chrome 136以降はセキュリティ上の理由でデフォルトプロファイルでのリモートデバッグがブロックされており、意図的にこの制限を解除する必要がある。

GitHub READMEには以下の警告が記載されている。

chrome-devtools-mcp exposes content of the browser instance to the MCP clients allowing them to inspect, debug, and modify any data in the browser or DevTools.

この設計は意図的なものだ。既存のブラウザセッションにアクセスできるということは、ログイン済みのすべてのサービスにアクセスできるということでもある。ユーザーが明示的に有効化し、接続のたびに承認が必要な仕組みにすることで、悪用リスクを最小化している。

とはいえ、いったん接続が確立されればセッションは生きたままだ。ここにいくつかの未解決の問題がある。

認証済みセッションの暗黙的な委譲

エージェントにDevToolsアクセスを許可した時点で、そのブラウザでログインしているすべてのサービスにエージェントがアクセスできる。Gmail、GitHub、社内ツール、銀行サイト。DevToolsのJavaScript実行機能を使えば、Cookie、localStorage、sessionStorageの中身も取得できる。

graph TD
    A[ユーザーがリモートデバッグを許可] --> B[MCPサーバーがChromeに接続]
    B --> C[エージェントがDevTools APIを取得]
    C --> D[任意のURLにナビゲーション可能]
    C --> E[任意のJavaScriptを実行可能]
    C --> F[Cookie・localStorageの読み取り可能]
    D --> G[ログイン済みサービスに<br/>エージェントとしてアクセス]
    E --> H[認証トークンの抽出が<br/>技術的に可能]
    F --> H

許可ダイアログは「このMCPサーバーにデバッグアクセスを与えるか」を問うだけで、「どのタブに」「どの操作を」許可するかの粒度はない。全か無かの設計になっている。

この問題はMicrosoft Copilotのデータ保護ポリシー迂回問題と構造が同じだ。Copilotは組織のアクセス制御ポリシーを迂回して機密メール（契約書、人事文書、法務文書）にアクセスできてしまった。「AIは信頼された仲介者」として従来のアクセス制御をバイパスする新しいセキュリティベクトルだとされたが、DevTools MCPでも同じことが起きる。エージェントは人間のセッションを「信頼された仲介者」として利用し、人間が意図しないサービスにもアクセスできてしまう。

プロンプトインジェクション経由の攻撃

エージェントが「このURLを開いて確認して」という指示を受けたとき、そのURLがログイン必須のサービスだった場合どうなるか。認証済みセッションでは、エージェントは普通にログイン済み状態でそのページにアクセスする。エージェント側には「このサービスにはアクセスしない」という制約を設定する仕組みがない。

graph TD
    A[攻撃者がコードコメントや<br/>Issueに悪意あるURLを埋め込む] --> B[エージェントがコードを読む]
    B --> C[プロンプトインジェクションで<br/>URLを開くよう誘導]
    C --> D[認証済みセッションで<br/>攻撃者のページにアクセス]
    D --> E[ページ上のスクリプトが<br/>セッション情報を取得]
    D --> F[エージェントにJS実行を<br/>指示してトークンを抽出]

これは理論上の話ではない。Perplexity Cometの脆弱性では、Redditの投稿に埋め込まれた悪意あるコマンドがエージェントにアカウント設定へのナビゲート、メール抽出、ワンタイムパスワード取得を実行させた。視覚的プロンプトインジェクションでは、偽CAPTCHAに隠された指示がビジョン対応エージェントを100%の確率で欺いたという研究結果もある。

間接プロンプトインジェクションの72%以上がモデルのガードレールをバイパスするという調査があり、「エージェントが自律的にブラウザを操作する」設計とプロンプトインジェクションの組み合わせは、従来のWebセキュリティ（Same-Origin Policy、CORS）を無意味にする。エージェントはフルユーザー権限でサイト間をブリッジできるからだ。

Chromeのゼロデイとの複合リスク

Chromeは2026年に入って攻撃面が急速に広がっている。

CVEコンポーネント種類CVSSパッチ時期
CVE-2026-2441CSS/Blinkuse-after-free8.82026年2月
CVE-2026-2649V8整数オーバーフロー-2026年2月
CVE-2026-3909Skiaout-of-bounds write8.82026年3月
CVE-2026-3910V8不適切な実装8.82026年3月
-Mojoゼロデイ-2026年3月

V8の脆弱性ならページを開くだけでサンドボックス内のコード実行が成立する。Skiaの脆弱性と組み合わせれば、サンドボックスエスケープからOSレベルの任意コード実行に至る攻撃チェーンも構成できる。

DevTools MCP経由でエージェントがURLを開く行為は、人間がそのURLをクリックするのと同じリスクを持つ。エージェントが自律的にURLを巡回する設計では、人間が1つ1つのURLを目視確認することはない。「エージェントが開いたページにゼロデイ攻撃が仕込まれていた」というシナリオは、--autoConnect で既存セッションを使う場合に特に深刻になる。認証済みセッションのCookieやトークンが攻撃者に渡る可能性があるからだ。

推奨される対策

Chrome DevTools MCPを使う場合の現実的な対策は以下の通りだ。

  • 隔離プロファイルの使用: --user-data-dir で専用プロファイルを作り、開発に必要なサービスだけにログインする。--autoConnect は便利だが、銀行やメールなど無関係なサービスにログインしたブラウザで使わない
  • 開発・テスト環境限定: 本番環境の認証情報が入ったブラウザでは使わない
  • エージェントの出力監視: エージェントがアクセスしたURLやJS実行のログを確認する。Chrome DevTools MCPはデフォルトでツール呼び出しの統計を収集しているが（--no-usage-statistics でオプトアウト可能）、これはGoogleへの送信用であってユーザー向けの監査ログではない
  • コンテンツファイアウォール: 正規表現パターン検出とLLMセマンティック分析を組み合わせたプロンプトインジェクション検出。ただし完全な防御は困難

セットアップ手順

Chrome M144以降が必要（M144がStableに昇格するまでは --channel=beta を指定する）。

手順1: リモートデバッグを有効化

Chromeで chrome://inspect/#remote-debugging を開き、ダイアログの指示に従ってリモートデバッグを有効化する。

手順2: MCPサーバーを設定

Claude Codeでの設定例:

claude mcp add chrome-devtools --scope user -- npx chrome-devtools-mcp@latest --autoConnect

JSON設定ファイルを直接編集する場合:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--channel=beta"
      ]
    }
  }
}

Gemini CLI、Cursor、Windsurfなど他のMCP対応エージェントでも同様の設定が可能だ。

手順3: 動作確認

エージェントに「現在開いているページのパフォーマンスを分析して」など、ブラウザの状態に言及するプロンプトを送ってみる。

既存の接続方法との関係

--autoConnect は既存の接続方法を置き換えるものではなく、補完として追加された。従来からある接続方法は以下の3つ。

方法用途
MCPサーバー専用プロファイルでChromeを起動隔離された環境でのテスト・自動化
リモートデバッグポートを指定して接続CI環境や特定インスタンスへの接続
一時プロファイルで複数インスタンスを分離並列テスト、互いに干渉しない環境

認証済みの既存セッションをそのまま活用したい場合、--autoConnect が最もシンプルな選択になる。ただし「シンプル」は「安全」とイコールではない。専用プロファイルや一時プロファイルを使う方法は、まさにこの記事で書いたセキュリティ上の懸念を回避するための設計だった。--autoConnect はその隔離を意図的に外す機能であり、利便性と引き換えに何を差し出しているかを把握してから使うべきだ。

個人的には --autoConnect 自体は便利な機能だと思う。ただ、OpenClawが「real logins, one toggle, zero extensions」と宣伝しているのを見ると、「簡単に使える」ことがそのまま「簡単に悪用される」ことにつながる未来が見える。Chrome DevTools MCPのGitHub READMEにある警告文は控えめに言っても不十分で、「ブラウザ内のあらゆるデータにアクセスできます」を太字で書くべきだと思った。

関連記事