Playwright 1.56の新機能紹介 – AIエージェントや新APIなど最新機能を徹底解説

Playwright 1.56の新機能紹介 – AIエージェントや新APIなど最新機能を徹底解説

2025年にリリースされたPlaywrightバージョン1.56では、エンドツーエンドテスト自動化をさらに強化する多数の新機能が導入されました。中でも注目はPlaywright Test Agentsと呼ばれるAI搭載のテスト自動生成機能で、LLM（大規模言語モデル）を用いてテストケースのプランニングからコード生成・修復まで自動化します。加えて、テスト開発者向けに新しいAPIも複数追加されました。例えば、ページ上の直近のコンソールログを取得できるpage.consoleMessages()やページエラー取得用のpage.pageErrors()、ネットワークリクエスト一覧を得られるpage.requests()メソッドが新設されています。さらにコマンドラインオプションにも強化があり、テストファイル内の特定のテストだけを実行指定できる–test-list/–test-list-invertフラグが追加されました。これらに加え、UIモードやHTMLレポーターの機能向上（レポート統合表示オプションなど）も行われています。総じてPlaywright 1.56は、AI支援によるテスト生産性の向上とテスト管理機能の拡充が図られたリリースと言えます。

Playwright Test Agents（エージェント）とは？AI搭載の自動テスト生成機能の概要を詳しく解説

Playwright Test Agents（以下エージェント）とは、Playwright 1.56で導入されたAI駆動の自動テスト生成システムです。これは予め定義された3種の「エージェント」（Planner・Generator・Healer）が協調して、アプリケーションの探索からテストコード作成・失敗テストの修正までを自動で行う仕組みです。具体的には、Planner（プランナー）がアプリを探索してテスト計画（プラン）を作成し、Generator（ジェネレータ）がそのプランを元にPlaywrightのテストコードを生成、そしてHealer（ヒーラー）がテストを実行して失敗した箇所を自動修正します。これらエージェントは単独でも順番に連携させても使うことができ、まるでAIエージェントが人の代わりにテスト設計・実装・デバッグを行ってくれるような体験を提供します。
エージェント機能を利用するには、まずプロジェクト内にエージェント定義ファイルを生成するセットアップが必要です。PlaywrightのCLIコマンドnpx playwright init-agentsを実行すると、使用するAIクライアントに合わせたエージェント定義（プロンプトやツールの指示集）がプロジェクトに追加されます。例えばVS Code上でGitHub Copilotを使う場合は–loop=vscodeオプションを付けてコマンドを実行し、Claudeを使う場合は–loop=claudeを指定するといった具合です。これによりエージェントの設定が整ったら、あとはお使いのAIツール上でエージェントに指示を与えることで、自動テスト生成フローがスタートします。要するにPlaywright Test Agentsは、テスト開発におけるLLM活用を容易にするための土台とガイドを提供し、AIが人間の代わりにテストコードを書くのを支援する画期的な仕組みと言えるでしょう。

プランナーエージェントの使い方・活用例 – AIがテストプランを自動生成する方法とその効果を具体例で詳しく解説

3つのエージェントのうち最初の工程を担うプランナーエージェント（Planner）は、アプリケーションを実際に操作・探索してテストプラン（計画書）を自動生成します。使い方としては、まずプランナーに対してテスト化したいシナリオを明確にリクエストします（例：「ゲストチェックアウトフローのテストプランを作成して」など）。加えて、シードテストと呼ばれる初期化用のテストファイルを用意しプランナーに与えます。このシードテストにはテストに必要なログインやフィクスチャのセットアップ処理などを記述し、プランナー実行時にまずそれが実行されることでアプリの初期状態が整えられます。必要に応じて製品仕様書や要件ドキュメントなどを追加コンテキストとして渡すこともできます。
プランナーエージェントを起動すると、上記の情報を基に自動的にアプリを操作しながらテストすべきポイントを洗い出し、最終的にMarkdown形式のテストプラン文書を生成します。出力されたプランはspecs/○○.mdといったファイルに保存され、人間が読める記述でありながらテスト生成ツールにとって十分に厳密な手順書となっています。例えばTodoMVCサンプルアプリに対してプランナーを実行した場合、「アプリ概要」「テストシナリオ一覧」といったセクションが含まれる計画書が得られます。シナリオ例として「1. 新規Todoアイテムの追加」などの項目が挙げられ、それぞれについて前提状態（シード:testファイル）や操作手順、期待結果が箇条書きで整理されます。このようにプランナーエージェントを活用すると、テスト担当者が一から手動でテストケースを書き起こす手間を大幅に削減でき、見落としがちなシナリオも網羅した詳細なプランを短時間で得ることができます。

