Playwright vs Selenium比較：ブラウザ要件と保守性で選ぶ【2026年】

2026年のPlaywright vs Selenium比較では、新しくブラウザテストを組むならPlaywrightを、必須のブラウザや既存の基盤が選択を左右するならSeleniumを選ぶのが基本です。Playwrightは3種類のブラウザエンジンに対応していますが、付属のWebKitビルドはSafariそのものではありません。この違いだけで、AIエージェントがテストを書き始める前に採用するツールが決まることもあります。Playwrightの対応ブラウザ。

Playwright vs Selenium比較：どちらを選ぶべきですか？

新しいWebアプリで、必要なブラウザが対応範囲に収まるなら、Playwrightを選びます。 特に向いているのは、テストランナー、アサーション、ブラウザの分離、失敗時の調査を共通の手順にまとめたいJavaScriptやTypeScriptのプロジェクトです。コーディングエージェントにテストコードの多くを書かせる場合も、最初の候補になります。チームで組み立て、エージェントに教えるテストの規約を少なくできるためです。

Safariそのものを使う必要がある、Rubyバインディングが欲しい、または適切に保守されたWebDriverのテスト群とGridがすでにある場合は、Seleniumを選びます。 WebDriverは、Seleniumの基盤となるブラウザ操作インターフェースです。既存のフィクスチャ、失敗レポート、ブラウザ設定、運用ノウハウは資産です。置き換えるなら、自分たちのアプリで具体的な改善を示す必要があります。

要件が分かれるなら、両方を併用します。 新しい製品領域にはPlaywrightを使い、ブラウザ固有のリグレッションテストはSeleniumに残す方法もあります。各テストの担当者と存在意義を明確にし、同じ操作フローを重複して保守し続けないようにします。

判断の順序はシンプルです。まず必須ブラウザへの対応、次に言語とテストランナーとの相性、最後に失敗の原因を調べてテストを保守する手間です。 エージェント連携が役立つのは、これらの要件を満たした後です。

フレームワークの機能は、2026年10月19日に公開されていたPlaywrightとSeleniumの公式ドキュメントで確認しています。本記事はドキュメントに基づく比較であり、実測による性能ベンチマークではありません。

ホスト型グリッドの導入は、別途検討するインフラの購入判断です。その比較には、最新のBrowserStack代替サービス比較を参照してください。

アーキテクチャの違い：テスト環境を一体化するか、組み合わせて作るか？

新しいテスト環境を組み立てるならPlaywrightが有利です。既存のテストシステムにブラウザ自動化を組み込むことを優先するなら、Seleniumが向いています。 違いはブラウザ操作の周辺に何が用意されているかであり、実行速度の優劣が保証されるわけではありません。

Playwright：テストのライフサイクルをまとめて管理する

Playwrightはブラウザ自動化フレームワークで、Node.jsパッケージにはテストランナーのPlaywright Testが含まれています。ランナーはテストを検出し、実行環境を準備し、実行順序を管理して結果を報告します。Playwrightの言語別ドキュメントでは、この一体化された環境と、他の言語向けの連携方法を区別しています。Playwrightの言語別連携。

設計上の重要な単位がブラウザコンテキストです。Cookieとブラウザストレージを独立して持つ、分離されたブラウザプロファイルを指します。Playwright Testは、テストごとに新しいコンテキストを提供します。そのため、ログインのテストシナリオを、別のシナリオのセッションを引き継がずに開始できます。ブラウザコンテキストによる分離。

ブラウザテストの作成と原因調査に、プロジェクト共通の作法を設けたい場合に適した方式です。ただし、対応範囲と連携には制約があります。Node.jsのランナーをすべての言語で使えるわけではなく、付属のブラウザビルドで、製品版ブラウザが必要なすべての要件を満たせるわけでもありません。

Selenium：WebDriverを中心にテストシステムを組み立てる

Seleniumは、WebDriverを中心としたブラウザ自動化ツール群です。ブラウザ操作ライブラリは、より大きなテストアプリケーションに組み込む設計になっています。ランナーとアサーションライブラリを選び、セットアップ、終了処理、レポートの仕組みを決めるのは利用側です。Seleniumの設計、テストの構成方法。

