Web性能診断にChrome DevTools MCPが選ばれる理由

AI コーディングエージェントに UI の修正やパフォーマンス改善を任せたとき、「本当に直ったのか」を誰が確かめているでしょうか。多くの場合、確かめているのは人間です。エージェントはコードを書き換えることはできても、そのコードがブラウザ上でどう描画され、どこで時間を使い、どのリクエストが失敗しているかを見ることができません。

この「見えなさ」があると、改善は推測の積み重ねになります。「画像の遅延読み込みを入れれば速くなるはずです」という提案が返ってきても、そもそもボトルネックが画像なのかどうかはエージェントには分かっていません。結果として、人間が Chrome DevTools を開いてトレースを取り、原因を特定し、それをエージェントに伝え直すという往復が発生します。

この往復を減らすために、ブラウザを操作・検査できる MCP サーバーがいくつも登場しました。ただし選択肢が増えたことで、別の悩みが生まれています。Playwright MCP、browser-tools-mcp、クラウドブラウザ系のサーバー——名前は目にするものの、どれが自分たちの要件に合うのかを比べる材料が揃いません。

そこに Chrome DevTools チーム自身が公開しているのが Chrome DevTools MCP（npm パッケージ名は chrome-devtools-mcp）です。特徴は、ブラウザの「操作」よりも「計測とデバッグ」に重心を置いている点にあります。パフォーマンストレースの記録と知見抽出、ソースマップを適用したスタックトレース、ヒープスナップショットの比較といった、DevTools 固有の深い計測がそのままツールとして公開されています。

本記事では、Chrome DevTools MCP が何をするサーバーなのか、58 個のツール構成から読み取れる守備範囲、公式が明文化している設計思想、Playwright MCP や browser-tools-mcp との違いと使い分け、そして導入前に社内規程と照らし合わせるべき仕様（利用統計・CrUX 送信・ファイルシステムアクセス）までを整理し、採用判断の軸を提示します。

なお本記事の記述は、GitHub リポジトリの README と docs/ 配下の公式ドキュメント、Chrome for Developers の公式ブログ、および GitHub API から取得したリポジトリメタデータに基づくものです。インストールや実行による動作検証は行っておらず、すべて公開ドキュメントを整理した内容である点をあらかじめお断りしておきます。

Chrome DevTools MCPとは｜AIエージェントにブラウザ検査を任せる公式MCPサーバー

Chrome DevTools MCP は、コーディングエージェントが稼働中の Chrome を操作・検査できるようにする MCP（Model Context Protocol）サーバーです。GitHub 上のリポジトリ説明文は「Chrome DevTools for coding agents」（コーディングエージェントのための Chrome DevTools）と簡潔に位置づけを示しています。MCP クライアントを介さずに使える実験的な CLI も同梱されています。

開発元は Chrome DevTools チームです。サードパーティ製ではなく、DevTools の実装（devtools-frontend）をそのまま計測基盤として使える点が、この後で述べる機能の厚みにつながっています。

Chrome DevTools MCPが解決しようとしている課題

公式ブログ「Chrome DevTools (MCP) for your AI agent」は、解決対象の課題を明確に書いています。コーディングエージェントは、自分が生成したコードがブラウザ上でどう動くかを見ることができない、というものです。公開プレビューの発表は 2025 年 9 月 23 日でした。

同ブログが例示している指示文は、この課題の裏返しになっています。

• 「Verify in the browser that your change works as expected」（変更が期待どおり動くかブラウザで確認して）
• 「A few images on localhost:8080 are not loading. What's happening?」（localhost:8080 で一部の画像が読み込まれない。何が起きている？）
• 「Why does submitting the form fail after entering an email address?」（メールアドレスを入力した後にフォーム送信が失敗するのはなぜ？）
• 「Localhost:8080 is loading slowly. Make it load faster」（localhost:8080 の読み込みが遅い。速くして）

いずれも「人間が DevTools を開いて調べ、結果をエージェントに伝える」という工程を挟んでいた種類の依頼です。Chrome DevTools MCP は、その工程をエージェント自身に渡すことを狙っています。

なお、MCP サーバーに接続しただけではブラウザは起動しません。ブラウザを必要とするツールが呼ばれた時点で自動的に起動する設計です。

リポジトリの基本情報

採用可否を判断する際の一次材料として、GitHub API から取得したメタデータを整理します。

