Playwright対Selenium
PlaywrightとSeleniumは、ブラウザ自動化フレームワークとして最も有力な2つです。このガイドでは、速度、対応言語、ブラウザカバレッジ、デバッグ機能、そしてどちらを選ぶべきかといった点を、コードサンプルと5分で実践できる結論を交えながら、両者を徹底的に比較します。
- ブラウザとデバイス
- 6100+
- クラウド並列処理
- 100倍
- 稼働時間SLA
- 99.9%
世界で最も革新的な企業のいくつかから信頼されています
どちらを選ぶべきでしょうか？
Playwrightを選ぶべき理由は…
新しいWebプロジェクトを開始し、チームがJavaScriptまたはTypeScriptでコーディングを行い、高速なテスト、自動待機、組み込みのトレース機能をすぐに利用できるようにしたいと考えている。
Seleniumを選ぶべきなのは…
あなたのチームがJava、C#、またはRubyで開発を行っている場合、レガシーブラウザ（Internet Explorer、旧バージョンのSafari）のサポートが必要な場合、または既存のSeleniumスイートと強力なページオブジェクトライブラリをお持ちの場合。
フロントエンドとバックエンドのテストスイートが別々になっている場合、段階的に移行を進めている場合、あるいは新規コードにはPlaywrightを、レガシーブラウザのロングテール部分にはSeleniumを使用したい場合など、TestingBotは両方を同じグリッド上で実行できます。
PlaywrightとSeleniumとは何ですか？
2つのフレームワーク、2つの哲学。しかし、目標は同じ。実際のブラウザを操作してエンドツーエンドテストを自動化することだ。
Playwright
リリース日：2020年 · Microsoft · Apache 2.0
Playwrightは、Microsoftが開発したエンドツーエンドのテストフレームワークで、単一のAPIを通じてChromium、Firefox、WebKitを制御できます。GoogleでPuppeteerを開発したチームが、クロスブラウザ対応と最新のWebアプリのニーズを念頭に置いて設計しました。
WebDriverの代わりにブラウザのDevToolsプロトコル（またはFirefox/WebKit用の独自のブリッジ）を使用することで、要素の自動待機、ネットワークトラフィックの傍受、豊富なトレースの取得をデフォルトで可能にします。
- TypeScript / JavaScript / Python / Java / C# バインディング
- 自動待機、ネットワーク傍受、フィクスチャ、トレース
- Chromium、Firefox、WebKit · IEおよび旧Safariは非対応
Selenium
2004年リリース · オープンソース · Apache 2.0
Seleniumは、元祖ブラウザ自動化フレームワークであり、W3C WebDriver標準の基盤となっています。Selenium WebDriverは、ベンダー提供のドライバ（chromedriver、geckodriver、safaridriver、edgedriver、IEDriverServerなど）を介して、同一のワイヤプロトコルを使用してあらゆるブラウザを操作します。
20年にわたるエコシステムの成熟により、IDEとの高度な統合、成熟したページオブジェクトパターン、そして主要なすべての言語に対応したバインディングが実現しました。Selenium 4では、Chrome DevToolsのサポート、BiDiイベント、双方向プロトコルが追加されました。
- Java / Python / C# / Ruby / JavaScript / Kotlin
- W3C WebDriver標準：すべてのブラウザで動作します
- Chrome、Firefox、Safari、Edge、IE 11 - 完全対応
Playwright vs Selenium：並べて比較
CI での選択、移行、または実行において重要なあらゆる側面において。
| 寸法 |
Playwright
|
Selenium
|
 Cypress