Seleniumのコードとブラウザの間には、ブラウザ専用のドライバーが入ります。ドライバーが用意されていない場合は、Selenium Managerが必要なドライバーを検出し、ダウンロードしてキャッシュできます。通常はこれにより、手動でダウンロードする手順が不要になります。Selenium Manager。

周辺システムがすでに資産になっているなら、Seleniumが適しています。ただし、保守の責任は明確にする必要があります。待機処理、セッションのライフサイクル、原因調査用の記録を、一貫した形で誰かが維持しなければなりません。技術責任者が評価すべきなのは、クリックが動くかどうかだけでなく、それを支えるテスト実行基盤です。

対応言語とブラウザ：使いやすさより要件を優先する

Playwrightが直接満たせない要件、特にRubyとSafariそのものが必要な場合は、Seleniumが有利です。 新規のJavaScriptやTypeScriptのテスト群では、統合ランナーを備えたPlaywrightが引き続き第一候補になります。

PlaywrightはJavaScript/TypeScript、Python、Java、.NETに対応しています。ブラウザ自動化の中核は共通の実装を使っていますが、テストとの連携方法は異なります。JavaScript/TypeScriptにはPlaywright Test、Pythonには推奨のpytestプラグインがあり、JavaではJUnitやTestNGを利用できます。.NETにはテストフレームワーク向けの基底クラスが用意されています。対応言語。

Seleniumのドキュメントには、Java、Python、C#/.NET、Ruby、JavaScriptのバインディングが掲載されています。KotlinはJavaバインディングを使用します。Rubyで構築したテスト資産があることは、Seleniumを使い続ける具体的な理由になります。移行を、単にライブラリ名を変える作業とは考えられません。Seleniumの言語別インストール。

Pythonで使うなら、PlaywrightとSeleniumのどちらですか？

ブラウザAPIとコンテキストベースのフィクスチャで、現在の保守上の問題を解決できるなら、Python版Playwrightを選びます。既存のpytestフィクスチャ、対象ブラウザ、レポートで十分に運用できているなら、Python版Seleniumを使い続けます。どちらを選んでも、Pythonのテスト環境は意図を持って設計する必要があります。

Node.jsのランナーのデモを見て、Pythonでの移行を決めないでください。PlaywrightのPython向けドキュメントでは、並列実行にpytest-xdistを使用しています。ブラウザ自動化の機能はバインディング間で共通でも、ランナーの設定まで共通になるわけではありません。PlaywrightのPython向けテストランナー。

Safariなどの製品版ブラウザが必須なら、選択は変わります

PlaywrightはChromium、Firefox、WebKitを自動操作し、Google ChromeとMicrosoft Edgeのチャネルも利用できます。FirefoxとWebKitとの連携はパッチに依存しており、公式ドキュメントは製品版のFirefoxとSafariを明確に対象外としています。SeleniumはChrome、Edge、Firefox、Safariに加え、Internet Explorerドライバーも掲載しています。Playwrightの対応ブラウザ、Seleniumの対応ブラウザ。

つまり、「Safariでこの現象を再現する必要がある」と「WebKitの描画不具合を検出したい」は、別の要件です。前者について、SeleniumはSafariDriverによる実際のSafariセッションを文書化しています。後者なら、PlaywrightのWebKit対応が適している場合があります。また、モバイル用のビューポートやデバイスプロファイルもエミュレーションであり、スマートフォン実機で確認した証拠にはなりません。SeleniumのSafari対応。

テストを書き換える前に、必要なブラウザとOSの組み合わせを評価要件に明記してください。対象を取り違えたテストは、フレームワークでは補えません。

自動待機：Playwrightは標準のままでテストを書きやすい

通常の操作に有用な準備状態のチェックが組み込まれている点で、Playwrightが有利です。 対象機能に変更がないのに結果が変わるテストを、不安定なテスト、いわゆるフレイキーテストと呼びます。多くの場合、テストとアプリの処理タイミングが競合することで発生します。

