「PlaywrightにAIエージェントが来た」と聞いて、ブラウザ作業を丸投げできると思った人は多いはずです。結論から言うと、v1.56で追加されたのはテスト作成を支援する3つのエージェントであり、汎用のWebワーカーではありません。
この記事では、Playwright v1.56のAIエージェントが何をして、何をしないのかを整理します。テスト自動化とAIエージェントの違いがわかれば、導入判断と運用方針を誤りにくくなります。
この記事でわかること
- Playwright v1.56で追加された3つのAIエージェントの役割
npx playwright init-agentsによるセットアップ手順- テストフレームワークとAIエージェントの設計思想の違い
- 実務で押さえるべき注意点とPlaywright MCPとの関係
v1.56で追加されたPlaywright Agents
Microsoftは2025年10月6日、Playwright v1.56.0をリリースし、Playwright Agentsを標準機能として公開しました（リリースノート）。
ここでいうエージェントは、LLM（大規模言語モデル）にテスト作成の手順を案内するための定義ファイルです。ブラウザを自律的に操作して業務を完遂する汎用ワーカーとは目的が異なります。公式ドキュメントでも、Planner・Generator・Healerの3つを「Playwright Test Agents」と呼び分けています。
同時に、Chromium 141、Firefox 142、WebKit 26への対応や、page.consoleMessages()・page.requests() といったデバッグ用APIも追加されています。AI機能だけでなく、テスト基盤全体のアップデートである点も押さえておきましょう。
3つのエージェントが担う役割
Playwright Agentsは、テスト計画の作成からコード生成、失敗時の修復までを分担します。
Planner（プランナー） はアプリを探索し、Markdown形式のテスト計画を出力します。ページをDOMのCSSセレクタではなく、アクセシビリティツリー（要素の役割と名前の一覧）で把握するため、Role: button, Name: Checkout のように人間の認識に近い形で画面を読み取ります。
Generator（ジェネレーター） は計画書をもとに、実行可能なPlaywright Testファイルを生成します。生成中にセレクタやアサーションを実際の画面で検証するため、机上のコード生成より精度が高い設計です。
Healer（ヒーラー） は失敗したテストをデバッグモードで再実行し、コンソールログ・ネットワークリクエスト・ページスナップショットを確認しながら修復を試みます。ロケータ更新や待機条件の調整、データ修正などのパッチを提案し、テストが通るかガードレールで停止するまで繰り返します。機能自体が壊れていると判断した場合は、テストをスキップにします。
いずれも最終成果物はPlaywrightのテストコードです。AIが作業を代行しても、コードのレビュー・コミット・CI実行・保守は開発チームの責任のままです。
セットアップと基本的な使い方
エージェント定義は、次のコマンドでプロジェクトに追加します。
npx playwright init-agents --loop=vscode
npx playwright init-agents --loop=claude
npx playwright init-agents --loop=opencode
--loop には、利用するエージェントループ（VS Code、Claude Code、opencode）を指定します。Playwrightをアップデートした際は、新しいツールや指示を取り込むため、定義ファイルの再生成が推奨されています。
VS Codeでエージェント体験を使う場合、v1.105以降が必要です（2025年10月9日リリース）。Insidersチャンネルで先行提供されていた機能のため、環境のバージョン確認は導入前の必須チェックです。
典型的な流れは次のとおりです。
seed.spec.tsなどのシードテストで環境を初期化する- Plannerに「ゲストチェックアウトのテスト計画を作って」と依頼し、
specs/にMarkdown計画を出力させる - Generatorに計画を渡し、
tests/にPlaywright Testを生成させる - 失敗が出たらHealerに修復を依頼する
生成物は specs/（人間が読める計画書）と tests/（実行用コード）に分かれ、監査しやすい構成になっています。
テストは「検証」、エージェントは「実行」
PlaywrightはもともとE2E（エンドツーエンド）テスト向けのフレームワークです。Chromium・Firefox・WebKitを単一APIで操作し、要素の表示・有効化・安定性を待ってからクリックする仕組みを持ちます。テストコードはフロー・対象要素・期待結果をすべて事前に定義する決定論的な設計です。
test('checkout flow works', async ({ page }) => {
await page.goto('https://example.com/login');
await page.getByLabel('Email').fill('demo@example.com');
await page.getByRole('button', { name: /sign in/i }).click();
await expect(page.getByText(/order summary/i)).toBeVisible();
});
一方、汎用AIエージェントが目指すのは「ログインボタンを押して」のような自然言語の意図を、実行時に解釈して動くことです。HTMLのクラス名が変わっても、画面上でログインボタンと判断できれば動き続ける——この解釈型のモデルが、スクリプト生成型とは根本的に異なります。
Playwright Agentsは前者のテストワークフローを高速化する道具です。Thunders.aiのCEO Karim Jouini氏が語った事例では、100万行規模のPlaywrightコードを抱えた企業がリブランディング後に6か月かけてテスト修復に追われた、という話が紹介されています（参考）。AIでテストを量産しても、生成されたスクリプトの保守負債は残ります。ボトルネックが「書く時間」から「持つ時間」へ移る点を理解しておく必要があります。
使い分けの基準はシンプルです。テストは検証（assert）、エージェントは実行（act）。デプロイ後にチェックアウトが壊れていないか確認したいならPlaywrightが向いています。複数サイトを横断してレポートを組み立てるような曖昧な業務を任せたいなら、Playwright単体ではなくエージェント基盤が必要です。
実務で押さえる注意点
まず、Playwright Agentsの利用にはLLMのAPIコストがかかります。フレームワーク自体は無料ですが、トークン課金は別途発生します。CIで毎回Healerを回す運用は、コストと実行時間の両面で設計が必要です。
次に、生成コードの品質は100%保証されません。Healerが修復に成功しても、意図しないアサーション緩和やスキップ判定が入る可能性があります。人間によるレビューは省略できません。
また、Playwrightはブラウザ操作に特化しています。スプレッドシート処理、メール確認、Slack通知、API連携を含む業務全体を自動化するには、別ツールとの組み合わせが前提です。ブラウザ部分の部品として使うのは有効ですが、エージェント全体と同一視しないでください。
アクセシビリティツリー依存は、ロールやラベルが整ったアプリでは強みになります。逆に、ラベル不足やDOM構造の激しい変化がある画面では、Plannerの探索精度やHealerの修復成功率が下がります。テスト対象アプリのアクセシビリティ品質が、AI支援の効果を左右します。
Playwright MCPとの関係
Playwright v1.56のAgentsと混同しやすいのが、Playwright MCP（Model Context Protocol）です。MCPはAIモデルとライブブラウザセッションを橋渡しするサーバーで、アクセシビリティスナップショットを通じてクリックや入力を行います（公式ドキュメント）。GitHub CopilotのCoding Agentにも組み込まれており、コード変更後にブラウザで動作確認する用途で使われています。
Agentsはテスト計画・生成・修復のパイプライン、MCPはAIツールとブラウザの接続層——役割が異なります。CopilotやClaude Codeから「チェックアウトフローのテストを書いて」と依頼する場面ではMCPが活き、社内のテスト資産を体系的に増やす場面ではAgentsが活きます。両方を「PlaywrightのAI機能」と一括りにせず、課題に応じて選ぶのが実務的です。
用途に合わせた選択
Playwright v1.56のAIエージェントは、テスト作成の初期コストと保守工数を下げる有力な一手です。Plannerで探索計画を立て、Generatorでコード化し、HealerでUI変更に追随する——この流れは、回帰テストのカバレッジ拡大に直結します。
ただし、これはあくまでテスト自動化の強化であり、自然言語だけで業務全体を委任する汎用エージェントではありません。フレームワークの強みである決定論的な検証を活かす場面で導入し、それ以外の業務自動化にはエージェント専用の設計を検討する——この線引きが、導入後の期待値ズレを防ぐ鍵になります。