Seleniumは捨てろ。Playwrightへの移行でテストの壊れやすさを克服する方法

近年のWebアプリケーション開発において、E2Eテストの重要性はますます高まっています。
しかし、その一方でSeleniumを中心とした従来のテスト基盤は、DOM構造の変更や非同期処理のタイミング問題により、テストが壊れやすいという課題を抱え続けてきました。
結果として、CI環境でのフレイキーテストが増え、保守コストが開発速度を圧迫している現場も少なくありません。

こうした状況に対して、近年注目されているのがPlaywrightへの移行です。
Playwrightはブラウザ操作の抽象化が洗練されており、従来の「待機処理の手動実装」や「不安定な要素セレクタ」に依存する設計から脱却できます。
特に、テストの再現性と安定性の観点で大きな改善が見込める点は見逃せません。

本記事では、SeleniumからPlaywrightへ移行することで得られる具体的なメリットと、実際にテストの壊れやすさを克服するための実践的なアプローチについて整理します。

フレイキーテストの発生要因を構造的に理解する
Playwrightが提供する自動待機の仕組みを活用する
セレクタ設計を見直し安定性を高める
並列実行とトレース機能でデバッグ効率を改善する

単なるツールの置き換えではなく、テスト設計そのものを見直す契機としてPlaywrightを捉えることで、長期的に安定した品質保証体制を構築することが可能になります。

Seleniumが抱える課題とフレイキーテストの正体
1. DOM依存によるテストの脆さ
2. 非同期処理と待機問題の落とし穴
Playwrightとは何か：次世代E2Eテスト自動化フレームワーク
1. マルチブラウザ対応の強み
2. Seleniumとの設計思想の違い
自動待機（Auto-wait）がテスト安定性を劇的に改善する理由
1. 明示的waitを削減するメリット
セレクタ設計の最適化で壊れにくいE2Eテストへ
1. data-testid戦略の活用
2. CSSセレクタ依存からの脱却
CI環境とGitHub ActionsでのPlaywright実行最適化
1. 並列実行によるテスト高速化
2. 失敗時のログ収集と可視化
Playwrightのトレース機能でデバッグ効率を最大化する
1. ステップ単位の実行可視化
SeleniumからPlaywrightへの移行戦略と実践ポイント
1. 段階的移行のすすめ
2. 既存テスト資産の活用方法
SeleniumとPlaywrightのE2Eテストツール比較
Seleniumを捨てるべきか：Playwright時代のテスト戦略まとめ

Seleniumが抱える課題とフレイキーテストの正体

Seleniumは長年にわたりE2Eテスト自動化の標準的な選択肢として利用されてきましたが、その設計思想の古さが現在のフロントエンド開発の速度と複雑性に追いつかなくなりつつあります。
特に問題となるのは、テストが環境やタイミングに強く依存しやすく、いわゆるフレイキーテストが発生しやすい点です。
これは単なる実装ミスではなく、Seleniumの構造的な制約に起因するものです。

DOM依存によるテストの脆さ

Seleniumのテストは基本的にDOMツリーの構造に強く依存しています。
つまり、HTMLの構造が少しでも変更されると、セレクタが機能しなくなりテストが容易に壊れてしまいます。
例えば、UIのボタンのラベルが変わる、あるいはコンポーネントの階層がリファクタリングされるだけでテストが失敗するケースは珍しくありません。

この問題の本質は、テストが「ユーザー視点の振る舞い」ではなく「実装詳細」に結びつきすぎている点にあります。
例えば以下のようなセレクタは典型的な脆弱性を持ちます。

driver.findElement(By.css(".container > div:nth-child(2) > button"))

このような構造依存のセレクタは、UI改善のたびに修正が必要となり、結果としてテストの保守コストが指数関数的に増加します。
理想的には、テストは実装の詳細ではなく意味的な識別子に依存すべきです。

非同期処理と待機問題の落とし穴

もう一つの大きな課題は、非同期処理に対する扱いの不十分さです。
現代のWebアプリケーションはSPA（Single Page Application）が主流であり、API通信やレンダリングは非同期で行われます。
しかしSeleniumでは、これらの状態遷移を明示的に待機する必要があり、その実装が非常に不安定になりがちです。

特に問題となるのは「適切な待機時間の見積もりが困難である」という点です。
短すぎれば要素が存在せず失敗し、長すぎればテスト全体の実行時間が増大します。
このトレードオフは本質的に解決が難しく、開発者の経験則に依存してしまいます。

