Playwright 1.56 Test Agents活用：E2Eテスト生成・修復を自動化するGitHub Actions実装術

• Playwright 1.56で導入されたTest Agentsにより、E2Eテストの計画・生成・修復がAIによる自動化の対象となった。
• MCPプロトコルを活用し、GitHub Actions上で非対話的にテストを生成・修復するワークフローを構築可能。
• AIの暴走を防ぐためのガードレール（AST解析による変更制限）と、人間による承認プロセスを組み合わせた安全な運用が鍵となる。

多くのエンジニアにとって、E2Eテストは「書くのは大変、維持するのはもっと大変」という負の遺産になりがちだ。UIの微細な変更一つでテストが落ち、深夜のデプロイ時に修正に追われる……そんな経験は誰しも一度はあるだろう。Playwright 1.56で登場した「Playwright Test Agents」は、この苦痛を解消するための強力な武器となる。単なるコード生成ツールではなく、Planner（計画）、Generator（生成）、Healer（修復）という3つのエージェントが、テストのライフサイクル全体を自律的に管理する仕組みだ。

しかし、シニアエンジニアとして私が強調したいのは、AIを「魔法の杖」として盲信してはならないという点だ。特に、無人で動くエージェントがプロダクトのコードを書き換えるという行為は、セキュリティと品質管理の観点から極めて危険な賭けになり得る。今回紹介する手法は、公式の機能をそのまま使うのではなく、GitHub Actions上で「ガードレール」を設けることで、AIの暴走を物理的に封じ込める設計だ。具体的には、AST（抽象構文木）解析を用いて、エージェントが変更可能なファイルをPage Objectのみに限定し、テストファイルそのものや機密情報へのアクセスを遮断する。この「制約付き自律化」こそが、実務でAIを導入するための唯一の現実解であると私は考える。

検証環境の構築においては、GitHubのEnvironment機能と連携し、mainブランチ以外からの実行を拒否する設定が不可欠だ。これにより、AIが生成したパッチが直接本番環境に影響を与えるリスクを排除し、必ず人間によるDraft PRのレビューを経由させるフローを強制する。技術的な実装の詳細は後述するが、この「AIによる自動化」と「人間によるガバナンス」の境界線をどこに引くかという設計思想こそが、今後の開発現場におけるエンジニアの腕の見せ所となるだろう。

AIエージェントをCI/CDパイプラインに組み込む際、最も恐ろしいのは「テストが失敗した原因をAIが誤認し、テストコードを改ざんして無理やりパスさせる」という事態だ。これを防ぐために、本手法では「分類（Classification）」と「ガード（Guard）」という二段構えの防衛策を導入している。まず、テストの終了コードとJSONレポートを解析し、失敗が「UI変更によるもの（Heal対象）」なのか「プロダクトのバグ（Escalate対象）」なのかを厳密に判定する。この判定ロジックを疎かにすると、バグを隠蔽するテストが量産されるという最悪のシナリオを招く。

ガードスクリプト（scripts/guard.mjs）は、TypeScriptのASTを解析し、エージェントが許可されていない操作を行おうとした瞬間にプロセスを強制終了させる。例えば、テストファイル内でのtest.skipやtest.onlyの追加、あるいはeval()やfetch()といった危険な関数の呼び出しを禁止する。この設計により、エージェントは「Page Objectのロケーター修正」という、最もメンテナンスコストが高いが、最も定型的な作業にのみ集中させることが可能となる。

以下の表は、エージェントごとの役割と変更権限の境界を整理したものだ。この権限分離こそが、AIを「同僚」として信頼するための前提条件である。

このように、役割を厳格に定義することで、AIは「テストの構造」を壊すことなく、「UIの変更」に追従するだけの存在に留まる。この制約が、逆にAIの推論精度を高めることにも寄与している。余計な自由度を与えないことが、結果として最も高い生産性を生むというパラドックスを、我々は理解しておく必要がある。

ここまで詳細な設計を提示したが、読者諸氏に問いたい。あなたのチームのE2Eテストは、本当に「AIに任せられるほどクリーンな構造」になっているだろうか？もし、テストコードの中にロケーターが散乱し、Page Objectが機能していないのであれば、AIエージェントを導入する前に、まずはテストの構造化という「泥臭いリファクタリング」から始める必要がある。AIは、混沌としたスパゲッティコードを整理する魔法の杖ではない。むしろ、構造化されたコードに対してこそ、その真価を発揮する。

明日から取り組むべきアクションは明確だ。まずは、既存のテストコードからロケーターを抽出し、Page Objectパターンへの移行を完了させること。そして、今回紹介したような「ガードスクリプト」をCIに組み込み、テストの失敗を自動的に分類する仕組みを構築することだ。最初は小さなコンポーネントのテストからで構わない。AIエージェントが生成したパッチを人間がレビューし、その精度を評価するサイクルを回すことで、チーム内に「AIとの協働」という新しい文化が根付くはずだ。

最後に、技術的な問いを投げかけたい。AIがテストを自動修復する時代において、我々エンジニアが書くべき「テストコード」の価値とは何だろうか？単なるブラウザ操作の羅列であれば、AIが書くコードの方が効率的かもしれない。しかし、ビジネス要件を理解し、どのケースが「テストすべき重要な境界値」であるかを判断するのは、依然として人間の役割だ。AIに「作業」を委譲し、我々は「テストの設計」というより高次元な課題に集中する。この役割分担を再定義できないチームは、AIを導入しても単に「自動化された負債」を増やすだけになるだろう。あなたは、AIを使いこなす側か、それともAIに仕事を奪われる側か。その境界線は、今この瞬間の設計判断によって引かれている。