アプリケーション開発において、動作テストは必須作業の1つとなります。
その上で、開発効率や品質の向上を図るためには、手動テストだけでなく自動テストの導入が欠かせません。
近年では、ReactやNext.jsなどの普及により、JavaScriptを多用した動的な画面を正確にテストできるツールが求められています。
その中の代表的なものの1つに、Playwrightというツールがあります。
今回の記事では、Playwrightの基本的な特徴やメリット・デメリット、SeleniumやCypressとの比較から、インストール方法、Trace Viewerなどの主要機能、Next.jsでの実践、AIエージェント連携(MCP)まで幅広く解説していきます。
Playwrightとは
Playwrightは、Microsoftが開発しているオープンソースの自動化フレームワークです。
Chrome系ブラウザだけでなくFirefoxやSafari系ブラウザにも対応しており、E2E(End to End)テストやWebスクレイピングの自動操作ツールの作成など、幅広い用途で利用されています。
さらに、2025年以降はAIエージェント向けのMCP(Model Context Protocol)との連携にも注目が集まっており、AIがブラウザを操作するための基盤技術としても活用され始めています。
なお、PlaywrightはGitHub上で公開されているオープンソースソフトウェアであり、ライセンス費用をかけずに導入できる点も、採用のハードルを下げている理由の1つです。
Playwrightでできること
Playwrightは、上述した3種類のブラウザエンジンを単一APIで操作できるツールです。
ブラウザに対して人間が行うような操作を、コードで再現できるため、以下のようなことが可能です。
- ボタンをクリックする
- フォームへ入力する
- スクロールする
- スクリーンショットを撮る
- PDFを生成する
- ファイルをダウンロードする
こうした基本操作に加えて、画像や書類をアップロードするフォームの検証や、APIの応答をテスト用に差し替えたり、通信エラーをわざと発生させたりといった、ネットワーク通信を監視・制御する高度な操作にも対応しています。
また、これらの操作は組み合わせて使うことができるため、実際のユーザーがWebサイトを利用する一連の流れ(例えば「ログイン→商品をカートに入れる→購入する」といった操作)を、そのままテストコードとして再現することが可能です。
こうして書いたテストコードは、人が毎回手作業でクリックや入力を繰り返すことなく、何度でも同じ条件で実行できます。
そのため、リリース前の動作確認や、機能追加のたびに発生しがちな「意図しない箇所が壊れていないか」を確認するリグレッションテストにも活用されています。
Playwrightの特徴
自動テストにおいて特に厄介な問題の1つが、Flaky Test(不安定なテスト)です。
これは、テスト対象の要素がまだ画面に表示されていないタイミングで操作を行おうとしてしまい、実行するたびに成功したり失敗したりする現象を指します。
従来は、この問題を避けるためにsleep(1000) のような固定の待機時間を挟む方法がよく使われてきましたが、環境によって待ち時間が長すぎたり短すぎたりするため、根本的な解決にはなりませんでした。
また、Playwrightには、Auto-wait(自動待機)と呼ばれる仕組みが標準で備わっています。
要素がクリック可能になる、テキストが表示される、アニメーションが完了するといった「操作可能な状態」になるまでを自動で判定して待ってくれるため、開発者が待機時間を細かく調整する必要がありません。
さらに、Playwrightは標準で並列実行機能が備わっており、以下のように複数のワーカープロセスで同時にテストを実行できます。
npx playwright test --workers=4Playwrightのメリット
Playwrightには、主に2つのメリットがあります。
①既存プロジェクトに導入しやすい
TypeScriptやJavaScriptだけでなく、Python・Java・C# にも対応しているため、既存プロジェクトへ導入しやすいです。
すでに開発環境がPythonやJavaを使用している場合でも、新しく別の言語を学び直す必要がなく、使い慣れた言語のままテスト自動化を始められます。
②テストが安定し、実行も速くなる
Auto-wait(自動待機)や並列実行といった仕組みは、実務上のメリットにもなります。
Flaky Testが減ることで、テストに失敗するたびに「アプリのバグなのか、テストコードの書き方が悪いのか」を調査する手間が減り、本来の作業に集中できます。
さらに、並列実行によってテスト全体の実行時間も短縮されるため、CI環境でのフィードバックサイクルが早まり、リリースまでのスピードを落とさずに品質を担保しやすくなります。
Playwrightのデメリット・注意点
Playwrightを導入・運用する際には、知っておくべき注意点が2つあります。
①プログラミングスキルが必要になる
Playwrightはコードを書いてテストを組み立てるツールであるため、ノーコード型のテスト自動化ツールと比べると、一定のプログラミングスキルが必要になります。
JavaScriptやTypeScriptといった言語に不慣れなメンバーがいるチームでは、最初の学習コストがかかる点は理解しておく必要があります。
②UI変更に伴うテストコードのメンテナンスが必要になる
テスト対象のWebサイトやアプリのUIが変更されると、それに合わせてテストコードのメンテナンスが必要になります。
特に、CSSのクラス名やHTML構造に依存したセレクタを使っている場合、デザイン変更のたびにテストが失敗し、修正の手間が発生しがちです。
とはいえ、これらは、環境設定やテスト設計の工夫、後述するLocatorやTrace Viewerを活用することによって、十分にカバーできる範囲のものです。
総合的な使いやすさや将来性を考えると、テスト自動化ツールとして有力な選択肢であることに変わりはありません。
Playwrightと他ツール(Cypress/Selenium)の違いと選定基準
PlaywrightとSelenium・Cypressの比較
代表的な自動化ツールの中に、同じくオープンソースである Selenium と Cypressがあります。
それぞれの特徴とPlaywrightとの違いについて確認してみましょう。
| 項目 | Playwright | Selenium | Cypress |
|---|---|---|---|
| 通信方式 | ブラウザと直接通信 | WebDriver経由 | ブラウザ内でJS実行 |
| 実行速度 | 速い | オーバーヘッドがあり比較的遅い | 速い |
| 対応ブラウザ | Chromium・Firefox・WebKit | 主要ブラウザ全般 | 主にChromiumベース |
| 複数タブ・複数ブラウザ | 得意 | 対応可能 | 制約あり |
| 対応言語 | TypeScript・JavaScript・Python・Java・C# | 多言語対応 | JavaScript・TypeScriptが中心 |
| 標準の並列実行 | あり(--workersオプション) |
別途設定が必要 | 有償プランで強化 |
ここからは、特に実行速度に影響する「通信方式の違い」について、それぞれの仕組みを 詳しく見ていきます。
【Selenium】
Seleniumは、WebDriverという標準プロトコルを利用しています。
以下のように複数の通信を経由するため、比較的オーバーヘッドが大きい点が挙げられます。
テストコード
↓
WebDriver
↓
ブラウザ
一方Playwrightは、以下の構成で直接通信するため、高速に動作するのが特徴です。
テストコード
↓
ブラウザプロトコル
↓
ブラウザ
また、Playwright Testには標準で並列実行機能があるため、以下のように複数のワーカープロセスで同時実行することも可能です。
npx playwright test --workers=4【Cypress】
Cypressは、ブラウザ内部でJavaScriptを実行する方式を採用しています。
デバッグ性に優れる一方、複数タブや複数ブラウザの扱いには制約がかかります。
一方、Playwrightは複数ページや複数ブラウザも自然に扱うことが可能です。
プロジェクトの言語スタックや目的に応じたツールの選び方
プロジェクトの環境や目的に応じたおすすめツールの一例は以下のとおりです。
- 既存のJava資産を活かしたい … Selenium
- React中心に開発 … Cypress
- Next.jsを使用 … Playwright
- Pythonスクレイピング … Playwright
- AIエージェント連携 … Playwright
これらの選定基準に共通しているのは、既存の資産や得意分野を活かせるかどうかという視点です。
特にPlaywrightは対応言語の幅広さとAIエージェント連携という新しい強みを持つため、技術スタックを問わず選ばれやすいツールになっています。
現在では、新規プロジェクトを始める場合にPlaywrightを第一候補にするケースが増えています。
Playwrightのインストールと初期セットアップ
Playwrightをインストールする前に、以下の環境を準備しておきましょう。
- Node.js(バージョン18以上、最新のLTS版を推奨)
- 対応OS:Windows、macOS、Linux
- 必要なディスク容量:ブラウザのダウンロードを含めて約500MB〜1GB程度
Node.jsがすでにインストールされているかは、ターミナルで以下のコマンドを実行することで確認できます。
node -vバージョン番号(例:v20.11.0)が表示されればインストール済みです。
表示されない場合は、Node.js公式サイトから事前にインストールしてください。
Playwrightのインストール方法
Node.js環境の場合、以下のコマンドを実行してインストールできます。
npm init playwright@latestコマンド実行後、対話形式で以下の項目を質問されるので、任意の内容で設定してください。
迷った場合は、以下の回答を参考にしてください。
・TypeScript かJavaScriptの選択
→迷ったらTypeScriptがおすすめです。
型のサポートにより、コード補完やエラーの早期発見がしやすくなります。
・テストフォルダ名
→特にこだわりがなければ、デフォルトのtestsのままで問題ありません。
・GitHub Actions workflowの追加の有無
→CI環境でテストを自動実行したい場合はYesを選択します。
まずはローカルで試したいだけの場合はNoでも構いません。
・ブラウザインストールの有無
→Yesを選択すると、この後に紹介するnpx playwright installを別途実行する手間が省けます。
既存プロジェクトの場合は、以下のコマンドでもインストール可能です。
# 既存プロジェクトでのインストール
npm install -D @playwright/test
# ブラウザのインストール
npx playwright installPythonの場合は、以下のコマンドで実行できます。
# playwrightのインストール
pip install playwright
# ブラウザのインストール
playwright installcodegenで操作を自動でコード化する
Playwrightの便利機能の1つに、codegenがあります。
codegenは、ブラウザで行われた操作を自動で記録し、それを元にテストコードを生成してくれる機能のことを言います。
以下のコマンドを実行することで、codegenを使用できます。
npx playwright codegen <URL>記録時は、以下のようなブラウザ操作を自動で記録します。
- クリック
- ボタン押下
- テキスト入力
- ページ遷移
以下は、実際に生成されるコードの一例です。
await page.goto("https://example.com");
await page.get_by_label("移動").click();
await page.get_by_label("検索").fill("playwright");変換可能な言語は以下の通りとなります。
- TypeScript
- JavaScript
- Python
- Java
- C#
テストの雛形作成や、スクレイピング開発の効率化などに役立つ便利な機能です。
特に、初めて触るWebサイトの操作をコード化したいときや、複雑なフォーム入力の手順を 素早くコードに落としたいときに重宝します。
生成されたコードはそのまま使うだけでなく、 実際のテストファイルに組み込む際の下書きとして活用し、アサーション(expect)を 追加していく使い方が実務では一般的です。
Playwrightの主要機能
Playwrightには、テストの安定性や速度だけでなく、開発・運用を助けるための便利な機能も数多く備わっています。
ここでは、その中でも特に実務でよく使われる「Trace Viewer」と「モバイルデバイスのエミュレーション」という2つの機能を紹介します。
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つのテストコードでカバーできます。
Playwrightを用いたNext.jsのE2EテストとPythonスクレイピング
Next.jsでUIテストを書いてみる
playwrightでは、下記のコマンドを実行することで UI Mode を立ち上げることができます。
npx playwright test --uiUI Modeが起動すると、Playwrightの全てのテストファイルのリストが表示され、下記の単位でテストを実行することができます。
- 全テストファイル
- 単一テストファイル
- テストグループ
- 単一テスト
各テストは、以下の構文で定義可能です。
test("内容説明", async ({ page }) => {...})test("ログイン", async ({ page }) => {
await page.goto("https://example.com");
await page.getByRole("button", {
name: "Login",
}).click();
await expect(page).toHaveURL("/login");
});Playwrightでは、Locatorと呼ばれる要素を取得するための仕組みが用意されています。
CSSセレクタのようにHTMLの構造やクラス名を直接指定する方法だと、デザインやマークアップ が変わるたびにテストが壊れてしまいます。
Playwrightでは、ユーザーが画面を見るときと 同じ視点で要素を探せる「Locator」という仕組みが用意されており、以下のような取得方法 があります。
getByRole()… ロールによる検索getByText()… テキストによる検索getByLabel()… ラベルテキストによる検索getByPlaceholder()… プレースホルダーによる検索getByAltText()… 代替テキストによる検索getByTitle()… タイトル属性による検索getByTestId()… テストIDによる検索
この中でも特にgetByRole()は、ボタンやリンクといった要素の役割で探すため、Playwright公式でも推奨されている最も安定した取得方法です。
迷ったときは、まずgetByRole()で 探せないかを検討し、難しい場合に他の方法を組み合わせるとよいでしょう。
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へ機密情報を不用意に渡さない
また、本番環境への自動操作を行なう場合は、十分な検証を行った上で導入するよう注意しましょう。
まとめ
Playwrightは、E2Eテストからスクレイピングまで幅広く活用できる便利なツールです。
また、自動化ツールとしてだけでなく、AIのブラウザ操作基盤としても重要性を増していく技術の一つとも言えるでしょう。