Playwrightのセットアップ手順 – 環境構築からプロジェクト導入までの具体的ステップ

ここではPlaywrightを新規プロジェクトに導入し、テスト環境を構築する手順を説明します。前提条件としてNode.jsがインストールされている必要があります（PlaywrightはNode.js版の他、Python版やJava版等も提供されていますが、本ガイドではNode.jsを前提にします）。手順は次のとおりです。

1.Playwrightのインストールと初期化

プロジェクトディレクトリを用意し、ターミナルでそのディレクトリに移動してから、次のコマンドを実行します。
npm init playwright@latest
これは新規にPlaywrightテストプロジェクトを作成するための公式コマンドで、既存プロジェクトに追加する場合にも利用できます。コマンドを実行すると対話式にいくつか質問が表示されます。例えば「TypeScriptまたはJavaScriptのどちらでテストを書くか」（デフォルトはTypeScript）、テストディレクトリ名（デフォルトはtests）、GitHub Actions用のCI設定ファイルを追加するか、ブラウザをインストールするか（デフォルトではい）等です。質問に答えるかデフォルトのままEnterキーを押し進めると、必要な依存パッケージのインストールとブラウザのダウンロードが行われます。

2.プロジェクト構成の確認

インストール完了後、Playwrightが自動生成したプロジェクト構成を確認しましょう。主なファイル・フォルダ構成は以下のようになっています。

• playwright.config.ts – Playwrightの共通設定ファイル。テスト対象ブラウザやタイムアウト、レポーター設定などを集中管理します。
• package.json / package-lock.json – Node.jsのパッケージ管理ファイル（Playwright試験フレームワークや関連ツールが依存として追加されています）。
• tests/ フォルダ – テストコードを配置するディレクトリ（対話形式で指定した名前）。初期状態ではサンプルとしてexample.spec.tsという簡単なテストが入っています。
• tests-examples/ フォルダ – いくつかのサンプルテストを含むディレクトリ。例えばTodoアプリを操作する少し凝ったテストケースdemo-todo-app.spec.ts等があり、Playwrightの書き方の参考になります。

以上が自動生成されたファイル群です。既存のプロジェクトにPlaywrightを追加した場合は、tests/配下に上記サンプルテストが追加され、既存のpackage.jsonに必要スクリプトが追記されます。
テストの実行確認: セットアップが正常に完了したら、サンプルテストが正しく動作するか実行してみましょう。ターミナルで次のコマンドを実行します。
npx playwright test
するとデフォルト設定ではChromium、Firefox、WebKitの3ブラウザでテストが並列実行されます。特にオプションを指定しなければヘッドレスモード（画面非表示）で動作し、各ブラウザごとのテスト結果がターミナル上に表示されるはずです。全テストがパスすればセットアップ成功です。仮に失敗した場合でも、Playwrightはどのブラウザのどのテストで失敗したかを示し、エラーメッセージやスタックトレースで原因を追跡できます。また、デフォルトで失敗時にはHTML形式のレポートが生成されます。終了後にnpx playwright show-reportコマンドを実行すれば、ブラウザで詳細なレポートを確認することも可能です。
以上が基本的なセットアップ手順です。なお、Visual Studio Codeを利用している場合は公式拡張機能を使ってGUI上でPlaywrightプロジェクトを作成・実行することもできます。