Playwrightは、ロケーターによる通常のクリックの前に、対象が単一の要素であること、その要素が表示され、位置が安定し、有効で、イベントを受け取れることを確認します。アサーションも、期待した条件が成立するまで再試行できます。これにより、多くのテストで準備状態を確認するコードの繰り返しを減らせます。Playwrightの操作可能性チェック。

Seleniumにも待機機能があります。ページ遷移はページ読み込み戦略に従い、要素検索には暗黙的待機、指定した条件のポーリングには明示的待機を使います。重要なのは、ドキュメントが読み込まれたことや要素が見つかったことだけでは、動的に変化するアプリが次の操作を受け付けられるとは限らない点です。Seleniumは、暗黙的待機と明示的待機を混在させないよう注意を促しています。Seleniumの待機戦略。

配送情報の検証が終わる前に、支払いボタンが表示される購入手続きを考えてみます。Seleniumでは、固定時間のスリープを入れるのではなく、次の操作に必要な条件を明示します。Playwrightでは、アプリがボタンの無効状態を正しく公開していれば、操作可能性のチェックが役立ちます。

どちらのフレームワークでも、注文が期待した状態に到達したことを確認するアサーションは必要です。クリックできたことは、支払いが成功した証拠にはなりません。エージェントが書くテストでは特に、ロケーターと同じくらい慎重に期待結果をレビューしてください。

並列実行：新規テストにはPlaywright、リモート実行基盤にはGrid

新規のNode.jsテスト群で手軽に並列実行するなら、Playwrightが有利です。リモートで動くWebDriverブラウザ群を運用するなら、Selenium Gridが適しています。 関連する課題を扱いますが、担当する層が異なります。

Playwright Testは、標準でテストファイルを並列実行します。一方、同じファイル内のテストは、別途設定しなければ順番に実行されます。ワーカー数を制御したり、完全な並列実行を有効にしたり、テスト群を複数のマシンに分割して実行したりできます。この分割をシャーディングと呼び、個々のシャードは別のジョブに割り当てられたテスト群の一部分です。Playwrightの並列実行。

Selenium Gridは、マシン、ブラウザのバージョン、OSが異なるリモートのブラウザインスタンスへコマンドを振り分けます。ただし、どのテストを同時に開始するかを決めるのは、引き続きテストランナーです。そのため、Gridの処理容量とテストの同時実行数は別々に設定する必要があります。ブラウザを動かすホストを増やしても、逐次実行のスケジュールが自動で書き換わるわけではありません。Selenium Grid、ランナーの役割。

どちらの仕組みでも、注意すべき失敗の原因はアプリケーションデータの共有です。ブラウザプロファイルを分けても、同じ顧客レコードを編集することはできます。あるテストがパスワードを変更し、その間に別のテストが古いパスワードでログインすれば、衝突の原因はブラウザフレームワークではなく、フィクスチャの設計にあります。Playwrightの並列実行ガイドも、ブラウザの分離と外部状態の分離を明確に区別しています。共有状態についての指針。

ワーカーを増やす前に、同時実行するテストに独立したレコードを割り当て、後片付けの担当を明確にしてください。フレームワークを選ぶ責任者にとって、有用な試験導入で測るべきなのは、確実に検証できる範囲と失敗調査のしやすさです。起動できるブラウザ数だけでは判断できません。

周辺ツール：Playwrightは標準機能で失敗の原因を追いやすい

テスト作成とデバッグを一体化した環境では、Playwrightが有利です。 実務での利点は、失敗したテストが何をしようとし、そのときアプリに何が表示されていたかを、レビュー担当者が素早く把握できることです。

Playwrightのcodegenはブラウザ操作を記録し、ロケーターの選択を助け、表示状態、テキスト、値に関するアサーションを追加できます。記録は下書きとして使ってください。たとえばアカウント設定の操作なら、生成されたテストが単に設定項目を開くだけでなく、保存後も設定が保持されることを確認しているかをレビューします。Playwrightのテストジェネレーター。

