要約
- Playwright Test Agentsは、テスト計画、テストコードを自動生成・修正でき、十分に実用的である
- ただし、実システムから情報を取得するため、リグレッションテストへの利用や仕様書ベースでの利用、レビューを前提に活用すべき
はじめに
みなさん、こんにちは。今回は、私が最近試行しているPlaywright Test Agentsについて紹介します。
Playwrightとは
Playwrightは、Microsoftが開発したオープンソースのWebシステムの自動テストツールです。
Webブラウザ上で動作するシステムの操作(マウスクリック、キーボード入力、など)や検証(表示された値が正しいか、など)を自動化することができます。
Playwrightの特徴
- 対応OS: Windows, macOS, Linux
- 対応ブラウザ: Chromium(Chrome/Edge)、Firefox1、WebKit(Safari)1
- 対応言語: Node.js(JavaScript/TypeScript)、Java、C#、Python
- 用途:UIテスト自動化、Webスクレイピング、スクリーンショット撮影、自動操作ボット、など
- ヘッドレスモード対応:画面を表示せず高速に実行可能
Playwright Test Agents
以下は、Playwright Test Agentsについて、リリースノートからの引用です。
Playwright Test Agentsは、LLMがPlaywrightのテストを構築する中核的なプロセスをガイドするために設計された3つのカスタムエージェントを提供しています。
- 🎭 Plannerは、アプリを探索し、Markdownテストプランを作成
- 🎭 Generatorは、MarkdownプランをPlaywright Testファイルに変換
- 🎭 Healerは、テストスイートを実行し、失敗したテストを自動的に修復
上記をAIが全て自動で行ってくれるのであれば、非常に便利そうです。そこで、実際に動かしてみて、どの程度使えるか確認してみました。
Playwright Test Agentsの準備
試行環境
- OS: Windows 11
- IDE: Visual Studio Code v1.106.3
- GitHub Copilot Chat / GPT-5mini
- Node.js: v22.20.0
- Playwright: v1.57
Playwright Test Agentsのインストール
- コマンドラインでワークスペース用のフォルダを作成、移動
mkdir playwright-agent-trial
cd playwright-agent-trial
- Playwrightのインストール
npm -g config set https-proxy {プロキシサーバーのアドレス}
npm init playwright@latest
- VSCode用のPlaywright Test Agentsのインストール
npx playwright init-agents --loop=vscode
- VSCodeの起動
code .
上記により、GitHub Copilot Chat画面に三つのエージェントが表示されます。

また、ワークスペース上には、以下のようなフォルダ/ファイルが作成されます。
これらは、Playwright Test Agentsが動作するために必要なCustom InstructionやPlaywright MCPの設定ファイルです。

Playwright Test Agentsの試行
テスト対象
東芝の新卒採用ページから辿れるインターンシップのエントリ(マイページ新規登録)を対象としてみました。
ただし、実際に登録するわけにはいかないので、登録画面までの遷移と入力フォームの必須項目未入力の場合の挙動の検証を対象としました。

