Playwright CLI v0.1.8 で普段使いの Chrome にそのまま attach する - ログイン済みブラウザを AI エージェントから操作する

E2E テストや AI エージェントによるブラウザ操作で、いつも詰まるのが「ログイン状態をどう持っていくか」でした。SSO や 2FA、社内 SaaS のセッション、1Password 拡張機能 ── これらを毎回サンドボックスの新規 Chrome に再現するのは現実的ではありません。

2026年4月14日にリリースされた Playwright CLI v0.1.8 で、まさにこの問題に直接答える機能 attach --cdp=chrome が追加されました。普段使っているローカルの Chrome / Edge に Playwright が直接 attach できるようになり、ログイン済みのタブ・拡張機能を持った状態のままエージェントや CLI から操作できます。

本記事では、Playwright CLI v0.1.8 で追加された attach 機能の仕組み・セットアップ手順・AI エージェントとの組み合わせ方を整理します。

v0.1.8 で何が変わったか

リリースノート（Release v0.1.8 · microsoft/playwright-cli）から重要な変更を抜粋すると次の3点。

中でも最大の目玉は 「普段使いの Chrome にそのまま attach できる」機能です。

何が革新的なのか

これまで connectOverCDP 自体は存在していましたが、

• 接続先の HTTP / WebSocket エンドポイントを 呼び出し側で用意する必要があった
• Chrome を --remote-debugging-port=9222 付きで起動する必要があり、普段の Chrome とは別プロセスになりがち
• そもそも Chrome 136 以降、セキュリティ強化で --remote-debugging-port が 既定ユーザーデータディレクトリでは無視されるようになった

という制約があり、「ログイン済みの普段使い Chrome」をそのまま使うのは現実的ではありませんでした。

v0.1.8 が解決したのは、

• チャンネル名（chrome、msedge など）だけで接続できる — エンドポイント URL を意識不要
• Chrome 144 以降の chrome://inspect/#remote-debugging フローに乗っているので、ユーザー操作で明示的に有効化する安全な方式
• 起動オプションではなく セッション内で動的に有効化できるので、普段使い Chrome をそのまま使える

の3点。「セキュリティを犠牲にせずに普段使いブラウザに繋ぐ」ところが大きな進歩です。

仕組み: connectOverCDP のチャンネル名解決

Playwright 本体側の PR microsoft/playwright#40177 で、connectOverCDP がチャンネル名を直接受け取れるよう拡張されました。

接続の流れはこうです。

1. ユーザーが playwright-cli attach --cdp=chrome を実行
2. Playwright がチャンネル名 chrome から、ローカルの Chrome ユーザーデータディレクトリを特定
3. その中の DevToolsActivePort ファイルを読み取って WebSocket エンドポイントを解決
4. Chrome 側で許可ダイアログが出る → ユーザーが承認 → 接続確立

エンドポイント URL を組み立てる手間や、ポート番号の衝突を気にする必要がなくなりました。

対応チャンネルは以下のとおり（Linux / macOS / Windows すべて）。

• Chrome: chrome, chrome-beta, chrome-dev, chrome-canary
• Edge: msedge, msedge-beta, msedge-dev, msedge-canary

従来どおりエンドポイント URL 指定もできます（クラウドブラウザサービスなど向け）。

playwright-cli attach --cdp=http://localhost:9222

セットアップ手順

0. 前提環境

1. Playwright CLI v0.1.8 をインストール

npm install -g @playwright/cli@0.1.8

@latest 指定でも構いません。

playwright-cli --version
# 0.1.8

2. Chrome 側でリモートデバッグを有効化

普段使っている Chrome で新しいタブを開き、アドレスバーに以下を入力。

chrome://inspect/#remote-debugging

開いた画面で 「Allow remote debugging for this browser instance」のトグルを ON にします。これで現在の Chrome インスタンスがリモートデバッグを受け付ける状態になります。

Chrome のバージョンが 144 未満だとこの画面自体が出ません。chrome://settings/help で確認してアップデートしてください。

3. attach する

別ターミナルから次のコマンドを実行。

playwright-cli attach --cdp=chrome

初回は Chrome 側で 接続許可ダイアログが出るので、許可します。接続中は Chrome 上部に「Chrome is being controlled by automated test software」のバナーが常時表示されます。

接続成功時の標準出力例。

