Playwright MCP vs Chrome DevTools MCP：同じフォームで実機テスト

要点

• ツール自身が Chrome を起動した場合、両サーバーともすべての入力欄を埋め、ファイルをアップロードし、同一オリジンとクロスサイトの iframe の中でも操作できました。どちらも5回中5回です。
• 人がすでに開いていた Chrome に接続した場合、Playwright MCP は開いているフォームにそのまま入力できました。Chrome DevTools MCP 1.10.1 はクリックはできたものの、入力欄を埋められたのはページを1回再読み込みした後だけで、これはすべての実行で同じでした。
• Chrome DevTools MCP が起動した Chrome は navigator.webdriver = true を返し、Playwright MCP が起動した Chrome は false を返しました。自分で起動した Chrome では、どちらも false でした。
• クリーンで再現性のある実行と短いツール一覧を求めるなら Playwright MCP を選んでください。自分の Web アプリをデバッグしたい（トレース、Lighthouse、ネットワーク）場合や、普段使っている Chrome をエージェントと共有したい場合は Chrome DevTools MCP が向いています。

テスト結果

各セルは 5 回中の成功回数です。テスト日 2026年9月30日、Google Chrome 154.0.8037.92、@playwright/mcp 0.0.83、chrome-devtools-mcp 1.10.1、3列目として agent-browser 0.38.1。

モード1：ツールが自分で Chrome を起動する

各ツールは新しいプロファイルフォルダでヘッドレスの Chrome を起動し、テストページを開いてページにログインし、フォームを埋め、人が行うステップにはチェックを入れずに送信ボタンを押しました。

モード2：人がすでに使っている Chrome にツールが接続する

Chrome は私たちが専用のプロファイルとローカルのデバッグポート付きで起動しました。人の代役がページを開き、ログインし、プロダクト名を入力しました。次にツールが接続して残りを埋めて停止し、代役が人のステップにチェックを入れて送信し、最後にツールが結果を読み取りました。

実行時のスクリーンショット

テスト方法

• 2026年9月30日に macOS 上の Google Chrome 154.0.8037.92 で実施しました。バージョンは固定しています：@playwright/mcp 0.0.83、chrome-devtools-mcp 1.10.1、agent-browser 0.38.1。
• フォームは 127.0.0.1 上のローカルのテストページで、クロスサイトの iframe は別ポートの localhost から読み込まれます。実在の Web サイト、アカウント、個人のブラウザプロファイル、支払いは一切使っていません。
• 小さなスクリプトが、エージェントのクライアントとまったく同じように MCP で各サーバーとやり取りしました。スナップショット、フォーム入力、アップロード、クリック、コンソールとネットワークの読み取りです。要素の参照は各ツール自身のスナップショットから取得しました。判断を下す言語モデルは使っていないため、すべての実行が同じ手順をたどりました。
• 各シナリオはツールごとに 5 回実行しました。表は成功した回数を示しています。
• モード2の「人」は、タブに素の DevTools Protocol コマンドを送るスクリプトです。代役であり、実在の人ではありません。これが Chrome DevTools MCP の入力失敗の原因でないことを確かめるため、スクリプトを使わずにテスト URL を指定して Chrome を直接起動する方法も試しましたが、結果は同じでした。
• agent-browser は MCP モードではなく、主なインターフェースであるコマンドラインから操作しました。

このテストの対象外

• 実際の CAPTCHA、ボット検出、第三者サイトでの実際のログイン。
• Firefox と WebKit、両プロジェクトのブラウザ拡張機能、Chrome の自動接続ダイアログ。
• パフォーマンストレース、Lighthouse、メモリツール。
• 言語モデルが手順を選ぶ場合：実際のエージェントが必要とするトークン数やターン数はモデルによって変わります。
• Windows と Linux。

目立った点

ドキュメント記載（未テスト）

以下の違いは、確認日時点の各プロジェクトの README とドキュメントに基づくもので、私たちは測定していません。

ツール一覧の重さ

ページを開く前の時点で、Playwright MCP は 25 個のツールと 20.3 KB のツール説明を、Chrome DevTools MCP は 30 個のツールと 25.7 KB を提示しました（デフォルト設定、tools/list で測定）。エージェントはこのテキストをセッション中ずっとコンテキストに抱えます。Chrome DevTools MCP には3つのツールだけにする --slim があり、Playwright MCP は --caps でツール群を追加します。

どちらを選ぶか

agent-browser は？

agent-browser は、オプションで MCP モードも備えたエージェント向けのコマンドライン型ブラウザツールです。自分でブラウザを起動した場合は同じフォームを埋めましたが、起動中の Chrome に接続した場合はクロスサイトの iframe を見落としました。エージェントが MCP ツールより短いシェルコマンドのほうをうまく扱えるなら、検討する価値があります。

