WebアプリやWebサービスを開発・運用していると、「Chromeでは問題なく動いたのに、iPhoneやMacのSafari（WebKit）で画面が動かなかった」「自動テストを導入したものの、通信のタイミング次第で毎回ランダムにテストが失敗してしまい、結局メンテナンスされなくなった…」といった悩みに直面することが少なくありません。

こうした従来のブラウザ自動操作・E2E（End-to-End）テストにおける長年の課題を解消する存在として、世界中の開発現場で急速に標準ツールへと定着しているのが、Microsoft製のオープンソースフレームワーク「Playwright（プレイライト）」です。

本記事では、Playwrightが誕生した歴史的背景や従来ツール（Selenium・Puppeteer・Cypress）との違いから、最大の特長である「auto-wait（自動待機）」の仕組み、ブラウザを操作するだけでテストコードを生成できる便利機能、初期セットアップ手順まで丁寧に分かりやすく解説します。

そもそも「E2E（End-to-End）テスト」とは？

プログラムの個別の関数を検証する「単体テスト（ユニットテスト）」とは異なり、実際のユーザーと同じようにブラウザを立ち上げ、「ログイン画面でIDを入力 → 商品を検索してカートに追加 → 決済ボタンを押して完了画面が表示される」というシステムの端から端（End-to-End）までの通し動作をまるごと自動検証するテスト手法のことです。

Selenium（2006年〜）：クロスブラウザ対応の老舗と「Flakyテスト」の悩み

長年にわたりブラウザ自動化の代名詞として使われてきた定番ツールです。多様な言語とブラウザに対応している一方、テストコードとブラウザの間に「WebDriver」という中継プログラムを挟んでHTTP通信で命令を送る構造のため、ブラウザのバージョンに合わせたドライバ管理の手間や実行速度の遅さが課題になりがちでした。また、非同期で動く現代のWebアプリではタイミングずれによって「同じテストなのに成功したり失敗したりする不安定なテスト（Flaky test）」に悩まされるケースが多くありました。

Puppeteer（2018年〜）：軽快な操作性とブラウザ限定の壁

GoogleのChrome DevToolsチームが開発したNode.js向けライブラリです。ブラウザの開発者ツール用プロトコル（CDP）を通じて直接ブラウザを操るため、Seleniumよりも高速でセットアップも手軽になりました。しかし、原則としてChrome（Chromium）系に特化した設計であり（近年Firefox対応も進みましたがSafari相当のWebKitには非対応）、また単体のブラウザ操作ライブラリであるため、テストランナーやアサーション機能はJestなどを別途組み合わせる必要がありました。

Cypress（2018年〜）：優れた開発者体験とアーキテクチャ上の制約

「開発者にとっての書きやすさ・デバッグのしやすさ（DX）」を重視して大きな人気を集めたE2Eテストツールです。GUI上でテスト経過を見ながら快適に開発できる反面、ブラウザ内部のJavaScriptと同じ実行ループ内で動く独自アーキテクチャを採用していたため、複数タブや複数ウィンドウをまたぐ操作、iframe内の操作、Safari（WebKit）での検証などに苦手分野がありました。

技術的な裏側：Playwrightが高速に動く2つの理由

Playwrightは操作のたびにHTTP通信を繋ぎ直すのではなく、WebSocketによる1本の常時接続パイプを使ってブラウザエンジンと双方向に高速通信します。さらに、テスト1件ごとに重いブラウザアプリ自体を再起動するのではなく、1つのブラウザプロセスの中に「シークレットウィンドウ」のような独立空間（BrowserContext）を瞬時に作っては破棄するため、Cookieなどが他テストと混ざらず圧倒的なスピードで並列実行できます。

• DOMへのアタッチ（Attached）：対象の要素がHTMLのDOMツリー上に存在しているか？
• 画面上の表示状態（Visible）：非表示（display: none など）ではなく、画面に見える大きさを持っているか？
• 座標の安定・アニメ完了（Stable）：スライドインなどのCSSアニメーションが終わり、要素の位置が静止したか？
• イベントの受信可否（Receives Events）：ローディング画面や別のポップアップが上に被さって邪魔をしていないか？
• 有効状態（Enabled）：ボタンや入力欄が disabled（非活性）になっていないか？

コードジェネレーター（codegen）：ブラウザを手動操作するだけでコード自動生成

初めてPlaywrightを触る方が一番驚く機能がコードジェネレーター（codegen）です。以下のコマンドを実行すると、操作用のブラウザとインスペクター画面が同時に立ち上がります。

npx playwright codegen https://example.com

あとは普段通りにマウスでリンクをクリックしたりフォームに文字を入力したりするだけで、横のウィンドウに推奨ロケーター（getByRole など）を使ったTypeScript / Python等のテストコードがリアルタイムで自動出力されます。ゼロからセレクタを調べる手間がなくなり、テスト作成スピードが何倍にも跳ね上がります。

Trace Viewer（トレースビューア）：失敗した全過程を録画タイムラインで振り返り

自分のPCでは通ったテストが、夜間のCI（GitHub Actionsなど）で失敗したとき、「画面が見えないサーバー上で何が起きたのか分からない」と困った経験はないでしょうか。PlaywrightのTrace Viewerを使えば、テスト実行中の全過程を記録したトレースファイルをブラウザ上で開いて調査できます。

npx playwright show-report

• 各クリックや入力の「直前・直後」の画面状態と、どこをクリックしたかを示す赤いポインター
• その瞬間の実際のDOMスナップショット（単なる静止画ではなく、開発者ツールで要素検証が可能！）
• 裏側で通信されたネットワークリクエスト（APIのステータスコードやJSONの中身）とコンソールエラーログ

