Chrome DevTools MCPとは｜使い方と既定29ツールの中身・Playwright MCPとの違い

Chrome DevTools MCPは、AIコーディングエージェントに「実際に動いているChrome」を触らせるための、Chrome開発チーム公式のMCPサーバーです。スクリーンショットを見せて推測させるのではなく、コンソールのエラー、実際に飛んだネットワークリクエスト、性能トレースといった実測値そのものをエージェントに渡せます。

MCPサーバーそのものの仕組みや、自分で作る場合の手順はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。本記事は「既にMCPを使っている人が、このサーバーを入れるべきか・どう絞るか」を判断するための記事です。

Chrome DevTools MCPとは——AIエージェントにDevToolsを開放するサーバー

ChromeDevTools/chrome-devtools-mcp は、Chrome DevToolsの機能をMCP（Model Context Protocol）経由でAIエージェントに開放するサーバーです。開発元はChrome DevToolsそのものを作っているチームで、リポジトリはChromeDevTools organizationの下にあります。2026-08-06時点でGitHubスターは48,593、ライセンスはApache-2.0、npmの最新版は1.6.0（2026-07-14公開）です。

READMEが掲げる特徴は3つです。

・性能インサイトの取得：DevToolsのトレース記録機能をそのまま使い、記録したトレースから改善点を抽出する
・ブラウザデバッグ：ネットワークリクエストの解析、スクリーンショット、コンソールメッセージの取得。スタックトレースはソースマップで解決される
・信頼できる自動化：Puppeteerを使って操作を実行し、その結果を自動で待つ

3つ目が地味に効きます。素のCDP（Chrome DevTools Protocol）を直接叩くと「クリックしたが次の描画がまだ」という競合状態を自分で捌く必要がありますが、Puppeteerが操作後の待機を面倒みてくれるため、エージェント側は「押した→次を見る」と素直に書けます。

「AIにブラウザを触らせる」との違い

ブラウザ操作系のMCPサーバーやエージェントは既にたくさんあります。差が出るのは取れる情報の種類です。

一般的なブラウザ操作ツールが返すのは、スクリーンショットとアクセシビリティツリー、つまり「見た目」です。これで「ボタンが押せない」までは分かっても、「なぜ押せないのか」は分かりません。Chrome DevTools MCPが返すのはDevToolsの中身、つまり以下のような症状ではなく原因側の情報です。

・コンソールに出ている例外とそのスタックトレース（ソースマップ解決済み）
・実際に飛んだHTTPリクエストのステータス・ヘッダー・タイミング
・性能トレースから抽出したインサイト（どこで詰まっているか）
・Lighthouse監査の結果
・ヒープスナップショット（メモリリークの調査用）

「フォーム送信が失敗する」という報告に対して、エージェントが自分でネットワークタブを見て「POSTが422で落ちていて、レスポンスボディにバリデーションエラーが入っている」と特定できる、という差です。

実際に何を頼めるのか

ツール一覧を眺めるより、頼める内容から逆算した方が導入判断は早くなります。既定の29ツールで成立するのは、たとえば次のような依頼です。

・デバッグ：「このページを開いてコンソールのエラーを全部拾って、原因になっているファイルと行を特定して」——navigate_pageでページを開き、list_console_messagesで例外を取得します。スタックトレースはソースマップで解決済みなので、ビルド後のバンドルではなく元のソース位置が返ります
・通信の調査：「ログインボタンを押して、そのとき飛んだリクエストのステータスとレスポンスを見せて」——clickで操作し、list_network_requestsとget_network_requestで個別のリクエストを掘ります
・性能調査：「トップページが遅い理由を調べて」——performance_start_traceでトレースを記録し、performance_analyze_insightで抽出された改善点を読ませます。lighthouse_auditで監査スコアを取ることもできます
・再現手順の確認：「モバイル幅・低速回線でこの画面がどう崩れるか見て」——emulateでCPUスロットリングやネットワーク条件を指定し、resize_pageで幅を変え、take_screenshotで確認します
・修正の検証：「直したので、さっきのエラーが消えたか確認して」——同じ手順を繰り返すだけなので、人間が確認作業から抜けられます

