Playwright vs Selenium in 2026：本当に比較すべきなのは「ライブラリ」ではなく「運用コスト」

Last updated at 2026-07-08Posted at 2026-07-08

Playwright と Selenium の比較は、テスト自動化の世界では定番のテーマです。

「Selenium はもう古い」
「Playwright のほうが速い」
「いや、Selenium のほうがブラウザ対応が広い」
「AI 時代なら Playwright のほうがいい」

こういう議論はよく見ます。

ただ、実務で本当に重要なのは、そこではありません。

本当に比較すべきなのは、

どちらのライブラリのほうが速くクリックできるか？

ではなく、

どの方法なら、チームが長期的に安定した E2E テストを運用できるか？

です。

この記事では、Playwright と Selenium の違いを整理しつつ、なぜ多くのチームが最終的に「内製フレームワーク」ではなく、Endtest のようなモダンなテスト自動化プラットフォームを検討するようになるのかを説明します。

1. Playwright と Selenium の目的は同じ

Playwright も Selenium も、基本的な目的は同じです。

ブラウザを操作して、ユーザーが実際に行う操作を自動化します。

たとえば：

ログインページを開く
メールアドレスを入力する
パスワードを入力する
ログインボタンをクリックする
ダッシュボードが表示されることを確認する

これは Playwright でもできます。

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

test('user can log in', async ({ page }) => {
  await page.goto('https://app.example.com/login');

  await page.getByLabel('Email').fill('qa@example.com');
  await page.getByLabel('Password').fill(process.env.TEST_PASSWORD!);
  await page.getByRole('button', { name: 'Sign in' }).click();

  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});

Selenium でもできます。

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
wait = WebDriverWait(driver, 20)

driver.get("https://app.example.com/login")

wait.until(EC.visibility_of_element_located((By.NAME, "email"))).send_keys("qa@example.com")
driver.find_element(By.NAME, "password").send_keys("secret")
driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()

wait.until(EC.visibility_of_element_located((By.XPATH, "//h1[normalize-space()='Dashboard']")))

driver.quit()

ここだけを見ると、どちらも大きく変わらないように見えます。

そして実際、最初のテストを書くところまでは、どちらでもそこまで難しくありません。

問題はその後です。

2. テスト自動化で難しいのは「コードを書くこと」ではない

テスト自動化でよくある誤解は、

テストコードが書ければ、テスト自動化はできている

という考え方です。

実際には、テストコードは全体の一部でしかありません。

本当に大変なのは、以下のような部分です。

安定したロケータ設計
適切な wait
テストデータの作成と削除
実ブラウザでのクロスブラウザ実行
Windows / macOS 環境での検証
Safari の実行環境
スクリーンショット、動画、コンソールログ、ネットワークログ
CI/CD 連携
失敗時の調査
レポート
権限管理
監査ログ
チーム全体での運用
メンテナンス

つまり、ライブラリは無料でも、テスト自動化の仕組みは無料ではありません。

Playwright や Selenium は「無料のライブラリ」です。

しかし、安定したテスト基盤を作るには、エンジニアの時間が必要です。

その時間は無料ではありません。

Endtest のブログでも、テスト自動化の ROI を考えるときは、ツール価格だけでなく、フレームワーク構築、保守、実行環境、デバッグ、チーム導入まで含めて考える必要があると説明されています。

参考：
How to Calculate ROI for Test Automation

3. アーキテクチャの違い

Selenium は WebDriver を使います。

テストコードが WebDriver に命令を送り、WebDriver がブラウザドライバを通じてブラウザを操作します。

ざっくり言うと：

テストコード
  ↓
Selenium WebDriver
  ↓
ChromeDriver / GeckoDriver / SafariDriver
  ↓
ブラウザ

Selenium の強みは、長い歴史、幅広い言語対応、ブラウザ対応、そして標準化された仕組みです。

一方、Playwright はよりモダンな設計です。

テストコード
  ↓
Playwright
  ↓
Chromium / Firefox / WebKit

Playwright は、auto-waiting、browser context、trace、test runner などが最初から統合されています。

そのため、開発者体験はかなり良いです。

ただし、ここで大事なのは、

Playwright のほうが新しいから勝ち

でも、

Selenium のほうが歴史があるから勝ち

でもありません。

どちらもブラウザ操作のライブラリです。

E2E テスト基盤全体を提供してくれるわけではありません。

4. 対応言語と対応ブラウザ

Selenium は Java、Python、C#、JavaScript、Ruby など、非常に多くの言語で使われています。

Playwright は TypeScript / JavaScript、Python、Java、.NET に対応しています。

言語だけで考えるなら、Java 中心の組織では Selenium が自然に見えることがあります。

フロントエンドチームが TypeScript 中心なら、Playwright のほうが自然に見えることもあります。

ブラウザ対応については、Selenium は Chrome、Firefox、Edge、Safari などを各ブラウザドライバ経由で操作できます。

Playwright は Chromium、Firefox、WebKit に対応していて、Chrome や Edge の branded browser も扱えます。