（出典: gh api /repos/ChromeDevTools/chrome-devtools-mcp 取得値、2026年9月15日時点）

メンテナンス状況の観点では、archived=false / fork=false / disabled=false です。アーカイブされておらず、他リポジトリのフォークでもない本流のプロジェクトとして稼働しています。ライセンスは Apache-2.0 が明示されており、ライセンス未設定のリポジトリにありがちな「使ってよいか分からない」という論点は生じません。スター 51,960 という規模は、後述する類似リポジトリの中でも最大級です。

Web性能診断にChrome DevTools MCPが選ばれる3つの理由

README が Key features として挙げているのは 3 点です。いずれも「ブラウザを操作できる」ではなく「ブラウザで何が起きているかを分かる形で取り出せる」方向に寄っています。ここでは各項目が、後述する Playwright MCP との差にどうつながるのかを添えながら見ていきます。

パフォーマンス知見の抽出とCrUXフィールドデータ

1 つ目は Get performance insights です。Chrome DevTools でパフォーマンストレースを記録し、そこから実行可能な知見を抽出します。公開されているツールは performance_start_trace / performance_stop_trace / performance_analyze_insight の 3 つで、トレースの記録開始・停止に加えて、記録済みトレースから個別の知見を掘り下げる操作が分離されています。

ここで重要なのは、返ってくるのが生のトレースデータではなく知見（insight）である点です。エージェントにとって 50,000 行の JSON は扱えませんが、「LCP は 3.2 秒」「レンダリングをブロックしているリソースはこれ」という粒度であれば次の行動に接続できます。この考え方は公式の設計思想として明文化されており、後ほど詳しく取り上げます。

加えて、パフォーマンスツールは Google の CrUX API にトレース URL を送信し、実利用者のフィールドデータを取得する場合があります。ラボ環境の計測値だけでなく、利用者の環境における指標も参照できるということです。ただしこれは外部への送信を伴うため、組織によっては確認が必要な項目になります（無効化の方法は後述します）。

ソースマップを適用したデバッグ情報

2 つ目は Advanced browser debugging です。ネットワークリクエストの解析、スクリーンショットの取得、コンソールメッセージの確認が含まれます。

注目すべきは、コンソールメッセージにソースマップを適用したスタックトレースが付く点です。バンドル後の main.a1b2c3.js:1:24601 という位置情報だけを渡されても、エージェントは修正すべきファイルを特定できません。ソースマップが適用されていれば、元のソースファイルと行番号に紐づけて考えられます。ビルド後のコードとソースコードの間にある断絶を埋める部分であり、エラー調査をエージェントに任せられるかどうかを左右します。

待機処理を自動化する信頼性の高い操作

3 つ目は Reliable automation です。内部的には Puppeteer を使ってアクションを自動化し、アクションの結果を自動的に待ちます。

ブラウザ自動化で最も壊れやすいのは、待機処理です。固定秒数の待機を挟むコードは、環境が変わるたびに不安定になります。待機をライブラリ側が引き受けるということは、エージェントが「クリックしたあと何秒待つべきか」を推測しなくてよいことを意味します。なお Puppeteer は競合ではなく、Chrome DevTools MCP が自動化基盤として利用している側のライブラリです。

58ツールの構成で分かるchrome-devtools-mcpの守備範囲

「何ができるか」を言葉で説明するより、公開されているツールの内訳を見るほうが守備範囲は正確に伝わります。公式の Tool Reference に掲載されているツールは、11 カテゴリ・合計 58 個です。

カテゴリ別ツール一覧

（出典: Tool Reference の見出し集計、2026年9月15日時点）

要素の指定方法にも設計が現れています。たとえば click の引数は pageId（必須）と uid（必須）で、uid はスナップショットから得られる要素 ID です。CSS セレクタを推測させるのではなく、いったんスナップショットを取ってそこに現れた要素を指す、という手順を前提にしています。

また fill_form の説明には、個別の fill や click を複数回呼ぶよりも常にこちらを優先すべきであり、高速かつ高信頼でターン数を削減できる、と明記されています。フォーム入力のように「1 項目ずつ埋める」とターン数が膨らむ操作に、まとめて扱う専用ツールを用意しているわけです。エージェント運用のコストに直結する部分で、公式が推奨の優先順位を示している点は判断材料になります。