いずれも共通しているのは、人間がDevToolsを開いてログをコピーし、チャットに貼り付ける往復が消えるという点です。エージェントが推測ではなく実測に基づいて次の手を決められるようになります。

インストールと接続手順（Claude Code・Cursor・VS Code・Codex）

必要なのはNode.jsのLTS版、現行安定版以降のChrome、そしてnpmの3つだけです。サーバー自体のインストール作業はなく、npxで都度取得する構成が公式の推奨です。

すべてのクライアントで共通して使える設定はこれです。

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

CLIを持つクライアントなら1行で登録できます。

# Claude Code（ユーザースコープに登録）
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

# Codex
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

# Gemini CLI（グローバル）
gemini mcp add -s user chrome-devtools npx chrome-devtools-mcp@latest

VS Codeはコマンドラインからも追加できます。Cursorは設定画面のMCP→New MCP Serverに上のJSONを貼るか、READMEのインストールボタンを使います。JetBrains系はSettings | Tools | AI Assistant | Model Context Protocol (MCP)から同じJSONを登録します。READMEにはAmp、Antigravity、Cline、Copilot CLI、Devin CLI、Factory CLI、Grok Build CLI、Kiro、Mistral Vibe、OpenCode、Qoder、Visual Studio、Warp、Windsurfなど20種類以上のクライアント向け手順が個別に載っています。

プラグインとして入れる選択肢

Claude CodeとVS Code（Copilot）では、MCPサーバー単体ではなくスキル込みのプラグインとして入れる方法が用意されています。Claude Codeの場合は次の2コマンドです。

/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

READMEには、既にMCPサーバーとして登録済みの場合は先に既存の設定を削除するよう注意書きがあります。二重登録になるためです。プラグイン版はツールに加えて「これらのツールをどう使うか」のスキルが付くので、エージェントが性能トレースの読み方などを知った状態で始まります。再起動後に/skillsで読み込みを確認できます。

動作確認

READMEが提示する最初のプロンプトはこれです。

Check the performance of https://developers.chrome.com

これでブラウザが開き、性能トレースの記録が走れば接続は成功です。ここで重要な挙動が1つあります。MCPサーバーに接続しただけでは、Chromeは起動しません。ブラウザが必要なツールがエージェントから最初に呼ばれた時点で初めて立ち上がります。

これは実測でも確認できました。ツール一覧の取得（tools/list）だけを投げた前後で、Chromeのプロセス数はいずれも0のままでした。つまりMCPクライアントの起動時に常時Chromeが常駐して重くなる、という心配は要りません。

既定で入るのは29ツール——ドキュメントの52本との差はどこから来るのか

ここからが、公式ドキュメントを読むだけでは分からない部分です。

リポジトリのdocs/tool-reference.mdとREADMEの自動生成ブロックには、52本のツールが列挙されています（カテゴリ別の内訳もREADMEに書かれており、合計は52で一致します）。ところが、READMEの標準設定どおりにnpx chrome-devtools-mcp@latestを起動してtools/listを投げると、返ってくるのは29本でした。

差の23本はどこへ行ったのか。答えは「フラグで明示的に有効化しないと出てこない」です。--helpを読むと、カテゴリ単位の出し入れが用意されていることが分かります。

既定でOFFになっていて、フラグで足せるのがこちらです。

逆に、既定でONだが外せるのがこちらです。

実際に「増やせるものを全部増やす」構成で起動したところ、51本まで到達しました。ドキュメントの52本に対して、届かなかったのは1本だけです。

・get_heapsnapshot_object_details：mainブランチのドキュメントには記載がありますが、npmで配布されている1.6.0のtools/listには現れませんでした