Trace Viewerでは、実行後に記録された操作を、ページのスナップショット、ソース、コンソール出力、ネットワーク通信とあわせて確認できます。失敗したCI実行に、後から検証できる履歴を残す仕組みです。トレースの収集方法は、目的に応じて選んでください。公式ドキュメントでは、失敗時にトレースを保持する方法や、再試行時に記録する方法を説明しています。再試行のトレースに残るのは再試行時の様子です。不定期に起きる問題を調べるなら、最初に失敗した実行の記録も残すことを検討します。Trace Viewerと収集方法。

操作の記録と再生を行うSelenium IDEは、現行ドキュメントでWindows、macOS、Linux向けのスタンドアロンアプリケーションと説明されています。この概要は2026年10月9日に更新されています。現象の再現手順を記録したり、コマンドの流れを学んだりするのに役立ちます。記録した操作は、継続的に保守するテストの素材と捉え、アサーションとデータ準備を意図的に追加してください。現行のSelenium IDEドキュメント。

Seleniumのテスト群でも、エージェント向けガイドが推奨するように、ランナー、スクリーンショット、ログを通じて有用な調査資料を揃えられます。選定時に確認したいのは、既存のテスト実行基盤で、それらをすでに確認しやすくできているかです。できているなら、失敗したジョブしか手掛かりが残らないテスト群と比べ、Playwrightの付属ツールを理由に移行する利点は小さくなります。

WebDriver BiDi：Seleniumはコマンドの送受信だけではありません

WebDriverプロトコルの相互運用性が要件なら、Seleniumが有利です。 イベントを監視できない単なるブラウザドライバーと捉えると、現在のアーキテクチャを見誤ります。

WebDriver BiDiは、Seleniumのドキュメントで説明されている双方向プロトコルです。従来のコマンドと応答による自動操作に加え、WebSocket接続を通じてブラウザのイベントを制御側のプログラムへ届けます。コンソールメッセージ、JavaScriptエラー、ネットワーク通信などが発生した時点で、テストがイベントを受け取れることに意味があります。SeleniumはBiDiをクロスブラウザ対応の方向性として示し、Chrome DevTools Protocolへの対応は一時的なものと説明しています。WebDriver BiDi。

たとえば、購入手続きで不定期に起こる失敗を調べる責任者には、最後のスクリーンショットに加えて、ブラウザ側のエラー記録が必要になることがあります。BiDiは、Chromiumのデバッグプロトコルにアーキテクチャを依存させずに、こうしたイベントを扱う機能を利用する方法として文書化されています。

必要なブラウザと言語バインディングで、使いたい操作に対応しているか確認してください。 SeleniumのAPIドキュメントによると、対応範囲はプロトコルとブラウザの実装の進展にあわせて広がります。クロスブラウザの標準であっても、現時点ですべての操作がどこでも同じように使えるという保証ではありません。BiDiの実装範囲。

BiDiはブラウザのプロトコルです。それ自体がSeleniumをAIエージェント向けのツールサーバーにしたり、完全なテストランナーを提供したりするわけではありません。

AIエージェント連携：Playwrightは導入経路がまとまっています

エージェントを活用した新しいテストの仕組みを作るなら、Playwrightが有利です。既存の技術構成の中でエージェントを動かすなら、Seleniumも十分な選択肢です。 ブラウザへのアクセス、コードの生成、生成されたテストの採用判断は、分けて考えてください。

Playwright MCP、CLI、Test Agentsは何を担当しますか？

Playwright MCPはModel Context Protocolサーバーです。AIエージェントが呼び出せるツールを公開するアダプターとして働きます。要素への参照を含む構造化されたアクセシビリティスナップショットを提示するため、エージェントはページを調べ、操作対象を指定できます。提供するのはブラウザとのやり取りであり、生成されたテストが正しい動作を検証していることまでは保証しません。Playwright MCP。

文書化されている選択肢はMCPだけではありません。簡潔なコマンドが適したコーディングエージェントのワークフローには、PlaywrightはCLIとインストール可能なスキルを推奨しています。一方、MCPは、状態を保ちながら探索を繰り返す用途に適しています。エージェントの動き方に合ったインターフェースを選んでください。PlaywrightのCLIガイド。

