2026.09.23 AI

Chrome DevTools MCPの導入手順と設定｜58ツールの絞り込みと接続方式を実装目線で解説

Chrome DevTools MCPの導入手順と設定｜58ツールの絞り込みと接続方式を実装目線で解説

Chrome DevTools MCP（パッケージ名 chrome-devtools-mcp）は、コーディングエージェントに実物のChromeを操作させ、DevToolsの計測結果をそのまま読ませるMCPサーバーです。npxで登録するだけで動く一方、既定のままだと58本のツールが全部見え、トレース対象のURLはGoogleのCrUX APIへ送られます。この記事では2026年9月時点のv1.9.0を対象に、導入手順、ツールカテゴリの絞り込み、計測の呼び出し順、既存Chromeへの2つの接続方式、通信制限と採用しない条件までを整理します。

まとめ｜導入は5分・決めるべき設定は3つ

導入は数行の設定JSONで終わります。詰まるのはその後の3点です。

第一にツールの露出範囲。既定では11カテゴリのうち6カテゴリ32ツールが有効になり、エージェントのコンテキストを食います。目視確認だけなら --slim で3ツールまで落とせます。第二に接続方式。新しいChromeを立ち上げるか実ブラウザへつなぐかで、ログイン状態の扱いも事故の範囲も変わる。第三に外部送信です。計測はトレース対象のURLをCrUX APIへ送り、使用統計もGoogleへ送られます。どちらも既定で有効なので、顧客の非公開環境を測るなら止める判断が要ります。

この3点を決めずに「npxで入れて動いたので本番でも」と進めると、エージェントが顧客のログイン済みタブを読める状態で放置されます。開発機の隔離プロファイルで使う分には強力な道具ですが、権限の線引きは人が引くしかありません。

Chrome DevTools MCPの現在地とnpm 1.9.0までの版の動き

「去年出た新しいやつ」で情報が止まりがちな領域です。まず版の現在地から合わせます。

2025年9月のプレビュー公開から1.9.0までの版と公開日

Chromeチームが公式ブログでパブリックプレビューを告知したのは2025年9月23日でした。npmレジストリ上では0.1.0が2025年9月16日、そこから0.x系で26版を重ね、1.0.0が2026年5月18日に出ています。2026年9月23日時点のlatestは1.9.0（2026年9月8日公開）、公開済みの版は61を数えます。

更新は2〜3週間に1回程度。設定に chrome-devtools-mcp@latest と書く公式推奨に従えば追随しますが、裏返せば、ある日ツール一覧が増えたり既定値が変わったりします。1.9.0ではトレースバッファの既定がDevToolsと同じ1.2GBへ上がりました。挙動が急に変わったときは、まずCHANGELOGを見てください。

READMEの名称がChrome DevTools for agentsへ変わった点

検索で引っかかる名前と公式の名前がずれています。GitHubリポジトリのREADME見出しは「Chrome DevTools for agents」で、本文は括弧書きで chrome-devtools-mcp を添える書き方です。npmパッケージ名とMCPサーバー名は変わっていないため、設定ファイルの記述を書き換える必要はありません。

MCPという規格そのものの位置づけは、MCPの仕組みとサーバーの作り方を整理した解説で先に押さえると、このサーバーが何をクライアントへ渡すのか掴みやすくなります。

Node.js 20.19以上とChrome安定版という前提条件の確認

READMEの要件はNode.js LTS・Chrome安定版以降・npmの3点です。実際のenginesは ^20.19.0 || ^22.12.0 || >=23 で、Node 20系なら20.19.0未満は弾かれます。ライセンスはApache-2.0。

ブラウザ側の制約はもう少し厳しめです。公式にサポートするのはGoogle ChromeとChrome for Testingだけで、他のChromium系は動くかもしれないが保証しない、という表現。修正の提供対象はExtended Stable Chromeの最新版と明記されています。Edgeや派生ブラウザで不具合が出ても自己責任の範囲です。

npxでMCPクライアントへ登録する導入手順と初回プロンプト確認

設定は1ファイルで済みます。

mcpServers設定JSONの最小記述と@latest指定の意味

クライアントの設定ファイルへ次を足します。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

公式は @latest を付ける形を推奨しています。npxが毎回レジストリを見るぶん初回起動は遅くなりますが、版ずれによる「手元では動くのに他のメンバーの環境で落ちる」を減らせる。社内で版を固定するなら [email protected] のように置き換えてください。エディタ別の書き場所は公式のClient Configurationsガイドにあり、クライアント側の権限設定はClaude Codeの導入と権限設定をまとめた記事で扱っています。

初回プロンプトでブラウザ起動とトレース記録を確かめる疎通手順