ここで1つ、ツール登録の仕組みが分かる挙動がありました。--categoryExperimentalWebmcpのヘルプには「Chrome 149以降と--enable-features=WebMCP,DevToolsWebMCPSupportが必要」と条件が書かれていますが、このフラグを付けてtools/listを投げるとlist_webmcp_tools / execute_webmcp_toolの2本はそのまま登録されました。前述のとおり列挙の時点ではChromeが1プロセスも起動していないので当然ではあるのですが、つまりツール一覧に載るかどうかはフラグだけで決まり、ブラウザ側の条件は実際にそのツールを呼んだときに効くという切り分けです。ヘルプの前提条件を満たしていなくてもツール定義のぶんのコンテキストは消費される、と理解しておくのが安全です。

残るget_heapsnapshot_object_detailsの1本については、ドキュメントが参照しているmainブランチ（2026-08-05にpush）と、npmの最新版1.6.0（2026-07-14公開）の間に3週間の差があるため、1.6.0の後に追加されたものと考えるのが自然です。いずれにせよREADMEやツールリファレンスはmainの状態を映しているため、@latestで入る内容と完全には一致しません。

tools/listを実測する——slim 3本と最大51本でコンテキストは36倍違う

MCPサーバーを繋ぐコストは、ツールを呼んだときだけ発生するのではありません。ツール定義そのものが、毎ターン、コンテキストに載り続けます。ツールを1つも使わなくてもかかる固定費です。

そこで、構成を変えながらtools/listのJSON応答のバイト数を測りました。方法はシンプルで、stdioでMCPサーバーを起動し、initialize→notifications/initialized→tools/listの順にJSON-RPCを送り、返ってきたresultをUTF-8のバイト数として数えるだけです。トークン数ではなくバイト数で示すのは、トークン化はモデルによって変わるためです。

いずれもchrome-devtools-mcp 1.6.0、2026-08-06の実測値です。最小と最大では約36倍の開きがあります。既定構成の23,254バイトは、日本語の記事に換算すればそこそこの分量が常に居座っているのと同じことです。

既定29本の中で特に重いツール定義は次のとおりでした。引数が多く、説明文が長いものほど嵩みます。

emulateが最大というのは意外ですが、CPUスロットリングやネットワーク条件、地理位置情報など指定できる項目が多いためです。性能計測をしないのであれば、--no-category-emulationと--no-category-performanceを付けるだけで体感できる量が削れます。

--slimの落とし穴——サブセットではなく別名

--slimは「ナビゲーション・スクリプト実行・スクリーンショットの3ツールだけ」という最小構成です。1,037バイトまで落ちるので、単にページを開いて中身を見たいだけの用途では非常に効率的です。

ただし、ここに実測しないと気づけない罠があります。

--slimのツール名は navigate / evaluate / screenshot です。一方、既定モードの対応するツールは navigate_page / evaluate_script / take_screenshot です。両者のツール名の重複はゼロでした。

つまり--slimは既定モードから機能を間引いたサブセットではなく、名前ごと別の3ツールです。実務上の影響は明確で、既定モード前提で書いたプロンプト・カスタムスキル・エージェントの手順書は、--slimに切り替えた瞬間にツール名が解決できず動かなくなります。逆も同じです。コンテキスト削減のつもりで--slimを足すときは、ツール名を直書きしている箇所がないか先に確認してください。

Playwright MCPとの違い——Chrome DevTools MCPを選ぶ基準

ブラウザ操作系MCPの比較対象として最もよく挙がるのが、Microsoftの@playwright/mcpです。公平を期すため、同じ計測方法で両方を実測しました。

数字だけ見ればchrome-devtools-mcpの方が5ツール多く、4,742バイト重いという結果です。ただし選択の決め手はサイズではありません。

Chrome DevTools MCPを選ぶ場面は、「計測」が目的のときです。性能トレース、Lighthouse監査、ヒープスナップショットは、実測した@playwright/mcpの24ツールの一覧には相当するものが見当たりませんでした。「このページが遅い理由を調べさせたい」「メモリリークの犯人を探させたい」という用途は、現状Chrome DevTools MCPの独壇場です。

