「SeleniumからPlaywrightに乗り換えるべきか」「2026年の今、どちらを選ぶべきか」——テスト自動化エンジニアの間でこの議論は尽きない。本記事では15年以上のQA実務経験をもとに、SeleniumとPlaywrightをコード・速度・求人・メンテコストの4軸で徹底比較する。新規プロジェクトの選定から既存環境の移行判断まで、実務に直結する判断基準を提供する。
「Playwrightが速い・安定している」は正しい。しかし「だからSeleniumは捨てるべき」は間違い——2026年でも使い分けが正解だ。
📌 この記事はこんな人向け
- 新規プロジェクトでSeleniumかPlaywrightか迷っている
- SeleniumからPlaywrightへの移行を検討しているQAエンジニア
- 2026年時点での両ツールのトレンドを把握したい
- Flaky TestやCI速度の問題を解決するツールを探している
✅ この記事を読むと得られること
- SeleniumとPlaywrightの違いが4軸で整理できる
- 同じテストを両ツールで書き比べたコードで実力差がわかる
- 「移行すべきかどうか」を判断できるチェックリストが手に入る
👤 この記事を書いた人
QAエンジニア・テスト自動化エンジニアとして15年以上の実務経験あり。SeleniumはWebDriver登場初期から、PlaywrightはMicrosoft公開直後から両方を実務で使用。移行プロジェクトの設計・実行も複数経験している。
「Playwrightが出たからSeleniumはオワコン」——SNSでそんな意見を見かけるたびに、実務の現場とのギャップを感じる。確かにPlaywrightは技術的に優れた部分が多い。しかし求人数・既存資産・チームのスキルセットを無視した乗り換えは、別の問題を生む。2026年時点の最新状況を踏まえて、冷静に比較してみよう。
📌 この記事の結論
- 新規プロジェクト:Playwrightを選ぶ理由が多い(速度・安定性・標準機能)
- 既存Seleniumプロジェクト:移行コストと得られるメリットを定量的に判断する
- 求人・キャリア視点:2026年もSelenium求人は健在。両方書ける人材が最強
SeleniumとPlaywrightとは|基本比較
| 項目 | 🌐 Selenium | 🎭 Playwright |
|---|---|---|
| 公開年 | 2004年(約20年の歴史) | 2020年(Microsoft製) |
| 待機処理 | 手動で書く必要あり | Auto-wait(自動) |
| 実行速度 | 🐢 やや遅い | ⚡ 速い(並列実行標準) |
| スクリーンショット・動画 | 別途設定が必要 | 標準搭載 |
| 対応言語 | Python・Java・C#・Ruby・JS など多言語 | Python・JS/TS・Java・C# |
| ネットワーク傍受 | 別途ライブラリが必要 | 標準搭載 |
| Flaky Test耐性 | 低い(sleep多用になりがち) | 高い(Auto-waitで解決) |
| GitHub Stars(2026年時点の目安) | 約31,000 | 約67,000 |
| 求人数(日本) | 多い(成熟した需要) | 増加中(急成長) |
コードで見る実力差|同じテストを書き比べ
同じシナリオ(ログインして結果を確認する)を両ツールで書いた場合、どれだけ差があるかを見てみよう。
Seleniumで書いた場合
import pytest
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
@pytest.fixture
def driver():
options = webdriver.ChromeOptions()
options.add_argument("--headless")
d = webdriver.Chrome(options=options)
yield d
d.quit()
def test_ログイン成功(driver):
driver.get("https://example.com/login")
# 要素が表示されるまで明示的に待つ(手動待機が必須)
wait = WebDriverWait(driver, 10)
wait.until(EC.visibility_of_element_located((By.ID, "username")))
driver.find_element(By.ID, "username").send_keys("test_user")
driver.find_element(By.ID, "password").send_keys("test_pass")
driver.find_element(By.ID, "login-btn").click()
# ダッシュボードが表示されるまで待機
wait.until(EC.url_contains("dashboard"))
assert "dashboard" in driver.current_urlPlaywrightで書いた場合
import pytest
from playwright.sync_api import Page
def test_ログイン成功(page: Page):
page.goto("https://example.com/login")
# Auto-waitのため明示的な待機処理が不要
page.fill("#username", "test_user")
page.fill("#password", "test_pass")
page.click("#login-btn")
# URLの変化もAuto-waitで検知
page.wait_for_url("**/dashboard")
assert "dashboard" in page.urlPlaywrightはAuto-waitにより待機処理をほぼ書かなくてよい。同じテストをSeleniumで書くと約1.5〜2倍の行数になることが多い。Flaky Testの主因となる
time.sleep() / WebDriverWait の複雑さが根本的に解消されている点が最大の差だ。より実務的な機能比較コード
# Playwrightで特に扱いやすい機能:ネットワーク傍受(APIモック)
def test_APIモックを使ったテスト(page: Page):
# 特定のAPIを傍受してモックレスポンスを返す
page.route("**/api/users", lambda route: route.fulfill(
status=200,
body='[{"id": 1, "name": "テストユーザー"}]'
))
page.goto("example.com/users")
assert page.locator(".user-name").first.text_content() == "テストユーザー"
# Playwrightのみの強み:スクリーンショット・動画(標準機能)
def test_証拠収集(page: Page):
page.goto("example.com/dashboard")
page.screenshot(path="screenshots/dashboard.png")
# conftest.pyにrecord_videoオプションを設定すれば動画も自動保存2026年の求人・トレンドから見る選択
技術的な比較だけでなく、キャリア・求人の視点も重要だ。
| 視点 | 🌐 Selenium | 🎭 Playwright |
|---|---|---|
| 日本国内求人 | ◎ 依然として多数 | △ 増加中(まだSeleniumより少ない) |
| 海外求人 | ○ 安定需要 | ◎ 急増中 |
| 学習リソース | ◎ 圧倒的に豊富 | ○ 充実してきた |
| コミュニティ | ◎ 成熟(Stack Overflowも豊富) | ○ 活発に成長中 |
| 将来性 | ○ 維持(既存プロジェクト多数) | ◎ 新規採用の主流に |
2026年の日本市場ではSeleniumの求人がまだ多いため、Python系QAエンジニアなら Selenium をベースに持ちつつPlaywrightも書けるのが最強のポジションだ。学習ロードマップは「Selenium → pytest → Playwright」の順が実務的に最も合理的だ。JS/TS主体のチームであれば、最初からPlaywright + TypeScriptの組み合わせで入るのも十分ありだ。
どちらを選ぶべきか|判断フロー
状況に応じた選択基準を整理した。まず自分のケースがどれに当てはまるか確認してほしい。
▶ 新規プロジェクトですか? | ||
| YES ↓ | NO ↓ | |
✅ Playwrightを選ぶ | ▶ 既存Seleniumのコードが多い? | |
| YES ↓ | NO ↓ | |
▶ Flaky多発・CI遅い? | ✅ Playwrightを選ぶ | |
| YES ↓ | NO ↓ | |
⚡ 移行を検討する価値あり | ✅ Seleniumを継続 | |
移行判断チェックリスト|Selenium → Playwright
既存のSeleniumプロジェクトをPlaywrightに移行するかどうかは、以下のチェックリストで判断しよう。
| チェック項目 | 判断 |
|---|---|
| Flaky Testが週3件以上発生している | YES → +1点 |
| CIの1回の実行が30分以上かかる | YES → +1点 |
time.sleep() が10箇所以上ある | YES → +1点 |
| テスト失敗時のスクリーンショット取得が手動設定になっている | YES → +1点 |
| ネットワークの傍受・APIモックをテストで使いたい | YES → +1点 |
| 既存のSeleniumテストコード数が100件以下 | YES → +1点 |
🔑 判断基準
- 4点以上:移行を積極的に検討すべき。得られるメリットが大きい
- 2〜3点:部分移行(新規テストはPlaywright)を検討
- 1点以下:今すぐ移行する必要はない。Seleniumを磨き続ける方が効率的
Seleniumが今も選ばれる理由
「Playwrightが優れているならSeleniumはもう不要では?」という疑問に正直に答えておきたい。
| 理由 | 詳細 |
|---|---|
| Selenium 4.xの進化 | Selenium Manager(ドライバ自動管理)・Relative Locators・CDP対応など、4.x系も着実に改善が続いている |
| 多言語対応 | Java・C#・Rubyチームでは依然Seleniumが主流。Playwrightは対応言語がまだ少ない |
| 既存資産の膨大さ | 数百〜数千件のSeleniumテストを移行するコストは現実的ではないケースも多い |
| 学習リソースの豊富さ | Stack Overflow・Qiita・Udemy等、20年分の情報量はPlaywrightの比ではない |
| Selenium Grid(分散実行) | 大規模なクロスブラウザ分散テストではSelenium Gridの成熟したエコシステムが強い |
| 求人・JSTQB | 2026年現在も日本の求人ではSeleniumの記載が多く、JSTQB試験でも参照される |
Playwrightの弱点も正直に言う
Playwrightを過度に礼賛するのは正しくない。実務で感じる弱点もきちんと整理しておこう。
| 弱点 | 詳細 |
|---|---|
| Python求人ではまだSelenium優勢 | 2026年時点、日本のPython×テスト自動化求人はSeleniumの記載が多い。Playwrightのみでは見逃す案件がある |
| Java企業での導入障壁 | Java主体の大企業ではSelenium + TestNGの組み合わせが標準化されており、Playwright導入の稟議が通りにくいケースがある |
| 歴史が浅くナレッジが少ない | Seleniumと比べてStack Overflow・Qiitaの日本語情報がまだ少なく、マイナーなバグへの対処に時間がかかることがある |
| 初回セットアップがやや重い | playwright install でブラウザバイナリを別途ダウンロードする必要があり、CI環境のキャッシュ設定に一手間かかる |
📖 関連記事
FAQ|よくある質問
Q. SeleniumとPlaywright、どちらから先に学ぶべきですか?
日本の求人市場ではSeleniumの案件が多いため、Selenium → pytest → Playwrightの順が実務的に合理的だ。SeleniumでWebDriver・待機処理・Page Object Modelの基礎を身につけてからPlaywrightに移ると、Auto-waitの価値が体感レベルで理解できる。最初からPlaywrightのみで学ぶと、Seleniumが必要な現場で困ることがある。
Q. PlaywrightはSeleniumより必ず速いですか?
一般的にPlaywrightの方が速いが、「必ず」ではない。Playwrightは並列実行がデフォルトで有効なため、テスト数が多い場合に特に差が出る。一方、少数のテストをシリアルで実行する場合は体感差は小さい。速度改善を目的に移行するなら、まず並列化の余地があるかを確認することが大切だ。
Q. SeleniumからPlaywrightへの移行はどのくらいの工数がかかりますか?
テスト1件あたり15〜30分を目安にするのが実務的だ。Page Object Modelで設計されているSeleniumコードはPlaywrightへの移行が比較的スムーズだが、time.sleep()や直接的な要素操作が多いコードは書き直しが多くなる。100件のテストなら純粋な移行作業だけで25〜50時間程度を見ておくのが現実的だ。
Q. JSTQB(ISTQBシラバス)ではどちらが推奨されていますか?
JSTQB/ISTQBのシラバスはツールを特定の製品に縛らない形で書かれている。試験ではツール名よりも「テスト自動化の設計原則」が問われる。実務でどちらを使うかは現場判断であり、シラバスに「Playwrightが正解」「Seleniumが正解」という記載はない。
Q. 2026年以降、Seleniumはなくなってしまいますか?
なくならない。SeleniumはW3C WebDriverの標準規格に準拠しており、膨大な既存資産と多言語対応を持つ。Playwrightが急成長しているのは事実だが、両ツールは共存する形が続くと考えられる。実際、2026年現在もSelenium 4.x系の開発・メンテナンスは継続されており、長年運用実績のある安定した技術として使われている。
🔑 忘れがちな大切な視点
「移行しない」という選択も正しい。SeleniumでFlaky Testも少なく、CIも安定しているなら、移行コストをかける理由は薄い。ツールの乗り換えは目的ではなく手段だ。「Playwrightが流行っているから」という理由だけで動くのは、最も避けるべきアンチパターンの一つだ。
まとめ
📋 この記事のまとめ
- 技術的にはPlaywrightが多くの面で優位(Auto-wait・速度・標準機能)
- 求人・既存資産・多言語対応ではSeleniumがまだ強い
- 新規プロジェクトはPlaywright、既存Seleniumは移行判断チェックリストで判断する
- キャリア戦略的にはSelenium + Playwright両方書けるのが最強
- 学習順序は「Selenium → pytest → Playwright」が実務的に最も合理的
「どちらが正解か」ではなく「自分のチーム・プロジェクトにとってどちらが最適か」で選ぶことが大切だ。本記事のチェックリストと判断フローを参考に、現場に合った選択をしてほしい。