Lighthouse の監査（lighthouse_audit）が Debugging カテゴリに含まれている点にも触れておきます。パフォーマンススコアの取得だけであれば、トレース解析まで踏み込まずにこのツールで足ります。

ヒープスナップショット解析という他にない厚み

カテゴリ別に見て最も多いのは、13 ツールを擁する Memory です。ヒープスナップショットの取得（take_heapsnapshot）、スナップショット同士の比較（compare_heapsnapshots）、オブジェクトの保持パス取得（get_heapsnapshot_retaining_paths）などが並びます。

メモリリークの調査は、DevTools の中でも手順が煩雑な領域です。操作前後でスナップショットを取り、差分を比較し、増えたオブジェクトが誰に保持されているかを保持パスで辿る——この一連の流れがツールとして分解されており、エージェントが順に呼び出せる形になっています。ブラウザ操作系の MCP サーバーの中で、ここまでメモリ解析に踏み込んでいるものはほとんどありません。Chrome DevTools の実装を土台にしていることの利点が、最も分かりやすく出ているカテゴリと言えます。

既定で無効になっているカテゴリと有効化の条件

58 ツールすべてが最初から使えるわけではありません。Configuration Guide によれば、Extensions（--categoryExtensions）、PWA（--categoryPwa）、実験的なサードパーティ開発者ツール（--categoryExperimentalThirdParty）は既定値が false で、明示的に有効化する必要があります。

さらに Extensions と PWA のツールには接続方式の制約があります。これらは pipe 接続でのみサポートされ、--autoConnect / --browserUrl / --wsEndpoint による接続では利用できません（Chrome 149 のリリースまで、と公式ドキュメントに記載があります）。「稼働中の Chrome に接続して拡張機能を操作する」という組み合わせは現時点では成立しないため、拡張機能の自動化を目的に検討している場合は、この制約を先に確認しておく必要があります。

逆に、Emulation / Performance / Network といった主要カテゴリは既定で有効ですが、--categoryEmulation などのフラグでカテゴリ単位の除外もできます。エージェントに渡すツール数を絞ってコンテキストを節約したい場合に使える設定です。

設計思想から読み解くChrome DevTools MCPのツール設計

Chrome DevTools MCP が他のブラウザ系 MCP サーバーと最も違うのは、設計方針が Design Principles として公開されている点かもしれません。長期的に自社のエージェント基盤へ組み込めるかを判断するうえで、実装の現状より方針のほうが手がかりになる場面があります。ここでは 7 原則のうち、採用判断に直結する 3 つを取り上げます。

トークン最適化と「Reference over Value」

Token-Optimized の原則は、意味のある要約を返すべきであり、「LCP was 3.2s」のほうが 50,000 行の JSON より良い、と述べています。大量のデータはファイルに置く、という方針も併記されています。

これを補強するのが Reference over Value の原則です。スクリーンショット・トレース・動画のような重いアセットは、生データではなくファイルパスや resource URI として返す、と定めています。

この 2 つが意味するのは、コンテキストウィンドウの消費を設計段階から抑えているということです。ブラウザ検査は本質的に大量のデータを生む作業であり、それをそのままエージェントに流し込むと、1 回のトレース取得でコンテキストが埋まってしまいます。トークン単価とコンテキスト上限は運用コストに直結するため、ここに明確な方針があるかどうかは実務上の差になります。

小さく決定的なツールを合成する設計

Small, Deterministic Blocks の原則は、「魔法のボタン」ではなく合成可能な小さいツール（Click / Screenshot）をエージェントに渡す、と述べています。

58 個というツール数は一見多すぎるようにも見えますが、この原則から見れば必然です。「パフォーマンスを改善する」のような高レベルの単一ツールを用意すると、内部で何が起きたかがブラックボックスになり、失敗したときに切り分けができません。小さく決定的な単位に分けておけば、エージェントは状況に応じて組み合わせられますし、人間も実行ログを追えます。

関連して Self-Healing Errors の原則は、文脈と修正候補を含む対処可能なエラーを返すこと、Human-Agent Collaboration の原則は、出力が機械可読（構造化）かつ人間可読（要約）であることを求めています。エージェントが自力で回復できる余地と、人間が途中経過を検証できる余地の両方を残す方針です。

エージェント非依存であることの意味

Agent-Agnostic API の原則は、MCP のような標準を使い、特定の LLM にロックインしないことを掲げています。加えて Progressive Complexity の原則が、既定は単純に保ちつつパワーユーザー向けの高度な任意引数を提供する、としています。

