はじめに
本記事は、前回の記事「Playwrightへの移行 〜ノーコードツールから乗り換えた理由と、その裏側〜」
の続編です。 前回は、私がノーコードツールからPlaywrightへの移行を決断した背景や、準備・設計段階での工夫についてお話ししました。
今回はその続きとして、移行プロジェクトの現場で実際に直面したリアルな課題や、それをどう乗り越えてきたのか、そしてその過程で得られた実践的な運用ノウハウやTipsをご紹介します。
この記事が、すでにE2E自動化やPlaywrightを使い始めている方、そして実装や運用で壁にぶつかっている方にとって、私の失敗や成功の記録が、次の一歩を踏み出すためのヒントになれば嬉しいです。
私が直面した、3つの大きな壁
移行プロジェクトの道のりは、決して平坦ではありませんでした。ここでは、特に印象に残っている「壁」と、それをどう乗り越えたのかというエピソードをご紹介します。
壁1：VSCode拡張機能とCI環境の差分問題
Playwrightの実装初期、私はVSCode拡張機能を使ってテストを実行していました。ボタン一つでテストが実行でき、デバッグも簡単。画面上でテストの進行状況を追いかけられるため、「これは開発効率が良いぞ」と感じていました。しかし、その安堵はプロジェクトの中盤、もろくも崩れ去ります。
本番運用を想定し、CI環境と同じコマンド実行に切り替えた瞬間、それまで成功していたテストが大量に失敗したのです。拡張機能の実行では何の問題もなかったのに、なぜ…？原因がすぐには分からず、本当に戸惑いました。
「なぜ実行方法が違うだけで、こんなにもテストが落ちるんだ？」 「一体どこから手を付ければいいんだ…？」
並列実行の挙動、headlessモードの特性、タイムアウト設定の微妙な違い。そういった実行環境ごとの小さな差分が積み重なり、テストの安定性を大きく損なっていたのです。まさか、開発初期の「楽なやり方」が、後になってこれほど大きな壁になるとは、想像もしていませんでした。
この苦い経験から私が得た、たった一つの、しかし最も重要な教訓。それは、「テストの実行方法は、最初から本番（CI環境）と同じにすべし」ということです。
この一件以来、開発の早い段階から本番に近い環境でテストを実行する運用ルールを徹底しました。遠回りに見えても、それが一番の近道だったのです。
壁2：終わりが見えない… ノーコードツールとPlaywrightの並行運用
移行期間の中盤からは、既存のノーコードツールと新しいPlaywrightの両方を、同時にメンテナンスする必要がありました。ツールが違えば、仕様も作法も異なります。細かな対応漏れや混乱が起きやすく、完全移行が完了するまでの間は、常に神経を尖らせていました。
「あ、ノーコードツール側のシナリオ修正を忘れてた…」 「Playwright用に用意したテストデータが、ノーコードツールのテストに影響しちゃってる！」
一つのことに集中すると、もう一方が疎かになる。そんな状況が続き、現場の負担は決して小さくありませんでした。
この状況を乗り切るために採った戦略は、「今は何を優先するのか、チームで都度、明確に決める」ことでした。例えば、プロダクトの大型リリース前はノーコードツールでの安定運用を最優先し、Playwrightへの移行作業は一時的にストップする。状況に応じてリソース配分を柔軟に調整していきました。
Playwrightのテストがなかなか安定せず、我慢の時間が続きましたが、この「優先順位付け」によって混乱を最小限に抑え、着実に移行を進めることができたと感じています。
壁3：個々の環境差分
当初、テストはそれぞれのローカル環境で実行していました。しかし、CI/CDパイプライン（GitHub Actions）に組み込んだり、他のメンバーがローカルで実行したりすると、新たな問題が発生しました。
「自分のPCでは動くのに、AさんのPCだとエラーになる…」 「CI上だと、なぜかタイムアウトする…」
これらの経験から、個人の環境に依存しない、誰でも同じ結果を再現できる仕組みの重要性を痛感しました。
現在は、誰が実行しても同じようにテストができる体制を目指し、実行環境やテストデータの整備、ドキュメントの拡充を進めています。テストの属人化を防ぐこともまた、品質を守る上で欠かせない要素なのです。
現場で本当に役立った、実践Tips集
ここからは、移行作業を乗り切る上で、特に役立った実践的なTipsをご紹介します。
Tips1：生成AI
1つ目はもはや当然すぎるかもしれませんが、生成AIの活用です。私はこのプロジェクトが始まるまでTypeScriptをほとんど書いたことがありませんでした。新しい言語やツールに挑戦する時、文法や設計でつまずくことは少なくありませんが、AIを「いつでも隣にいてくれるベテランエンジニア」のように活用することで、学習コストを大幅に削減し、心理的なハードルもぐっと下げることができました。
E2Eテスト自動化のプロジェクトは経験があったので、大体のやることのイメージはありましたが、生成AIを使用することで効率的に具体に落とし込むこともできました。
もちろん、ただ便利だっただけではありません。時には思い通りの出力をなかなかしてくれず、特にローケーターの取得などでは、期待通りのコードを出力してもらうために、提供するHTML構造や追加情報をどう調整するか、試行錯誤を繰り返しました。 この経験こそが、AIを使いこなす上での重要な学びになりました。そしてこの知見は、今後、コーディング未経験のQAメンバーへメンテナンスを引き継いでいく上で、効果的なオンボーディングに繋がると考えています。
Tips2：Playwright Inspector
実装を進める上で、最も役立ったのが「Playwright Inspector」です。--debugオプションを付けて実行するだけで起動するこのツールは、私の実装時のデバッグ作業を劇的に効率化してくれました。
# Playwright Inspectorの実行コマンド npx playwright test --debug
Playwright Inspectorのどこがそんなにすごいのか、特に役立ったポイントを絞ってご紹介します。
- ステップ実行: テストを一行ずつ止めながら、どこで問題が起きているのかを正確に特定できます。
- Pick Locator: ブラウザ上で要素をクリックするだけで、最適なロケータを提案してくれます。「このロケータで合ってるかな？」という試行錯誤の時間がなくなりました。
- リアルタイム編集: Inspector上でロケータを書き換えると、即座にブラウザ上でどの要素を指しているかハイライトしてくれます。これが非常に便利！
- Actionability Logs: 「なぜクリックが失敗したのか」の理由（まだ表示されていなかった、など）を、詳細なログで教えてくれます。
タイムアウトエラーや要素が見つからないエラーの調査では、Inspectorがなければ原因特定に何倍もの時間がかかっていたでしょう。Playwrightを使うなら、絶対にマスターすべき機能だと断言できます。
Tips3：Trace Viewer
Playwright Inspectorと合わせて活用しているのが「Trace Viewer」です。失敗したテストの原因調査で、特に役立っています。
Inspector が「リアルタイムでのデバッグ」に適しているのに対し、Trace Viewer は「事後分析」に向いています。テスト実行時にトレースを記録しておけば、後からテストの実行過程を詳しく振り返ることができます。
# トレースを記録してテスト実行 npx playwright test --trace=on
Trace Viewerで確認できること
- 実行履歴: テストがどの順番で何を実行したか、タイムラインで確認できます
- スクリーンショット: 各ステップでの画面状態を記録
- ネットワーク通信: APIの呼び出しやレスポンスの詳細
- コンソールログ: ブラウザで発生したエラーやwarningの記録
私の場合、「時々失敗する」テストの原因をTrace Viewerで特定できたことがありました。APIレスポンスのタイミングが原因でした。リアルタイムでは気づきにくい問題も、後から落ち着いて分析することで見つけられる場合があります。
チーム内での共有も簡単
traceファイル（.zip形式）は他のメンバーと共有できるため、テストの状況を具体的に見せながら相談できます。文字だけでは説明しにくい複雑な状況も、実際の画面を見せることで理解してもらいやすくなります。
Inspector とTrace Viewer、この2つのツールを使い分けることで、デバッグ作業がかなり効率化されました。
今後の展望
より安定したテストを目指して
UI要素を特定するためのロケータ指定は、テスト安定性の要です。現状、Playwrightが推奨する方法でも取得が難しい要素に対しては、waitForTimeout（指定時間待つ）のような暫定対応に頼らざるを得ない場面もあります。
これは根本的な解決策ではないため、今後は、プロダクト側のコードにテスト用のID（data-testidなど）を付けてもらうよう、開発チームとの連携をさらに強化していきたいと考えています。
安定したテストは、テストコードだけで完結するものではありません。開発チームを巻き込み、プロダクト自体を「テストしやすい設計」にしていくこと。この視点が長期的な保守性を大きく左右すると信じており、これからの重要な取り組みの一つです。
Playwright MCPの導入
すでにご存知の方や、導入されているプロジェクトも多いかと思いますが、弊社においてもE2Eテスト自動化のあり方をさらに進化させるべく、Playwright MCPの活用を始めています。
実際に業務で使い始めてみると、非常に興味深い発見がありました。
一つは、ページオブジェクトモデルの作成が驚くほど簡単になることです。前回の記事で「完璧を目指さないコード設計」について書きましたが、MCPを使えば、その共通化の設計・実装の手間を大幅に削減できる可能性を感じています。
しかし、MCPの得意・不得意も見えてきました。既存のテストに手を加えるような「追加・修正」のタスクは失敗しがちな一方で、まっさらな状態からMCPのプロセスに寄り添うように進めると、特にページオブジェクトの作成などは驚くほどスムーズに進む傾向があります。LLMの思考プロセスに合わせた付き合い方が求められるのかもしれません。
もちろん、上記の不得意なこと以外でも課題はあります。MCPは時に大量のコードを出力するため、その内容が正しいかを一つひとつ検査していくのが大変、という現実的な課題もあります。
まだまだ試行錯誤の段階ですが、この新しい技術をどう乗りこなし、E2Eテスト自動化の未来をどう作っていくか。非常にエキサイティングな挑戦だと感じています。
おわりに
E2Eテスト自動化の運用は、時に予期せぬ困難が伴う、挑戦の連続です。 しかし、現場で直面した一つひとつの失敗は、今後の運用に対して教訓となり、かけがえのない財産になりました。
この前後編にわたる奮闘記が、今まさに同じような壁にぶつかっている方や、これから挑戦しようとしている方にとって、何か少しでも「自分たちだけじゃないんだ」という安心感や、次の一歩を踏み出すためのヒントになればと思います。
つまずいた時は、一人で抱え込まず、チームの仲間や、今回ご紹介したような便利なツールの力を借りながら、一歩ずつ前に進んでいきましょう。 私自身も、これからも現場のリアルな声を発信し続けていきたいと思います。