ただし、実務では「対応ブラウザ一覧」だけでは足りません。

重要なのは：

そのブラウザはどこで動いているのか？
実ブラウザなのか？
Windows なのか？
macOS なのか？
Safari は本物の macOS 上で動いているのか？
失敗時に動画やログを確認できるのか？
同じ失敗を再現できるのか？

ここが、内製フレームワークで大きなコストになりやすい部分です。

Endtest のブログでも、ブラウザ選定やクロスブラウザ戦略では、単に Chrome だけで確認するのではなく、実際のユーザー環境や Safari / Windows / macOS の差を考える必要があると説明されています。

参考：
What Browsers Should You Test Your Website On?
How Web Browsers Work

5. 「Selenium は古い」「Playwright は速い」という単純な話ではない

Playwright と Selenium の比較では、よく次のような話になります。

Playwright のほうが速い
Selenium は flaky
Selenium はモダンなアプリに向いていない
Playwright なら flaky test が減る

しかし、これはかなり単純化された見方です。

もちろん、Playwright の auto-waiting は便利です。

トレースや test runner も使いやすいです。

ただ、flaky test の原因は、多くの場合ライブラリそのものではありません。

よくある原因は：

不安定なロケータ
固定 sleep
遅い staging 環境
テストデータの衝突
前回のテスト状態に依存している
非同期処理を正しく待っていない
ブラウザ差分を考慮していない
CI 環境だけ遅い
失敗時のログが足りない

つまり、Selenium から Playwright に移行しても、設計が悪ければ flaky test は残ります。

逆に、Selenium でも、ロケータ、wait、テストデータ、実行環境が適切であれば、安定したテストは作れます。

Endtest の記事「How to Stabilize Automated Tests」でも、安定したテストには、信頼できるロケータ、安定した環境、ログ、再現性、適切なテストデータ設計が重要だと整理されています。

参考：
How to Stabilize Automated Tests
Speed Up Test Executions: 5 Practical Ways

6. AI と Playwright / Selenium

最近は、AI を使って Playwright や Selenium のテストコードを生成する流れも増えています。

最初はかなり魅力的に見えます。

AI にテストを書かせる
コードが生成される
実行する
一回成功する

ここまでは簡単です。

しかし、ここにも落とし穴があります。

AI は「コードを増やす」ことが得意です。

でも、コードが増えるほど、メンテナンス対象も増えます。

AI が生成したテストには、次のような問題が起きることがあります。

ロケータが不安定
既存テストと重複している
チームの設計ルールに従っていない
一回だけ成功するが、長期的に壊れやすい
失敗時に人間が理解しづらい
テスト全体の構造がバラバラになる

Playwright には MCP もあります。

AI agent がブラウザとやり取りできるという意味では面白い仕組みです。

ただし、実務では注意が必要です。

MCP 的なアプローチで、AI に毎回ブラウザ状態を解釈させると、トークンを消費します。

そして、多くのケースでは、もっとシンプルな方法で十分です。

たとえば：

スクリーンショットを取得する
page source / HTML を取得する
AI に「この要素に対する安定した selector を提案して」と聞く

これだけで十分なケースは多いです。

重要なのは、

AI を毎回呼ぶことではなく、必要なときだけ使うこと

です。

すでに信頼できるロケータがあるなら、そのロケータを直接使うべきです。

毎回 AI に「ログインボタンはどこですか？」と聞く必要はありません。

それはトークンを消費し、遅くなり、結果も不安定になります。

良い使い方は、次のようなものです。

テスト作成を補助する
壊れたロケータの候補を出す
失敗原因の調査を助ける
自己修復の候補を出す
複雑な画面の理解を補助する

Endtest のブログでも、AI トークンを節約するには、AI をすべてのステップで使うのではなく、必要な場面に限定することが重要だと説明されています。

参考：
How to Reduce AI Token Usage in Test Automation
AI Playwright Testing: Useful Shortcut or Maintenance Trap?
Is AI Test Automation Reliable?
AI Test Automation: Practical Guide

7. 内製フレームワークが失敗しやすい理由

ここが一番重要です。

多くのチームは、最初こう考えます。

Playwright は無料だから、自分たちで作れば安い
Selenium は無料だから、自分たちで作れば安い
エンジニアがいるから内製できる

もちろん、技術的にはできます。

しかし、

作れること

と、

それが最も良い投資であること

は違います。

内製フレームワークでよく起きる問題は、次のようなものです。

最初は速く進む
一部のエンジニアだけが詳しい
QA が自分で直せない
失敗時の調査に時間がかかる
CI の失敗が無視されるようになる
テストが増えるほど実行時間が長くなる
レポートがマネージャーや非エンジニアに伝わらない
ブラウザ環境の維持が面倒になる
ロケータ修正が日常業務になる
作った本人が退職すると誰も触りたがらない

これはライブラリが悪いからではありません。

Playwright も Selenium も、ツールとしては有用です。

問題は、会社がいつの間にか「テスト自動化プラットフォーム」を内製している状態になることです。

