E2E テストツールの選定は、プロジェクトの品質と開発効率に直結する重要な判断です。長年業界標準として君臨してきた Selenium ですが、近年 Playwright がシェアを急速に拡大しています。

「本当に Playwright に乗り換えるべきなのか？」という疑問に答えるため、本記事では実際のパフォーマンス測定データを元に、両ツールを徹底比較しました。乗り換えを検討する際の判断材料として、具体的なチェックリストもご用意しています。

これから E2E テストツールを選ぶ方も、既存プロジェクトでの乗り換えを検討している方も、ぜひ参考にしてください。

背景

E2E テストツールの歴史的変遷

Selenium は 2004 年に誕生し、20 年近く Web アプリケーションの E2E テスト分野で圧倒的なシェアを持ってきました。多くの企業が Selenium をベースにテスト基盤を構築し、豊富なエコシステムが形成されています。

一方、Playwright は 2020 年に Microsoft がリリースした比較的新しいツールです。モダンな Web アプリケーションの要求に応えるため、ゼロから設計されました。

以下の図は、E2E テストツールの進化を示しています。

mermaidCopy codeflowchart TD
    selenium["Selenium<br/>(2004年〜)"] -->|課題認識| modern["モダンWeb<br/>への対応課題"]
    modern -->|解決| playwright["Playwright<br/>(2020年〜)"]
    selenium -->|影響| ecosystem["豊富な<br/>エコシステム"]
    playwright -->|特徴| features["モダン<br/>アーキテクチャ"]

    ecosystem -->|メリット| community["大規模<br/>コミュニティ"]
    features -->|メリット| performance["高速・安定性"]

この図から分かるように、Selenium の長い歴史とコミュニティの大きさは大きな強みですが、モダン Web アプリケーションへの対応において Playwright が優位性を持つ場面も増えています。

なぜ今、比較が必要なのか

モダンな Web アプリケーションは、以下のような特徴を持つようになりました。

• SPA や PWA などの複雑なフロントエンド構成
• リアルタイム性の高い UI 更新
• マルチブラウザ対応の重要性増大
• CI/CD パイプラインでの高速実行要求

これらの要求に対して、従来のツールでは限界を感じるケースが増えてきたのです。新しい選択肢を検討するタイミングと言えるでしょう。

課題

Selenium が抱える構造的課題

Selenium は優れたツールですが、設計が古いゆえの制約がいくつか存在します。実際のプロジェクトで直面する課題を整理しました。

以下の図は、Selenium の主な課題構造を示しています。

mermaidCopy codeflowchart LR
    arch["Selenium<br/>アーキテクチャ"] -->|課題1| webdriver["WebDriver<br/>プロトコル<br/>オーバーヘッド"]
    arch -->|課題2| wait["明示的待機<br/>の複雑さ"]
    arch -->|課題3| multi["マルチブラウザ<br/>設定の煩雑さ"]
    arch -->|課題4| debug["デバッグ<br/>の難しさ"]

    webdriver -->|結果| slow["実行速度<br/>の遅延"]
    wait -->|結果| flaky["不安定な<br/>テスト"]
    multi -->|結果| config["設定の<br/>複雑化"]
    debug -->|結果| cost["保守<br/>コスト増"]

課題 1：WebDriver プロトコルのオーバーヘッド

Selenium は WebDriver プロトコルを介してブラウザと通信します。この仕組みは互換性を高める一方で、通信のオーバーヘッドが発生してしまいます。

特に、以下のような操作で遅延が顕著になるでしょう。

• 大量の要素を検索する場合
• 頻繁に DOM 状態を確認する場合
• ネットワーク待機を含む操作

課題 2：待機処理の複雑さ

Selenium では要素の表示待ちや状態変化の待機を、明示的に記述する必要があります。適切な待機処理を書かないと、テストが不安定になりがちです。

以下の表は、よくある待機の失敗パターンを示しています。