初回テスト作成方法 – Playwrightで最初のE2Eテストをゼロから作成・実行する手順を丁寧に徹底解説

セットアップが完了したら、実際にPlaywrightでE2Eテストを書いてみましょう。初回のテスト作成では、公式サンプルを参考にしつつ基本的な構文に慣れることが大切です。ここではシンプルな例として「特定のページにアクセスしてタイトルを検証する」テストを一から作成する手順を解説します。

テストファイルの作成

プロジェクトのtests/ディレクトリに、新しくfirst-test.spec.ts（TypeScriptの場合）という名前のファイルを作成します。拡張子はTypeScriptなら.ts、JavaScriptなら.jsを使用します。ファイルができたら、次のようにコードを記述します。
import { test, expect } from '@playwright/test';
test('Exampleドメインのタイトル確認', async ({ page }) => {
// 指定URLへブラウザで移動
await page.goto('https://example.com');
// ページタイトルに「Example Domain」という語が含まれることを期待
await expect(page).toHaveTitle(/Example Domain/);
});
上記では、まずPlaywrightのテスト用オブジェクトtestとアサーションexpectをインポートしています。続いてtest()関数を使い、テストケースの名前（ここでは’Exampleドメインのタイトル確認’）と非同期のテスト関数を定義しています。関数の引数{ page }はPlaywrightが提供するブラウザページオブジェクトで、これを使ってページ遷移や要素操作を行います。page.goto()で指定URLに移動し、expect(page).toHaveTitle(/Example Domain/)でページタイトルに特定文字列が含まれることを検証しています。toHaveTitleのようなPlaywrightのアサーションは対象要素が条件を満たすまで自動で待機するため、明示的なwaitのコードを書く必要がない点が特徴です。
テストの実行: テストコードが書けたら実行してみます。先ほどと同様にターミナルでnpx playwright testを実行すると、新たに追加したテストが実行されます。特定のテストファイルだけを実行したい場合は、例えばnpx playwright test tests/first-test.spec.tsのようにパスを指定することも可能です。実行結果としてターミナルに各ブラウザでテストがパスした旨が表示されれば成功です。もし失敗した場合、エラーログに加えてPlaywrightの便利なデバッグ機能を活用できます。例えば、失敗したテストに対しては–debugオプションを付けて再実行すると、対話的にブラウザを開いてデバッグモードでテストをステップ実行できます。また、–uiオプションでPlaywrightのUIモードを起動すれば、テスト結果の一覧や失敗時のスクリーンショット・トレースを確認しながらテストを再試行できます。
以上が初歩的なE2Eテストの作成と実行手順です。シンプルなテストを書いてみることで、Playwrightの基本的な書式（test関数やexpectによる検証）や自動待機機能を体感できたと思います。慣れてきたら、フォーム入力やクリック操作、複数ページにまたがるユーザーフローなど、段階的にシナリオを拡大してテストを書いてみるとよいでしょう。

Playwright MCP（自動化エンジン）概要 – AIとブラウザを繋ぐMCPサーバーの仕組みを詳しく解説

