ハクソク

世界を動かす技術を、日本語で。

Chrome DevTools MCPは、Chromeの開発者ツールの一部です。

45日前原文(developer.chrome.com)

概要

Chrome DevTools MCPサーバーに新機能追加。
コーディングエージェントがアクティブなブラウザセッションへ直接接続可能に。
サインイン済みセッションやデバッグセッションの再利用が実現。
セキュリティ確保のため、接続時にユーザー許可が必須。
今後さらに多くのDevToolsパネルデータ公開予定。

Chrome DevTools MCPサーバーの新機能概要

  • Chrome DevTools MCPサーバーの強化
    • コーディングエージェントがアクティブなブラウザセッションへ直接接続可能
    • 既存セッションの再利用やアクティブなデバッグセッションへのアクセスが可能
  • サインイン済みセッション再利用
    • サインイン後のセッションを利用し、追加のサインイン不要
    • サインインが必要な問題解決をコーディングエージェントが担当可能
  • デバッグセッションへのアクセス
    • DevTools UIでアクティブなデバッグセッションへコーディングエージェントがアクセス
    • ElementsパネルやNetworkパネルで選択した要素やリクエストを調査依頼可能
  • 手動操作とAIアシストのシームレスな切り替え
    • 手動デバッグからAIへのタスク引き継ぎが容易
  • 既存の接続方法も継続利用可能
    • MCP専用プロファイルでの起動
    • リモートデバッグポート経由の接続
    • 一時プロファイルでの複数インスタンス運用

新しいリモートデバッグフローの仕組み

  • **Chrome M144（Beta）**に新機能追加
    • MCPサーバーがリモートデバッグ接続をリクエスト可能
    • 既存のリモートデバッグ機能を拡張
  • デフォルトではリモートデバッグ無効
    • chrome://inspect#remote-debugging で明示的に有効化が必要
  • --autoConnectオプションによる自動接続
    • MCPサーバーがアクティブなChromeインスタンスへ自動接続
    • デバッグセッション開始時、ユーザー許可ダイアログを表示しセキュリティ確保
    • デバッグ中は「Chromeは自動テストソフトウェアにより制御されています」バナー表示

新しいリモートデバッグ機能の利用手順

  • Step 1: Chromeでリモートデバッグを有効化
    • Chrome（バージョン144以上）で chrome://inspect/#remote-debugging にアクセス
    • ダイアログUIでデバッグ接続の許可/拒否を選択
  • Step 2: MCPサーバーの自動接続設定
    • --autoConnect コマンドラインオプションを指定
    • 設定例（gemini-cliの場合）: 
      {
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--channel=beta"
      ]
    }
  }
}
  • Step 3: 設定テスト
    • gemini-cliで「Check the performance of https://developers.chrome.com」と入力
    • MCPサーバーがChromeインスタンスへ接続し、ユーザー許可ダイアログを表示
    • 許可後、developers.chrome.comを開きパフォーマンストレースを取得

コーディングエージェントによるデバッグセッションの引き継ぎ

  • 自動化と手動操作の両立
    • DevToolsで問題発見後、調査や修正をAIコーディングエージェントへ引き継ぎ可能
    • ElementsパネルやNetworkパネルで選択した対象を直接調査依頼
  • 今後の展望
    • さらに多くのパネルデータをコーディングエージェントへ段階的に公開予定
    • 継続的な機能拡張を予告

詳細・最新情報はGitHubのREADMEを参照

Hackerたちの意見

