こんにちは！
KDDIアイレットの取り組みとして6月22日〜7月3日の期間で開催中の「Google Cloud Next '26 / Google I/O やってみた系ブログリレー」、本日は9日目の投稿です。
今回は「Google I/O 2026 で発表された Chrome DevTools for Agents」を対象に、簡単な比較を行ってみました。
前回の記事はこちらです。
動機
Google I/O 2026 で Chrome DevTools for Agents が発表されました。AI エージェントがアクティブな Chrome セッションに接続し、コンソールログ・ネットワークトラフィック・アクセシビリティツリーを直接参照してデバッグや Lighthouse 監査を自律的に行えるというものです。
LY Corporation がパフォーマンス監査の手動分析を 96〜98% 削減したという事例も紹介されています。
少し前に、Chrome Devtool MCPのリモートデバッグ機能が使用可能となっていますが、そちらや、playwright-cliと比較する場合にトークン消費がどう変わるのか、興味があったので簡単に調べてみました。
Chrome DevTools for Agents とは
Chrome DevTools for Agents は、MCP（Model Context Protocol）経由で AI エージェントが Chrome の内部データに直接アクセスできる仕組みです。
エージェントが利用できる主な機能は以下の3つです。
- ライブデバッグ — アクティブな Chrome セッションに接続し、コンソールログやネットワークリクエストを取得
- UX エミュレーション — レスポンシブデザイン・地理情報・ユーザーフローをエージェントが制御
- Lighthouse 監査 — アクセシビリティ・SEO・パフォーマンスの自動監査
前提
対象ページ
自身の Qiita 記事を使用しました。
プロンプト
3モードすべてに対して見出し構造を取得するタスクを指示してみました。
この記事の構成（セクション見出しと各セクションの概要）をまとめて
URL: https://qiita.com/y-mae/items/a869b52f2fa401133087
計測方法
モードごとにセッションを分離し、各セッションで1コマンドだけ実行した後に /cost（Settings > Usage）でトークン数を記録しました。
今回の比較構成
以下3ツールを比較対象としました。
| ツール | 位置づけ |
|---|---|
| chrome-devtools-cli（plugin） | Chrome DevTools for Agents（プラグイン接続） |
| chrome-devtools（デバッグモード） | Chrome DevTools for Agents（MCP server + --autoConnect） |
| playwright-cli | 比較対象（ブラウザ自動化ツール） |
①chrome-devtools-cli（plugin）の場合
Claude Code にプラグインとして追加します。
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins
インストール後は Chrome を起動して対象ページを開いた状態にするだけです。エージェントが自動的にアクティブなタブに接続します。
②chrome-devtools（デバッグモード）の場合
--autoConnect フラグを使った接続方式です（Chrome 144 以降が必要）。
1. Chrome でリモートデバッグを有効化
Chrome のアドレスバーに chrome://inspect/#remote-debugging と入力し、リモートデバッグを有効にします。
2. MCP 設定に --autoConnect を追加
Claude の MCP 設定ファイルに chrome-devtools サーバーを追加し、--autoConnect オプションを指定します。
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
}
}
}
3. 接続許可ダイアログを承認
Claude Code からリクエストを送ると、Chrome 側で DevTools 接続の許可を求めるダイアログが表示されます。承認することで接続が確立します。
接続後は evaluate_script などのツールを呼び出せます。
エージェントはブラウザの認証済みセッション・Cookie・JavaScript API にアクセスできます。信頼できるエージェントのみで使用してください。
③playwright-cli
記載がありますが、以下コマンドでインストール可能です
npm install -g @playwright/cli@latest
結果
①chrome-devtools-cli（plugin）
プロンプトを送ると、AI は navigate_page でページに遷移し、evaluate_script で記事本文を取得しました。
取得した記事本文から見出し構造を解釈し、以下のような出力が得られました。
コスト（claude-sonnet-4-6）
| 項目 | 値 |
|---|---|
| 使用ツール |
navigate_page / evaluate_script
|
| Input tokens | 5 |
| Output tokens | 1,600 |
| Cache read | 86,700 |
| Cache write | 19,700 |
| 合計コスト | $0.1688 |
②chrome-devtools（デバッグモード）
「Chrome のデバッグモードを使用する」形で、同じ指示をしてみます。
Chrome 側で、 DevTools 接続の許可を求めるダイアログが表示されます。
最初に list_pages でブラウザで開いているページ一覧を取得し、select_page で対象ページを指定します。
その後、AI 自身が JavaScript を書いて evaluate_script で実行します。まず見出し要素を取得する関数を実行し…
記事本文のコンテナを特定して見出しと本文を対応づける関数を実行し…
さらに本文テキストを取得する関数を実行しました。計3回の evaluate_script 呼び出しで目的のデータを取得しています。AI が自分で DOM セレクタを指定した JS を書いて実行するため、取得されるのは記事本文のコンテナに絞り込んだデータです。
() => {
const selectors = ['.it-MdContent', '.markdown-body', '[class*="ArticleBody"]', 'article'];
let container = null;
for (const s of selectors) {
container = document.querySelector(s);
if (container) break;
}
return container
? { tag: container.tagName, className: container.className, innerText: container.innerText.slice(0, 2000) }
: { found: false };
}
コスト（/cost スクリーンショット）
| 項目 | 値 |
|---|---|
| 使用ツール |
list_pages / select_page / evaluate_script（3回） |
| Input tokens | 23（Sonnet）+ 590（Haiku） |
| Output tokens | 2,700（Sonnet）+ 24（Haiku） |
| Cache read | 359,100（Sonnet） |
| Cache write | 21,900（Sonnet） |
| 合計コスト | $0.2809 |
③playwright-cli
playwright-cli goto でページに遷移してコンテンツを取得しました。
Playwright Remote Control でページが開いた状態を確認できます。（playwright-cli showコマンドをターミナルで叩くと表示される）
取得結果
Playwright は独自の参照ID（ref=）付きスナップショット形式で返します。①②と異なりページ全体が対象で、ナビ・サイドバーも取得範囲に含まれます。
- text: Qiita Tech Festa ← ナビ
- text: 公式コラム
- text: Qiita Careers
- heading "Qiitaにログインして..." [level=2] [ref=e403] ← サイドバー
...（中略）...
- heading "Claude Code のスキルで..." [level=1] [ref=e103] ← 記事本文
- heading "この記事について" [level=2] [ref=e121]
- heading "作成したスキル" [level=2] [ref=e130]
...（中略）...
- heading "まとめ" [level=2] [ref=e262]
- heading "参考リンク" [level=2] [ref=e264]
コスト（/cost スクリーンショット）：
| 項目 | 値 |
|---|---|
| 使用ツール |
goto など |
| Input tokens | 360（Sonnet）+ 568（Haiku） |
| Output tokens | 3,800（Sonnet）+ 23（Haiku） |
| Cache read | 413,600（Sonnet） |
| Cache write | 29,800（Sonnet） |
| 合計コスト | $0.3608 |
比較まとめ
| chrome-devtools-cli | chrome-devtools（デバッグ） | playwright-cli | |
|---|---|---|---|
| 主なツール |
navigate_page / evaluate_script
|
evaluate_script（3回） |
goto など |
| Sonnet input | 5 | 23 | 360 |
| Sonnet output | 1,600 | 2,700 | 3,800 |
| Cache read | 86,700 | 359,100 | 413,600 |
| Cache write | 19,700 | 21,900 | 29,800 |
| コスト | $0.1688 | $0.2809 | $0.3608 |
| playwright-cli 比 | −53% | −22% | 基準 |
| 実行時間（実測値） | 34秒 | 1分54秒 | 47秒 |
※ 数値は参考値としてご覧ください。
plugin モードと debug モードはどちらも evaluate_script で DOM を取得する点は同じですが、debug モードは事前に list_pages → select_page でセッションを特定するステップが入るため、ツール呼び出しが計3回になります。plugin モードはその手順が不要なため呼び出し回数が少なく、実行時間（34秒 vs 1分54秒）とコストの両面で有利になったと考えられます。
playwright-cli の Cache write が最も多いのは、goto + スナップショット取得でページ全体を ref= 形式で展開するため語数が増えやすいためと思われます。
まとめ
Chrome DevTools for Agents は今回の構造取得タスクにおいては、playwright-cli よりもトークン消費を抑えられることがわかりました。
必要な情報をある程度絞って取得できるため、より効率的なトークン消費が期待できます。
今回は単一ページの構造取得という限定的なタスクでの比較にとどめましたが、既存のアプリをベースとしたテストケース作成など、より複雑なタスクにおけるトークン消費の差についても比較してみたいと思います。