また、以下のような明示的な待機コードは可読性と保守性を著しく低下させます。

driver.sleep(5000);

このような設計は一見シンプルに見えますが、実際にはシステムの状態を正しく表現しておらず、結果として不安定なテストを生み出します。
理想的には「状態が満たされるまで待つ」という宣言的な仕組みが必要ですが、Selenium単体ではそれを自然に表現するのが難しいのが現実です。

これらの問題が積み重なることで、Seleniumを用いたE2Eテストは次第に信頼性を失い、開発サイクル全体のボトルネックとなっていきます。

Playwrightとは何か：次世代E2Eテスト自動化フレームワーク

Playwrightは、Microsoftによって開発されたE2Eテスト自動化フレームワークであり、従来のSeleniumが抱えていた不安定性や非同期制御の複雑さを抜本的に見直した設計になっています。
特に現代のWebアプリケーションに求められる「高速・安定・再現性」の3点を高い次元で満たすように設計されている点が重要です。

従来のE2Eテストは、ブラウザ操作を外部ドライバ経由で制御するためオーバーヘッドが大きく、実行速度や安定性に課題がありました。
一方でPlaywrightはブラウザエンジンにより近いレイヤーで制御を行うため、より低レベルかつ直接的に操作できる設計となっています。
その結果として、テストの実行速度と信頼性が大幅に向上しています。

マルチブラウザ対応の強み

Playwrightの大きな特徴の一つは、単一のAPIで複数のブラウザを統一的に扱える点です。
Chromium系ブラウザだけでなく、FirefoxやWebKitにも対応しており、クロスブラウザテストを効率的に実現できます。
従来はブラウザごとに異なるドライバや設定を管理する必要がありましたが、Playwrightではその複雑性が大幅に削減されています。

さらに重要なのは、各ブラウザに対して同一のテストコードをそのまま適用できるという点です。
これにより、環境差異によるテスト結果のばらつきを抑え、CI環境での再現性を高めることが可能になります。

Seleniumとの設計思想の違い

PlaywrightとSeleniumの本質的な違いは、「テストの不安定さをどこで吸収するか」という設計思想にあります。
Seleniumは基本的に開発者側が待機処理やリトライ処理を明示的に管理する必要がありますが、Playwrightはその多くをフレームワーク側が自動的に処理します。

例えば、要素が表示されるまでの待機処理についても、Playwrightでは以下のように宣言的に記述できます。

await page.click('button#submit');

この一行の裏側では、要素の可視性や有効性が自動的に評価され、条件が満たされるまで適切に待機が行われます。
これにより、従来のような不必要なsleepや手動waitロジックは基本的に不要になります。

この違いは単なるAPIの使いやすさの問題ではなく、テスト設計そのものの抽象度が一段階上がっていることを意味します。
つまり、Seleniumが「操作手順を細かく制御するツール」であるのに対し、Playwrightは「状態ベースで振る舞いを記述するツール」として機能しているのです。

結果として、テストコードはより宣言的になり、可読性と保守性の両方が向上します。
これは長期運用を前提としたプロダクト開発において非常に大きな差になります。

自動待機（Auto-wait）がテスト安定性を劇的に改善する理由

E2Eテストの安定性を議論する際に避けて通れないのが「待機処理」の設計です。
従来のSeleniumでは、要素の描画完了やAPI応答のタイミングを開発者が明示的に制御する必要があり、その結果として環境依存のフレイキーテストが頻発していました。
これに対しPlaywrightが採用している自動待機（Auto-wait）は、テストの抽象度を一段階引き上げる重要な仕組みです。

自動待機の本質は、「操作が可能な状態になるまでフレームワーク側が責任を持つ」という設計にあります。
つまり、開発者は「いつクリックするか」を考えるのではなく、「クリックできるべき状態」を記述するだけで済むようになります。
この設計転換が、テストの安定性に直接的な影響を与えています。

明示的waitを削減するメリット

従来のテストコードでは、非同期処理やレンダリング遅延に対応するために明示的なwaitを挿入することが一般的でした。
しかしこの方法は、環境ごとの実行速度差やネットワーク遅延を正確に見積もることができないため、結果として「過剰に待つ」か「不足して失敗する」かの二択になりがちです。

例えば以下のようなコードは典型例です。