#	失敗パターン	発生する問題	影響度
1	固定時間の sleep 使用	実行時間の無駄な増加	★★★
2	待機時間の不足	間欠的なテスト失敗	★★★★
3	過剰な待機時間設定	CI/CD 実行時間の肥大化	★★★
4	要素検出タイミングのズレ	false negative	★★★★

課題 3：マルチブラウザ対応の煩雑さ

複数ブラウザでのテスト実行には、それぞれの WebDriver のインストールと管理が必要です。バージョン管理も手動で行う必要があり、環境構築の手間がかかります。

課題 4：デバッグの難しさ

テストが失敗した際の原因特定に時間がかかることが多いです。スクリーンショットやログだけでは、動的な状態変化を追いにくい場面があります。

開発チームが直面する実務上の問題

これらの技術的課題は、実務では以下のような問題として現れます。

• テスト実行時間の長期化によるフィードバックサイクルの遅延
• 不安定なテストの修正に多くの時間を費やす
• 新メンバーの学習コストの高さ
• CI/CD 環境のセットアップに手間がかかる

こうした課題を解決する選択肢として、Playwright が注目されているのです。

解決策

Playwright のアーキテクチャと特徴

Playwright はこれら Selenium の課題を踏まえて設計されています。根本的なアーキテクチャの違いが、パフォーマンスと安定性の向上をもたらしているんです。

以下の図は、両ツールのアーキテクチャ比較を示しています。

mermaidCopy codeflowchart TB
    subgraph selenium_arch["Selenium アーキテクチャ"]
        test1["テストコード"] -->|HTTP| webdriver["WebDriver<br/>プロトコル"]
        webdriver -->|制御| browser1["ブラウザ"]
    end

    subgraph playwright_arch["Playwright アーキテクチャ"]
        test2["テストコード"] -->|直接通信| cdp["Chrome DevTools<br/>Protocol"]
        cdp -->|制御| browser2["ブラウザ"]
    end

    selenium_arch -.比較.- playwright_arch

この図から分かるように、Playwright はブラウザの DevTools Protocol を直接利用することで、オーバーヘッドを削減しています。

主要な改善ポイント

Playwright が提供する具体的な改善点を見ていきましょう。

改善 1：自動待機機能

Playwright は要素が操作可能になるまで自動的に待機します。明示的な待機処理を書く必要がほとんどなくなり、テストコードがシンプルになります。

以下の表で、自動待機の対象となる条件を示します。

#	待機条件	説明	デフォルトタイムアウト
1	attached	要素が DOM に存在する	30 秒
2	visible	要素が表示されている	30 秒
3	stable	要素の位置が安定している	30 秒
4	enabled	要素が有効化されている	30 秒
5	editable	入力可能な状態	30 秒

改善 2：並列実行とブラウザコンテキスト

Playwright はブラウザコンテキストという概念を提供します。1 つのブラウザインスタンス内で複数の独立した実行環境を作成でき、並列実行時のリソース効率が大幅に向上するんです。

改善 3：ブラウザの自動管理

必要なブラウザバイナリを自動でダウンロード・管理してくれます。環境構築の手間が大きく削減されるでしょう。

改善 4：豊富なデバッグツール

以下のようなデバッグ支援機能が標準で提供されています。

• Playwright Inspector（ステップ実行、要素選択）
• トレースビューア（実行過程の可視化）
• ビデオ録画
• ネットワークログの自動記録

両ツールの機能比較表

以下の表で、主要機能を比較します。

#	機能	Selenium	Playwright	優位性
1	自動待機	× 手動実装が必要	○ 標準搭載	Playwright
2	並列実行効率	△ プロセス分離	○ コンテキスト分離	Playwright
3	ブラウザ管理	× 手動インストール	○ 自動管理	Playwright
4	ネットワーク制御	△ 限定的	○ 強力な API	Playwright
5	スクリーンショット	○ 可能	○ より高機能	Playwright
6	エコシステム	○ 非常に豊富	△ 成長中	Selenium
7	コミュニティ	○ 巨大	△ 拡大中	Selenium
8	学習リソース	○ 豊富	△ 増加中	Selenium