Playwright MCP（Model Context Protocol）は、AIエージェントと実ブラウザを繋ぐためのサーバーコンポーネントで、いわばAIのためのブラウザ操作エンジンです。MCPサーバーを起動すると、LLMのようなAIエージェントがPlaywright経由でブラウザを操作できるようになります。具体的には、AIが「ページを開く」「クリックする」といったブラウザ操作コマンド（ツール）を発行すると、MCPサーバーが裏でPlaywrightを用いて実際のブラウザにその操作を実行させ、結果をAIにフィードバックします。フィードバックの内容には、操作後のページDOMやスナップショット画像、現在のURLやタイトル、さらには指定要素の特定に使える参照IDなど、次の判断に有用な豊富なコンテキスト情報が含まれます。この仕組みによりAIはまるで自身でブラウザを見て操作しているかのようにウェブアプリケーションと対話できるのです。
MCPサーバーが解決しようとしている課題は、「AIに実環境でウェブを操作・観察させる」ことです。従来のLLMはテキストベースの推論しかできませんでしたが、MCPに対応したクライアント（例: VS Code＋Copilot Chatなど）では、AIが必要に応じてブラウザ操作ツールを呼び出し、得られたページの状態をプロンプトに取り込んで会話を続行できます。その結果、AIはUIの変化を確認しながら次のアクションを決定でき、より正確なテストコードや操作シーケンスの生成が可能になります。
MCPの活用例としては、まず前述のPlaywright Agentsによる自動テストケース生成があります。Planner/Generator/Healerのエージェントループ内で、AIがMCP経由でアプリを探索・操作することで新規テストケースを発見・生成できます。また、手動テストの自動化にも応用可能です。例えばテスト担当者がシナリオを文章でAIに伝えると、AIがMCPを使ってその操作を実行し、検証コードを生成するといった使い方です。さらに、GitHub CopilotのコーディングエージェントではMCPが組み込まれており、プルリクエスト上の変更に対してAIがブラウザでアプリを起動・操作し、変更箇所が正しく機能するかを自動検証するという高度なことも実現しています。このようにPlaywright MCPは、AIによる「実際のブラウザを使った開発・テスト支援」を可能にする基盤技術であり、今後のAI活用型テスト自動化のキーとなるでしょう。

AI連携によるテスト自動生成 – LLMを活用した自動テストコード生成の可能性と課題

ChatGPTやGPT-4などのLLM（大規模言語モデル）をテスト自動化に活用する試みは、Playwright AgentsやMCPの登場により現実味を帯びてきました。その可能性とメリットとしてまず挙げられるのが、テストケース作成の効率化です。人間が日本語や英語で書いたテスト要件（シナリオ）をAIが理解し、自動でPlaywrightのテストコードを吐き出してくれれば、テスト実装にかかる時間は大幅に短縮されます。特に繰り返しの多いパターンテストや、初期のラフなテストケース生成にはAIが非常に有用でしょう。また、AIはプロジェクト内のコードや仕様を学習データとして取り込めるため、プロジェクト固有のユーティリティ関数やドメイン知識を踏まえたテストを提案・生成してくれる可能性もあります。これは単純な録画ツールでは得られないAIならではの利点です。
さらに、AIがアプリケーションを自動探索して潜在的なテストシナリオを発見してくれる点も見逃せません。通常、テスト設計者のバイアスで見落としていたようなエッジケースを、AIエージェントがMCP経由でUIを操作しながら見つけ出し、「こういうケースもテストできますがどうしますか？」と提案してくれる未来も期待できます。加えて、GitHub Copilotの例に見られるように、コード生成とテスト実行・検証をセットでAIが行う自己フィードバック型の開発も実現しつつあります。これは新機能の実装→テスト→結果確認までをAIがひと通り行い、人間はそれをレビューするだけという効率的なフローで、将来的に開発生産性を大きく向上させる可能性があります。
しかし、一方で課題や注意点も多く存在します。まず信頼性の問題として、AIが生成したテストが意図した通りの検証を行っている保証はありません。例えば「ヘッダーナビゲーションのリンクをクリックして」と指示したのに、AIが誤ってフッターの似たリンクをクリックしてしまってもテスト自体は通ってしまうことがあります。AIは目的達成のために予期せぬ操作フローを選択する可能性があるため、生成されたテストコードがきちんと仕様を満たしているか人間のレビューが不可欠です。実際、AI生成コードは常にレビュープロセスを経るべきであり、テストコードも例外ではありません。また、曖昧な指示によるテストの不備にも注意が必要です。人間が大雑把なテストシナリオ（例：「商品をカートに追加して購入するテスト」）だけを与えた場合、AIはシナリオを補完しながらテストを作りますが、その過程でアプリ上のバグを見落とす恐れがあります。例えば本当は特定ページの「カートに追加」ボタンが壊れていても、AIが別のページ経由でカート追加に成功してしまえばテストは緑になり、バグが検知されないという事態も起こりえます。このようにAI生成テストが必ずしもアプリの問題を検出できるとは限らない点に注意が必要です。
さらに、生成速度やコストの問題もあります。Playwrightのコード生成（Codegen）と比べて、LLMを使ったテスト生成は内部で何度もAPI呼び出しや思考プロセスを経るため、場合によってはテスト1本作るのに数分要することもあります。ただしAIは人手では難しい大量の文脈を考慮できるため、その時間が価値あるテストケース創出につながるなら許容範囲とも言えます。最後に、保守性の課題として、AIに頼りすぎるあまりテストコードの中身を人間が把握していない状態になるのは避けるべきです。プロンプトの工夫やエージェント定義のアップデートは継続的に行い、生成されたテストも定期的に人間が実行結果を確認する運用が望ましいでしょう。
以上のように、LLMによる自動テスト生成は革新的な可能性を持ちながらも、現時点では人間の知見によるチェック＆バランスが不可欠です。「AIに全部任せきり」ではなく、あくまでテスト自動化エンジニアの生産性を高めるアシスタントとしてAIを位置づけ、上手に活用していくことが重要と言えます。

