「画面を作ったけど、ちゃんと動くかどうか手で全部確認するの、正直つらい……」
そう感じたことはありませんか? チェックボックスをクリックして、フィルターを切り替えて、カウントが正しく更新されるか確認して……と繰り返していると、それだけで開発時間の大半が溶けていくなんてことも。
今回は、そんな画面テストのつらみを解消すべく、Claude Code に Playwright の MCP サーバーを組み合わせて、実際に Todo アプリの画面テストを実施してみました。
設定方法から、テスト仕様書の作成、そして実際のテスト実行まで、一連の流れをまるごとご紹介します。
Playwright とは?
Playwright は、Microsoft が開発しているオープンソースのブラウザ自動化ライブラリです。Chrome・Firefox・Safari(WebKit)の 3 大ブラウザを一つの API で操作できるのが最大の特徴で、End-to-End テストのデファクトスタンダードになりつつあります。
ざっくり言えば、「人間がブラウザでやる操作を、コードで自動化できるツール」です。
具体的にできることとしては、
- URL にアクセスする
- ボタンをクリックする
- フォームに入力する
- 画面キャプチャを撮る
- 表示内容を検証する
といったことが自由自在にできます。
Playwright の使い方は 2 パターンある
Playwright の使い方は、大きく 2 つに分かれます。
【パターン 1】テストコードとして書く(従来の使い方)
npm でインストールして、TypeScript/JavaScript でテストコードを書き、コマンドラインで実行する方法。CI/CD との相性が抜群です。
【パターン 2】MCP サーバーとして Claude Code から使う(今回の方法)
Playwright を MCP(Model Context Protocol)サーバーとして起動し、Claude Code から AI に指示を出す形でブラウザを操作する方法。コードを書かなくても、自然言語の指示だけで画面テストができます。
MCPについては以下を参照してください。
NotionのタスクをGitHub Issueへ自動同期!Claude Code + MCPで実現してみた
今回はパターン 2 の「Claude Code × Playwright MCP」を採用しました。テスト仕様書を作成しておけば、あとは AI に投げるだけという手軽さが魅力です。
Step 1:Playwright MCP サーバーを登録する
まず、Playwright MCP を Claude Code で使えるようにします。
Claude Code に MCP サーバーを登録する
Claude mcp add コマンドで登録するのが一番かんたんです。
claude mcp add playwright npx @playwright/mcp@latest
このコマンドを実行すると、設定が自動で保存されます。
設定ファイルの保存先はスコープによって異なります。
| スコープ | コマンド | 用途 |
|---|---|---|
| ローカル (デフォルト) |
claude mcp add playwright npx @playwright/mcp@latest |
このプロジェクトだけで使いたい場合 |
| ユーザー | claude mcp add --scope user playwright npx @playwright/mcp@latest |
自分の PC のすべてのプロジェクトで共通で使いたい場合 |
| プロジェクト | claude mcp add --scope project playwright npx @playwright/mcp@latest |
チームで設定を共有したい場合 (Git 管理可) |
設定が正しく追加されたかどうかは以下で確認できます。
claude mcp list
Claude Code のチャット内で /mcp と入力しても確認できます。
Step 2:動作確認をしてみる
Playwrightの登録が出来たら動作確認をしてみましょう。
今回は簡単にTodo アプリを作成してみました。
主に以下の機能が存在します。
1. タスクの登録、削除
2. 登録したタスクを一覧で確認(何個タスクが存在して、完了したものはいくつかなど)
こちらでテストをしてみたいと思います。
今回のアプリが localhost:3001で動作している場合、
チャット欄に以下のように入力しClaudeCodeを動作させます。
Playwright を使って、<http://localhost:3001> にアクセスして、
ページタイトルと表示されているタスク数を教えてください。
「Todo App」というタイトルと、サマリーカードに「全タスク:10」が表示されていることが確認できました
直感的な日本語で操作できるのが、MCP パターンの最大のメリットです。
Step 3:テスト仕様書を作成する
このTodoアプリのテスト対象の機能は以下の 4 つです。
- サマリーカード — 全タスク数・未完了・完了済み・完了率の集計表示
- タスク追加フォーム — タスク名・優先度・期日を入力して追加
- フィルター切り替え — すべて / 未完了 / 完了済みで絞り込み
- タスク一覧テーブル — チェックボックスで完了切り替え・削除ボタン
これらに対して、Claude Code にソースコードを読ませたうえで、機能ごとに項番付きのテスト仕様書を作成してもらいました。
プロンプト例
このプロジェクトに必要なテストをPlaywrightを使ってテストを行いたい。
Playwright用のテスト仕様書を作成してほしい。
画面毎に分けてテストごとに項番を割り振って、Playwrightに指示する内容を記載して。
出力されたテスト仕様書(抜粋)