クライアントを再起動したら、公式の確認用プロンプト「Check the performance of https://developers.chrome.com」をそのまま投げます。成功すればChromeが自動で立ち上がり、ページを読み込んでパフォーマンストレースが記録されます。

ここで押さえておきたい挙動がひとつ。MCPサーバーに接続しただけではブラウザは起動しません。ブラウザを要するツールが最初に呼ばれた時点で、はじめてChromeが立ち上がる設計です。接続直後にウィンドウが出ないのは異常ではありません。

–slimで3ツールだけに絞る設定と通常モードとの使い分け

目視確認だけで足りるなら、スリムモードがあります。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--slim", "--headless"]
    }
  }
}

公式のSlim Tool Referenceに載っているのは navigate・evaluate・screenshot の3つだけです。58ツールぶんのスキーマが消えるため、トークン消費はかなり減る。逆に、ネットワーク一覧もトレースもコンソールログも取れません。「生成したUIが崩れていないか見せるだけ」ならslim、「遅い原因を調べさせる」なら通常モードという切り分けです。

58ツールの内訳とカテゴリフラグで露出範囲を絞る設定の考え方

既定で何が見えているかを把握せずに使うと、エージェントが妙なツールを呼びます。

11カテゴリ58ツールの内訳と既定で無効になるカテゴリの一覧

公式のTool Referenceを2026年9月23日時点で数えると、11カテゴリ58ツールでした。既定の有効・無効は次のとおりです。

カテゴリ ツール数 既定 主な用途
Input automation 10 有効 クリック・入力・フォーム
Navigation 6 有効 ページ遷移・タブ操作
Debugging 9 有効 コンソール・スクショ・監査
Emulation 2 有効 回線・端末の擬似設定
Performance 3 有効 トレース記録と分析
Network 2 有効 リクエスト一覧と詳細
Memory 13 無効 ヒープスナップショット
Extensions 5 無効 拡張機能の導入と操作
Progressive Web Apps 4 無効 PWAの導入と起動
Third-party 2 無効 ページ提供の開発ツール
WebMCP 2 無効 ページ側ツールの呼び出し

有効なのは6カテゴリ32ツール。Memoryの13本が隠れているのは、ヒープスナップショットの出力が巨大でコンテキストを潰すためです。メモリリークを追うときだけ --memory-debugging を足し、使わないカテゴリは --no-category-emulation のように個別で落とせます。

categoryExtensionsとcategoryPwaがpipe接続限定の制約

Configurationガイドに、見落とすと確実にはまる制約があります。拡張機能カテゴリとPWAカテゴリはpipe接続でしか使えず、--autoConnect・--browserUrl・--wsEndpoint と組み合わせても動きません。拡張機能側には「Chrome 149がリリースされるまでは非対応」と期限つきの但し書きが入っています。

実務での意味はひとつ。「手元で開いているChromeにつないで拡張機能のデバッグもさせたい」は現状できません。拡張機能を触らせるなら、MCPサーバー自身にChromeを起動させる構成へ戻します。

pageIdRoutingで並行セッションのタブを振り分ける既定動作

1つのMCPサーバーを複数の会話で共有すると、どのタブへの操作なのかが曖昧になります。これを避けるため、ページ単位のツールに pageId を要求する --pageIdRouting が既定で有効です。--no-page-id-routing を渡せば、選択中のページだけを対象にする旧来の動きへ戻り、セッションごとに独立したプロファイルを使うなら --isolated を併用します。

エージェントへ渡すツールをどこまで絞り、どの単位で権限を切るかという設計は、Chrome DevTools MCPに限らず共通の論点です。tool定義と認可の分け方はAIエージェントへMCPで外部ツールを接続する実装手順で整理しています。

performance_start_traceでパフォーマンス調査を回す作業手順

このサーバーの主戦場は、スクリーンショットではなく計測です。なおOS層まで含めた重い性能解析は守備範囲外で、ETWのようなカーネル側のトレースを扱うならWindows Performance Analyzer MCPとETW MCPの違いで整理した別系統を見てください。

トレース記録からinsight抽出までのツール呼び出しの順序

Performanceカテゴリのツールは3本です。performance_start_trace で記録を開始し、performance_stop_trace で止め、performance_analyze_insight でインサイトを掘る順序になります。

引数を見ると設計意図が読めます。start側は pageId が必須で、任意引数に reload（記録開始と同時に再読み込み）と autoStop、保存先の filePath を持つ。読み込み性能を測るなら reload を真にしないと、計測開始前に描画が終わって何も取れません。analyze側は insightName と insightSetId を要求するため、停止時に返る一覧を見てから名前を指定する2段構えです。ネットワーク側の list_network_requests も resourceTypes で型を絞らないと、一覧だけでコンテキストが埋まります。