日本語環境での動作検証 – ロケール設定や文字入力など、日本語対応テストのポイントと注意点

日本語対応のウェブアプリケーションをPlaywrightでテストする際には、いくつか留意すべきポイントがあります。主なものを順に説明します。

ロケール（言語・地域）設定

デフォルトではPlaywrightは実行環境（ホストOS）のロケールと言語設定をそのまま使用します。開発マシンやCIサーバーのロケールが英語だと、テスト中のブラウザも英語環境として動作し、日本語表示や日付・通貨のフォーマットが期待通りでない可能性があります。この問題を避けるため、テスト実行時にブラウザのロケールを強制的に日本（ja-JP）に指定することが推奨されます。Playwrightではbrowser.newContext({ locale: ‘ja-JP’ })といった形でロケールを指定できますが、便利な方法としてはPlaywrightの設定ファイル（playwright.config.*）でグローバルにuse: { locale: ‘ja-JP’, timezoneId: ‘Asia/Tokyo’ }を指定しておくことです。こうしておけば全テストが日本語ロケール・タイムゾーンで実行され、たとえばエラーメッセージや日付フォーマットの検証で環境差異に悩まされるリスクが減ります。

日本語文字入力の扱い

PlaywrightはUTF-8を含む各種文字エンコーディングに対応しており、日本語の文字入力も基本的にはそのまま可能です。例えばテキストフィールドへの入力にはpage.fill(‘input[name=”username”]’, ‘テストユーザー’)のように文字列リテラルで日本語を渡せますし、期待通り「テストユーザー」という文字が入力されます。バックエンドでの受け渡しもUTF-8で行われるため通常問題ありません。ただし、IME（日本語入力メソッド）の挙動そのものをテストすることは難しい点に注意が必要です。Playwrightはキー入力をシミュレートして直接文字を要素に送ることはできますが、実際のOSのIME変換プロセス（ローマ字入力からかな変換、候補選択など）をエミュレートすることはできません。そのため、「変換候補が正しく表示されるか」等のIME特有の挙動を確認するE2Eテストには不向きです。多くのWebアプリではテキスト入力は最終確定文字列が重要なので問題になりませんが、例えばチャットアプリで未確定文字状態の挙動をテストしたい、といった場合はPlaywright単体では困難でしょう。

フォントと文字化けへの対処