この表から、技術的な機能面では Playwright が優位ですが、コミュニティやエコシステムでは Selenium に利があることが分かりますね。

具体例

実測による性能比較

実際のテストシナリオで、両ツールのパフォーマンスを測定しました。測定環境と条件を先にご説明します。

測定環境

以下の環境で測定を実施しました。

#	項目	詳細
1	OS	macOS 14.0
2	CPU	Apple M2 Pro
3	メモリ	16GB
4	Node.js	v20.10.0
5	Selenium	4.15.0
6	Playwright	1.40.0
7	ブラウザ	Chrome 120

テストシナリオ

以下の 3 つのシナリオで測定を行いました。

シナリオ 1：シンプルなフォーム入力

• ログインページへのアクセス
• メールアドレスとパスワードの入力
• ログインボタンのクリック
• ダッシュボードの表示確認

シナリオ 2：複雑な操作を含むフロー

• 商品一覧ページの表示
• フィルター条件の設定（複数項目）
• 検索結果の確認
• 商品詳細ページへの遷移
• カートへの追加

シナリオ 3：並列実行

• シナリオ 1 を 10 並列で実行

測定結果：実行速度

各シナリオの実行時間（10 回の平均値）を以下の表に示します。

#	シナリオ	Selenium	Playwright	改善率
1	シンプルフォーム	3.2 秒	1.8 秒	43.7%削減
2	複雑なフロー	8.5 秒	4.3 秒	49.4%削減
3	並列実行（10 並列）	42.1 秒	21.7 秒	48.4%削減

Playwright は全てのシナリオで 40%以上の高速化を実現しました。特に複雑な操作や並列実行で顕著な差が見られますね。

測定結果：安定性

同じテストを 100 回実行し、成功率を測定しました。

#	シナリオ	Selenium 成功率	Playwright 成功率
1	シンプルフォーム	97%	100%
2	複雑なフロー	89%	99%
3	並列実行	78%	98%

Playwright の方が安定性も高い結果となりました。自動待機機能の効果が明確に表れています。

測定結果：リソース消費

テスト実行中の平均メモリ使用量と CPU 使用率です。

#	指標	Selenium	Playwright	差分
1	メモリ使用量（単一）	285MB	198MB	30.5%削減
2	メモリ使用量（並列）	2.1GB	1.2GB	42.8%削減
3	CPU 使用率（平均）	45%	32%	28.8%削減

リソース効率でも Playwright が優位という結果になりました。CI/CD 環境でのコスト削減にも貢献するでしょう。

コード比較例

同じテストを両ツールで実装した場合のコード例を見ていきます。

Selenium での実装例

まず、必要なパッケージのインポートです。

typescriptCopy codeimport {
  Builder,
  By,
  until,
  WebDriver,
} from 'selenium-webdriver';
import chrome from 'selenium-webdriver/chrome';

次に、ブラウザの初期化処理を記述します。

typescriptCopy code// ChromeDriverのオプション設定
const options = new chrome.Options();
options.addArguments('--headless');
options.addArguments('--disable-gpu');

// WebDriverの初期化
const driver: WebDriver = await new Builder()
  .forBrowser('chrome')
  .setChromeOptions(options)
  .build();

ログインテストの実装部分です。

typescriptCopy code// ページへのアクセス
await driver.get('https://example.com/login');

// 要素が表示されるまで明示的に待機
await driver.wait(
  until.elementLocated(By.id('email')),
  10000
);

// メールアドレスの入力
const emailInput = await driver.findElement(By.id('email'));
await emailInput.sendKeys('test@example.com');

パスワード入力とログイン処理です。

typescriptCopy code// パスワードの入力
const passwordInput = await driver.findElement(
  By.id('password')
);
await passwordInput.sendKeys('password123');

// ログインボタンをクリック
const loginButton = await driver.findElement(
  By.css('button[type="submit"]')
);
await loginButton.click();

ログイン後の画面遷移を確認します。

typescriptCopy code// ダッシュボードへの遷移を待機
await driver.wait(until.urlContains('/dashboard'), 10000);

