「結局AIは何を見てテストを直したんですか」と聞かれた
以前Playwrightのself-healing機能を紹介した記事を書いたところ、読んでくださった方から「AIエージェントに落ちたテストを直させるのはわかったんですが、エージェントって結局そのとき何を見てるんですか」と聞かれました。正直、良い質問だと思いました。私自身も「ロケータを直してくれた」という結果は見ていても、エージェントが直す瞬間にブラウザの中で何を見ていたのかまでは、いつも把握できていたわけではなかったからです。
調べてみると、Playwright 1.59でこの不透明さに直接効く仕組みが入っていました。browser.bind()という新しいAPIと、npx playwright test --debug=cli、playwright-cli attachの組み合わせです。今回はこれを実際に手を動かして追いかけてみます。
これまでは「別々のブラウザ」を見ていた
これまでのAIエージェント活用では、テスト実行用のブラウザ、MCPサーバーが操作するブラウザ、CLIツールが立ち上げるブラウザは、それぞれ別プロセスとして起動していました。エージェントに「このテストを直して」と頼むと、エージェントは自分専用の新しいブラウザを立ち上げて調査を始めます。私が落ちたテストを見ていた画面と、エージェントが調査に使っている画面は、別物なわけです。
これだと、エージェントが「セレクタが変わっていたので直しました」と報告してきても、私は結果しか確認できません。途中でどのDOMを見て、どのタイミングでどう判断したのかは、エージェントの説明を信じるしかありませんでした。1年目でAIにテストを直させ始めると、この「何を見て直したのかわからない」という不安は誰もが一度は感じると思います。
browser.bindで1つのブラウザを共有する
Playwright 1.59のリリースノートを確認したところ、次のように書かれていました。
New browser.bind() API makes a launched browser available for
playwright-cli, @playwright/mcp, and other clients to connect to.起動したブラウザに名前を付けて共有できるようにする、というAPIです。使い方はシンプルで、ブラウザを起動したあとに次のように呼び出します。
const browser = await chromium.launch({ headless: false });
await browser.bind('my-session');第2引数のオプションでhostとportを指定すると、名前付きパイプの代わりにWebSocketでバインドできます。workspaceDirでこのブラウザセッションに紐づく作業ディレクトリも指定できるようです（複数プロジェクトを並行で触るときに使うものだと思うのですが、具体的な使い分けの例まではドキュメントに載っておらず、正直まだ腹落ちしていません）。ここまでは公式のAPIリファレンス（class-browser）で確認できました。
ちなみにこの機能、私が事前に集めていた情報では「1.59で入った」という記事と「1.60」と書いている記事が混在していて、正直どちらが正しいのか自信がありませんでした。今回playwright.dev/docs/release-notesとGitHubのmicrosoft/playwrightのリリースページを直接確認したところ、browser.bind()も--debug=cliもどちらもv1.59のリリースノートに載っていました。バージョン表記に揺れがあるのは事実なので、手元の環境で試す際はご自身のPlaywrightのバージョンも確認してから読み進めてください。
落ちたテストをその場で止めて、エージェントを呼び込む
ここからが今回の本題です。テストを普通に実行する代わりに、--debug=cliを付けて実行します。
npx playwright test --debug=cliこれを実行すると、テストは失敗する（あるいはブレークポイントに達する）タイミングで一時停止し、セッション名を出力します。公式ドキュメントの例ではplaywright-test-1のような名前が表示されるとのことでした。この名前をエージェントに渡せば、エージェント側は次のコマンドで同じブラウザに入ってきます。
playwright-cli attach playwright-test-1ここが従来との決定的な違いです。エージェントは新しいブラウザを立ち上げません。私が止めたその場、まさに落ちている状態のブラウザにそのまま入ってきます。
attachしたあとは、エージェントは次のようなコマンドでその場を調査できます。
playwright-cli snapshot # 現在のDOM状態を確認
playwright-cli screenshot # スクリーンショット
playwright-cli eval "..." # ページ内でJSを評価
playwright-cli step-over # 次のアクションまで進める
playwright-cli resume # 実行を再開
つまりエージェントは、私が見ていたのと同じ画面のスナップショットを取り、同じDOMに対してセレクタを試しながら直していくことになります。「何を見て直したのか」の答えは、このsnapshotやevalの実行ログそのものです。ここは以前trace CLIで実行の証跡を残す記事を書いたときと近い感覚で、証跡が残るからこそ信頼できる、という話に近いと思います。
ブラウザをheadedで起動しておけば、横で見ていられる
もう1つ見逃せないのが、ヘッドあり（headless: false）でブラウザを起動しておけば、エージェントが操作している様子を横の画面でそのまま見ていられることです。エージェントがsnapshotを取っている間も、evalでDOMを触っている間も、同じウィンドウなので画面が動きます。これまでのように「エージェントの報告を待つだけ」ではなく、直している最中の様子を眺めていられるのは、安心感がまるで違います。
正直に書いておくと、今回試したのは公式ドキュメントの手順を1つずつなぞりながら、コマンドと動作を確認したところまでです。実際に自分の壊れたテストスイートに丸ごと組み込んで、何十本も直させるところまではまだやっていません（近いうちにやってみるつもりです）。なのでここに書いた内容は「仕組みとしてこう動く」という確認であって、「大規模に運用した実感」ではない、という点は正直に断っておきます。
接続先はplaywright-cliだけじゃない
もう1つ面白いのは、browser.bind()でバインドしたセッションにはplaywright-cliだけでなく@playwright/mcpからも接続できることです。つまりMCP経由でエージェントに操作させている場合も、同じ仕組みでブラウザを共有できます。公式の想定ユースケースとして、プランナー役のエージェントがログインまで済ませてセッションをbindし、実作業を担当する別のエージェントがログインし直さずに引き継ぐ、という使い方も紹介されていました。認証を何度もやり直さずに複数のエージェントで1つのブラウザを回せるのは、業務効率化としても効きそうです。
バインドされているセッションの一覧はplaywright-cli showで確認できます。エンジン名や開いているコンテキスト数、ページ数、ステータスまで一覧できるとのことなので、複数のエージェントを並行で走らせているときの状況把握にも使えそうです。
これで「AIが勝手に直した」不安は減るか
Healer回を書いたときに感じていた不安の正体は、「直った」という結果だけが返ってきて、過程がブラックボックスだったことだと思います。browser.bind()と--debug=cliの組み合わせは、その過程を人間とエージェントで同じブラウザ上に並べて見られるようにする仕組みでした。ログを後から読むのではなく、止まっているその場に一緒に立ち会える、という感覚に近いです。
ただし万能ではありません。エージェントがsnapshotやevalで何を見て、どう判断したかまでは、結局コマンドの実行ログを追う必要があります。「横で見ていれば安心して丸投げできる」というよりは、「丸投げしたときに、何かあれば検証できる手段が増えた」くらいの捉え方が正確だと思います。AIにブラウザ操作を任せる際の注意点はプロンプトインジェクションの記事でも書いたので、あわせて読んでいただくと安心材料になるかもしれません。
1.59はまだ出たばかりの機能なので、コマンド体系やオプションは今後も変わっていく可能性があります。実際に導入する際は、この記事の内容を鵜呑みにせず、お手元のバージョンの公式ドキュメントを確認することをおすすめします。試してみた方がいたら、コメントで感想を教えてもらえると嬉しいです。
コメント