await page.waitForTimeout(3000);
await page.click('#submit');

このような設計は一見安全に見えますが、実際にはシステム状態ではなく時間に依存しているため、本質的な安定性を担保できません。
特にCI環境では実行速度が変動するため、この手法は長期的には信頼性を損ないます。

一方でPlaywrightの自動待機では、以下のように状態ベースで操作が行われます。

await page.click('#submit');

この一行の裏では、要素の可視性、クリック可能性、アニメーション完了などが自動的に検証され、条件が満たされるまで内部的に待機が行われます。
つまり、開発者は「時間」ではなく「状態」に集中できるようになります。

この違いは単なるコード量削減ではなく、テスト設計のパラダイムシフトです。
明示的waitを排除することで、以下のような効果が得られます。

まず、テストコードの可読性が向上し、意図が明確になります。
次に、環境依存の不安定要素が削減されるため、CI/CDパイプラインでの失敗率が低下します。
さらに、待機時間の調整という経験依存の作業が不要になるため、開発者の認知負荷も軽減されます。

結果として、自動待機は単なる便利機能ではなく、E2Eテストを「手続き的な時間制御」から「宣言的な状態検証」へと進化させる中核的な仕組みであると言えます。

セレクタ設計の最適化で壊れにくいE2Eテストへ

E2Eテストの安定性を左右する要素の中で、セレクタ設計は非常に重要な位置を占めています。
どれだけ優れたテストフレームワークを導入しても、要素の特定方法が不適切であれば、UIの軽微な変更だけでテストが崩壊します。
この問題はSelenium時代から一貫して存在しており、Playwrightへ移行した後も設計思想として改善しなければならない領域です。

セレクタ設計の本質は「UIの実装構造に依存するか、それとも意味的な構造に依存するか」という点にあります。
前者は脆く、後者は安定します。
したがって、テストの設計段階でどの抽象レイヤーに依存するかを明確に決定することが、長期的な保守性に直結します。

data-testid戦略の活用

近年のフロントエンド開発では、UI変更とテストの安定性を両立させるためにdata-testid属性を利用する手法が一般化しています。
これはDOM構造やCSSクラス名ではなく、テスト専用の識別子を付与することで、UIリファクタリングの影響を受けにくくする設計です。

例えば以下のような実装は、セレクタの安定性を大きく向上させます。

<button data-testid="submit-button">送信</button>

await page.click('[data-testid="submit-button"]');

この設計の利点は明確で、UIの見た目やレイアウトが変更されてもテストの意味的な意図が維持される点にあります。
つまり、テストは「ボタンの位置」ではなく「送信アクションそのもの」を検証する構造になります。

さらに重要なのは、data-testidを導入することでテストコードとUI実装の結合度を意図的にコントロールできるという点です。
これにより、プロダクトの進化とテストの安定性を両立させることが可能になります。

CSSセレクタ依存からの脱却

従来のテストではCSSセレクタを用いた要素指定が一般的でしたが、これは構造変化に極めて弱いという欠点があります。
特に.container > div:nth-child(2)のような指定は、UIのリファクタリングやコンポーネント分割のたびに壊れる典型例です。

CSSセレクタ依存の問題は、単に脆いというだけではなく、UI設計とテスト設計が密結合になる点にあります。
この状態ではフロントエンドの改善がテスト修正コストに直結し、結果として技術的負債が蓄積されます。

Playwrightを用いる場合でも、この問題の本質は変わりません。
フレームワークがどれだけ進化しても、セレクタ設計が不適切であればテストは不安定になります。
そのため、CSSセレクタではなく意味的セレクタ、すなわちrole属性やdata-testidのような安定した識別子への移行が重要です。

結果として、セレクタ設計の最適化とは単なる技術的改善ではなく、UIとテストの責務分離を明確にするアーキテクチャ上の判断であると言えます。

CI環境とGitHub ActionsでのPlaywright実行最適化

E2Eテストを本番運用レベルで安定させるためには、ローカル環境での動作確認だけでは不十分であり、CI（継続的インテグレーション）環境での実行最適化が不可欠です。
特にGitHub Actionsのような分散実行環境では、テストの実行時間、安定性、そして失敗時のデバッグ容易性が品質保証の重要な指標になります。
Playwrightはこの領域において非常に優れた設計を持っており、CIとの親和性が高い点が特徴です。