CrUX APIへのURL送信が既定で有効という前提と停止方法

READMEに明記されている挙動です。パフォーマンス系ツールはトレース対象のURLをGoogleのChrome User Experience Report（CrUX）のAPIへ送り、実ユーザーのフィールドデータを結果に添えます。ラボ計測だけでは見えない体感を並べるための仕組みで、既定は有効。止めるには --no-performance-crux を渡します。

公開済みの本番URLを測るぶんには実害がありません。判断が要るのは、顧客の非公開ステージング環境や、URLにトークンが載る画面を測るとき。URL文字列そのものが外へ出る前提を関係者と共有しておいてください。

既存Chromeへ接続するautoConnectとbrowser-urlの選び分け

既定では専用プロファイルの新しいChromeが立ち上がります。ログインが必要な画面を触らせたいとき、これが壁になります。

Chrome 144以降のautoConnectで既存プロファイルへ接続

Advanced Usageガイドによると、起動中のChromeへつなぐ道は2本あります。ひとつが --autoConnect。Chrome 144以降が必要で、事前にブラウザ側で chrome://inspect/#remote-debugging を開き、ダイアログからリモートデバッグ接続を許可しておきます。

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

接続時には許可を求めるダイアログが出ます。プロファイルが複数あるときの接続先はChromeが決める既定プロファイルで、そこで開いている全ウィンドウがMCPサーバーから見える。手動テストとエージェント経由のテストで同じ状態を使い回す場面向けです。

サンドボックス環境でbrowser-urlとポート転送を使う条件

もう一方は --browser-url で、http://127.0.0.1:9222 のようなデバッグ用エンドポイントを直接指定します。公式が挙げる用途は、LLMをサンドボックス内で動かしていて外側のChromeへつなぎたいケース。WebDriver経由の起動を検知してサインインを拒むサービスを相手にするときも、この方式が要ります。CIコンテナ内でChromeを別サービスとして立てる組み方ができるのはこちら側です。

MCPサーバー自身にChromeを起動させる場合、ユーザーデータは既定で $HOME/.cache/chrome-devtools-mcp/chrome-profile に置かれ、実行のたびに消されず再利用されます。同時に使えるのは1ブラウザだけなので、並行して動かすなら --isolated で一時ディレクトリにしてください。終了時に消えるため、ログイン状態を残したくない検証にも向きます。

顧客案件へ入れる前に決める情報漏えい対策と通信制限の設定条件

ここが受託開発の現場で実際に止まる箇所です。判断を先に書きます。顧客の本番アカウントでログイン済みのブラウザへエージェントをつなぐ構成は、採用しないでください。

ブラウザの内容がMCPクライアントへ渡るという前提と隔離の判断

READMEの免責は率直です。このサーバーはブラウザの内容をMCPクライアントへ露出し、クライアントはブラウザやDevTools上のあらゆるデータを検査・デバッグ・改変できる、と書かれています。共有したくない機密情報をブラウザへ入れるな、とも。

つないだ瞬間に「開いているタブの中身はモデル側へ渡りうる」と考えるのが正しい。検証用アカウント、検証用データ、隔離プロファイルの3点を揃えてから接続すれば、事故の範囲は検証環境で止まります。

blockedUrlPatternとallowedUrlPatternでの通信遮断設定

通信そのものを縛る引数もあります。--blockedUrlPattern は指定したパターンのURLを遮断し、--allowedUrlPattern は許可したパターン以外を遮断する引数で、どちらもURLPattern仕様の記法で配列で渡せます。条件に反するターゲットからは黙って切り離され、実行中のナビゲーションやサブリソース取得も止まる。許可リスト側はChrome 149以降が必要です。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--isolated",
        "--no-usage-statistics",
        "--no-performance-crux",
        "--allowedUrlPattern", "https://staging.example.com/*",
        "--logFile", "/tmp/chrome-devtools-mcp.log"
      ]
    }
  }
}

ステージング環境の検証なら、この形が出発点です。許可ドメインを1本に固定し、隔離プロファイルで動かし、外部送信を止め、ログをファイルへ落として証跡にする。エージェントが指示から逸れて別サイトへ出ようとしても、ブラウザ層で止まります。

使用統計の既定送信とCI環境変数で自動的に止まる条件の確認方法

Googleはツール呼び出しの成功率・レイテンシ・環境情報などの使用統計を集めており、これも既定で有効です。Chromeブラウザ本体の統計送信とは独立していて、ブラウザ側でオプトアウトしていてもこちらは止まりません。逆も同じ。