採用判断の観点では、特定のエージェント製品に依存しないことは無視できない条件です。README では、Antigravity・Claude・Cursor・Copilot といった複数のコーディングエージェントからの利用が想定されているほか、製品に「ブラウザサブエージェント」として組み込む用途も挙げられ、Gemini CLI の browser agent が参照実装として示されています。自社プロダクトにブラウザ操作能力を組み込む検討をしている場合、この位置づけは評価材料になります。

Playwright MCP・browser-tools-mcpとの違いと使い分け

ここまでで Chrome DevTools MCP が何をするかは整理できました。次は「では他と比べてどうか」です。日本語での検索でも「Playwright MCP とどちらを選ぶべきか」という論点は繰り返し取り上げられており、選定の中心はこの比較にあります。

主要な類似リポジトリの比較

（出典: 各リポジトリの gh api /repos/{owner}/{name} 取得値、2026年9月15日時点）

browserbase/mcp-server-browserbase は、クラウド上のリモートブラウザを操作する構成で、ローカル Chrome を必要としない点が差分でした。ただし 2026 年 7 月時点でアーカイブ済みであり、新規採用の候補にはしにくい状態です。比較表に含めたのは、選択肢の地図として「クラウド実行という方向性もあるが、この実装は止まっている」という情報が判断に必要なためです。

また、しばしば同じ文脈で名前が挙がる browser-use/browser-use（スター 114,639・MIT）は、MCP サーバーではなく Python 製のブラウザエージェントフレームワークです。エージェント本体を自作する層に属するため、Chrome DevTools MCP の直接の代替にはなりません。レイヤーが違うものを横並びで比べると判断を誤るので、切り分けて考える必要があります。

Playwright MCPを選ぶべきケース

Playwright MCP の最大の差分は、クロスブラウザ対応です。Chromium だけでなく Firefox・WebKit を扱えるため、「Safari で表示が崩れる」「Firefox だけ挙動が違う」といった検証が要件に含まれる場合、Chrome DevTools MCP では守備範囲が足りません。公式サポート対象が Google Chrome と Chrome for Testing に限られているためです。

もう 1 つの差分は、E2E テストコードの生成との相性です。Playwright MCP はアクセシビリティツリーのスナップショットから要素の参照を取得して操作し、等価な Playwright のコード例をレスポンスに含められます。エージェントにブラウザを触らせた結果をそのままテストコードとして残したい場合、この性質は直接的な利点になります。

したがって、以下に該当するなら Playwright MCP が有力です。

• 複数ブラウザでの表示・挙動の検証が必要である
• 目的が E2E テストの作成・保守であり、成果物としてテストコードが欲しい
• Playwright を既にテスト基盤として採用しており、実行環境を揃えたい

Chrome DevTools MCPを選ぶべきケース

一方、Chrome DevTools MCP が優位なのは「動くかどうか」ではなく「なぜ遅いのか・なぜ壊れたのか」に踏み込む場面です。パフォーマンストレースの解析、CrUX のフィールドデータ参照、ヒープスナップショットの比較、ソースマップを適用したスタックトレースは、いずれも Playwright MCP の守備範囲外にあります。

判断軸としては次の 3 点が使えます。

1. クロスブラウザ検証が要件か：必要なら Playwright MCP、Chrome 中心で足りるなら Chrome DevTools MCP
2. 成果物としてテストコードが欲しいか：欲しいなら Playwright MCP、原因特定が目的なら Chrome DevTools MCP
3. 原因の深掘りまで任せたいか：パフォーマンス・メモリ・ネットワークの原因特定までエージェントに渡したいなら Chrome DevTools MCP

browser-tools-mcp が向くのは、これらとはまた別の状況です。Chrome 拡張機能とローカルサーバーの構成で、人が開いているブラウザのコンソールログ・ネットワークログを IDE 側へ取り込むことに特化しています。操作の自動化やパフォーマンス計測の深さは限定的ですが、「自分が触っているブラウザのログをそのままエージェントに見せたい」という用途には素直に噛み合います。MIT ライセンスである点も、ライセンス要件によっては選定理由になり得ます。

併用という選択肢

3 つの中から 1 つを選ばなければならないわけではありません。MCP サーバーはクライアント側で複数登録できるため、クロスブラウザの E2E は Playwright MCP、パフォーマンスとメモリの原因特定は Chrome DevTools MCP、という使い分けも成立します。