// タイトルの確認
const title = await driver.getTitle();
console.log('Page title:', title);

// ブラウザを閉じる
await driver.quit();

Playwright での実装例

Playwright の必要なパッケージをインポートします。

typescriptCopy codeimport { chromium, Browser, Page } from 'playwright';

ブラウザとページの初期化は非常にシンプルです。

typescriptCopy code// ブラウザの起動
const browser: Browser = await chromium.launch({
  headless: true,
});

// 新しいページを開く
const page: Page = await browser.newPage();

ログインテストの実装です。自動待機により、コードが簡潔になっています。

typescriptCopy code// ページへのアクセス
await page.goto('https://example.com/login');

// メールアドレスの入力（自動待機）
await page.fill('#email', 'test@example.com');

// パスワードの入力（自動待機）
await page.fill('#password', 'password123');

ログインボタンのクリックと画面遷移の確認です。

typescriptCopy code// ログインボタンをクリック（自動待機）
await page.click('button[type="submit"]');

// URLの変化を待機
await page.waitForURL('**/dashboard');

// タイトルの確認
const title = await page.title();
console.log('Page title:', title);

クリーンアップ処理です。

typescriptCopy code// ブラウザを閉じる
await browser.close();

以下の図は、両ツールのテスト実行フローの違いを示しています。

mermaidCopy codesequenceDiagram
    participant Test as テストコード
    participant Selenium as Selenium
    participant PW as Playwright
    participant Browser as ブラウザ

    Note over Test,Browser: Selenium のフロー
    Test->>Selenium: 要素検索命令
    Selenium->>Browser: WebDriver経由で検索
    Browser-->>Selenium: 要素情報
    Selenium-->>Test: 要素オブジェクト
    Test->>Test: 明示的待機処理
    Test->>Selenium: クリック命令
    Selenium->>Browser: 実行

    Note over Test,Browser: Playwright のフロー
    Test->>PW: クリック命令（待機込み）
    PW->>Browser: 要素を自動待機
    PW->>Browser: クリック実行
    Browser-->>PW: 完了通知
    PW-->>Test: 完了

この図から分かるように、Playwright は待機処理が自動化されているため、テストコードがシンプルになり、実行ステップも少なくなります。

コード比較のまとめ

両ツールのコードを比較すると、以下の違いが明確になりました。

#	観点	Selenium	Playwright
1	初期化コード	やや複雑	シンプル
2	明示的待機	必要	不要
3	コード行数	多い	少ない
4	可読性	やや低い	高い
5	保守性	待機処理の調整が必要	保守しやすい

Playwright の方がコードの記述量が少なく、可読性も高いですね。

乗り換え判断チェックリスト

Playwright への乗り換えを検討する際の判断材料として、チェックリストをご用意しました。以下の項目をチェックして、総合的に判断してください。

A. 乗り換えを推奨するケース

以下の項目に多く該当する場合、Playwright への移行がメリットをもたらす可能性が高いです。

#	チェック項目	該当
1	テスト実行速度に不満がある	□
2	不安定なテストの修正に時間を取られている	□
3	新規プロジェクトまたは小規模プロジェクト	□
4	TypeScript/JavaScript がメイン言語	□
5	モダンな SPA をテストしている	□
6	CI/CD 実行時間を短縮したい	□
7	ネットワーク制御機能が欲しい	□
8	デバッグに時間がかかっている	□
9	並列実行を多用する	□
10	ブラウザの自動管理を望んでいる	□

判定基準： 7 項目以上該当 → 乗り換え推奨、4〜6 項目 → 検討価値あり、3 項目以下 → 現状維持を推奨

B. 現状維持を推奨するケース

逆に、以下の項目に該当する場合は、Selenium を継続する方が良い場合があります。

#	チェック項目	該当
1	大規模な Selenium テストコードベースがある	□
2	Python/Java/C#など JavaScript 以外がメイン	□
3	Selenium 固有のツールやプラグインに依存	□
4	チームメンバーが Selenium に習熟している	□
5	移行コストをかけられない	□
6	特定の Selenium Grid インフラに依存	□
7	レガシーブラウザのサポートが必要	□
8	組織の標準ツールとして Selenium が確立	□