T-001: ページタイトルと見出しの表示確認
- http://localhost:3001/ にアクセスし、読み込み完了を待つ
- ページタイトルが「Todo App」であることを確認する
- h1 見出しに「Todo アプリ」が表示されていることを確認する
T-012: 初期状態で「すべて」ボタンが選択状態になっている
- http://localhost:3001/ にアクセスし、読み込み完了を待つ
- 「すべて」ボタンの背景色が青(#1890ff)であることを確認する
- 「未完了」「完了済み」ボタンの背景色が白であることを確認する
ソースコードを読み込んでいるので、実際のコンポーネントの挙動に基づいた現実的なテスト仕様書が出来上がります。
足りなければ自分で追加しても良いかもしれませんね。
今回は全 30 件のテストケースが生成されました。
Step 4:テストを実行する
仕様書ができたら、いよいよテストの実行です。
Claude Code に対して以下のように指示します。
このテスト仕様書に基づいてテストを行ってください。
テストの結果は別ファイルで OK、NG(NGの場合はどのようなNGだったか記載)と
スクリーンショットも記録してください。
あとは Claude Code が自動で順番にテストを実行してくれます。
自分でテストコードを書かなくても、仕様書の内容に合ったコードを生成して実行してくれるのが驚きでした。
※ ただし、テスト仕様書やテストした内容が正しいかどうかは最終的に人間が確認する必要があると思っています。
テスト結果
今回の実行結果はこちらです。
| 結果 | 件数 |
|---|---|
| ✅ OK | 26 件(86.7%) |
| ❌ NG | 3 件 |
| ⏭ SKIP | 1 件 |
| 合計 | 30 件 |
ほとんどのテストはパスしましたが、NG になったケースもありました。
以下はNGケースの一部です。
NG ケース① T-010 NG 詳細:空のタスク名で追加してもフィードバックがない
確認内容: タスク名フィールドを空のまま「追加」ボタンをクリックした。
期待動作: エラーメッセージが表示される、またはボタンが disabled 状態になる。
実際の動作: タスクは追加されなかった(全タスク数=10 のまま)が、エラーメッセージも何も表示されず、ユーザーには何も起きていないように見える。 コード上は弾いているがUIフィードバックが一切ない。
対応案: バリデーションエラーメッセージの表示、または追加ボタンの disabled 制御を追加する。
NG ケース② T-028 NG 詳細:スペースのみのタスク名でもフィードバックがない
確認内容: タスク名フィールドに 「 」(スペース 3 つ)を入力して「追加」ボタンをクリックした。
期待動作: 空入力と同様にエラーメッセージが表示される。
実際の動作: タスクは追加されなかった(全タスク数=10のまま)が、T-010 と同様にエラーメッセージが一切表示されない。trim 処理により登録は防がれているが、ユーザーには何も起きていないように見える。
対応案: T-010 と共通のバリデーションフィードバック実装で解消できる。
Playwright MCP × Claude Code を使ってみての感想
良かった点
テストコードをほぼ書かなくていい
仕様書さえあれば、コード生成から実行まで Claude Code が全部やってくれます。テスト自動化の心理的ハードルがぐっと下がります。
スクリーンショットが自動で残る
テスト失敗時の状態が画像で残るので、何が起きたか一目でわかります。
想定外のバグが見つかる
今回の空入力時のフィードバック不足など手動確認で見落とすテストも実施してくれるのは良かった。
気になった点
非同期処理の待機が難しい
React の状態更新完了を待つタイミングの調整は、AI 任せにするとたまにタイムアウトします。
仕様書に「更新完了を待つ」と明記しておくことで改善できます。
まとめ
Claude Code × Playwright MCP の組み合わせは、「テストコードを書く工数をかけずに画面の動作確認を自動化したい」というケースにぴったりです。
手順をまとめるとこんな感じです。
- Step 1 : Playwright MCP を設定する
- Step 2 : 動作確認(簡単な URL アクセスから試す)
- Step 3 : ソースコード、もしくは画面仕様書を読ませてテスト仕様書を生成する
- Step 4 : テスト仕様書をもとにテスト実行・結果ファイルとスクリーンショットを保存する
画面の仕様が固まってきたタイミングで仕様書を作り、そのまま AI に流すというワークフローは、リリース前のリグレッションチェックとしても十分に使えるレベルでした。
ぜひ自分のプロジェクトでも試してみてください。想定外の発見があるかもしれません。