本来作るべきプロダクトではなく、テスト基盤そのものにエンジニアリング時間を使い続けることになります。

Endtest の「Scalable Test Automation」や「Test Automation Maturity Model」でも、スクリプトが増えることと、スケーラブルなテスト自動化ができていることは別だと説明されています。

参考：
Scalable Test Automation: Practical Guide
Test Automation Maturity Model
The 5 Stages of Test Automation Maturity

8. ROI：無料ライブラリは無料の戦略ではない

Playwright と Selenium は無料です。

しかし、無料なのはライブラリだけです。

以下は無料ではありません。

フレームワーク設計
CI/CD 連携
並列実行
クロスブラウザ環境
Safari 実行環境
スクリーンショット / 動画 / ログ
テストデータ管理
メールテスト
SMS テスト
ファイルアップロード / ダウンロード検証
データベース検証
権限管理
レポート
AI 修復
メンテナンス
新メンバーのオンボーディング

つまり、ライブラリを選んだ瞬間から、チームは「周辺システム」を作り始めます。

このコストは、最初は見えにくいです。

でも、半年後、1年後、2年後に効いてきます。

特に、以下のような状態になったら注意が必要です。

テストを追加するたびにレビューが重い
QA が自分でテストを直せない
一部のテストだけが CI でよく落ちる
失敗しても誰も見なくなる
テスト結果がリリース判断に使われていない

この状態では、テストは存在していても、ROI は低いです。

参考：
Affordable AI Test Automation
How to Calculate ROI for Test Automation

9. では、成功しているチームは何を使っているのか

外から見ると、大きな会社や成熟した開発チームは、すべてを Playwright や Selenium で内製しているように見えるかもしれません。

しかし、実際には、重要な E2E テストやビジネスクリティカルなフローでは、エンタープライズ向けのテスト自動化プラットフォームを使うケースも多いです。

理由はシンプルです。

エンジニアリング時間は高価だからです。

強いエンジニアチームがあるからといって、社内用テストプラットフォームを作るのが最善とは限りません。

むしろ、強いエンジニアほど、プロダクトのコア価値に集中すべきです。

テスト基盤、ブラウザクラウド、レポート、ログ、権限管理、AI 修復、メールテスト、SMS テスト、ファイル検証まで全部内製するのは、多くの会社にとって ROI が悪くなりがちです。

10. Endtest のようなモダンな代替案

ここで、Endtest のようなツールが選択肢になります。

Endtest は、Playwright と Selenium のどちらが「宗教的に正しいか」を競うものではありません。

ポイントは、

テスト自動化プラットフォームを自社で作る代わりに、最初から使える形で持つ

ということです。

Endtest のようなモダンなプラットフォームでは、以下のような機能を最初から使えます。

テスト作成
AI を使ったテスト作成支援
クロスブラウザ実行
実行レポート
スクリーンショット
詳細ログ
アクティビティログ
ロールベース権限
メンテナンス支援
no-code / codeless な操作
チームで共有しやすいテスト

これは、小さいチームにとってはエンジニアリング時間の節約になります。

大きいチームにとっては、権限、監査性、レポート、ガバナンスの面で重要になります。

QA チームにとっては、毎回開発者に頼らず、自分たちでテストを作成・確認・修正しやすくなります。

参考：
Best No-Code Test Automation Tools in 2026
The 12 Best AI Test Automation Tools for 2026
What Is the Fastest Way to Automate Tests?
Codeless Automation Testing Tools: 12 Best

11. 結論：Playwright vs Selenium ではなく、ROI vs メンテナンスを見る

Playwright も Selenium も、有用なツールです。

Selenium は成熟していて、柔軟で、長い実績があります。

Playwright はモダンで、開発者体験が良く、便利な機能が多く含まれています。

しかし、E2E テストを本気で運用するなら、比較すべきなのはライブラリだけではありません。

見るべきなのは：

誰がメンテナンスするのか？
失敗時に誰が調査するのか？
ブラウザ環境を誰が維持するのか？
レポートは誰が読むのか？
QA は自分でテストを直せるのか？
2年後もそのフレームワークは使われているのか？
その時間は本当にプロダクトにとって最良の投資なのか？

多くの内製 Playwright / Selenium フレームワークは、ライブラリが悪いから失敗するわけではありません。

メンテナンスが増え、導入率が下がり、チーム全体で使えなくなり、ROI が悪くなるから失敗します。

AI は助けになります。

しかし、AI がただコードを増やすだけなら、問題を加速させることもあります。

だからこそ、2026 年のテスト自動化では、

どのライブラリが速いか

だけではなく、

どの仕組みならチームが長期的に使い続けられるか

を考えるべきです。

そして、社内でテスト自動化プラットフォームを作り続けるより、Endtest のようなモダンな代替案を使うほうが、結果的に安く、速く、安定するケースは多いです。

Selenium が悪いわけではありません。

Playwright が悪いわけでもありません。

ただ、あなたのチームには、たぶん他にもっと作るべきものがあるはずです。

参考記事

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up