Webアプリケーションの開発が高速化する中、画面操作の自動テスト(E2Eテスト)ツールとして急速に支持を集めているのが「Playwright(プレイライト)」です。
「Playwrightという名前は聞くけれど、SeleniumやCypressと何が違うの?」「自社のプロジェクトで使えるか知りたい」「最短で動かしてみたい」とお悩みの方も多いのではないでしょうか。
本記事では、Playwrightの基本概要から主要機能、他ツールとの違い、そして最短5分で完了する環境構築手順と実際のテスト実行方法までを解説します。
Playwrightとは?注目される3つの特徴
Playwright(プレイライト)は、Microsoftがオープンソースとして開発・提供しているWebブラウザ自動化・E2E(End-to-End)テスト用のライブラリです。
従来から使われてきたSeleniumやPuppeteerなどの課題を解決するために作られており、主に以下の3つの強力な特徴を備えています。
① 複数ブラウザ(Chromium / Firefox / WebKit)を標準サポート
1つのテストコードで、主要なブラウザエンジン(Chromium、Firefox、WebKit=Safari相当)を網羅してテスト実行が可能です。ChromeだけでなくSafariでの動作確認も一括で行えるため、クロスブラウザテストの工数を大幅に削減できます。
② 自動待機(Auto-waiting)による安定したテスト実行
従来のテスト自動化で頻発していた「画面要素の読み込みが間に合わずテストが落ちる」という問題に対し、Playwrightは要素が操作可能になるまで自動で待機する仕組み(Auto-waiting)を備えています。固定時間のスリープ処理(sleep 等)を書く必要がなく、安定したテストを実行できます。
③ Codegen(コード自動生成)とデバッグ機能の充実
ブラウザ上でユーザー操作を行うだけで、その手順をテストコードとしてリアルタイム生成してくれる「Codegen」や、テスト失敗時の画面・通信状態を時系列で再生確認できる「Trace Viewer」など、エンジニアの作業効率を高めるエコシステムが標準で揃っています。
Playwrightと他のE2Eテストツール(Selenium/Cypress/Puppeteer)の比較
E2Eテストツールを選ぶ際によく比較される「Selenium」「Cypress」「Puppeteer」との違いをまとめました。
機能・性能の比較表
| 比較項目 | Playwright | Selenium | Cypress | Puppeteer |
|---|---|---|---|---|
| 開発元 | Microsoft | OpenQA | Cypress.io | |
| 対応ブラウザ | Chromium / Firefox / WebKit | ほぼ全ブラウザ | Chrome / Firefox / Edge | 主にChromium |
| 実行速度 | 非常に高速 | 普通 | 高速 | 高速 |
| 自動待機(Auto-waiting) | 〇 (標準搭載) | △ (明示的指定が必要) | 〇 (標準搭載) | × (手動指定) |
| 複数タブ・フレーム操作 | 〇 (完全対応) | 〇 | × (制約あり) | 〇 |
| 言語サポート | TS / JS / Python / C# / Java | 多数 (Java, Python, Ruby等) | TS / JS のみ | TS / JS のみ |
| 並列実行 | 〇 (標準で高速処理) | △ (Grid等が必要) | 〇 (有償/設定要) | △ |
なぜ今SeleniumからPlaywrightへの移行が増えているのか?
これまで業界標準だったSeleniumは、通信速度や環境構築の手間、テストの不安定さ(Flaky Test)が課題とされていました。
Playwrightはブラウザと直接高速に通信(WebSocket経由)するため実行速度が速く、自動待機機能によってテストが落ちにくいという決定的なアドバンテージがあります。そのため、モダンなWeb開発においてはSeleniumからPlaywrightへ移行するプロジェクトが急増しています。
Playwrightのインストールと初期セットアップ
Playwrightをインストールする前に、以下の環境を準備しておきましょう。
- Node.js(バージョン18以上、最新のLTS版を推奨)
- 対応OS:Windows、macOS、Linux
- 必要なディスク容量:ブラウザのダウンロードを含めて約500MB〜1GB程度
Node.jsがすでにインストールされているかは、ターミナルで以下のコマンドを実行することで確認できます。
node -vバージョン番号(例:v20.11.0)が表示されればインストール済みです。
表示されない場合は、Node.js公式サイトから事前にインストールしてください。
現場でSeleniumを使ったテスト環境の構築を経験した身としては、ブラウザドライバのバージョン管理に悩まされるケースが多かった印象があります。
実際にPlaywrightの環境構築を試したところ、コマンドを実行するだけで短時間のうちにテストが動く状態まで整い、この手間が発生しにくい点は実務上のメリットとして特に大きいと感じました。
Playwrightの導入(VScodeで実践)
・インストール
Node.js環境の場合、以下のコマンドを実行してインストールできます。
npm init playwright@latestコマンド実行後、対話形式で以下の項目を質問されるので、任意の内容で設定してください。
迷った場合は、以下の回答を参考にしてください。
・TypeScript かJavaScriptの選択
→迷ったらTypeScriptがおすすめです。
型のサポートにより、コード補完やエラーの早期発見がしやすくなります。
・テストフォルダ名
→特にこだわりがなければ、デフォルトのtestsのままで問題ありません。
・GitHub Actions workflowの追加の有無
→CI環境でテストを自動実行したい場合はYesを選択します。
まずはローカルで試したいだけの場合はNoでも構いません。
・ブラウザインストールの有無
→Yesを選択すると、この後に紹介するnpx playwright installを別途実行する手間が省けます。
インストールが完了すると、テストプロジェクトが作成されます。