CI環境における課題の一つは、テストケース数の増加に伴う実行時間の肥大化です。
これを解決するためには、単純な最適化ではなく、テスト実行モデルそのものを見直す必要があります。
Playwrightはその点で並列実行と分離実行の仕組みが整っており、スケーラブルなテスト基盤を構築しやすくなっています。

並列実行によるテスト高速化

Playwrightは標準で並列実行をサポートしており、複数のテストを同時に実行することでCI全体の実行時間を大幅に短縮できます。
従来のSelenium環境では、並列化を実現するためにSelenium Gridのような外部インフラを構築する必要があり、その運用コストは決して低くありませんでした。

Playwrightではテストランナーが並列実行を前提として設計されているため、特別なインフラ構築なしにスケーラビリティを確保できます。
例えば以下のような設定により、テストを複数ワーカーで分散実行できます。

// playwright.config.js
module.exports = {
  workers: 4
};

この仕組みにより、テストスイート全体の実行時間を線形に近い形で削減できる可能性があります。
ただし重要なのは単なる高速化ではなく、テスト間の独立性が保証されているという設計的前提です。
状態共有を避けることで、並列実行時の不安定性を抑制しています。

失敗時のログ収集と可視化

CI環境で最も重要な要素の一つが、失敗時の原因特定能力です。
テストが失敗した際に原因が不明瞭であれば、デバッグコストが急激に増大し、開発速度に直接的な影響を与えます。
Playwrightはこの問題に対して、トレース機能、スクリーンショット、動画記録といった多層的なログ収集機能を提供しています。

特にトレース機能は、テスト実行時のDOM状態、ネットワーク通信、ユーザー操作を時系列で可視化できるため、単なるログ以上の価値を持ちます。
これにより、CI環境で発生した一時的な失敗も再現可能な形で分析できます。

またGitHub Actionsと組み合わせることで、失敗時に自動的にアーティファクトとしてログを保存する構成も容易に実現できます。
これにより、ローカル環境に依存せずに問題解析が可能となり、チーム全体のデバッグ効率が向上します。

結果として、CI環境におけるPlaywrightの最適化は単なる速度改善ではなく、品質保証プロセス全体の可観測性を高める取り組みであると言えます。

Playwrightのトレース機能でデバッグ効率を最大化する

E2Eテストにおいて最も時間を消費する工程の一つが、失敗原因の特定です。
特にCI環境で発生するフレイキーな失敗は再現性が低く、従来のログベースのデバッグでは原因追跡が困難になるケースが多く存在します。
Playwrightはこの問題に対して、トレース機能という強力な可視化基盤を提供しており、テストデバッグのアプローチそのものを変革しています。

従来のSelenium環境では、スクリーンショットやコンソールログを断片的に収集することが一般的でした。
しかしそれだけでは「どの操作の結果として失敗したのか」を正確に追跡することが難しく、結果として試行錯誤的なデバッグに依存してしまう傾向がありました。
Playwrightのトレース機能はこの問題を構造的に解決します。

ステップ単位の実行可視化

Playwrightのトレース機能の中心的な価値は、テスト実行をステップ単位で完全に再現できる点にあります。
各操作がどのような順序で実行され、その時点でDOMがどのような状態であったのか、ネットワーク通信がどう発生していたのかを時系列で確認することができます。

例えば、以下のようなテストがあったとします。

await page.goto('https://example.com');
await page.click('#login');
await page.fill('#email', 'test@example.com');
await page.click('#submit');

この一連の操作はトレースビューア上でステップごとに分解され、それぞれの時点でのスクリーンショット、DOM構造、ネットワークイベントが紐づけられます。
これにより、単なる「失敗した」という結果ではなく、「どのステップで、どの状態変化が原因で失敗したか」を明確に特定できます。

この可視化の利点は単なるデバッグ効率の向上に留まりません。
むしろ重要なのは、テストの設計品質そのものを改善できる点にあります。
トレースを前提にテストを書くことで、無駄な操作や不安定な前提条件を早期に発見できるため、結果としてテスト全体の品質が向上します。

さらに、トレースはCI環境と組み合わせることでその価値が最大化されます。
失敗時に自動的にトレースファイルを保存し、後からブラウザベースで再生できるため、ローカル環境に依存しない完全な再現性が確保されます。
これは分散開発環境において極めて重要な特性です。

結果として、Playwrightのトレース機能は単なるデバッグ支援ツールではなく、E2Eテストの「観測可能性」を根本から引き上げる基盤技術であると言えます。