|
|---|---|---|---|
| First release | 2020 | 2004 | 2017 |
| Maintained by | Microsoft | Open-source community + W3C | Cypress.io |
| Languages | TS, JS, Python, Java, C# | Java, Python, C#, Ruby, JS, Kotlin | JavaScript / TypeScript only |
| Browsers | Chromium, Firefox, WebKit | Chrome, Firefox, Safari, Edge, IE 11 | Chrome, Edge, Firefox, WebKit (experimental) |
| Mobile testing | Mobile emulation only | Real iOS + Android via Appium | Viewport emulation only |
| Wire protocol | CDP + custom (Firefox/WebKit) | W3C WebDriver standard | Executes inside the browser |
| Auto-waiting | Built in everywhere | Manual waits or WebDriverWait | Built in everywhere |
| Network interception | First-class API | BiDi (Selenium 4) or proxy | First-class (cy.intercept) |
| Multiple tabs / origins | Native, same context | Window switching API | No multi-tab; cy.origin for cross-origin |
| Test runner | Built-in (@playwright/test) | Bring your own (JUnit, pytest, Mocha) | Built-in |
| Parallel execution | Built-in worker pool | Selenium Grid or test-runner level | Cypress Cloud or CI-level sharding |
| Trace / replay | Built-in Trace Viewer | Screenshots + manual logs | Time-travel debugger + video |
| Debugging | Inspector + UI mode | IDE + driver logs | Interactive test runner |
| Speed (typical suite) | About 30-40% faster on Chromium | Mature, predictable | Fast, but one browser per run |
| Ecosystem maturity | Growing fast since 2020 | 20 years of integrations | Large plugin ecosystem |
| Page Object pattern | Supported, less common | Industry standard | Supported, discouraged by the docs |
| Runs on TestingBot | ✓ | ✓ | ✓ |
速度の数値は公開ベンチマークによるものであり、アプリケーションによって異なります。両フレームワークはTestingBotのクラウド上で動作し、ローカル実行時と同じAPIを提供します。
フォームに記入し、結果を主張する
自動待機（Playwright）を使用したログインフローと、明示的な待機（Selenium）を使用したログインフローを比較します。どちらも同じTestingBotグリッド上でテストに合格します。
Playwright + TypeScript
login.spec.ts
// playwright.config.ts → set TestingBot endpoint import { test, expect } from '@playwright/test'; test('login redirects to dashboard', async ({ page }) => { await page.goto('https://app.example.com/login'); // auto-wait, no explicit wait needed await page.getByLabel('Username').fill('jane@example.com'); await page.getByLabel('Password').fill('••••••••'); await page.getByRole('button', { name: 'Sign in' }).click(); await expect(page).toHaveURL(/\/dashboard/); await expect(page.getByRole('heading', { name: /welcome, jane/i })).toBeVisible(); });
Selenium + Python
test_login.py
# Driver points at TestingBot remote URL 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 def test_login_redirects_to_dashboard(driver): driver.get('https://app.example.com/login') driver.find_element(By.NAME, 'username').send_keys('jane@example.com') driver.find_element(By.NAME, 'password').send_keys('••••••••') driver.find_element(By.CSS_SELECTOR, 'button[type=submit]').click() # explicit wait WebDriverWait(driver, 10).until(EC.url_contains('/dashboard')) welcome = driver.find_element(By.TAG_NAME, 'h1') assert 'Welcome, Jane' in welcome.text
どちらのテストも、TestingBotのクラウド上の同じPlaywright / Seleniumエンドポイントを対象としています。ブラウザ、並列処理、ダッシュボードもすべて同じです。
Cypressの位置づけ
PlaywrightとSeleniumを比較検討するチームの多くは、Cypressも候補に入れます。要点は次のとおりです。
Cypressはアプリケーションを外部から操作するのではなく、ブラウザ内でアプリケーションと並んでテストコードを実行します。好評な対話型テストランナーやタイムトラベルデバッグはここから生まれていますが、制約の原因でもあります。JavaScriptとTypeScriptのみ、ネイティブモバイルアプリのテスト不可、複数タブ不可、クロスオリジンにはcy.originが必要です。
Playwrightとの比較では、開発体験と適用範囲のトレードオフになります。Playwrightはより多くの言語とブラウザエンジンをカバーし、タブやオリジンの扱いにも困りません。Seleniumとの比較では、使い勝手とカバー範囲のトレードオフです。3つのうちAppium経由で実機のiOS・Androidを操作できるのはSeleniumだけです。
Cypressを本気で検討しているなら、専用の比較ページ Cypress vs Playwright と Cypress vs Selenium で詳しく扱っています。3つともTestingBotで実行できます。
どちらを選ぶかは
Playwrightを選ぶとき
- 新規にテストスイートを構築するので、移行コストを考慮する必要はありません。
- あなたの技術スタックはJavaScript/TypeScriptを主体としており、フレームワークに付属するテストランナーを使いたいと考えている。
- アドオンツールを使用せずに、ネットワークモック、マルチタブフロー、ファイルアップロード、または位置情報オーバーライドが必要な場合。
- トレースベースのデバッグが必要な場合、失敗した実行をフレームごとに記録、保存、シークして確認できます。
- 対応ブラウザはChromium、Firefox、WebKitです。Internet Explorer 11以前のSafariは不要です。
Seleniumを選択する場合
- あなたのチームがJava、C#、またはRubyでプログラミングする場合、Playwrightのバインディングは存在するものの、JavaScript優先の使いやすさは薄れてしまいます。
- Internet Explorer 11、古いSafari、またはWebDriverのみが動作する特殊なブラウザビルドでテストする必要があります。
- 既に成熟したページオブジェクトライブラリ、カスタムロケーター、またはBDDフレームワーク（Cucumber、SpecFlow）をお持ちで、それらを捨てたくない場合。
- ウェブと実際のモバイルデバイスの両方で標準化を進めているわけですね。SeleniumのAPIは、統一されたWebDriver（モバイル向けにはAppium）に最も近いものです。
- 安定性とエコシステムの成熟度は、機能の少なさよりも重要です。Seleniumは20年間、実戦でその真価が証明されてきました。
どちらかを選ぶのはやめて、両方を同じグリッドで実行しよう
PlaywrightをTestingBotエンドポイントに、Seleniumを同じエンドポイントに指定すると、テストは同じ6100+ブラウザとデバイス、同じダッシュボード、同じ並列スロット、同じEUデータ所在地を共有します。
- 同じ認証、同じプロジェクト、同じ請求
- 両フレームワークのテスト履歴を並べて表示
- オープンソースであれば無料：両方のフレームワーク
command_executor='https://hub.testingbot.com/wd/hub'
)
よくある質問
チームがこれらのフレームワークを選択する前、あるいはフレームワーク間を移行する前に自問する質問。
PlaywrightはSeleniumより速いですか？
一般的には、Chromiumベースのブラウザではそうです。DevToolsプロトコルがWebDriverのHTTPラウンドトリップをバイパスするため、Playwrightでは一般的なテストスイートが30～40%高速に実行されます。FirefoxとSafari（Playwrightが独自のブリッジを使用する）ではその差は縮まり、テストがネットワークに依存するようになると差はなくなります。Selenium 4のBiDiサポートにより、この差はさらに縮まります。ほとんどのチームにとって、速度差は確かに存在しますが、決定的な要因ではありません。
SeleniumからPlaywrightに移行すべきでしょうか？
費用対効果が見合う場合に限ります。既存のSeleniumスイートが安定していて、JavaScript以外の言語で記述されており、ページオブジェクトを多用している場合は、移行する労力に見合う価値はほとんどありません。スイートが不安定で、JavaScriptベースであり、トレース機能が不足している場合は、Playwrightの自動待機機能とトレースビューアだけでも、移行費用に見合うだけの価値があります。現実的なチームは両方を維持します。既に動作しているテストにはSeleniumを、新しいテストスイートにはPlaywrightを使用します。
PlaywrightはSeleniumがサポートするすべてのブラウザをサポートしていますか？
いいえ。PlaywrightはChromium（およびChrome/Edgeも含む）、Firefox、WebKit（Safariに似ていますが同一ではありません）をサポートしています。Seleniumは、ベンダー提供のドライバを使用して、Internet Explorer 11、古いSafariバージョン、および珍しいブラウザを含む実際のブラウザビルドを駆動します。IE 11または特定の旧バージョンのSafariでテストする必要がある場合は、Seleniumが唯一の選択肢となります。
Playwrightはモバイルアプリのテストを行うことができますか？
ネイティブでは対応していません。Playwrightはモバイルブラウザのエミュレーション機能（Chromiumでモバイルビューポートとユーザーエージェントをシミュレートできます）を提供していますが、ネイティブのiOSアプリやAndroidアプリを直接操作することはできません。実際のモバイルアプリのテストには、 Appium 、 XCUITest 、 Espresso 、またはMaestroが必要です。Seleniumは、WebDriverプロトコルに基づいて構築されたAppiumを介してモバイルアプリを操作できます。TestingBotは、実際のiOSおよびAndroidデバイス上でこれらのすべてをサポートしています。
クロスブラウザテストにはどちらが適していますか？
最新のChromium、Firefox、WebKitの場合、Playwrightの単一APIにより、より高速で信頼性の高いクロスブラウザテストをすぐに実行できます。レガシーブラウザ（IE 11、旧Safari、Edge Legacy）を含む包括的なテストには、実際のブラウザバイナリを駆動できるSeleniumが依然として唯一の選択肢です。いずれの場合も、多数の実際のブラウザで並行してテストを実行するには、TestingBotのクラウドを利用することで大きなメリットが得られます。どちらのフレームワークも、設定を1行変更するだけでTestingBotのクラウドと統合できます。
Playwrightを使うにはJavaScriptを学ぶ必要がありますか？
いいえ、Playwright の人間工学は JS/TS を最優先に設計されています。Python、Java、C# のバインディングは一流ですが、新機能の実装は JS API に比べて数週間遅れています。チームが既に Python または Java で開発を行っている場合は、Playwright は依然として有力な選択肢ですが、Selenium のバインディングの互換性により、JS 以外のスタックにはより自然な形で適合します。
TestingBot上でPlaywrightとSeleniumを実行できますか？
はい、どちらも同じ TestingBot クラウド上で動作します。Playwright は wsEndpoint 設定を介してwss://cloud.testingbot.com/playwrightに接続し、Selenium はwebdriver.Remoteを介してhttps://hub.testingbot.com/wd/hubに接続します。テストは同じダッシュボードに表示され、並列実行スロットを共有し、同じ EU データレジデンシー、ビデオ録画、ライブデバッグ、CI/CD 統合のメリットを享受できます。どちらもオープンソースプロジェクトでは無料で利用できます。
PlaywrightはSeleniumに取って代わりますか？
完全に置き換わることはありません。PlaywrightはJavaScriptおよびTypeScriptの新規プロジェクトで大きなシェアを得ていますが、SeleniumはW3C標準であり、20年の導入実績、6言語のバインディング、そしてAppium経由で実機のiOS・Androidを動かせる唯一の手段を備えています。現実的な帰結は共存です。新しいテストスイートはPlaywrightに傾き、大規模な既存スイートやJS以外のスタックはSeleniumに留まります。両方を併用するチームも数多くあります。
Seleniumはもう時代遅れですか？
いいえ。Selenium 4はW3C WebDriver標準に移行し、相対ロケーター、Chrome DevTools Protocolへのブリッジ、BiDiサポートを追加しました。Playwrightに比べて記述に手間がかかり明示的な待機がより頻繁に必要ですが、活発に保守されており、Safari、Internet Explorer 11、実機のモバイル端末を含め、言語とブラウザのカバー範囲では最も広い選択肢であり続けています。
Seleniumを知らなくてもPlaywrightを学べますか？
はい。PlaywrightはSeleniumの上に構築されておらず、APIも共有していないため、事前に学ぶべきことも、学び直すべきこともありません。Seleniumの経験が役立つのは主にロケーター、待機、Page Objectパターンといった一般的な概念であり、Playwrightの構文そのものではありません。ゼロから始めるなら、Playwrightを直接学ぶほうが近道です。
Playwrightにコーディングは必要ですか？
はい。Playwrightはコードを前提としたフレームワークで、テストはTypeScript、JavaScript、Python、Java、C#のいずれかで記述します。Codegenツールはブラウザ操作を記録して動作するテストスクリプトを生成し、導入の敷居を大きく下げますが、出力されるのは結局のところ自分で編集し保守するコードです。ノーコードのモードはありません。
さらに詳しく知りたい方は、PlaywrightとSeleniumに関する専用ページをご覧ください。