これらが動画編集ソフトのようなタイムライン上に並ぶため、「ボタンが押せなかったのではなく、直前のAPIが500エラーを返していたんだ！」とひと目で原因を特定できます。

UI Mode（UIモード）：GUI画面でステップ確認もホットリロードも自在

バージョン1.32で追加されたUI Modeは、手元でテストを書きながら動作確認するときにおすすめの対話型実行画面です。

npx playwright test --ui

左側にテスト一覧、右側にタイムトラベル可能なブラウザプレビューが表示され、特定の1件だけを再生したり、ウォッチモード（目のアイコン）をオンにしてエディタでコードを保存するたびに即座に自動再実行（ホットリロード）させたりと、軽快なリズムで開発を進められます。

スクリーンショット・操作動画・トレースの自動保存

設定ファイル（playwright.config.ts）に数行書いておくだけで、「普段はディスク容量を節約し、テストが失敗したときだけ証拠のスクリーンショットや動画を自動で残す」という運用が簡単に組めます。

// playwright.config.ts の設定例
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: 1, // 失敗時に1回リトライする
  use: {
    screenshot: 'only-on-failure', // 失敗時のみスクリーンショットを自動保存
    video: 'retain-on-failure',    // 失敗時のみ操作動画を保持
    trace: 'on-first-retry',       // 初回リトライ時に詳細トレースを記録
  },
});

REST APIテストも同じフレームワークで一元管理できる

Playwrightは画面操作だけでなく、組み込みの request コンテキストを使ってバックエンドのREST APIテストも同じテストファイル内に記述できます。「先にAPIを叩いてテスト用の商品データを素早く登録し、その直後にブラウザ画面を開いて表示を確認する」といったハイブリッドなテストもスムーズに書けます。

import { test, expect } from '@playwright/test';

test('ユーザー取得APIが正しいJSONデータを返すこと', async ({ request }) => {
  const response = await request.get('/api/users/1');
  expect(response.status()).toBe(200);

  const body = await response.json();
  expect(body.name).toBe('Alice');
});

複数タブ操作やログイン認証状態の保存・使い回し（storageState）

別タブで開く外部決済画面やポップアップウィンドウの操作に強いのはもちろん、実務で絶大な威力を発揮するのがログイン状態のファイル保存（storageState）です。
100件のテストがあるとき、毎回ログイン画面でIDとパスワードを入力していると膨大な時間がかかります。最初に1回だけログインしてCookieやLocalStorageの状態をJSONファイルに書き出しておけば、残りのテストはすべて「最初からログイン済みの状態」で一瞬でスタートできます。

// 保存しておいた認証情報（Cookie / LocalStorage）を読み込む
test.use({ storageState: 'playwright/.auth/user.json' });

test('ログイン後のマイページが表示されること', async ({ page }) => {
  await page.goto('/dashboard');
  // ログイン画面の入力ステップを省略して、すぐ本題の検証に入れる！
  await expect(page.getByRole('heading', { name: 'マイページ' })).toBeVisible();
});

Pythonユーザー向け：PythonでPlaywrightを導入する場合

業務自動化やスクレイピング、Django / FastAPIアプリのテストなどでPythonからPlaywrightを使いたい場合も、わずか2ステップで導入できます（playwright codegen もそのまま利用可能です）。

pip install pytest-playwright
playwright install

Playwrightの導入効果が特に大きい場面

• ビジネスに直結する重要導線の通しテスト：「会員登録 → 商品購入 → 決済完了 → マイページ履歴反映」のように複数ページや外部連携をまたぐシナリオ。
• ログイン認証や権限管理が絡む画面：一般ユーザーと管理者アカウントの切り替え、複数タブでの同時操作検証。
• クロスブラウザ・スマホ表示の自動検証：Chrome・Firefox・Safari（WebKit）やモバイル画面サイズでの崩れ・動作不良の早期検知。
• CI/CDパイプラインでのリリース前ゲート：GitHub Actions等と連携し、プルリクエスト時に主要機能が壊れていないかを毎回自動チェックする仕組み。
• ブラウザ業務のRPA化やAIエージェント連携：管理画面への定型データ入力・記事入稿の自動化や、近年注目されているブラウザ操作を自動化するAIエージェント（Playwright MCPサーバーなど）の実行エンジンとしての活用。

他のテストツールに任せた方がよい場面

• 単一の計算関数やバリデーションの細かい分岐テスト：消費税計算や入力文字数チェックの全パターンなどを毎回ブラウザ起動で検証すると非効率です。これらは Vitest や Jest などの高速な単体テスト（ユニットテスト）でミリ秒単位で検証しましょう。
• バックエンド内部のビジネスロジック単体検証：データベース計算やクラス単体のロジックは、各言語の標準テスティングフレームワーク（pytest・JUnit・RSpecなど）で細かく守り、Playwrightは「システム全体を通したユーザー体験の保証」に集中させるのが理想的なバランスです。

本記事のポイント

• Playwright（プレイライト）は、Microsoftが開発したオープンソースのブラウザ自動操作・E2Eテストフレームワーク。
• Chromium・Firefox・WebKit（Safari相当）の主要3大ブラウザエンジンを1つのコードで操作でき、TypeScript / JavaScript / Python / Java / C# に対応している。
• 最大の特長である「auto-wait（自動待機）」により、手動の sleep 記述をなくして高速かつ壊れにくい安定したテストを実現できる。
• ブラウザ操作からコードを自動生成する codegen、失敗原因を録画のように追える Trace Viewer、対話型の UI Mode、さらにAPIテストや認証状態の保存（storageState）まで標準搭載されている。

参考リンク

• Playwright 公式ドキュメント（playwright.dev）
• Playwrightとは何か？誕生の背景から便利な機能までの解説記事（Qiita – @tanaka_taro_JP_KYUSYU）