SeleniumからPlaywrightへの移行戦略と実践ポイント

SeleniumからPlaywrightへの移行は単なるツールの置き換えではなく、E2Eテスト設計のパラダイムそのものを更新する作業になります。
そのため一括移行のようなアプローチは現実的ではなく、既存システムへの影響を最小化しながら段階的に進める設計が重要になります。
特に大規模プロジェクトでは、テスト資産が複雑に絡み合っているため、慎重な移行戦略が求められます。

移行の本質は「テストの再実装」ではなく「テストの責務再定義」です。
Selenium時代のテストは実装詳細に依存しているケースが多いため、そのまま移行するとPlaywrightの恩恵を十分に活かせません。
したがって、移行プロセスではテストの抽象度を上げる作業が並行して必要になります。

段階的移行のすすめ

現実的な移行戦略として最も有効なのは、段階的な共存アプローチです。
まずは新規に追加されるテストケースからPlaywrightで実装し、既存のSeleniumテストは維持しながら徐々に置き換えていく方法が安定しています。
このアプローチにより、システム全体のテストカバレッジを維持しつつリスクを分散できます。

特に重要なのは、テスト対象を機能単位で分割し、影響範囲を明確にすることです。
例えば認証系、UI操作系、API連携系などの単位で優先順位を決めることで、移行の進行状況を可視化できます。

また、移行期間中はSeleniumとPlaywrightが混在するため、CIパイプラインの設計も工夫が必要になります。
両者の実行結果を統合的に管理し、テスト失敗の原因を明確に分離できる構成が望ましいです。

既存テスト資産の活用方法

移行時に最も懸念されるのは既存のSeleniumテスト資産の扱いですが、これらを完全に破棄する必要はありません。
むしろ、テストロジックの再利用可能な部分を抽出し、Playwright向けに再構成することで効率的な移行が可能になります。

例えば、ページ遷移のシナリオや入力データの定義などはフレームワーク非依存の形に分離することで、再利用性が高まります。
一方でセレクタや待機処理などのフレームワーク依存部分は、PlaywrightのAPIに合わせて再設計する必要があります。

このとき重要なのは、単純なコード変換ではなく「テストの意図を保持したまま再実装する」という視点です。
Seleniumの実装をそのまま移植するのではなく、Playwrightの宣言的なモデルに適合させることで、初めてその価値が発揮されます。

結果として、移行プロセスは単なる技術的作業ではなく、テストアーキテクチャ全体の再設計プロジェクトとして位置付けるべきです。
これにより、将来的な保守性と拡張性を同時に確保することが可能になります。

SeleniumとPlaywrightのE2Eテストツール比較

E2Eテストの領域において、SeleniumとPlaywrightはしばしば比較対象として語られますが、その違いは単なるツールの世代差にとどまりません。
両者は設計思想そのものが異なっており、テストの安定性、開発体験、CI適性、デバッグ容易性といった複数の観点で明確な差が存在します。
特に現代のフロントエンド開発においては、アーキテクチャの変化に伴い、Playwrightの優位性がより顕著になっています。

Seleniumは長い歴史を持つ成熟したフレームワークであり、多くの言語やブラウザをサポートする汎用性の高さが強みです。
しかしその一方で、ブラウザ制御が外部ドライバ経由で行われるためオーバーヘッドが大きく、テスト実行の不安定性や待機処理の複雑さといった課題を抱えています。

一方でPlaywrightは、ブラウザとの通信レイヤーをより低レベルで直接制御する設計となっており、結果として高速かつ安定した実行が可能になっています。
また、待機処理やリトライ処理がフレームワーク側に統合されているため、テストコードの複雑性が大幅に低減されます。

両者の違いを整理すると以下のようになります。

Seleniumは外部ドライバ経由のため柔軟性は高いがオーバーヘッドが大きい
Playwrightはブラウザ制御が統合されており高速かつ安定性が高い
Seleniumは明示的waitが必要だがPlaywrightは自動待機を標準装備
Seleniumは環境依存のフレイキーが発生しやすいがPlaywrightは再現性が高い

この違いは単なる実装差ではなく、テスト設計の抽象レベルそのものに関係しています。
Seleniumは「操作手順を細かく記述する命令型モデル」であるのに対し、Playwrightは「状態を記述する宣言型モデル」に近い構造を持っています。
この違いが、長期的な保守性と安定性に大きな影響を与えます。