ただし併用にはコストがあります。登録したツールの定義はコンテキストを消費するため、ツール数の多いサーバーを複数入れると、それだけでエージェントの作業余地が削られます。Chrome DevTools MCP には基本的なブラウザ操作のみに絞る --slim モードや、カテゴリ単位でツールを除外するフラグが用意されているので、併用する場合はこうした設定で搭載ツールを絞る前提で考えるとよいでしょう。

導入前に確認したいChrome DevTools MCPの仕様と制約

機能面で候補に残ったとして、組織として導入できるかは別の問いです。README の Disclaimers と設定ドキュメントには、社内規程との照合が必要になりそうな項目がいくつか含まれています。事前に洗い出しておくと、導入後に差し戻される事態を避けられます。

ブラウザ内容の露出とサポート対象ブラウザ

README が最初に挙げている注意点は、Chrome DevTools MCP がブラウザインスタンスの内容を MCP クライアントに露出させる、という点です。したがって、MCP クライアントに渡したくない機微情報や個人情報を扱わないよう明記されています。

ここは運用ルールの設計が必要な箇所です。既定では専用プロファイルで新しい Chrome が起動しますが、後述する「稼働中の Chrome に接続する」構成を選ぶと、業務用のログインセッションを保持したブラウザの内容がエージェント経由で外部の LLM に渡り得ます。どのプロファイルで動かすかは、機能の話ではなく情報管理の話として決めるべきでしょう。

サポート対象も限定されています。公式にサポートされるのは Google Chrome と Chrome for Testing のみで、他の Chromium 系ブラウザは動作保証の対象外です。サポートは Extended Stable Chrome の最新版に対してコミットされている、と記載されています。社内で配布しているブラウザが対象に含まれるかは確認が必要です。

なお動作要件は Node.js の LTS、Chrome の stable 以降、および npm です。

既定で有効な利用統計とCrUX送信の無効化方法

外部送信に関わる項目が 2 つあります。いずれも既定で有効なので、無効化が必要かどうかを判断する必要があります。

1 つ目は利用統計です。Google が利用データ（ツール呼び出しの成功率・レイテンシ・環境情報など）を収集しており、既定値は有効です。Chrome ブラウザ本体のメトリクス設定とは独立している、と明記されています。無効化する手段は 3 つあり、--no-usage-statistics フラグを渡すか、CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS 環境変数を設定するか、CI 環境変数が設定されている環境で動かすかです。CI 環境では自動的に無効になる点は、パイプラインに組み込む場合に知っておくと役立ちます。

2 つ目は CrUX API への送信です。パフォーマンスツールは、フィールドデータを取得するためにトレースから得た URL を Google の CrUX API に送信する場合があります。--no-performance-crux で無効化できます。社内検証環境の URL やステージング環境のホスト名が外部に出ることを許容できない場合は、この設定を先に固める必要があります。

このほか、既定では npm レジストリへの更新確認が行われます。外部通信を絞りたい環境では CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS 環境変数で無効化できます。

同梱CLIのファイルアクセス範囲

Chrome DevTools MCP のパッケージには、MCP クライアントを介さずに使える実験的な CLI が同梱されています。npm i chrome-devtools-mcp@latest -g でインストールすると chrome-devtools コマンドが使えるようになり、バックグラウンドで動くデーモンに対するクライアントとして機能します（Linux / macOS は Unix ソケット、Windows は名前付きパイプを使用）。最初のツール呼び出しで自動起動し、以降は同じインスタンスを再利用してブラウザの状態（開いているページや Cookie）を保持します。start / stop / status で明示的に制御することもできます。

導入時に確認すべきなのは、この CLI が既定で無制限のファイルシステムアクセスを有効にすることです。CLI ドキュメントは、--workspace フラグでファイル操作系ツールの対象ディレクトリを限定できると説明しています。フラグは複数回指定できます。

chrome-devtools start --workspace=/path/to/project --workspace=/path/to/output

（出典: docs/cli.md）

互換性のために --allow-unrestricted-paths も単独では使えますが、--workspace との併用はできません。CLI の利用を前提にするなら、作業ディレクトリを限定する運用を最初から決めておくのが無難です。出力形式は既定で人間可読のサマリですが、--output-format=json で機械可読形式にも切り替えられます。なお CLI で使えるのは追加引数なしで動くツールに限られ、拡張機能系のツールは CLI では扱えません。