ヘッドレスブラウザ環境ではシステムに日本語フォントが入っていないと、スクリーンショットやPDF出力で日本語文字が豆腐（□）になってしまうことがあります。CI環境でPlaywrightを使う際には、必要に応じてIPAフォントやNoto Sans JPなどをインストールしておくと安心です。また、テストで文字列比較を行う際には全角半角の違いや、一般的な全角スペースと不可視の特殊スペースの違いなど、日本語特有の要注意ポイントにも気を配りましょう。たとえば「テスト （全角スペース）ユーザー」と「テスト（半角スペース）ユーザー」は見た目は似ていますがUnicodeでは異なる文字列です。PlaywrightのtoHaveTextや正規表現マッチを使うときは、意図しない不一致にならないようこれらを揃えておく必要があります。

日本語特有のUI要素の扱い

日本語入力欄でのプレースホルダーやボタンのラベルなどをgetByTextやgetByRoleで取得する場合、正規表現や部分一致を活用すると便利です。例えばボタンに「保存する」というテキストが表示されているとき、page.getByRole(‘button’, { name: /保存/ })のように記述すれば「保存」を含むボタン要素を柔軟に取得できます。完全一致を狙う場合は{ exact: true }オプションも指定できます。また、スクリーンリーダー用のアクセシブルネーム（aria-label等）が日本語になっている場合も同様に取得可能です。日本語UIテストでは、目に見えるテキストとHTML上の要素属性（例えばvalueやplaceholder）が異なるケースもあるので、状況に応じてgetByPlaceholderText等の適切なメソッドを選ぶこともポイントです。
まとめると、日本語環境でPlaywrightテストを行う際は「ロケール設定の明示」「日本語入力の直接操作（IMEを避ける）」「フォントや文字コードの確認」「テキストマッチ手法の工夫」といった点に気を付ける必要があります。これらを押さえておけば、日本語UIのアプリケーションでも安定したE2Eテストを実装・実行することができるでしょう。

実プロジェクトでの利用Tips・落とし穴 – Playwrightを現場導入・活用する際の有用なヒントと注意事項

最後に、Playwrightを実際のプロジェクトに導入・運用する際に知っておきたいベストプラクティスや、陥りがちな落とし穴について整理します。

安定したセレクタ戦略を使う

テストが壊れやすくなる典型例として、DOM構造に依存しすぎた脆いセレクタ（例: div:nth-child(2) > .btn のようなもの）を使用することが挙げられます。Playwrightでは可能な限り人間に分かりやすく安定したセレクタを使うことが推奨されています。例えば、主要なボタンはARIAロールやラベルテキストで取得し（getByRole(‘button’, { name: ‘保存’ })など）、フォーム要素にはdata-testid属性を仕込んでgetByTestId()で参照する、といった方法です。UIが変わっても意味的に同じ要素であればテストが壊れにくくなり、可読性も向上します。

暗黙的な待機を活用し、明示的な待ちを最小限に

Playwrightは自動で待機処理（auto-wait）を行ってくれるため、基本的に手動でwaitForTimeoutやsleepを入れる必要はありません。それにも関わらず明示的な待機を入れてしまうと、ネットワークやマシンスピードのばらつきで不必要に待たされたり、逆にタイミング不一致でテストが失敗する原因になります。要素の出現を待つ場合はpage.waitForSelector()ではなく、expect().toBeVisible()のようなアサーションに任せる方が理想的です。外部API呼び出し完了の待ちなどはwaitForResponse等を使い、ハードコーディッドなタイマー待ちは原則排除しましょう。

テストを独立させシナリオを単純明快に

各テストケースはできるだけ単一の機能やシナリオにフォーカスし、他のテストに依存しないようにしましょう。例えば、あるテストで作成したデータを別のテストで前提として使い回すのは避けるべきです。PlaywrightではbeforeEachやafterEachフック、またはFixtures機能を使ってテストごとに環境をリセットできます。こうすることでテスト間の干渉を防ぎ、どのテストが何を検証しているか明確になります。また、エンドツーエンドテストはあれもこれもと盛り込みすぎるとシナリオが冗長になり失敗時の原因追跡が困難になります。重要なユーザーフローを中心に、適切な粒度でテストケースを分割しましょう。