・拡張機能の追加
VScodeでPlaywrightを導入する場合、拡張機能(Playwright Test for VSCode)を入れるのがおすすめです。

Playwright Test for VSCodeを入れることで、テスト実行、デバック操作がしやすくなります。

実行、デバック操作方法
・テストの実行
Playwrightは標準設定だと、
**/*.spec.ts
**/*.test.ts
をテストファイルとして認識します。
それらのテストを実行し、成功すると、✅、失敗すると×で表示されます。

rensa.spec.tsのテストを全て実行もできれば、一つずつテストすることもできます。

・デバック機能
デバック機能が備わっているので、ブレークポイントを張って確認することができます。

エラーになった際はエラー箇所を教えてくれます。

実際にテストコードを書いてみる
・E2Eテストの実践
テストコードのサンプルを紹介します。
商品登録のアプリの登録→確認→完了までのフローのテストを実施してみます。

↓

↓

以下がサンプルコードです。
import { test, expect } from '@playwright/test';
test('商品登録', async ({ page }) => {
// ページ遷移
await page.goto('TestSample/sample.html');
await expect(page.getByRole('heading', { name: '商品登録' })).toBeVisible();
// 登録画面
await page.locator('select[name="product"]').selectOption({ label: 'ラベンダー' });
await page.getByLabel('ギフトあり').check();
await page.getByLabel('個数').fill('3');
// 金額チェック
await expect(page.locator('#price')).toHaveText('4,100円');
await page.getByRole('button', { name: '登録' }).click();
// 確認画面
// 登録画面で入力した内容になっているか確認
await expect(page.getByRole('heading', { name: '登録確認' })).toBeVisible();
await expect(page.getByText('ラベンダー')).toBeVisible();
await expect(page.getByText('あり')).toBeVisible();
await expect(page.getByText('3個')).toBeVisible();
await expect(page.getByText('4,100円')).toBeVisible();
await page.getByRole('button', { name: '登録確定' }).click();
// 完了画面
// 完了画面に遷移できていれば成功
await expect(page.getByRole('heading', { name: '登録完了' })).toBeVisible();
});
・コードの解説
// ページ遷移
await page.goto('TestSample/sample.html');
await expect(page.getByRole('heading', { name: '商品登録' })).toBeVisible();
page.gotoで商品登録のページに遷移します。
その後、画面上にある「商品登録」という見出しを取得し、
登録画面に遷移できているか確認しています。
// 登録画面
await page.locator('select[name="product"]').selectOption({ label: 'ラベンダー' });
await page.getByLabel('ギフトあり').check();
await page.getByLabel('個数').fill('3');
// 金額チェック
await expect(page.locator('#price')).toHaveText('4,100円');
await page.getByRole('button', { name: '登録' }).click();
続いて、商品を登録していきます。
最初の3行で商品選択、チェックボックスの入力、個数の入力を行います。
入力が終わったら、金額チェックを行います。
id=”price” が設定された要素を取得し、4100円になっているか確認します。
金額が合っていれば、登録ボタンを押下し、確認画面に遷移します。
// 確認画面
// 登録画面で入力した内容になっているか確認
await expect(page.getByRole('heading', { name: '登録確認' })).toBeVisible();
await expect(page.getByText('ラベンダー')).toBeVisible();
await expect(page.getByText('あり')).toBeVisible();
await expect(page.getByText('3個')).toBeVisible();
await expect(page.getByText('4,100円')).toBeVisible();
await page.getByRole('button', { name: '登録確定' }).click();
最初の行では登録確認画面に遷移できているか確認しています。
その後、登録画面と入力内容があっているか確認します。
登録画面で入力した内容を変数に代入しておいて、それらと比較させるのもありかと思います。
最後に登録確定画面に遷移します。
// 完了画面
// 完了画面に遷移できていれば成功
await expect(page.getByRole('heading', { name: '登録完了' })).toBeVisible();
登録完了画面に遷移できているか確認します。
不正な登録のフローを実施させて、エラー画面に遷移させるといったテストも可能です。
・APIテストの実施
apiTest.spec.ts
import { test, expect } from '@playwright/test';
test('商品登録API', async ({ request }) => {
const response = await request.post('/api/products', {
data: {
product: 'lavender',
gift: true,
quantity: 3
}
});
// ステータスチェック
expect(response.status()).toBe(200);
// レスポンスチェック
const body = await response.json();
expect(body.isSuccess).toBe(true);
});
リクエストデータを作成し、APIへのリクエスト送信からレスポンスの確認まで、一連の流れをテストすることが可能です。
リクエストパラメータに不正値や不備のあるデータを設定し、
APIから400・500などのエラーステータスが適切に返却されることを確認するテストを実施することもできます。
Playwrightの主要機能
codegenによるGUI操作でのコード生成
以下のコマンドを実行します。
\\project\TestSample> npx playwright codegen URL
実行すると、指定したURLのブラウザが表示されます。
ブラウザ操作をすることで、右側のウインドウにコードを生成してくれます。

