ナレッジワークでは、お客様に安定したサービスを提供するため、E2Eテストを活用した品質保証に取り組んでいます。ただし、E2Eテストの開発・保守には多くの時間と労力が必要で、正直なところ手間だと感じる場面も少なくありません。本記事では、そうした課題を Playwright MCP を活用して解消した取り組みをご紹介します。
※ Playwright MCP は Playwright をAIエージェントなどから実行し、ブラウザ操作を行えるようにする MCP（Model Context Provider）です
課題
主に次の3点に課題がありました。
- ロケーターの記述に手間がかかる
- テストケースの記述に手間がかかる
- テストのデバッグに時間がかかる
それぞれ具体的に説明します。
ロケーターの記述に手間がかかる
E2Eテストでは、ページ上で行いたい操作に必要なボタンやインプットなどのロケーター（セレクタ）を記述する必要があります。
この作業はブラウザの開発者ツールの Elements タブを操作しながら必要なDOM要素を特定し、適切なロケーターを記述するために Accessibility tree を確認したり、必要に応じてdata-testidを参照したりします。
少数であればそこまで負担ではないものの、実際のテスト実装では複数ページで同様の作業を繰り返す必要があり、想定以上に時間を要します。
page.getByRole('button', { name: 'ログイン' })
page.getByRole('dialog', { name: 'ユーザー設定' })
.getByRole('region', { name: 'プロフィール情報' })
.getByRole('textarea', { name: 'ユーザー名' })
テストケースの記述に手間がかかる
E2Eテストでは、ユーザーが実際に行う操作を一つ一つ順序立てて記述する必要があります。
例えば「ログインしてユーザー情報を変更する」という一見シンプルなフローでも、実装では入力欄に値を入力するpage.fill()、特定の要素をクリックするpage.click()などの操作を網羅的に記述する必要があり、手間がかかります。
「ログインしてユーザー情報を変更する」の例
test('ログインしてユーザー情報を変更する', async ({ page }) => {
await page.goto('https://example.com/login');
await page.getByRole('textbox', { name: 'ユーザーID' }).fill('test-user');
await page.getByRole('textbox', { name: 'パスワード' }).fill('secret');
await page.getByRole('button', { name: 'ログイン' }).click();
await expect(page).toHaveURL(/dashboard/);
await page.getByRole('link', { name: '設定' }).click();
await page.getByRole('button', { name: 'プロフィール編集' }).click();
const dlg = page.getByRole('dialog', { name: 'ユーザー設定' });
await dlg.getByRole('region', { name: 'プロフィール情報' })
.getByRole('textbox', { name: 'ユーザー名' })
.fill('新しい名前');
await dlg.getByRole('button', { name: '保存' }).click();
await expect(page.getByText('新しい名前')).toBeVisible();
});
テストのデバッグに時間がかかる
テストの記述を終えた後、実際に実行して正しく通るかを確認する工程も時間を要します。
主な要因は次の2点です。
- E2Eテストの実行自体に時間がかかる
- 失敗時の原因把握と修正に時間がかかる
E2Eテストは、実際のプロダクトにアクセスしてブラウザを操作して実行する特性上、実行時間が長くなりがちです。テスト内容によっては1回の実行に数分を要する場合もあります。
加えて、失敗時の修正にも時間を要します。多くの場合、失敗の原因は不適切なロケーターに起因します。エラーログから問題となっているロケーターとその理由を特定し、正しいロケーターに修正したうえで再度テストを実行する必要があります。1件の失敗対応に20〜30分かかってしまうことも珍しくありません。
解決策
今回、これらのE2Eテストにまつわる課題を Playwright MCP の活用によって解消しました。
ロケーターの記述を任せる
Playwright MCPを利用し、実際のプロダクトにアクセスして取得した Accessibility Snapshot をもとに適切なロケーターを抽出し、ロケーターの記述を任せます。
弊社では、一つのページをオブジェクトとして扱い再利用性を高める Page Object Model を採用しているため、一度ロケーターを作成すれば再利用が可能です。
以下のようなプロンプトを利用して、Page Object Modelを作成依頼したところ、筆者は一切コードを触らずにロケーターを記述することが出来ました。
プロンプト例：
https://example.com にPlaywright MCPを使ってアクセスし、Page Object Modelの形で hoge/fuga.ts に実装してください。
- クラス名は Hoge にしてください。
- 各 UI 要素は `getByRole` / `getByLabel` / `getByText` などできる限りアクセシビリティ属性のついたロケーターを利用してください。
テストケースの記述を任せる
テストケースの実装も効率化します。（厳密には Playwright MCP そのものは使用していませんが…）
ロケーターの記述を任せるで作成した Page Object Model を参照することで、AI がある程度画面構造を推測できるようになり、それを踏まえてテストケースの実装を依頼します。
まずはテストケースを自然言語でざっくりと記述し、それをもとにコードへ落とし込んでもらいます。
これにより、複雑なフローに沿ったE2E実装でも効率的に進められます。
AIが画面を推測しながらの実装となるため、初回実行では失敗するコードが生成される場合もありますが、次項のテストのデバッグを任せるで修正できるため、この段階では大枠の作成を重視します。
今までであれば、テストケースをもとに必要なPage Objet Modelの要素を確認して、操作のコードを書くという、それなりに時間がかかる要素でしたが、AIに依頼することで数分で完了するようになりました。
test('ユーザー名を更新できる', async ({ page }) => {
})
プロンプト例：
hoge/fuga.spec.ts にかかれているコメントのフローをPage Object Modelを利用しつつ実装してください。
テストのデバッグを任せる
Playwrightは、テスト実行後に npx playwright show-report を実行することでWebブラウザ上で実行結果を詳細に確認できます。Webブラウザで確認できるということは、Playwright MCP でも同様に確認できるため、デバッグを任せることが出来ます。
さらにレポート内には Trace というページがあり、テスト実行時の環境におけるDOM構造を保持したページのモックが確認できます。DOM構造が残っているということは、Playwright MCP を用いてこの情報を読み取り、不適切なロケーターがあった場合でも実際の構造を参照しながら正しいロケーターへと修正できます。
Playwright HTML レポートのTrace画面
https://playwright.dev/docs/ci-intro#viewing-the-html-report
「テストの実行 → レポートの確認 → テストの修正」のループを回すことで、人手を最小限に抑えつつAIが正しいE2Eテストを実装できるようになります。
ここのループをAIが回してくれるのは本当に楽で、今までは「実行中は別のことをやってテストが失敗したらログを確認し、テストの修正を行う」というループでスイッチングコストが非常に高かったので、勝手に書き上げてくれるのはとっても助かっています。
実行例
事前に別のターミナル上で npx playwright show-report を実行した上で以下プロンプトを実行します。
プロンプト例：
hoge/fuga.spec.tsのテストを流して、失敗した箇所を修正してください。
テストが失敗した場合、テスト失敗の詳細は http://localhost:9323 に載ってますので、失敗時にplaywright mcpを使ってアクセスして、内容を解析し修正を試みてください。
エラーレポートのTrace ページにより具体的なエラー原因とページのモックがありますので、テストの修正、ロケーターの修正などに利用してください。
注意点
コスト面の注意
Playwright MCP を活用することでE2Eテスト実装を楽にできる一方、ページのスナップショットをコンテキストとして渡すため、比較的早いペースでトークンを消費します。
特にテストのデバッグを任せるで述べたループ工程では、レポートの読み取りを繰り返す場面があり、トークン消費が増えがちです。
筆者は Claude Code を利用して実装しましたが、コンテキストの圧縮（compact）が頻発し、渡した情報が失われるケースがありました。
まとめ
Playwright MCP を活用することで、楽にE2Eテストの実装ができました。
今回の例では、テストケース自体への理解があれば実装可能なため、E2Eテスト実装の未経験者や、日常的にプロダクトコードを書かないQAエンジニアの方でも取り組みやすい点がメリットだと考えています。
KNOWLEDGE WORK Blog Sprint、明日9/11の執筆者はmadoです。お楽しみに〜。