接続方式と並行セッション運用の設定

ここまでの制約を踏まえたうえで、自分たちの開発環境に合わせてどう構成するかを整理します。設定オプションを網羅するのではなく、運用パターンごとに必要な組み合わせを見ていきます。

最小構成と--slimモード

README の Getting started には、MCP クライアントの設定例が掲載されています。

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

（出典: README.md）

npx で最新版を取得して起動するだけの構成です。README は動作確認用の指示文として Check the performance of https://developers.chrome.com を示しています。

搭載ツールを絞りたい場合は --slim を指定します。基本的なブラウザ操作のみに限定する設定で、ヘッドレス実行と組み合わせた例も README に掲載されています。

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

（出典: README.md）

他の MCP サーバーと併用する場合や、エージェントに渡すツール定義を軽くしたい場合の出発点になります。

稼働中のChromeに接続する2つの方法

既定では専用プロファイルで新しい Chrome インスタンスが起動します。Advanced Usage Guide は、これが適さない状況として 3 つのケースを挙げています。

1. 手動でのサイト検証とエージェント駆動の検証で、アプリケーションの状態を共有したい場合
2. サイトへのサインインが必要で、WebDriver 制御下ではサインインを拒否されるアカウントがある場合
3. LLM をサンドボックス環境内で動かしつつ、サンドボックス外の Chrome に接続したい場合

これらに該当する場合は、先に Chrome を起動しておき、サーバーから接続する構成を取ります。方法は 2 系統です。

自動接続（Chrome 144 以降） は、手動検証との状態共有に向いています。Chrome で chrome://inspect/#remote-debugging を開いて受け入れ可否を設定したうえで、サーバーに --autoConnect を渡します。複数プロファイルがある場合は既定プロファイルに接続し、そのプロファイルの全ウィンドウにアクセスできます。前節で述べたブラウザ内容の露出という注意点は、この構成で最も強く効いてきます。

リモートデバッグポート経由の手動接続 は、サンドボックス環境での利用に向いています。--browserUrl（例: http://127.0.0.1:9222）で接続先を指定します。WebSocket エンドポイントを直接指定する --wsEndpoint や、カスタムヘッダを付与する --wsHeaders も用意されています。

ここで思い出したいのが、既に触れた拡張機能・PWA ツールの制約です。これらは pipe 接続でのみサポートされるため、--autoConnect や --browserUrl での接続とは併用できません。「稼働中の Chrome に接続しつつ拡張機能も自動化する」という構成は現状では選べない、という点は設計段階で押さえておく必要があります。

複数エージェントで同時に使う場合の設定

サブエージェントを並行で走らせる構成では、ユーザーデータディレクトリとページのルーティングの 2 点が問題になります。

ユーザーデータディレクトリの既定値は、Linux / macOS が $HOME/.cache/chrome-devtools-mcp/chrome-profile、Windows が %USERPROFILE%\.cache\chrome-devtools-mcp\chrome-profile です。非 stable チャネルを使う場合はディレクトリ名にチャネル名が付きます。このディレクトリは実行間でクリアされずに再利用され、同時に 1 つのブラウザしか使えません。独立したセッションごとに一時プロファイルを使いたい場合は --isolated を指定します。終了時に自動で破棄される一時ディレクトリに切り替わります。

ページのルーティングについては、1 つのサーバーインスタンスを複数のエージェント／サブエージェントで共有する場合に、各エージェントが自分の担当タブへツール呼び出しを振り分けられる必要があります。Configuration Guide には --pageIdRouting が既定 true で記載されており、ページスコープのツールで pageId を必須にしてページ ID によるルーティングを行う設定です（無効化は --no-page-id-routing）。一方 Advanced Usage Guide の並行セッションの節では --experimentalPageIdRouting を付けて起動する例が示されています。ドキュメント間でフラグ名の表記が異なるため、指定すべきオプション名は、利用するバージョンの --help 出力で確認することをおすすめします。

このほか運用上有用な設定として、--channel（canary / dev / beta / stable の切り替え）、--proxyServer や --chromeArg による Chrome 起動引数の制御、--viewport（例: 1280x720、ヘッドレス時の上限は 3840x2160）、--logFile（バグ報告用のデバッグログ出力）、--acceptInsecureCerts（自己署名・期限切れ証明書のエラーを無視。注意して使用）などが用意されています。

