劇作家対セレン
PlaywrightとSeleniumは、ブラウザ自動化フレームワークとして最も有力な2つです。このガイドでは、速度、対応言語、ブラウザカバレッジ、デバッグ機能、そしてどちらを選ぶべきかといった点を、コードサンプルと5分で実践できる結論を交えながら、両者を徹底的に比較します。
- ブラウザとデバイス
- 6100+
- クラウド並列処理
- 100倍
- 稼働時間SLA
- 99.99%
世界で最も革新的な企業のいくつかから信頼されています
どちらを選ぶべきでしょうか？
劇作家を選ぶべき理由は…
新しい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 - 完全対応
劇作家 vs セレン：並べて比較
CI での選択、移行、または実行において重要なあらゆる側面において。
| 寸法 |
Playwright
|
Selenium
|
|---|---|---|
| First release | 2020 | 2004 |
| Maintained by | Microsoft | Open-source community + W3C |
| Languages | TS, JS, Python, Java, C# | Java, Python, C#, Ruby, JS, Kotlin |
| Browsers | Chromium, Firefox, WebKit | Chrome, Firefox, Safari, Edge, IE 11 |
| Mobile testing | Mobile emulation only | Real iOS + Android via Appium |
| Wire protocol | CDP + custom (Firefox/WebKit) | W3C WebDriver standard |
| Auto-waiting | Built in everywhere | Manual waits or WebDriverWait |
| Network interception | First-class API | BiDi (Selenium 4) or proxy |
| Multiple tabs / origins | Native — same context | Window switching API |
| Test runner | Built-in (@playwright/test) | Bring your own (JUnit, pytest, Mocha…) |
| Parallel execution | Built-in worker pool | Selenium Grid or test-runner level |
| Trace / replay | Built-in Trace Viewer | Screenshots + manual logs |
| Debugging | Inspector + UI mode | IDE + driver logs |
| Speed (typical suite) | ≈30–40% faster on Chromium | Mature, predictable |
| Ecosystem maturity | Growing fast since 2020 | 20 years of integrations |
| Page Object pattern | Supported, less common | Industry standard |
| Free for open source 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エンドポイントを対象としています。ブラウザ、並列処理、ダッシュボードもすべて同じです。
どちらを選ぶかは
劇作家を選ぶとき
- 新規にテストスイートを構築するので、移行コストを考慮する必要はありません。
- あなたの技術スタックは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 統合のメリットを享受できます。どちらもオープンソースプロジェクトでは無料で利用できます。