Playwright MCPを選ぶ場面は、クロスブラウザが要るときです。Chrome DevTools MCPのREADMEは、公式にサポートするのはGoogle ChromeとChrome for Testingのみで、他のChromium系ブラウザは動くかもしれないが保証しない、と明記しています。Firefox・WebKitでの挙動確認が要件に入るなら、そもそも選択肢に入りません。

なお両者は排他ではありません。E2Eテストの実行はPlaywright側、失敗したときの原因調査はDevTools側、という分担も成立します。ただし両方を常時繋ぐとtools/listだけで41,766バイトになるため、常用するのは片方に絞り、必要なときだけもう片方を有効化するのが現実的です。MCPサーバーが増えてきたら、MCPJungle徹底解説｜散らばるMCPサーバーを1本に束ねる自己ホスト型MCPゲートウェイのようなゲートウェイで束ねる手もあります。

トークン消費を抑えるという観点では、コードを読ませる側で同じ問題に取り組んだSerena MCPの使い方｜セマンティック解析でClaude Codeのトークンを削るも参考になります。

既定でONになっている送信と、その止め方

導入前に把握しておくべき挙動が3つあります。いずれもREADMEに明記されていますが、設定をコピペするだけだと見落としやすい部分です。

1. 使用統計の送信（既定ON）

Googleがツール呼び出しの成功率・レイテンシ・環境情報などを収集します。READMEには「Data collection is enabled by default」と明記されています。止めるには起動引数を足します。

"args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]

環境変数 CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS または CI が設定されている場合は自動的に無効になります。CI上で動かす分には既定でも送信されない、ということです。なおREADMEは、この収集はChromeブラウザ本体の使用統計とは独立しており、Chrome側でオプトアウトしても自動的にはこちらのオプトアウトにならない（逆も同様）と注記しています。

2. CrUX APIへのURL送信（既定ON）

性能計測ツールは、実ユーザーの体感データを併せて提示するため、トレース対象のURLをChrome User Experience Report（CrUX）のAPIへ送ることがあります。ラボデータだけでなくフィールドデータも見せるための仕組みですが、社内向けの検証環境やステージングURLを扱う場合は挙動を把握しておくべきです。--no-performance-crux で無効化できます。

3. 更新チェック（既定ON）

サーバーは定期的にnpmレジストリを見て、新しいバージョンがあればログに通知します。CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS 環境変数で止められます。

ブラウザの中身が見えるということ

READMEの免責事項には、chrome-devtools-mcpはブラウザインスタンスの内容をMCPクライアントに公開し、クライアントはブラウザやDevTools内のあらゆるデータを閲覧・デバッグ・改変できる、と書かれています。共有したくない機微な情報・個人情報を扱わないよう促す注意書きです。

これは実際に効いてくる話です。既定の設定では、Chromeは $HOME/.cache/chrome-devtools-mcp/chrome-profile に作られる専用プロファイルを使いますが、--browserUrl や --autoConnect で普段使いのChromeに接続する構成にすると、そこにログイン済みのセッションがすべてエージェントの視界に入ります。切り分けるための選択肢は用意されています。

・--isolated：毎回使い捨てのユーザーデータディレクトリを作り、ブラウザを閉じたら破棄する
・--userDataDir：プロファイルの場所を明示的に指定する
・--blockedUrlPattern / --allowedUrlPattern：ブラウザのネットワークアクセスをURLパターンで制限する（allow側はChrome 149+が必要）
・--redactNetworkHeaders：機微とみなされるネットワークヘッダーを、クライアントへ返す前に伏せ字にする

なおファイル書き込み系のツールについては、MCPクライアントがroots機能を提供していない場合、既定でOSの一時ディレクトリ配下に制限される仕様です。1.6.0で追加された --allowUnrestrictedPaths はこの制限を外すフラグで、READMEには「rootsを実装していない信頼できるローカルクライアントに接続する場合のみ使うこと」と条件が添えられています。