メンテナンス状況とライセンスから見た採用判断

開発ツールの採用可否を左右するのは、機能と同じくらい「継続して手入れされているか」です。この観点では、Chrome DevTools MCP の状況は良好と言えます。

最新リリースは v1.9.0（2026 年 9 月 8 日）です。その前は v1.8.0（2026 年 8 月 25 日）、v1.7.0（2026 年 8 月 10 日）で、およそ 2 週間間隔でマイナーリリースが続いています。GitHub API 上の最終 push は 2026 年 9 月 14 日で、リリース間隔とも整合します（Releases）。

リリース内容の傾向にも注目すべき点があります。v1.9.0 には、CLI の --allow-unrestricted-paths の既定化、設定可能なファイルシステムルートへの対応、JavaScript 実行ツールを無効化するオプション、ソースマップ無効化オプションといった項目が含まれます。加えて Agent Plugins 1.0 パッケージの追加、cookie デバッグ用スキルの追加、screencast の fps オプション、パフォーマンストレースのバッファ既定値を DevTools と同じ 1.2GB に揃える変更などが並びます。

ここで読み取れるのは、機能追加と並行して権限制御側の設定が厚くなっているという傾向です。「JavaScript の実行を止められる」「ファイルシステムのルートを絞れる」といった項目は、個人の実験用途では不要ですが、組織導入では必須になりがちな設定です。こうした方向に開発リソースが割かれていることは、業務利用を想定するチームにとって前向きな材料になります。

ライセンスは Apache-2.0 です。特許条項を含むため企業利用でのライセンスレビューが通りやすく、社内ツールへの組み込みでも論点になりにくいライセンスです。フォーク数 3,648 という数字は、単に利用されているだけでなく、コードに手を入れる層が一定数存在することを示しています。

一方で、留意すべき点もあります。同梱 CLI は実験的な機能と位置づけられており、既定が変わる可能性があります。拡張機能ツールの pipe 接続限定という制約にも「Chrome 149 がリリースされるまで」という条件が付いており、仕様は動いている最中です。バージョンを固定せず @latest で運用する場合、この変化の速さは利点にも不確実性にもなります。安定性を優先するなら、設定ファイルでバージョンを固定する運用を検討する価値があります。

まとめ｜Chrome DevTools MCPが向くチーム・向かないチーム

Chrome DevTools MCP は、ブラウザを「操作する」ことよりも「計測して分かる形で返す」ことに軸足を置いた MCP サーバーです。58 個のツール構成、Memory カテゴリの厚み、要約を返す設計方針——いずれも、エージェントに原因特定まで任せるという狙いから逆算されています。

向いているのは、次のようなチームです。Chrome を主対象としたフロントエンド開発を行っており、パフォーマンス・メモリ・ネットワークの原因特定までエージェントに任せたいチーム。ソースマップ適用済みのスタックトレースを前提に、エラー調査の初動を自動化したいチーム。そして、設計思想が公開されていることを、長期的に基盤へ組み込む際の判断材料として評価するチームです。

慎重に判断すべきなのは、クロスブラウザ検証が要件に含まれるチームです。公式サポートは Google Chrome と Chrome for Testing に限られるため、Firefox や WebKit での検証が必要なら Playwright MCP のほうが要件に合います。E2E テストコードの生成を主目的とする場合も同様です。

もう 1 つ、外部へのデータ送信を一切許容できない環境も慎重な検討が必要です。利用統計と CrUX API 送信はいずれも既定で有効であり、無効化する手段は用意されているものの、その設定を確実に全員の環境へ行き渡らせる運用が前提になります。ブラウザインスタンスの内容が MCP クライアントに露出する点も、扱う情報の性質によっては規程上の論点になります。

判断を進める順路としては、まず README で Disclaimers と最小構成を確認し、機能の守備範囲を詰めたければ Tool Reference を、設計方針への納得感を得たければ Design Principles を、導入条件を固めたければ Configuration Guide と Advanced Usage Guide を参照する、という流れが取れます。自分たちが「動くかどうかの確認」を求めているのか、「なぜそうなるのかの特定」を求めているのか——その切り分けを起点に検討してみてください。

関連情報

AI エージェントを開発フローに組み込む設計や、フロントエンドのパフォーマンス改善を含む開発基盤の整備をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。