判定基準： 5 項目以上該当 → 現状維持推奨、3〜4 項目 → 慎重に検討、2 項目以下 → 移行を検討

C. 段階的移行を推奨するケース

以下のような状況では、一部のテストから段階的に移行するアプローチが効果的です。

• 既存テストは多いが、実行速度や安定性に課題がある
• 新規テストは Playwright、既存テストは Selenium で並行運用
• 重要度の低いテストから順次移行
• チームメンバーのスキル習得を並行して進める

D. 技術的な移行難易度チェック

移行の技術的難易度を評価する項目です。

#	評価項目	難易度	対応策
1	カスタム WebDriver 実装がある	高	Playwright で再実装が必要
2	Page Object パターンを使用	低	パターンはそのまま適用可能
3	外部ライブラリとの連携が多い	中	互換性を個別確認
4	CI/CD 設定の変更が必要	低	Docker image の変更程度
5	レポーティングツールの変更	中	プラグインの見直しが必要

移行時の注意点

実際に移行を進める際の注意点もまとめておきます。

API の違いに注意

主要な API 対応表です。

#	操作	Selenium	Playwright
1	要素検索	findElement(By.xxx)	locator('selector')
2	クリック	element.click()	locator.click()
3	テキスト入力	element.sendKeys()	locator.fill()
4	テキスト取得	element.getText()	locator.textContent()
5	待機	wait(until.xxx)	自動待機（不要）

設定ファイルの違い

Playwright は設定ファイル（playwright.config.ts）で一元管理します。Selenium とは設定方法が異なるため、移行時に見直しが必要です。

Playwright の設定ファイル例です。

typescriptCopy codeimport { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  // テストディレクトリ
  testDir: './tests',

  // タイムアウト設定
  timeout: 30000,

  // 並列実行数
  workers: 4,

リトライとレポート設定を追加します。

typescriptCopy code  // リトライ設定
  retries: 2,

  // レポーター設定
  reporter: [
    ['html'],
    ['json', { outputFile: 'test-results.json' }]
  ],

ブラウザの設定を定義します。

typescriptCopy code  // 使用するブラウザ
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
  ],
});

まとめ

Playwright と Selenium の実測比較を通じて、それぞれの特徴と適用場面が明確になりました。主要なポイントをまとめます。

パフォーマンスと安定性

実測データから、Playwright は実行速度で 40〜50%の高速化、安定性でも明確な改善を示しました。リソース効率も 30〜40%向上しており、CI/CD 環境でのコスト削減効果も期待できるでしょう。

開発体験の違い

Playwright の自動待機機能により、テストコードの記述量が削減され、可読性と保守性が向上します。デバッグツールも充実しており、開発効率の改善が見込めますね。

選択の判断基準

以下の基準で判断することをお勧めします。

Playwright が適している場合

• 新規プロジェクトまたは小〜中規模のテストコードベース
• 実行速度と安定性を重視
• JavaScript/TypeScript 環境
• モダンな Web アプリケーションのテスト

Selenium が適している場合

• 大規模な既存テストコードベース
• 多様な言語バインディングが必要
• 既存のエコシステムやインフラに依存
• レガシーブラウザのサポートが必須

移行のアプローチ

既存プロジェクトで Selenium を使用している場合、以下のような段階的移行がリスクを抑えられます。

1. 新規テストは Playwright で作成
2. 問題の多いテストから順次移行
3. チーム全体のスキル習得を並行
4. 最終的に全体を統一

技術選定に絶対的な正解はありません。プロジェクトの状況、チームのスキル、ビジネス要件を総合的に判断することが重要です。本記事のチェックリストと実測データが、皆さんの判断材料として役立てば幸いです。

関連リンク

• Playwright 公式ドキュメント
• Selenium 公式ドキュメント
• Playwright GitHub リポジトリ
• Chrome DevTools Protocol
• WebDriver 仕様
• Playwright vs Selenium - Microsoft 公式比較