マルチブラウザ・マルチデバイス対応

現場導入では、テストをすべての主要ブラウザで実行することが品質保証に繋がります。Playwrightは単一のテストコードでChromium（Chrome相当）、Firefox、WebKit（Safari相当）をサポートしているのが強みです。プロジェクトのPlaywright設定ファイルで複数ブラウザをprojectsとして定義しておけば、コマンド一つでそれら全てに対しテストを並行実行できます。また、モバイルデバイスの画面サイズやUAでのテストもデバイスエミュレーション機能（例えば…devices[‘iPhone 12’]）を使って実施可能です。ユーザー層に応じてテスト環境を網羅し、ブラウザ依存の不具合も早期に検出できるようにしましょう。

CIパイプラインへの統合とレポート活用

PlaywrightのテストはCI環境で定期的に回すことで真価を発揮します。npm init playwright@latest実行時にオプションで選択できるGitHub Actionsのワークフローテンプレートなどを利用し、プルリクエストやデイリービルドでテストを自動実行しましょう。CI上でもHTMLレポートやJUnitレポートを出力してアーティファクトとして保存すれば、後から失敗内容を詳細に確認できます。特にTrace Viewerやビデオ録画、スクリーンショットの活用は有用です。Playwright設定でtrace: ‘on-first-retry’やvideo: ‘retain-on-failure’等を有効にしておけば、CIで失敗が起きた際に自動で詳細なトレースログや動画が保存されます。それらをダウンロードして確認することで、「CIだけ再現する不具合」の原因調査も格段に効率化できます。

Playwright公式ツールの活用

開発効率向上のためにPlaywrightが提供する様々なツールを積極的に使いましょう。例えばテストコード自動生成のCodegenは、新しいページフローのテストを作る際に手動操作を記録して雛形コードを得るのに便利です（得られたコードはそのままではなくリファクタして使う前提ですが、素早いプロトタイピングに役立ちます）。Playwright Inspector（page.pause()や–debugオプションで起動）も強力で、ステップ実行しながらUI要素を選択・ハイライトしてセレクタを試せるため、要素探索や動的な待ち時間の調整に重宝します。他にも、テスト中にコンソールログを収集するpage.on(‘console’, …)や、ネットワークモック機能（page.route()）など、Playwrightには便利なAPIが揃っています。公式ドキュメントのガイドやコミュニティの知見を活かし、手作業や回り道を減らせるツールは積極的に取り入れましょう。

外部サービスや不確定要素の扱い

現場でE2Eテストを運用する際には、テストが不安定になる要因を可能な限り排除することも重要です。外部のAPIや認証サービスなど自分たちでコントロールできない要素に直接依存したテストは、外部側の一時的な障害でこちらのCIが赤くなるなど望ましくない影響を受けます。可能であればそれら外部呼び出しはモックし、純粋に自社アプリの動作だけを検証するようにテストを組み立てましょう。また日時や乱数に依存する挙動についても、テスト時には値を固定するかシード値を与えるなどして、実行のたびに結果が変わらないように工夫します。Playwrightではpage.addInitScript()で日時関数をモンキーパッチすることなども可能なので、必要に応じて活用してください。
以上、Playwrightを実プロジェクトで活用するためのポイントを紹介しました。堅牢なテストを書くコツは、人間のユーザー視点に立ったシナリオ設計と、ツールが提供する便利機能の活用にあります。逆に、焦って雑に実装すると待機漏れや要素特定ミスでテストが不安定になり「Playwrightは不安定だ」と誤解してしまうことにもなりかねません。適切なベストプラクティスに従えばPlaywrightは非常に強力で信頼性の高いテストフレームワークです。本ガイドで挙げたポイントを参考に、ぜひPlaywrightを現場で役立ててみてください。