Plannerの試行
Plannerエージェントに対して、以下のように指示しました。
https://www.global.toshiba/jp/recruit/corporate/newgraduates/entry.html
上記のWebサイトの実装を調査して、27卒以降 インターンシップのマイページを新規登録するためのテスト計画書を作成してください
Plannerは、Playwright MCPを利用して、指示されたWebサイトを自動で開き、画面上の要素を調査し、以下のようなテスト計画書を作成しました。
----------------------------------------
テスト計画書の詳細を表示(折りたたみ)
------------------------------------------
# 東芝 27卒以降 マイページ新規登録 テストプラン
## Application Overview
対象ページ: https://job.axol.jp/bx/s/toshiba_27/entry/
目的: 27卒以降インターンシップ参加者向けの「マイページ新規登録」フォームの実装を検証する。正常系(登録完了)および入力検証、境界値、エラー時挙動、外部連携(学校検索・郵便番号検索・マイナビ連携)などを網羅する。各テストは独立して実行可能で、常に新規/空の状態を前提とする。
## Test Scenarios
### 1. 27卒以降 マイページ新規登録
**Seed:** `tests/seed.spec.ts`
#### 1.1. 正常系: 新規登録(フル入力)
**File:** `specs/toshiba-mypage-27.testplan.md`
**Steps:**
1. ブラウザを起動し、https://www.global.toshiba/jp/recruit/corporate/newgraduates/entry.html にアクセスする。
2. ページ内の「27卒以降エントリー(マイページ新規登録)」ボタンをクリックする。
3. 会員規約ページで「上記会員規約に同意する」をクリックする。
4. 表示された登録フォームで必須項目をすべて正しく入力する(漢字氏名、カナ、ローマ字、性別、生年月日、現住所(郵便番号・都道府県・市区町村・町域)、電話(自宅または携帯)、メールアドレスと確認用一致)。
5. 郵便番号から検索ボタンで住所自動入力を試し、都道府県・市区町村が自動で反映されることを確認する。
6. 学校情報:学校名の頭文字を入力して「学校検索」から該当校を選択する。入学年月と卒業(予定)年月を選択する。
7. アンケート項目をすべて選択/入力(文理区分、学年、学校(キャンパス)所在地、出所、興味分野、職種チェック、ゼミ研究テーマ(50字以内)、進路)する。
8. 画面下の「次の画面に進む」をクリックする。
9. 確認画面で入力値が正しく表示されることを確認し、最終送信(登録完了)を完了する。
**Expected Results:**
- フォームの必須エラーがなく、確認画面へ遷移する。
- 郵便番号検索で住所が自動補完される。
- 学校検索で学校を選択でき、選択値がフォームに反映される。
- 確認画面に全ての入力値が正しく表示される。
- 登録完了メッセージが表示される、または完了ページに遷移する。
#### 1.2. 異常系: メールアドレス不一致で進めないこと
**File:** `specs/toshiba-mypage-27.testplan.md`
**Steps:**
1. 会員規約に同意して入力画面を開く。
2. 必須項目を正しく入力するが、メールアドレス欄と確認用に異なる文字列を入力する(例:a@example.com と b@example.com)。
3. 「次の画面に進む」をクリックする。
**Expected Results:**
- メールアドレス確認欄に一致しない旨のバリデーションエラーが表示され、次画面へ進めない。
- エラーメッセージは日本語で明確に表示される。
#### 1.3. 異常系: 必須項目未入力時のバリデーション表示
**File:** `specs/toshiba-mypage-27.testplan.md`
**Steps:**
1. 会員規約に同意して入力画面を開く。
2. 漢字氏名、メール、卒業予定年月など必須項目を空のままにする。
3. 「次の画面に進む」をクリックする。
**Expected Results:**
- 各必須項目の近くに「必須です」等のバリデーションメッセージが表示される。
- ページが遷移せず、ユーザはエラーを修正するよう促される。
- アクセシビリティ対応としてエラー要約やフォーカス移動があれば確認する。
#### 1.4. 異常系: 電話番号フォーマットの検証(不正な文字・桁数)
**File:** `specs/toshiba-mypage-27.testplan.md`
**Steps:**
1. フォームを開いて電話番号欄に英字や全角文字、または短すぎる/長すぎる数字列を入力する(例:abc-def-ghij、090-123-456789)。
2. 「次の画面に進む」をクリックする。
**Expected Results:**
- 電話番号欄に形式エラーが表示され、送信がブロックされる。
- エラーメッセージに入力例(半角数字でハイフン区切り等)が含まれていることが望ましい。
#### 1.5. 境界値: ゼミ/研究テーマの文字数制限(50文字)
**File:** `specs/toshiba-mypage-27.testplan.md`
**Steps:**
1. ゼミ/研究テーマ欄に50文字の文字列を入力し「文字数を確認する」ボタンを押す。
2. 続けて51文字以上の文字列を入力して同ボタンを押す。
**Expected Results:**
- 50文字の場合、許容される旨の表示または問題なく次に進める。
- 51文字以上では「50文字以下」等のエラーが表示され、次に進めない。
#### 1.6. 機能検証: 郵便番号検索で日本国外フラグを切り替えた場合の挙動
**File:** `specs/toshiba-mypage-27.testplan.md`
**Steps:**
1. フォームで「日本国外の場合」チェックをONにする。
2. 郵便番号欄や都道府県選択の動作が適切に無効化/変更されることを確認する。
3. 国外選択のまま住所(国名・市区町村等)を入力して進める。
**Expected Results:**
- 「日本国外の場合」チェックONで国内向けの郵便番号検索が無効化される。
- 都道府県欄が「日本国外」または入力不可となるなどUIで国外モードを示す。
- 国外住所で次に進める、もしくは国外の場合に要求される別項目が表示される。
テスト計画書の内容を確認してみると、マイページの新規登録機能について概要と網羅的なテストシナリオを作成してくれています。
正常系のテストシナリオを読むと、実際の登録画面に表示される入力項目を正しく把握していることが分かります。
異常系や境界値のシナリオも妥当なケースが記載されていると思います。
ただし、テストシナリオの手順として「表示された登録フォームで必須項目をすべて正しく入力する」はやや抽象的であり、具体的にどの項目をどう入力するかまでは記載されていません。
また、期待結果については、「エラーメッセージは日本語で明確に表示される。」「アクセシビリティ対応としてエラー要約やフォーカス移動があれば確認する。」「国外住所で次に進める、もしくは国外の場合に要求される別項目が表示される。」など、やや曖昧な表現が見られます。
Plannerの挙動を確認すると、登録画面の情報までは取得していますが、次の画面遷移までは確認していないため、期待結果が具体的に記載できていないようです。
手順や期待結果の具体化のために、Plannerへの指示内容を具体化する、あるいは人間が補完する必要があるかもしれません。
Generatorの試行
次に、Generatorエージェントに対して、テスト計画書を指定して、以下のように指示しました。
このテストの計画書を参考に、「1.3. 異常系: 必須項目未入力時のバリデーション表示」を実装してください
Generatorは、Playwright MCPを利用して、指示されたテストシナリオに基づき、Webサイトにアクセスして手順を実行して、以下のようなPlaywrightのテストコードを自動生成しました。
----------------------------------------
テストコードの詳細を表示(折りたたみ)
------------------------------------------
// spec: specs/toshiba-mypage-27.testplan.md
// seed: tests/seed.spec.ts
import { test, expect } from '@playwright/test';
test.describe('27卒以降 マイページ新規登録', () => {
test('異常系: 必須項目未入力時のバリデーション表示', async ({ page }) => {
// 1. 会員規約に同意して入力画面を開く。
await page.goto('https://job.axol.jp/bx/s/toshiba_27/entry/agreement');
await page.getByRole('button', { name: '上記会員規約に同意する' }).click();
// 2. 漢字氏名、メール、卒業予定年月など必須項目を空のままにする。
// intentionally leave required fields empty
// 3. 「次の画面に進む」をクリックする。
// handle possible alert dialog that appears on submit
let dialogMessage = '';
const dialogPromise = page.waitForEvent('dialog').then(dialog => {
dialogMessage = dialog.message();
return dialog.accept();
}).catch(() => null);
await page.getByRole('button', { name: '次の画面に進む' }).click();
await dialogPromise;
// Expect: ページ上に入力エラーの要素が表示されること
const expectedErrors = [
'漢字姓 は必須です',
'漢字名 は必須です',
'カナ姓 は必須です',
'カナ名 は必須です',
'ローマ字姓 は必須です',
'ローマ字名 は必須です',
'生年月日 は必須です',
'郵便番号 は必須です',
'現住所(都道府県) は必須です',
'現住所(市区郡町村) は必須です',
'現住所(町域・番地) は必須です',
'メールアドレス は必須です',
'確認用 は必須です',
'学校区分 は必須です',
'設置区分 は必須です',
'学校 は必須です',
'入学年月 は必須です',
'卒業(予定)年月 は必須です',
'設問 1 は必須です',
'設問 2 は必須です',
'設問 3 は必須です',
'設問 4 は必須です',
'設問 5 は必須です',
'設問 6 は必須です',
'設問 7 は必須です',
'設問 8 は必須です'
];
for (const text of expectedErrors) {
const loc = page.getByText(text, { exact: true });
await expect(loc).toBeVisible();
}
// If an alert dialog appeared, assert its message contains expected substring
if (dialogMessage) {
expect(dialogMessage).toContain('入力内容にエラーがあります');
}
});
});
生成されたテストコードを実行してみたところ、問題なく成功しました。
生成されたテストコードは、必須項目未入力時のバリデーション表示やエラーダイアログの表示を検証する内容となっており、テスト計画書の手順と期待結果をおおむね反映していると思います。
ただし、期待結果では「ページが遷移せず、ユーザはエラーを修正するよう促される。」とありましたが、生成されたコードではページ遷移の確認が含まれていません。
前述した通り、テスト計画書の期待結果が具体的でないため、生成されなかった可能性がありますが、やはり生成AIを利用する上では人間が必ず生成物の内容を確認する必要があります。
Healerの試行
最後に、Healerエージェントに対して、生成されたテストコードを指定して、以下のように指示しました。
「次の画面に進む」をクリックした時に、次の画面に遷移せず入力画面に残ったままであることを期待結果として確認するようテストに追加してください。
Healerは、指定されたテストコードを確認し、指示されたアサーションを自動的に追加して、以下のような修正版のテストコードを生成しました。
// spec: specs/toshiba-mypage-27.testplan.md
// seed: tests/seed.spec.ts
import { test, expect } from '@playwright/test';
test.describe('27卒以降 マイページ新規登録', () => {
test('異常系: 必須項目未入力時のバリデーション表示', async ({ page }) => {
// 省略
await page.getByRole('button', { name: '次の画面に進む' }).click();
await dialogPromise;
// Expect: 次の画面に遷移せず、入力画面に留まっていることを確認
await expect(page).toHaveURL(/\/entry\/input/); // この行が追加部分
// 省略
});
});
生成された修正版のテストコードを再度実行してみたところ、問題なく成功しました。
まとめ
Playwright Test Agentsを試した結果、網羅的なテスト計画書を自動生成し、その計画に基づくテストコードの自動生成、自動修正が可能であることを確認しました。
生成されたテスト計画書やテストコードには一部曖昧さや不備が見られましたが、全体としては十分に実用的であり、人間による確認・補完を行うことで効率的に自動テストを構築できると感じました。
実際、社内で使用しているフレームセットを含むレガシーなWebシステムに対しても、Playwright Test Agentsを利用してテスト計画、テストコードの自動生成が可能であることを確認しました。
ただし、重要な点として、Playwright Test Agentsは実際のWebシステムを操作して情報を取得するため、対象システムにバグがある場合、その誤った挙動を正しいものとしてテスト計画やテストコードを生成する可能性があります。
そのため、以下のようにPlaywright Test Agentsの利用方針を明確にすることが重要です。
Playwright Test Agentsの利用方針
- リグレッションテストで利用する場合のみ、既存システムを正しい挙動としてテスト生成する
- リグレッションテスト以外で利用する場合、テストベース2を明示的にPlannerエージェントに渡す
- 生成結果(テスト計画書、テストコード)を必ず人間がレビューし、必要に応じて修正する
今後も社内でPlaywright Test Agentsを試行し、その有用性を検証していきたいと思います。