Playwright Test Agentsには、planner、generator、healerが用意されています。plannerは探索して計画を作り、generatorは計画をテストに変換し、healerは失敗を調査して修正を提案します。スキップされたテストは必ずレビューしてください。公式ドキュメントによると、healerは機能が壊れていると判断した場合、テストをスキップすることがあります。 スキップ後に実行が成功しても、検証範囲が回復したことにはなりません。Playwright Test Agents。

セットアップの手順はPlaywright MCPによるブラウザテストガイドを参照し、生成されたテストにも通常のコードレビューを適用してください。

Selenium公式が示すエージェントの使い方

Selenium自身のAIエージェントガイドは、手軽な方法を紹介しています。コーディングエージェントに一時的なSeleniumスクリプトを書いて実行させ、アプリを調査し、ロケーターを検証する方法です。コミュニティが保守するMCPサーバーも紹介していますが、Seleniumの構成要素ではなく、サードパーティーのプロジェクトであることを明示しています。Seleniumのエージェント向けガイド。

同じガイドは、最新のドキュメント、明文化したプロジェクトルール、失敗時の記録も推奨しています。具体的な作法として、明示的待機、新しいセッション、適切な終了処理、実際のページでのロケーター検証を挙げています。既存のSeleniumテスト群でも、フレームワークを移行せずにエージェントを活用する手順を整えられます。

どちらを使う場合も、エージェントにはアサーションの説明、テストの実行、検証資料の添付を求めます。期待結果の変更、スキップの追加、チェックの弱体化はレビューしてください。必要な成果物は、エージェントがアプリを無事にクリックして回った記録ではなく、要件を守るテストです。

SeleniumからPlaywrightへの移行：周辺のテスト基盤にも工数を見込む

移行で工数がかかるのは、ブラウザAPIの周囲にあるテストの規約を作り直す部分です。 「SeleniumからPlaywrightへ切り替える」作業は、構文の一括変換ではなく、検証範囲を段階的に確保するプロジェクトとして扱います。

テストの意図は、多くの場合そのまま残せます。たとえば、権限のある顧客が配送先住所を変更し、次の注文で変更後の住所を確認する、という要件です。一方で、Seleniumの要素操作、待機処理、ページオブジェクト、セッション準備は、見直しや書き換えが必要になります。ページオブジェクトとは、画面の操作部品を「住所を保存する」といった操作の背後にまとめるヘルパーです。有用な業務用語は残し、ブラウザに依存する仕組みは意図を持って置き換えます。

運用面のコストには、両方のテスト群を並行して維持する期間、新しいCI設定、失敗の調べ方をレビュー担当者に教える作業が含まれます。移行先に縛られる要因の多くは、自分たちのコードと運用規約です。Playwrightのロケーター、フィクスチャ、トレースの調査手順は、WebDriverのヘルパーとレポートをそのまま置き換えるものではありません。どちらもライセンス料が不要だからといって、こうしたエンジニアリング作業がなくなるわけではありません。

1. 1

   テストを書き換える前に要件を棚卸しする

   対象ブラウザ、言語、ランナー、ページオブジェクト、認証設定、データ作成、ダウンロードやアップロード、レポート、Gridへの依存を洗い出します。Safariそのものなど、予定しているPlaywright構成でカバーできない対象が必要なテストを明示してください。その要件を満たす代替手段ができるまでは、該当テストを既存の仕組みに残します。

2. 2

   代表的な操作フローで試験導入する

   認証、変化するUI、業務上の結果を確実に検証するアサーションを含むフローを選びます。現在のテスト群が苦手とするシナリオも追加してください。期待する動作を維持したまま、ロケーターと待機処理を書き換えます。自動生成による変換で、テストを成功させるためにチェックがひそかに削られないようにします。

3. 3

   テストの分離と失敗時の記録を整え直す

   ブラウザのセットアップを、選択した言語のフィクスチャへ移します。テストごとに独立したアプリケーションレコードを割り当て、認証状態の扱いを定義し、原因調査に役立つ記録を収集します。試験導入したテストが、単独でも他のテストと同時でも動くことを確認してください。ブラウザコンテキストの分離だけで、バックエンドのデータまで独立するわけではありません。