VScodeの場合、Record at cursorでコードを生成することも可能です。

codegenと同様にGUI操作でコードを生成できます。
ただ、こちらの場合は既存ファイルに記述ができるので、VScodeを使用している際はこちらのほうが使いやすい印象です。


Trace Viewerによる失敗解析
テストを運用していると、「ローカルでは成功するのに、CI環境だけ失敗する」「実行するたびに結果が変わる」といった、原因の特定が難しい失敗に遭遇することがあります。
こうした場合の調査に役立つのが、Trace Viewerという機能です。
Trace Viewerを使うには、まず設定ファイル(playwright.config.ts)でトレースの記録方法を指定します。
// playwright.config.ts
export default defineConfig({
use: {
trace: 'on-first-retry',
},
});on-first-retryと指定すると、テストが1回目に失敗し、リトライされたタイミングでのみトレースが記録されます。
常に記録したい場合はon、失敗したときだけ記録したい場合はretain-on-failureなど、用途に応じたオプションが用意されています。
記録されたトレースは、以下のコマンドで確認できます。
npx playwright show-trace trace.zipTrace Viewerを開くと、テスト実行中の各ステップが時系列で表示され、以下のような情報を確認できます。
- 各操作を実行した瞬間のスクリーンショット
- 操作前後のDOMのスナップショット(実際の画面構造)
- 発生したネットワークリクエストとそのレスポンス内容
- コンソールに出力されたログやエラー
これらの情報を、テストを再実行することなく後から確認できるため、CI環境で発生した再現しにくい不具合の原因調査に特に効果的です。
モバイルデバイスのエミュレーション
Webサイトやアプリの多くは、スマートフォンからのアクセスを前提に設計されています。
そのため、PC向けの画面だけでなく、スマートフォンやタブレットでの表示・操作も確認したい場面が多くあります。
Playwrightには、実機を用意しなくても、主要なモバイルデバイスの画面サイズやユーザーエージェントを再現できる「デバイスエミュレーション」という機能が備わっています。
利用するには、設定ファイル(playwright.config.ts)で、あらかじめ用意されているデバイスのプリセットを指定します。
// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
{
name: 'iPhone',
use: { ...devices['iPhone 14'] },
},
{
name: 'Pixel',
use: { ...devices['Pixel 7'] },
},
],
});devicesには、iPhoneやPixel、iPadなど、実在する主要な端末の画面サイズ・ユーザーエージェント・タッチ操作対応の有無といった情報があらかじめ設定されています。
上記のように projects(プロジェクト)としてデバイスを複数指定しておくと、同じテストコードを、指定したすべてのデバイスに対して自動的に実行できます。
あらかじめ用意されたデバイス以外にも、以下のようにビューポート(画面サイズ)やユーザーエージェントを個別に指定できます。
ユーザーエージェントとは、ブラウザが「自分がどの端末・ブラウザであるか」をWebサイト側に伝える文字列のことです。
下記の例ではiPhoneのSafariを模したユーザーエージェントを指定しています。
use: {
viewport: { width: 390, height: 844 },
userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1',
},これにより、実際のスマートフォン端末を用意しなくても、レスポンシブデザインの崩れや、モバイル特有のタップ操作の不具合などを、開発中のPC上で効率的に確認できます。
特に、PC版とスマートフォン版でレイアウトが大きく異なるサイトを開発している場合、この機能を使って両方の見え方を1つのテストコードでカバーできます。
Pythonでスクレイピングを実践する
以下は、Pythonで記述する場合のサンプルコードです。
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch()
page = browser.new_page()
page.goto("https://example.com")
print(page.title())
browser.close()Pythonの場合も、page.locator() や page.text_content() などの Locatorで要素を取得できます。
Playwright MCPが実現するAIエージェントへのブラウザ操作移譲
Model Context Protocol(MCP)の仕組みとメリット
MCPとは、AIと外部ツールを安全に接続するための共通規格(プロトコル)のことを言います。
Playwright MCPの場合、ページ遷移やクリック、フォーム入力といったブラウザ操作をAIに自律的に実行させることができます。
また、手動で実行したテストを元に、AIでテストコードを自動生成するといった活用方法もあります。
これにより、作業効率を大幅に向上させることができます。
コードを書く時代からAIに指示する時代へ
従来の開発では、実行したい操作をコードで細かく記述する必要がありました。
一方、MCPを活用した場合、「管理画面へログインして注文一覧を取得して」 などといった内容を指示するだけで、AIがブラウザ操作を行ってくれる世界が現実になりつつあります。
今後は、テストの自動生成や業務の自動化など、様々な場面へ利用が広がっていくはずです。
Playwright MCPサーバーの動かし方とClaude連携の手順
Playwright MCPは、主に以下のMCP対応クライアントと連携可能です。
- VS Code
- Cursor
- Windsurf
- Claude Code
- Claude Desktop
今回は上記の中から、Claude Desktopとの連携方法について紹介します。
Claude Desktopと連携する手順
Claude Desktopと連携する場合は、まず以下の手順で claude_desktop_config.json ファイルを開きます。
- Claude Desktopの設定ウィンドウを開く
- 開発者タブに移動する
- 構成を編集 (Edit Config) ボタンをクリックする
上記の手順を行い、config.jsonファイルが無事に開かれたら、以下の内容を記述します。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Claude Desktopを再起動して設定を反映させた後、設定ウィンドウの開発者タブにplaywrightが追加されていれば設定完了です。
実際にMCPを動かす際は、主に以下のセキュリティ面における対策が重要となります。
- 信頼できるサイトのみ操作する
- 認証情報をハードコードしない
- 権限を最小限にする
- AIへ機密情報を不用意に渡さない
また、本番環境への自動操作を行なう場合は、十分な検証を行った上で導入するよう注意しましょう。
まとめ
実務でのWebアプリ開発・保守を通じて、テストのメンテナンスコストや、CI環境特有の不具合調査に苦労してきた立場から見ても、実際に環境構築からNext.jsでのテスト実装、Trace Viewerでのデバッグまで一通り触れてみて、Auto-waitやTrace Viewerといった仕組みは、こうした課題を軽減してくれると感じました。
一方で、コードを書く前提のツールであるため、チーム内のスキルセットによっては、導入前に学習コストを見込んでおく必要があります。
Playwrightは、E2Eテストからスクレイピングまで幅広く活用できる便利なツールです。
自動化ツールとしてだけでなく、AIのブラウザ操作基盤としても、今後さらに存在感を増していくはずです。