Playwright とは何か？クロスブラウザ E2E テストの定番と Cypress との使い分け

E2E テストフレームワークって Cypress じゃないの？ Playwright と Cypress、結局どっち使えばいいの？ 「モバイル対応はどう？」 ── 2020 年に登場した Playwright は、急速に Cypress を追い抜き、「現代の E2E テスト」 のデファクトに近い位置を占めるようになりました。

ざっくり言うと、Playwright は ブラウザを自動操作してテストする フレームワークで、3 大エンジン(Chromium / Firefox / WebKit)すべてに対応している のが最大の特徴です。 「Auto-Wait」 でテストの安定性を確保し、「Trace Viewer」 で失敗時のデバッグを劇的に楽にする ── という、「E2E テストが苦手としていた領域」 を構造的に解決した道具です。

この記事では、2026 年 5 月時点の Playwright v1 系をベースに、仕組み・Cypress との違い・典型ユースケース・採用判断軸 を整理します。 仕様は活発に変化しているので、最終確認は 公式ドキュメント を見るのが安全です。

Playwright が解決する E2E の課題

「E2E テストが嫌われる理由」 を整理すると、Playwright の価値が見えます。

「E2E が辛い」 と思っていた理由のかなりの部分が、Playwright で構造的に解消されます。

基本の書き方

最小例で雰囲気をつかみます。

// tests/login.spec.ts
import { test, expect } from '@playwright/test';

test('ユーザーがログインできる', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.getByLabel('メールアドレス').fill('alice@example.com');
  await page.getByLabel('パスワード').fill('password');
  await page.getByRole('button', { name: 'ログイン' }).click();

  await expect(page).toHaveURL('https://example.com/dashboard');
  await expect(page.getByRole('heading', { name: 'ようこそ' })).toBeVisible();
});

# 実行
npx playwright test

# UI モード(GUI で実行 / デバッグ)
npx playwright test --ui

# Trace を見る
npx playwright show-report

# 特定ブラウザだけ
npx playwright test --project=webkit

「ユーザーがやることをそのまま書く」 のが、Playwright のテストの書き味を一言で表す部分です。

Trace Viewer の威力

Playwright の特徴で外せないのが Trace Viewer です。

// playwright.config.ts
export default {
  use: {
    trace: 'retain-on-failure',   // 失敗時だけトレース保存
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
};

これだけで、テストが失敗したときに 動画・各ステップのスクショ・DOM 状態・ネットワークログ・コンソールログ」 がすべてのまとまった `Trace として保存されます。

「E2E テスト最大の敵 = flaky の原因究明」 を、Trace Viewer は構造的に潰しに行きます。

codegen — 録画でテスト生成

Playwright を初めて触る人がまず驚くのが codegen です。

npx playwright codegen https://example.com

これを実行すると、「ブラウザが立ち上がる + 操作録画ウィンドウが開く」。 ブラウザを手で操作 すると、録画ウィンドウに自動でテストコードが書かれていく。

「書き始めの心理障壁が圧倒的に低い」 のが、Playwright の普及を後押しした地味だが重要な特徴です。

Cypress との比較

「Cypress と Playwright、どう違う？」 を表で並べます。

要点は クロスブラウザ重視・大規模・多言語チームなら Playwright、ローカル開発体験の手厚さで残る Cypress という棲み分けです。 2026 年現在は 新規プロジェクトのほぼ全てが Playwright を選ぶ 流れになっています。

どんな案件で効くか

「Playwright を選ぶ価値が出る案件」 を整理します。

「E2E を真面目にやる案件 = Playwright」 がほぼ等号で結べる状態が、2026 年の景色です。

どこで詰まりやすいか

便利な反面、現場で踏みやすい注意点も整理します。

「E2E は維持コストが高い」 という前提を忘れず、「本当に E2E にすべきシナリオに絞る」 のが運用上の鉄則です。

AI 時代の Playwright

AI 連携の文脈でも Playwright の役割は強まっています。

「AI と Web 自動化の交差点」 にいる道具として、Playwright の重要性はテスト用途を超えて拡大しています。

Playwright に関するよくある質問

Q. Cypress から Playwright に移行する価値はありますか？

A. クロスブラウザが必要、flaky に困っている、並列実行をオープンソースで使いたい ならアリ。「既存 Cypress が安定運用できているなら無理に移行しない」 のも合理的です。「新規 / 大規模 / 移行コストが許容できる」 案件ほど Playwright のメリットが効きます。

Q. ブラウザ3つ全部で回すべきですか？

A. プロダクトのユーザー分布次第です。「Chromium だけで日常的に回し、Firefox / WebKit は週次 / リリース前」 のような運用が現実的なケースが多いです。「全部毎回回す」 は CI 時間を3倍に増やすので、目的と相談です。

Q. モバイルテストはできますか？

A. モバイルデバイスのエミュレーションが標準サポートされています。「--project='Mobile Safari'」 や 「devices['iPhone 15']」 のような設定で、「iPhone Safari っぽい挙動」 を再現できます。本物の実機テストには BrowserStack / Sauce Labs」 のサービスを併用。

Q. Playwright と Storybook はどう組み合わせますか？

A. Playwright Component Testを使うと、Storybook の Story をそのまま E2E として走らせることができます。「Story をテストデータとして共有」 する流れで、「Vitest + Storybook + Playwright」 の3点セットがハマる案件で強力です。

Q. CI(GitHub Actions など)でどう設定する？

A. Playwright 公式のセットアップ Actionを使うのが定石です。「browsers をキャッシュ」 「Trace アーティファクトを保存」 「失敗時の動画をアップロード」 などのテンプレが公式に揃っています。

Q. ローカルで遅いです、どうしたらいい？

A. ① 「--project=chromium」 で1ブラウザに絞る、② 「--ui」 で対象テストだけ実行、③ 「storageState」 で認証セットアップを使い回す、④ 「expect(page).toHaveURL(...)」 で正規表現マッチを使う。「どこで時間を食っているか」 を Trace Viewer で確認するのが王道です。

Q. Playwright の学習コストは？

A. 数時間で書き始められるレベルです。「codegen」 でたたき台を作り、「UI モード」 で実行しながら、「公式ドキュメントの API リファレンス」 を辞書として使えば十分。「E2E の本質的な難しさ」 のほうがフレームワーク学習より大きい点も覚えておく価値があります。

参考リンク

• Playwright: 公式
• Playwright Docs: Documentation
• Playwright: GitHub
• Trace Viewer: Docs
• Playwright Component Test: Docs
• Cypress: 公式