4. 4

   リリース判定に使うテストを切り替える前に、検証範囲を比較する

   対応予定のブラウザとCI条件で、試験導入したテストを実行します。検証範囲の不足、不定期な失敗、調査の手間、アサーションの変更を記録してください。要件を満たし、特定した保守上の問題が改善した時点で、移行を受け入れます。Seleniumのほうが要件を適切に満たす箇所では、Seleniumを残します。

エージェントがPlaywrightのコードを生成できるという理由だけで、健全に運用できているSeleniumのテスト資産を切り替えないでください。言語変更を考慮せずにRubyのテスト群を移行したり、SafariそのもののテストをWebKitで置き換えて、同じ検証範囲だと見なしたりしてはいけません。一方、壊れやすいヘルパーや読みにくい失敗レポートが大きな負担になっているテスト群なら、Playwrightの試験導入を検討する理由があります。

まず着手するなら、リリースに不可欠な操作フローのうち、受け入れ基準が最も明確なものを選びます。必要なブラウザを書き出し、そのフローを保守する手順を比較してください。対象を広げるのは、変更の妥当性を裏付ける結果が得られてからです。

よくある質問

SeleniumとPlaywrightは、どちらが習得しやすいですか？

新しくJavaScriptやTypeScriptのテスト群を作るなら、ランナーとテスト用ツールが統合されたPlaywrightのほうが始めやすく、おすすめです。使い慣れた言語とランナーの中に導入するなら、Seleniumのほうが扱いやすい場合もあります。既存の知識や必須ブラウザによっては、初期設定の手軽さよりもそちらが優先されます。

Playwrightの代わりになるツールはありますか？

本記事で直接比較している代替候補はSeleniumです。特に、Safariそのもの、Ruby、既存のWebDriver基盤が必要な場合に適しています。代替ツールは、対象ブラウザと解決したい保守上の問題に照らして評価してください。

Playwrightはもう時代遅れですか？

いいえ。本比較で確認した公開ドキュメントには、現在のブラウザテスト、MCP、CLI、テストエージェントの利用方法が記載されています。判断すべきなのは、それらのツールで自分たちのアプリの要件を満たせるかどうかです。

JavaでSeleniumを使うスキルに需要はありますか？

JavaはSeleniumが対応するバインディングです。ただし、プロジェクトのドキュメントから採用市場の需要は分からず、現在の求人需要についての主張を裏付けることはできません。フレームワークを選ぶ際は、すでに持っているJavaのスキルとテスト基盤を評価してください。

PlaywrightはSeleniumを置き換えますか？

あらゆる用途で置き換わると予測する根拠は、本記事にはありません。対応範囲が要件に合う新規テスト群ではPlaywrightが第一候補です。一方、Seleniumは現在も、選定を左右し得るブラウザ、言語、実行基盤の要件を満たしています。

Seleniumを使うテスターの給与はどのくらいですか？

どちらのプロジェクトのドキュメントも、給与の根拠となる情報は提供していません。信頼できる推定には、地域、経験・職位の水準、最新の報酬データが必要です。使うフレームワークだけでは判断できません。

Seleniumだけを学べば就職できますか？

Seleniumの知識だけでは、テスト職で求められ得る幅広い能力を示せません。有用なアサーションを設計し、テストデータを管理し、失敗を調査し、CI上でテストを保守できることを、実績で示してください。

テスト分野で最も給与が高い専門領域は何ですか？

本記事で使った情報源では、テストの専門領域ごとの給与順位を裏付けられません。技術責任者がフレームワークを選ぶ際は、根拠のない報酬比較ではなく、必要な検証範囲と保守性を基準にしてください。

テスト自動化は2か月で習得できますか？

期限を決めた学習計画として捉え、実務に対応できるようになる保証とは考えないでください。小さなアプリに対象を絞り、独立したテスト、意味のあるアサーション、失敗の原因調査、CI実行ができることを示してから、学習範囲を広げます。

テスト群を拡大する前に、どのテスト作業を自動化すべきか整理しましょう。ニュースレターからAI Business Workflow Audit Checklistを入手できます。