Claude in Chrome vs Chrome DevTools MCP：違いと使い分け →

自分でテストする

テストページは依存関係のない Node.js ファイル1つです。自分のマシン上でのみ待ち受けます。

1. ファイルをダウンロードし、Node.js 18 以降で実行します。
2. http://127.0.0.1:4461/ を一度開いてページを確認します。クロスサイトの iframe の読み込み元は http://localhost:4462/ です。
3. 下の MCP 設定のいずれかをエージェントに追加し、フォームを埋め、任意の小さな PNG をアップロードし、両方の iframe を埋めて、人のステップの手前で止まるよう指示します。
4. 人のステップに自分でチェックを入れて送信し、ページに今何が表示されているかをエージェントに尋ねます。

ダウンロード browser-mcp-test.mjs

このファイルはフォーム、iframe、ローカルのエコーエンドポイントを提供します。それ以外の場所には何も送信しません。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@0.0.83"
      ]
    }
  }
}

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.10.1",
        "--no-usage-statistics"
      ]
    }
  }
}

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@0.0.83",
        "--cdp-endpoint",
        "http://127.0.0.1:9222"
      ]
    }
  }
}

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.10.1",
        "--browser-url=http://127.0.0.1:9222",
        "--no-usage-statistics"
      ]
    }
  }
}

LaunchRepo の構成

• LaunchRepo のプレイブックは、あなた自身の Chrome に接続した Chrome DevTools MCP 向けに書かれ、テストされています。ディレクトリへの登録には実際のログインが必要で、すべてのステップをあなたが見られるべきだからです。
• 自分で起動した Chrome では、このテストのどのツールでも navigator.webdriver は false のままで、引き継ぎも機能しました。あなたが同じタブでステップを終え、エージェントが結果を読み取ります。
• エージェントの接続時にディレクトリのフォームがすでに開いている場合は、何か入力する前にページを再読み込みさせてください。入力した内容が失われずに済みます。

• コーディングエージェントをChromeに接続する →
• Claude CodeでSaaSをディレクトリにローンチ →
• Chrome DevTools Protocol →
• MCPサーバー →

出典

公式ページとリポジトリを2026年9月30日に確認しました。引用は原文どおりに転記しています。テスト結果は私たち自身の測定です。

よくある質問

コーディングエージェントには Playwright MCP と Chrome DevTools MCP のどちらが良いですか？

どんな場面でも勝つ方はありません。私たちのテストでは、自分で Chrome を起動した場合、両方ともフォームのチェックをすべて通過しました。Playwright MCP は人がすでに開いていたページにも入力でき、ツール一覧も短めでした。Chrome DevTools MCP は、自分のアプリをデバッグするためのパフォーマンストレース、Lighthouse、より詳しいネットワークとコンソールのツールを備えています。

Chrome DevTools MCP は、ログイン済みの自分の Chrome を使えますか？

はい。--autoConnect を使うと、リモートデバッグを許可してダイアログで承認した後、起動中の Chrome 144 以降に接続します。または、リモートデバッグポートと別のプロファイルフォルダを指定して Chrome を起動し、--browser-url でそこを指定します。Chrome 136 以降、デフォルトプロファイルではこのポートは無視されます。

両方とも iframe を扱えますか？

はい。私たちの実行では、両方とも両モードで同一オリジンとクロスサイトの iframe に5回中5回到達し、その中で入力とクリックができました。

ファイルのアップロードが失敗したのはなぜですか？

両サーバーとも、デフォルトでは許可されたフォルダからしかファイルを読み込みません。Playwright MCP はワークスペースのルートまたは作業ディレクトリから、Chrome DevTools MCP はクライアントがルートを指定しない場合はシステムの一時フォルダからです。ファイルをそこへ移すか、ドキュメントに記載されたフラグで制限を広げてください。

これらのツールで CAPTCHA を解けますか？

どちらも CAPTCHA 機能をドキュメントに記載しておらず、私たちも実際の CAPTCHA はテストしていません。代わりに引き継ぎを設計してください。エージェントが止まり、あなたが同じ表示中のウィンドウでそのステップを解き、エージェントが続行します。私たちの接続テストでは、この引き継ぎは両サーバーで機能しました。

navigator.webdriver でエージェントだと見破られますか？

私たちのテストでは、true になったのは Chrome DevTools MCP が自分で Chrome を起動したときだけでした。Playwright MCP が起動した Chrome も、私たちが自分で起動した Chrome も false を返しました。サイトがこれに反応するかどうかはそのサイト次第で、実際のボット検出はテストしていません。