Claude CodeとPlaywright MCPで実現する対話型UI自動テスト構築
はじめに
UIテストを書くとき、
「セレクタを探す → 失敗する → ブラウザを見直す」
という往復に時間を取られていませんか？
本記事では、Claude Code と Playwright MCP を組み合わせて、
実際のブラウザ操作を確認しながら対話的にUIテストを構築する方法を紹介します。
テストコードをあとから書くのではなく、
確認作業そのものをテスト生成につなげる のがこの方法の良いところです。
本記事は、Claude CodeとPlaywrightを利用したことがある方向けに書いています。
各サービスについて詳しく知りたい方は、こちらをご覧ください。
Claude CodeとPlaywrightの参考ブログ
Claude Code
Playwright
動画で動きを紹介
モバイル表示時のハンバーガーメニューのテストを対話的に作成している例です。
こんなことができます。
生成したテストコードの詳細
この記事で作成したテストコードは、GitHubにまとめています。
Playwright MCPとは？
Playwright MCPは、Claude Code（AIエージェント）が
Playwrightを使って実際のブラウザ操作を行えるようにする仕組みです。
Playwright MCPを使うことで、Claude Codeが表示された画面を確認しながら
テスト内容を考えることができます。
本記事では、この仕組みを使った対話的なUIテスト作成を紹介します。
公式リポジトリ
Claude Code × Playwright MCPで何が変わるのか
従来のPlaywrightテスト構築では、
- 実装者がブラウザで挙動を確認
- DOM構造やセレクタを調査
- その内容を元にテストコードを書く
という流れが一般的でした。
Claude CodeにPlaywright MCPを組み合わせることで、
この「確認作業」をAIと共有できるようになります。
Playwright MCPを通じてClaude Codeは、
特定の画面サイズでの表示結果や操作後の要素情報を取得し、
その情報を元にテスト内容を提案・コード生成します。
結果として、
- セレクタ調査にかける時間が減る
- 操作手順をテストコードに落とす時間が減る
- 動かないテストを書いてしまう手戻りが減る
という変化を感じました。
対話型でテストを作るワークフロー
このワークフローの良いところは、
「テストコードを書く前に、人間とAIで何をテストするか合意する」 点にあります。
大まかな流れは次の通りです。
- Claude CodeがPlaywright MCPを使ってブラウザを操作
- 画面表示や要素情報を確認した上で、テスト候補を提示
- 人間が内容を確認・承認
- 承認された内容をテストコードとして生成
- 生成したテストコードの動作をClaude Codeと人間の両面で確認
これにより、テストコードを自動生成しながらも どういったテストが行われているのかがスムーズに理解できます。
実例： モバイルナビゲーションのテスト構築
例として、DevelopersIO（https://dev.classmethod.jp）の
モバイル表示時のハンバーガーメニューをテストするケースを紹介します。
動画を再掲
Claude Codeに
「モバイル画面で左上にハンバーガーメニューが表示されて、クリックするとメニューが開くテストしたい」
と伝えると、Playwright MCPを使って以下を自動で行います。
- モバイルサイズへリサイズ
- 対象ページへ遷移
- 画面表示や要素情報を取得
- スクリーンショットによる視覚確認
確認した動作内容として、次のようなテスト項目を提案されました。
- モバイル画面（375px幅）で左上にハンバーガーメニュー（≡アイコン）が表示される
- メニューボタンをクリックするとナビゲーションメニューが開く
- メニューにはAWS、Amazon EC2、AWS IAM、Google Cloud、ChatGPT、Python、LINE、ビジネス・アナリティクス、Looker、セミナー、事例などのリンクが表示される
- メニューが開くとアイコンが「×」に変わる
この内容を承認すると、Claude CodeはPlaywrightのテストコードを生成し、実行して動作確認をします。
test("ハンバーガーメニューをクリックするとメニューが開く", async ({ page }) => {
await page.goto("/");
// ハンバーガーメニューボタンが表示されていることを確認
const menuButton = page.getByRole("button", { name: "メニューボタン" });
await expect(menuButton).toBeVisible();
// メニューが閉じている状態であることを確認
await expect(menuButton).not.toHaveAttribute("aria-expanded", "true");
// メニューボタンをクリック
await menuButton.click();
// メニューが開いたことを確認（aria-expanded属性がtrueになる）
await expect(menuButton).toHaveAttribute("aria-expanded", "true");
// メニュー内のリンクが表示されていることを確認
const menuList = page.locator("button[aria-expanded='true'] + ul");
await expect(menuList).toBeVisible();
// メニュー内のリンクがいくつか存在することを確認
await expect(menuList.getByRole("link", { name: "AWS" })).toBeVisible();
await expect(menuList.getByRole("link", { name: "Python" })).toBeVisible();
});
失敗すれば、原因を分析して対応し、再実行します。
ヘッド付きで実行すれば、ブラウザ上での挙動を人間も確認できるため、テスト内容の把握が簡単になります。
補足：マルチデバイス実行でテストが失敗した例
作成したテストケースはPlaywrightのテストコードになっているため、マルチブラウザ・マルチデバイスを想定してテスト実行することが可能です。
そして、モバイル向けに「ブログカードが縦一列に表示されること」というテストを作り、iPadで実行したところテストが失敗しました。
画面幅が広いため、想定していた1カラム表示になっていなかったことが、レポートのスクリーンショットで確認できます。
（システム側に問題が見当たらないので、わざと失敗するようなテストケースを作成しました(:P）
Playwrightレポートの画像
このような失敗についても、実行結果を確認しながらClaude Codeとテスト条件を見直していけます。
まとめ
Claude Code と Playwright MCP を組み合わせることで、
- ブラウザ確認とテスト作成が分断されない
- 手戻りの少ないUIテスト構築ができる
というメリットを感じました。
AIが生成するテストコードをそのまま信用するのはまだ難しいですが、
テストコードの生成は圧倒的に早いです。
AIにテストコードを生成してもらいながら、適宜テストコードの修正をすることで楽にPlaywrightのテストが作れそうです。