権限の渡し方という観点では、同じく公式MCPサーバーであるGitHub MCPとは｜公式MCPサーバーの使い方・86ツール・リモート/ローカル版と権限設計を解説でも似た論点を扱っています。

よくある詰まりどころ

実際に導入するときに引っかかりやすい点を、公式のトラブルシューティングと実測から整理します。

ブラウザが起動しない／接続できない

まず、接続しただけでは起動しない仕様であることを思い出してください。エージェントに「このページの性能を見て」と頼めば起動します。それでも起動しない場合は、Chromeが現行安定版以降か、Node.jsがLTS版かを確認します。Chromeの場所が特殊なら --executablePath で明示します。

Windows 11のCodexで起動がタイムアウトする

READMEに専用の記述があり、.codex/config.toml で SystemRoot と PROGRAMFILES を環境変数として渡し、startup_timeout_ms = 20_000 と起動タイムアウトを延ばす設定が案内されています。

Claude Codeのプラグインインストールが Failed to clone repository で失敗する

企業のファイアウォール配下でHTTPS接続が塞がれている場合に起きます。回避策はトラブルシューティングガイドに載っていますが、claude mcp add によるCLIインストール（MCPサーバーのみ・スキルなし）に切り替えるのが手っ取り早い解決です。

既に起動しているChromeに繋ぎたい

--browserUrl http://127.0.0.1:9222 で既存のデバッグ可能なChromeへ接続できます。WebSocketで繋ぐ --wsEndpoint もあり、こちらは --wsHeaders で認証ヘッダーを付けられます。Chrome 144以降なら --autoConnect で、指定チャンネルのローカルChromeへ自動接続する方法もあります（Chrome側で chrome://inspect/#remote-debugging からリモートデバッグを有効にしておく必要があります）。

Antigravityの場合は、内蔵ブラウザに繋ぐ構成が公式に案内されており、--browser-url=http://127.0.0.1:9222 を指定します。この構成ではサーバー側がブラウザを起動しないため、Antigravity側でブラウザを先に立ち上げておく必要があります。

スクリーンショットでコンテキストが膨らむ

1.6.0には出力サイズを抑えるオプションが揃っています。--screenshotFormat に jpeg か webp を指定するとPNGより大幅に小さくなり（READMEは3〜5倍小さいと記載）、--screenshotQuality で圧縮率、--screenshotMaxWidth / --screenshotMaxHeight で上限サイズを指定できます。エージェントに何度もスクリーンショットを撮らせる運用なら、最初に設定しておく価値があります。

拡張機能のツールが動かない

--categoryExtensions のヘルプに注記がありますが、この機能は現状パイプ接続でのみサポートされており、--autoConnect・--browserUrl・--wsEndpoint との併用はChrome 149のリリースまで対応しません。既存のChromeに繋ぐ構成では使えない、ということです。

参照ソース

・ChromeDevTools/chrome-devtools-mcp — GitHubリポジトリ（README・スター数・ライセンス。2026-08-06閲覧）
・Chrome DevTools MCP Tool Reference（52ツールの一覧とカテゴリ内訳）
・Chrome DevTools MCP Slim Tool Reference（--slimの3ツール）
・chrome-devtools-mcp — npm（バージョン1.6.0・公開日2026-07-14）
・CHANGELOG.md（1.5.0・1.6.0の変更点）
・Troubleshooting guide（プラグインのclone失敗など）
・@playwright/mcp — npm（比較対象・バージョン0.0.79）

本文中の実測値（ツール数・tools/listのバイト数・Chromeプロセス数）は、2026-08-06にmacOS上のNode.js 22.13.1で、stdio経由のJSON-RPCによって取得したものです。バージョンはchrome-devtools-mcp 1.6.0、@playwright/mcp 0.0.79、Chrome 150.0.7871.187です。