誰かがこれのために素晴らしいエージェントスキルを作ってくれて、毎日使ってるんだけど、めっちゃクールだよ！ https://github.com/pasky/chrome-cdp-skill 例えば、コーデックスを使ってローカルの音楽ライブラリを管理してるんだけど、そのスキルを使ってブラウザでYT Musicのタブを開いて、各アルバムを検索して、yt-dlpに渡すためのURLを取得できたんだ。今のところChromeブラウザ専用だから、別のChromiumブラウザのバイナリを指すようにスクリプトを編集しなきゃいけないけど（例えば、俺はHeliumを使ってる）、それほど難しくないよ。
└
一方ではクールなデモだけど、他方では、言い表せないほど恐ろしいことだよ。ほんとに、プロンプトインジェクション一発で、誰かがあなたのすべてに無制限にアクセスできる状態になるんだから。
└
はっきり言っておくけど、これはdevtools MCPのスキルじゃなくて、独立したプロジェクトだよ。見た目は悪くないけど、ブラウザの自動化とエージェントは、たくさんの並行した取り組みがある非常に忙しい分野だからね。DevTools MCPとその新しいCLIは、Chrome DevToolsとPuppeteerのチームによって維持されていて、確かにもっと包括的な機能セットがあると思う。もっと信頼性があると思うけど…オープンソースの競争がイノベーションを生むのは素晴らしいことだよね。:) （以前はDevToolsチームで働いてたし、今も働いてるよ）
└
こんなテープでくっつけたスキルを本当に使ってる人いるの？もっと信頼できるplaywriter.devみたいなものを使えばいいのに。
これがすごくうまく動いてるのを見つけたよ（同じアイデア - 既存のセッションに接続する）： https://github.com/remorses/playwriter
GoogleはエージェントCLIコーディングでかなり遅れをとってるね。Gemini CLIはひどい。実際、チームの誰も使ってないのが明らかだよ。それに、MCPは明らかに死んでるし、重いエージェントコーディングをしてる私たちにはわかることだよ。CLIツールを使えば、もっと速くて柔軟なのに、なぜそのコンテキストウィンドウの一部を永久に犠牲にするのか。Playwrightを使ってヘッドレスChromiumやヘッド付きChromeで作業するのが真剣にやってる人たちのやり方で、すでに開発や検査ツールも揃ってるし、完璧に動くよ。これは始めたばかりの人や、これが正しい道だと勘違いしてる人にしか魅力がないね。答えはほとんどの場合、MCPじゃないよ。
└
ちょっと脱線するけど、Gemini CLIについては君の言う通りだね。ほんとに使えないし、ほとんど機能しない。あの時は「無料」ユーザーだったからかもしれないけど、体験がひどすぎて、今のコーディングプランに加入する気になれなかったよ。
└
MCPは全然死んでないよ。中央集権的なリモートMCPサーバーはめちゃくちゃ便利だし、特注のCLIもモデルを効果的に使うためにはガイダンスが必要だから、トークンの効率性はまだ問題だってことが分かるね。
└
MCPはコーディングだけに使われてるわけじゃないよ。
└
> それに、MCPは明らかに死んでる 一部の人はこれに反論するだろうね。最近Anthropicが改善したことがMCPのコンテキストロット問題を解決してくれることを期待してるみたい。Anthropicの変更は少し改善するけど、豚に口紅を塗るようなもんだよ。助けにはなるけど、大したことない。MCPが死にかけてる理由は、設定されたMCPサーバーが使われていない時でもコンテキストを膨らませるから。誰がそんなの欲しいと思う？エージェントスキルを使って、MCPにさよならしよう。MCPからは卒業する必要があるね。
└
これがただの個人的な印象かもしれないけど、ここ1、2週間でGoogle CLIの使い心地がかなり良かったんだ。前はずっと文句言ってたのにね。Codexと一緒に使ってるけど、どちらが優れてるって言えないな。今は物事がすぐ変わるから、判断が難しいよね。
└
> MCPは明らかに死んでるって、重いエージェントコーディングしてる人ならみんな知ってるよね。俺も重いエージェントコーディングやってるけど（基本的に全てのツールを使ってる）、これは全然真実じゃない。こういうこと言ってる人は、大企業の環境で働いたことがないんだろうな。認証、RBAC、レート制限、悪用検出、中央管理/アップデート/運用などが開発とデプロイのワークフローの大部分を占めるからね。こういう状況では、スキルやCLIツールだけじゃ、膨大な再調整と運用・セキュリティの複雑さが必要になる。MCPはここで本当に役立つし、中央のエンジニアリングチームや運用チームが、組織全体の姿勢やポリシー、インフラに沿った形でサービスを管理できるようにしてくれる。 > GoogleはエージェントCLIコーディングに関してはかなり遅れてる。Gemini CLIはひどい。これには完全に同意する。どれだけひどいかを表現するのは本当に難しいし、すごくがっかりしてる。
└
> なんでCLIツールを使えばもっと速くて柔軟なのに、そのコンテキストウィンドウの一部を永久に犠牲にするの？ モデルの事前学習に組み込まれていないCLIツールはどうなるの？ 誰かが「拡張性メカニズムXは死んだ！」って言うたびに、「ああ、その人は2010年代のRedditの統計的平均を拡張する必要がないんだな」と思う。
└
> 実際、あまりにもひどいので、彼らのチームの誰も使っていないのが明らかだ。私は広範囲に使ってるし、同僚の多くも使ってるよ。すごく価値を感じてる。Antigravityを好む人もいるけど、私はGemini CLIが好き。かなり長いトラジェクトリーが得られるし、同僚の中には一日中のトラジェクトリーを得てる人もいる。最初に使い始めたときから、ものすごく改善されたよ。
Playwrightを使って、すべてのリクエストとレスポンスをキャッチして、Claude CodeにYouTubeのようなウェブサイトにアクセスさせて、すべての要素や入力をクリックして操作しながら、各インタラクションに関連するリクエストとレスポンスを記録してるんだ。それから、基盤となるAPIを使って、どんなウェブサイトともやり取りできる詳細で強く型付けされたAPIを作成するよ。はい、これが多分みんなの利用規約を破ってるのはわかってるけど、同時に、目的を達成するためにギガバイトの広告や画像、マークアップを読み込んでるわけじゃないからね。興味がある人がいれば、今週中にそれを公開する時間を取れるよ。
└
はい、ぜひやってください！
└
仮に、yt-dlpの競争が続かずにYouTubeから自由に動画をダウンロードできるようになるのかな？
└
なんでこれにPlaywrightを使う必要があるの？Claudeはagent-browserさえあれば、そこから決定論的なコードを生成できる気がするんだけど。
└
ぜひやってみて、終わったら教えてね（笑）。エージェントスキルにした？
└
すごく興味ある！これのAPIにはお金を払ってもいいくらいだよ。Vibiumで似たようなことをやってるけど、もっとトークン効率のいいものが必要なんだ。
└
ウェブバリデーションが必要な人みんながやってることじゃないの？
└
出してくれ！
└
手動でクリックしながらXHRリクエストをキャプチャして、エクスポートからAPIをリバースエンジニアリングするのは似たようなことをやってたけど、そのレベルの自律性は試したことがないな。あなたのイテレーションサイクルはどれくらい？俺のは多分、数回のプロンプトで10-20分くらいだったと思う。
└
私もこれやってるよ。主な用途は、DOM内の任意のツリーでページのレイアウトやスタイリングを再現すること。コンポーネントのさまざまな状態をキャプチャしたりね。複雑なウェブアプリでページのレスポンシブな挙動を自動的に取得するのにも使ってる。Playwrightを使って幅を調整し、正確な変化をモニターするために全体のツリーを監視して、スナップショットをサポートするためのスタイルの完全なカスケードを含む構造化データを書き出すんだ。手動でこの種の検査を行うためのツールも買えるけど、それは人間向けに設計されてるから、クリック音がいっぱいで人間の速度の結果になるんだよね。--- このFPを見たときの私の最初の反応は、なんでまだMCPをリリースしてる人がいるの？ってこと。今のところ、そのハイプループを完全に避けて、スキルが存在する前からカスタムCLIを作ることに直行したよ。人々は、欲しいものへの直接アクセスの力や効率、AIを効果的に使うためのスキルの重要性にまだ気づいていないと思う。この特定のユースケースで何か見落としてるのかな？
DevTools MCPプロジェクトが最近スタンドアロンのCLIをリリースしたよ： https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/m... MCPのトークンコストの高さをよく知ってる私たちにとって、素晴らしいニュースだね。 ;) CLIはまだ発表されてないけど（ごめんね、みんな！）、最新のv0.20.0リリースに含まれてるよ。（注意：以前はDevToolsチームで働いてたし、今も働いてるよ）
└
今はTool Searchのおかげで、MCPはCCでタダだよね。
これ、Playwright CLIと比べてどうなの？ https://github.com/microsoft/playwright-cli
└
Googleが作ってて、Chromeが付いてくるんだよね。
└
自分はPlaywright-CLIと、PlaywrightをラップしたAgent-browserの方が、素のMCPを使うよりもトークン効率がいいと思ったよ。2025年12月の記事がHNのトップに上がってるのはちょっと変だね。
ここ数ヶ月、MCPツールをめっちゃ使ってるけど、ブラウザデバッグの統合は、実際に試すまではギミックに聞こえるんだよね。本当に大事なのは、フレークな非同期状態を信頼できるように処理できるか、ただDOMがどう見えるかを妄想してるだけかってことだね。
ChromeテストをするAIエージェントを書いたよ。そう、Chrome MCPはちゃんと動くよ。https://github.com/netdur/hugind/tree/main/agent/chrome_test...
このスレッドが明らかにしている本当の問題は、ブラウザの自動化（Playwright、CDP、MCPラッパー）を人間用に設計されたインターフェース、つまりDOMに無理やり貼り付けていることだね。ここで話されているアプローチは、みんな同じ戦いをしてる：ページの状態を表現するためのトークンが多すぎる、フレークなセレクター、幻覚的なDOM構造、大量のコンテキストコスト。実際に必要なのは、ウェブサイトが人間用のインターフェースと並行して機械可読なインタラクションレイヤーを公開するための標準だよ。ロボット用のrobots.txtみたいなもので、利用可能なアクション、パラメータ、認証要件、レスポンススキーマを宣言するもの。DOMをスクレイピングして、AIがどのボタンをクリックするかを推測するのではなくてね。ウェブはすでにこの進化を一度経験してる：HTMLのスクリーンスクレイピングから構造化APIへ移行した。今は、エージェントが人間用インターフェースしかないサイトとやり取りする必要があるから、再びスクレイピングに戻ってる。軽量な標準、例えばagents.jsonとか呼ぶもので、サイトが「ここにできるアクションがあるよ、ここがエンドポイント、これが認証フロー」って宣言すれば、スレッドで話されているトークンの無駄やセキュリティの懸念、脆弱性の90%を排除できる。そんなものができるまでは、30年前に設計された機械消費用ではないドキュメントフォーマットの上に、ますます巧妙なハックを積み重ねていくことになるよ。
└
> 人間用のインターフェースと並行して機械可読なインタラクションレイヤーを公開する それはARIAと呼ばれていて、ずっと前から存在してるよ。
└
これはただのよく文書化されたAPIなの？
└
> 人間のために設計されたインターフェース、つまりDOM。引用が必要だね。 > ウェブはすでにこの進化を一度経験してる。HTMLのスクリーンスクレイピングから構造化されたAPIへと移行した。でも今は、エージェントが人間のインターフェースしか持たないサイトとやり取りする必要があるから、またスクレイピングに戻ってる。私にとって、「人間のインターフェースしか持たない」サイトは、ほぼ間違いなく意図的にそうなっていて、人間の保持やエンゲージメントを最大化しようとしてると思う。だから、使うためには厳しいボット対策、例えばプルーフ・オブ・ワークが必要になることが多いんじゃないかな。
私のアプローチは、薄いCLIラッパーにしてるよ。 https://news.ycombinator.com/item?id=47207790