また、CI/CD環境での運用という観点でも差は明確です。
SeleniumではSelenium Gridなどの追加インフラが必要になるケースが多く、構築・運用コストが高くなりがちです。
一方Playwrightは単体で並列実行やクロスブラウザテストをサポートしており、追加インフラなしでスケーラブルなテスト基盤を構築できます。

さらにデバッグ体験にも差があります。
Seleniumではログとスクリーンショットに依存するケースが多いのに対し、Playwrightはトレース機能や動画記録を標準で備えており、失敗時の原因特定が圧倒的に容易です。
この差は開発速度に直結する重要な要素です。

総合的に見ると、Seleniumは「柔軟だが手間がかかる汎用ツール」、Playwrightは「制約を設計側で吸収したモダンな統合ツール」という位置づけになります。
特にフロントエンドの複雑化が進む現在では、Playwrightの設計思想がより現実的な選択肢になりつつあります。

ただしSeleniumが完全に不要になるわけではなく、レガシー環境や既存資産の規模によっては依然として有効です。
重要なのはツールの優劣ではなく、プロジェクトの特性に応じて適切な抽象レベルを選択することです。
E2Eテストは単なる自動化ではなく、システムの信頼性を支える基盤であるため、その設計判断は慎重に行う必要があります。

Seleniumを捨てるべきか：Playwright時代のテスト戦略まとめ

SeleniumからPlaywrightへの移行が注目される中で、多くの開発チームが直面する本質的な問いは「Seleniumを完全に捨てるべきかどうか」という点です。
しかしこの問いに対する答えは単純ではなく、プロジェクトの成熟度、既存資産の規模、そしてテスト戦略の目的によって大きく異なります。
重要なのはツールの優劣ではなく、システム全体の品質保証戦略としてどのように位置付けるかという視点です。

まず前提として理解すべきなのは、PlaywrightはSeleniumの単純な置き換えではなく、E2Eテストにおける設計思想そのものを更新するフレームワークであるという点です。
自動待機、トレース機能、並列実行、クロスブラウザ対応といった機能は、従来のSeleniumが抱えていた問題を個別に解決するのではなく、構造的に吸収する方向で設計されています。

一方でSeleniumも依然として重要な役割を持ち続けています。
特に長期間運用されているレガシーシステムや、特定のブラウザ環境に強く依存したテストケースでは、既存のSelenium資産をそのまま活用する方が合理的な場合があります。
したがって現実的な戦略としては「完全移行」ではなく「段階的共存」が中心になります。

この段階的アプローチにおいて重要なのは、テスト戦略を明確に分離することです。
例えば以下のような観点で役割を整理することが有効です。

新規機能のE2EテストはPlaywrightで構築する
既存レガシー機能はSeleniumで維持する
CIパイプラインでは両者を統合的に管理する
テスト設計はUI依存から状態依存へ移行する

このように役割を分離することで、移行リスクを最小化しながら徐々にPlaywright中心の構成へ移行できます。

さらに重要なのは、テストの役割そのものを再定義することです。
従来のE2Eテストは「操作の再現」に重点が置かれていましたが、Playwright時代においては「システム状態の検証」が中心になります。
この変化により、テストはより宣言的になり、UIの細部変更に対する耐性が大幅に向上します。

また、CI/CDとの統合という観点でも戦略は変わります。
Seleniumでは外部インフラ依存が強く、スケーラビリティに制約がありましたが、Playwrightは単体で並列実行やトレース収集を行えるため、CI環境の設計自由度が高くなります。
これにより、テスト実行時間の短縮だけでなく、失敗分析の効率も向上します。

結論として、Seleniumを完全に捨てるかどうかは二者択一の問題ではありません。
むしろ重要なのは、以下のような段階的な移行戦略を採用することです。

新規開発はPlaywrightを標準とする
既存資産は段階的にリファクタリングする
テスト設計を状態ベースに統一する
CI環境で両フレームワークを統合運用する

このようなアプローチにより、リスクを抑えながら次世代のE2Eテスト基盤へ移行することが可能になります。
最終的に重要なのはツールの選択ではなく、テストがプロダクト品質をどれだけ安定的に支えられるかという一点に尽きます。
Playwrightはそのための強力な選択肢であり、Seleniumはその過渡期を支える現実的な基盤として位置付けるのが合理的です。