Claude CodeとPlaywright MCPで実現する対話型UI自動テスト構築
はじめに
UIテストを書くとき、
「セレクタを探す → 失敗する → ブラウザを見直す」
という往復に時間を取られていませんか？
本記事では、Claude Code と Playwright MCP を組み合わせて、
実際のブラウザ操作を確認しながら対話的にUIテストを構築する方法を紹介します。
テストコードをあとから書くのではなく、
確認作業そのものをテスト生成につなげる のがこの方法の良いところです。
本記事は、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のテストが作れそうです。