止め方は3通りあります。引数に --no-usage-statistics を渡す、環境変数 CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS を設定する、あるいは CI 環境変数があれば自動で無効になる。社内のジョブ基盤が CI を立てていない場合は明示してください。更新チェックの通信も CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS で切れます。

顧客の本番アカウント上では採用しないと判断する具体的な条件の線引き

見送る条件を具体的に書きます。ひとつ、個人情報や決済情報が表示される画面を含む業務システム。ふたつ、本番権限でログインしたセッションを再利用する構成。みっつ、URLに認証トークンが載る設計のアプリでCrUX送信を止めていない状態。どれかに当たるなら、権限を落とした検証アカウントとダミーデータの環境を先に用意するのが順序です。

逆に、公開サイトの表示速度調査、社内ステージングのUI回帰確認、ローカル開発サーバーのデバッグなら、隔離プロファイルと許可パターンの設定だけで実用へ乗ります。顧客環境でブラウザ操作エージェントを動かすときの権限分離や証跡の設計まで含めて相談したい場合は、生成AI開発・AI受託開発で要件定義から対応しています。

実験扱いのCLIとCI実行で使う場合の制約とワークスペース指定

MCPクライアント抜きで、ターミナルから直接叩く道もあります。公式が実験的と明記している機能です。

グローバル導入したchrome-devtoolsコマンドと書き込み先の限定

CLIのドキュメントによると、パッケージをグローバル導入すると chrome-devtools コマンドが使えます。CLIは常駐するMCPサーバーへのクライアントとして動き、LinuxとmacOSではUnixソケット、Windowsでは名前付きパイプで通信します。

npm i chrome-devtools-mcp@latest -g
chrome-devtools status
chrome-devtools start --workspace=/path/to/project
chrome-devtools new_page "https://example.com"
chrome-devtools take_screenshot 1 --filePath screenshot.png
chrome-devtools stop

最初にツールを呼んだ時点で常駐プロセスとブラウザが自動起動し、以降は同じインスタンスが再利用されるため、開いたページやCookieの状態が保たれます。CLIではheadlessが既定で有効、--userDataDir を指定しない限りisolatedも既定で有効。注意すべきはファイルシステムへの無制限アクセスが既定という点で、保存先を縛るには --workspace でディレクトリを限定します。なおCLIから呼べるのは追加引数なしで動くツールに限られ、wait_for と fill_form は生成対象から外れています。

よくある質問

導入検討でよく挙がる質問を、公式ドキュメントの記述をもとにまとめます。

PlaywrightやPuppeteerの代わりになりますか？

役割が違います。Chrome DevTools MCPの内部ではPuppeteerが操作の実行に使われており、置き換えではなく上に乗る層です。テストコードとしてリポジトリに残しCIで毎回回すなら、PlaywrightやPuppeteerのスクリプトが適しています。MCP側が向くのは、コードを書く前の調査、不具合の再現確認、生成したUIの検証といった対話的な工程。調査はMCP、確定した回帰テストはコードへ落とす分担になります。

費用はかかりますか？有償プランは必要ですか？

chrome-devtools-mcp自体はApache-2.0のオープンソースで、npmから無償で導入でき、追加の契約やAPIキーも不要です。かかるのはMCPクライアント側、つまりコーディングエージェントが消費するトークンの費用になります。58ツールぶんのスキーマとトレース出力はコンテキストを大きく消費するため、使わないカテゴリの無効化やスリムモードへの切り替えが、そのまま費用差になります。

ヘッドレスで動かせますか？CIに組み込めますか？

--headless を渡せばUIなしで動き、ヘッドレス時のビューポートは最大3840x2160pxまで指定できます。CIについては、環境変数 CI があれば使用統計の送信が自動で無効になる配慮が入っており、実行自体は可能。ただし本体の更新が速いため、版を固定したうえでブラウザはコンテナ内に別途用意し、--browser-url でつなぐ構成が安定します。

社内の閉じたネットワークや認証付きの画面でも使えますか？

到達性があれば社内ステージングでも動きます。認証付き画面はログイン操作をツールで自動化するか、--autoConnect でログイン済みの実ブラウザへつなぐ方法がある。ただし後者は開いている全ウィンドウがMCPクライアントから見えるため、検証用アカウントに限定してください。自己署名証明書の環境には --acceptInsecureCerts がありますが、既定は無効で、公式も慎重に使うよう注記しています。

どのコーディングエージェントから使えますか？

READMEにはAntigravity・Claude・Cursor・Copilotが例として挙がっており、MCPに対応したクライアントなら同じ設定JSONで動きます。自社のエージェント製品へブラウザ操作のサブエージェントを組み込む場合も、Chrome DevTools for agentsの上に構築することが公式に推奨され、参照実装としてGemini CLIのbrowser agentが案内されています。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る