### Browser `default` opened with pid 13889.
### Open tabs
- 0: (current) [My Dashboard](https://app.example.com/dashboard)
- 1: [Inspect with Chrome Developer Tools](chrome://inspect/#remote-debugging)
### Page
- Page URL: https://app.example.com/dashboard
- Page Title: My Dashboard
- Console: 2 errors, 1 warnings
### Snapshot
- [Snapshot](.playwright-cli/page-2026-05-19T10-30-00-000Z.yml)

ログイン済みのタブがそのまま見えており、サンドボックスではなく実際の Chrome セッションに繋がっていることが確認できます。

attach 後にできること

セッション一覧

playwright-cli list

### Browsers
- default:
  - status: open
  - browser-type: chrome (attached)

(attached) の表示で、新規起動ではなく attach 状態であることが識別できます。

DOM スナップショット

playwright-cli snapshot --depth=2

ログイン済みページの DOM に加えて、1Password などの拡張機能が注入した要素も拾えます。

### Snapshot
- generic [ref=e1]:
  - generic [ref=e2]:
    - generic [ref=e3]
    - region "Notifications alt+T"
  - status [ref=e1025]: 1Password menu is available. Press down arrow to select.

コンソールログ

playwright-cli console

実ページの 404 や警告を JSON 風に取得できます。バグ報告の現場で「コンソール何が出てる？」を一発で取れるのは便利。

デタッチ

playwright-cli close
# Browser 'default' closed
 
playwright-cli list
# (no browsers)

CLI 側のセッションだけが切れ、Chrome 本体は起動したまま残ります。普段使い Chrome を閉じる必要がない、というのが体験的に大きい。

セッション名指定

複数の Chrome / Edge を切り替えながら使うなら -s でセッション名を付けます。

playwright-cli attach --cdp=chrome -s=work
playwright-cli attach --cdp=msedge -s=personal
 
playwright-cli -s=work snapshot
playwright-cli -s=personal console

--cdp=chrome のようなチャンネル名指定では、-s を省略すると チャンネル名がセッション名になります（PR #40408）。

AI エージェントから使う: Skills のインストール

実運用としては、Claude Code / GitHub Copilot / Cursor などの コーディングエージェントから playwright-cli を呼ばせる形が主になります。Playwright CLI には エージェント向けの Skill ファイルが同梱されていて、これを入れておくとエージェントが CLI の使い方を把握したうえで必要なコマンドだけ呼び出してくれます。

Skill のインストール

playwright-cli install --skills

playwright-cli install --skills=agents

Skill 方式の利点

公式 README の Playwright CLI vs Playwright MCP によると、Skill 方式は

• 大きなツールスキーマやアクセシビリティツリーを モデルコンテキストに読み込ませずに済む
• 必要な時だけ CLI を呼び出すので トークン効率が良い
• コーディングエージェントとの相性が良い

という特長があります。MCP server を立てる方式と比べて、起動コストや常時接続のオーバーヘッドがありません。

Skill の更新

CLI 本体をアップデートしたあと、同じコマンドで Skill ファイルも最新化されます。

npm install -g @playwright/cli@latest
playwright-cli install --skills

v0.1.8 以降の Skill ファイル（.claude/skills/playwright-cli/SKILL.md）には、attach --cdp=chrome / attach --cdp=msedge / attach --cdp=http://localhost:9222 の使い方が記述されています。本体アップデート + install --skills だけでエージェント側も追従できます。

Skill を入れずに使う

playwright-cli --help を読めるエージェントなら、Skill 無しでもプロンプトに以下のように添えるだけで動くケースがあります。

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

試用フェーズではこれで十分。常用フェーズに入ったら Skill を入れるのが王道です。

Chrome DevTools MCP autoConnect との使い分け

同じく chrome://inspect/#remote-debugging 経由で既存セッションを再利用する仕組みとして、Chrome DevTools MCP の --autoConnect があります。両者は重なる部分も大きいですが、得意分野が違うので使い分けがポイント。

判断基準としては、

• Edge も含めて自動化したい / そのまま Playwright のテストコードに育てたい → Playwright CLI attach
• いま見ている DevTools の状態（選択要素、Network タブの履歴）を AI に引き継ぎたい → Chrome DevTools MCP autoConnect

両者を併用しても構いません。デバッグ深掘りは Chrome DevTools MCP、自動化のスケジューラは Playwright CLI、という分担も可能。

セキュリティ面の注意

Chrome 136 以降、--remote-debugging-port / --remote-debugging-pipe は既定のユーザーデータディレクトリでは無視される仕様になりました（公式アナウンス）。背景は、リモートデバッグポート経由で Cookie や認証情報を抜き取る攻撃が広がってきたためです。

v0.1.8 の attach --cdp=chrome は、この変更を踏まえた新しい安全フローに乗っています。

• 起動オプションではなく ユーザーが chrome://inspect/#remote-debugging で明示的に有効化
• 接続要求のたびに Chrome が 許可ダイアログを出す
• 接続中は 「Chrome is being controlled by automated test software」のバナーが常時表示
• セッションを終えたい時は同じ画面でトグルを OFF にできる

それでも普段使い Chrome を AI エージェントに繋ぐ以上、

• 機密性の高いタブ（ネットバンキング、社内管理画面）は閉じてから接続する
• 信頼できる Skill / プロンプトだけを動かす
• 接続中は Chrome のバナーを目視確認する
• 用が済んだら playwright-cli close してトグルも OFF

を習慣化しておくのが安全です。

実践: 使いどころ

普段使い Chrome に attach できる前提があると、以下のような用途が一気に現実的になります。

1. SSO / 2FA 突破済みの社内 SaaS 検証

「Notion の特定ページが壊れていないか」「Slack のメッセージ送信フローが想定どおりか」── これまでは 毎回ログインから自動化する必要があり、TOTP の自動入力やワンタイムコードの受け取りが必要でした。今後は 普段ログインしている Chrome をそのまま使えるので、ログイン部分は完全にスキップできます。

2. 拡張機能込みでのスクリーンショット取得

1Password、Grammarly、SimilarWeb、検証用の React DevTools など、拡張機能がインストールされた状態で UI を確認したいケースに対応できます。

3. 「いま見ているページ」のバグ報告自動化

「Cursor で記事を書いている最中に Notion のページが崩れた → そのページのスナップショットとコンソールログを取って GitHub に Issue を立てる」のような 状況依存の自動化を、ページを開き直さずにそのまま実行できます。

4. AI エージェントによる UI 操作の試行

ChatGPT や Claude のチャット欄で「いま開いている画面の文字起こしして」と頼んだとき、エージェントが裏で playwright-cli snapshot を呼んで 現在のタブの DOM をそのまま取得できる、という体験が成立します。

5. E2E テストのプロトタイピング

「この操作、自動化したいけどログインが面倒で着手していなかった」シナリオを、まず attach で手早く検証してから、固まったところで Playwright スクリプト化、という 2段階アプローチが取れます。

まとめ

• Playwright CLI v0.1.8（2026年4月14日リリース）で、playwright-cli attach --cdp=chrome により普段使いの Chrome / Edge にそのまま attachできるようになった
• 仕組みは Chrome 144 以降の chrome://inspect/#remote-debugging フローに乗っており、起動オプションではなくユーザー操作で動的に有効化する 安全寄りな方式
• 対応チャンネルは Chrome / Chrome Beta / Chrome Dev / Chrome Canary / Edge 系列の各チャンネル、Linux / macOS / Windows
• セッション内では list / snapshot / console / close などの CLI コマンドがそのまま使え、セッション名（-s）でマルチブラウザ運用も可能
• AI エージェントと組み合わせるなら playwright-cli install --skills で Skill ファイルを入れておくのが王道。トークン効率の良い MCP 代替として機能する
• 似た仕組みの Chrome DevTools MCP autoConnect とは「自動化寄り vs デバッグ文脈引き継ぎ」で使い分け
• ログイン済み / 拡張機能つきの 普段使いブラウザがそのまま検証対象になることで、SSO・2FA・社内 SaaS のテスト自動化のハードルが大きく下がる

「ログインを再現するのが面倒で AI エージェントにブラウザ操作を任せられなかった」案件は、これを機に一度棚卸ししてみる価値があります。

参考リンク

• Release v0.1.8 · microsoft/playwright-cli
• microsoft/playwright-cli README
• Attach コマンド公式ドキュメント
• microsoft/playwright#40177 feat(chromium): resolve channel names in connectOverCDP
• microsoft/playwright#40408 feat(cli): channel-named attach sessions and detach command
• microsoft/playwright-cli#358 feat: add remote debugging mode to playwright
• Let your Coding Agent debug your browser session with Chrome DevTools MCP
• Changes to remote debugging switches to improve security（Chrome 136 変更）