【ITニュース解説】Designing an AI-Assisted Locator Self-Healing Workflow for Playwright

システムエンジニアを目指す皆さんにとって、ソフトウェア開発におけるテストは非常に重要な工程だ。特に、ユーザーが実際に触れる部分、つまりユーザーインターフェース（UI）の動作を確認する「UI自動化テスト」は、製品の品質を保つ上で欠かせない。しかし、このUI自動化テストには頭を悩ませる問題が一つある。それは、製品自体には問題がないのに、テストが「壊れて」しまうことだ。

たとえば、ウェブサイトの「送信」ボタンをクリックするテストを作成したとしよう。このテストは、ボタンの名前が「Submit request」であることを前提に動作する。しかし、後日ウェブサイトのデザインが変更され、同じ機能を持つボタンの名前が「Send request」に変わったとする。すると、製品の機能自体は問題なく動作するにもかかわらず、テストはボタンが見つからないとして失敗してしまう。このように、UI要素の位置や名前が変わるだけでテストが動かなくなる現象を「壊れたセレクター」の問題と呼ぶ。セレクターとは、テストがUI上の特定の要素（ボタンや入力欄など）を見つけるための情報のことであり、これがUIの変更によって古くなってしまうのだ。

開発チームが大規模なソフトウェアを頻繁に更新する場合、このような「壊れたセレクター」を一つ一つ手動で探し出し、修正する作業は膨大な時間と労力を要する。これは、エンジニアが本来集中すべき新機能開発や本当の不具合修正から時間を奪う深刻な問題だ。

この課題を解決するために提案されているのが、「AIアシストのロケーター自己修復ワークフロー」である。これは、AIの力を借りて、自動で壊れたセレクターを見つけ出し、適切なものに修正する仕組みを指す。ただし、ここで言う「自己修復」は、単にテストをパスさせることだけを意味しない。最も重要なのは、テストがもともと持っていた「意図」を正確に維持することだ。つまり、単にボタンが見つかれば良いのではなく、「ユーザーがこのボタンをクリックして、特定の処理を完了する」というテストの目的や、その後の画面の状態を検証する部分まで含めて、元のテストが確認しようとしていた行動や結果が変わらないようにする、ということだ。

このAIアシストによる自己修復は、以下の段階を経て実現される。

まず、失敗の分類を行う。テストが失敗したとき、エラーメッセージは単なる手がかりに過ぎない。ロケーターが見つからない、というエラーが出たとしても、それが本当にUI要素の場所が変わったためなのか、あるいはネットワークの障害、アクセス権限の問題、テストデータの間違い、ビジネスロジックの変更、または製品自体の本当の不具合なのかを正確に診断する必要がある。AIアシストは、テストが失敗した際のアクション、その時のアプリケーションの状態、記録されたトレース情報などを詳細に分析し、「おそらくUI要素の変更が原因だろう」という可能性と、その確信度、そして次に何をすべきか、といった診断結果を提示する。これにより、本当にロケーターの問題なのか、それとも別の根本的な原因があるのかを切り分けることが可能になる。

次に、代替候補の発見だ。ロケーターの問題だと診断されたら、AIは現在のページを分析し、新しいロケーターの候補を探し出す。Playwrightのようなモダンなテストフレームワークは、UI要素を特定する際に、画面上のテキストや役割（ボタン、入力欄など）を使う、より頑丈な方法を推奨している。例えば、「Submit request」という名前のボタンが「Send request」に変わった場合、AIは新しい名前を持つボタンをページ上から探し出す。このとき、単に「ボタン」であれば良いわけではない。そのボタンが、元のテストが意図していた特定のダイアログやフォーム内にあるのか、あるいはページ全体で唯一の正しいボタンなのか、といった「文脈」も考慮に入れて、最適な候補を見つけ出す必要がある。

候補が見つかったら、すぐにコードを修正するわけではない。コード編集前の検証が不可欠だ。見つかったロケーター候補が本当に正しいのか、以下の点を慎重に確認する。第一に、その新しいロケーターが指すUI要素が、現在のUI状態において間違いなく存在し、かつ唯一のものであること。第二に、その要素の役割や名前、ラベル、または周囲の文脈が、元のテストが意図していた要素と一致していること。第三に、新しいロケーターを使って元のテストアクション（例えばクリック）を実行しても、意図しない別の動作が引き起こされたり、テストの流れが変わったりしないこと。第四に、そのアクションの後に続く検証（アサーション）が、依然として意図したユーザーの振る舞いを正しく確認できること。これらの検証をクリアしない限り、その候補は「正しい修復」とは言えず、もしAIの確信度が低い場合や、UIの動作が大きく変わってしまった場合は、人間のエンジニアによるレビューを要求する。間違ったボタンを修正してテストがパスしても、それはテストが本来検証すべきだったユーザー体験を正しく検証できていないことになるため、意味がない。

検証が完了し、新しいロケーターが正しいと判断されたら、ソースコードのパッチ適用を行う。この工程も慎重に進める必要がある。もし、あるロケーターが複数のテストファイルで共通して使われている場合、単純な文字列置換では、意図しない場所まで変更してしまうリスクがある。そこで、「ts-morph」のような「抽象構文木（AST）」を扱うライブラリが役立つ。ASTは、プログラムのコードを木構造のデータとして表現したもので、これによりコードの意味を理解した上で、狙った箇所だけを正確に修正できる。安全なパッチ適用ワークフローでは、修正内容の差分を必ず保持し、承認された箇所のみを更新し、プロジェクト全体で型チェックを実行して新たなエラーが発生しないことを確認し、さらに問題が発生した場合には簡単に元の状態に戻せるようにしておく。テストがパスしない原因となっている検証（アサーション）を勝手に削除したり、期待値を緩めたりするような修正は、絶対に行ってはならない。

最後に、再実行とレビュー用レポートの作成を行う。コードの修正が完了したら、以前に失敗したテストを、全く同じデータと環境で再度実行する。もし修正したロケーターが複数のテストで共有されていた場合は、関連する隣接テストも実行する。その結果をまとめたレポートを作成し、人間のエンジニアに最終的なレビューを依頼する。レポートには、失敗の分類、以前のロケーター、提案された新しいロケーター、検証結果（対象が一意であること、アクションが確認されたことなど）、そして修正後のテスト実行結果（パスしたかどうか）といった情報が含まれる。このレポートは、AIが提案した修正がなぜ妥当なのか、エンジニアが確認し、最終的に承認するための重要な証拠となる。一度パスしたからといって、その修正が永久に正しく、今後も安定して動作するという保証はないため、人間の最終確認は必須だ。

このようなAIアシストの自己修復システムを運用する上では、いくつかの安全対策（ガードレール）を設けることが極めて重要だ。AIに入力するデータは承認されたもののみを使用し、AIサービスとの連携は最小限の権限で行う。テストのトレース情報などは、秘密情報や個人情報が含まれていないかを確認し、必要に応じて匿名化（サニタイズ）する。AIによる修正プロセスは、本番環境とは分離された、管理された環境で実行し、いかなる変更も必ず人間のレビューを挟む。ウェブページのテキストやエラーログには、機密情報が含まれていたり、AIへの誤った指示（プロンプトインジェクション）を試みる悪意のある文字列が含まれていたりする可能性があるため、これらをAIに直接渡す際には最大限の注意を払う必要がある。「OWASP Top 10 for LLM Applications」のようなガイドラインは、AIを活用する上でのセキュリティリスクを理解するのに役立つだろう。

さらに、このシステムが本当に役に立っているのかを評価するためには、厳密な指標（メトリクス）の追跡が不可欠だ。例えば、AIが提案し、人間が承認したロケーター修正の数、AIが誤って提案した修正（誤検知）の数、エンジニアが修正をレビューするのにかかった時間、修正後のテストの再実行結果、そして結局元に戻された修正の数などを記録する。これらのデータを分析することで、システムの精度と効率を改善していくことができる。ただし、ロケーター修復によってテスト失敗が減ったとしても、それがソフトウェア全体の品質向上に直結するわけではないため、「全体的な回帰テスト失敗の減少」というような、測定範囲を超えた主張は避けるべきだ。

最終的に、このAIアシストの自己修復システムは、エンジニアの仕事を助ける「アシスタント」として機能する。単に失敗するテストを無理やりパスさせるためのものではない。最も難しいのは、テスト失敗の原因を正確に分類すること、元のテストが意図していた振る舞いを維持すること、ソースコードへの変更を最小限に抑えること、そして、レビューするエンジニアが信頼できる明確な証拠を生成することだ。

この堅牢な設計は、「失敗の証拠」から始まり、「ロケーターの診断」、「候補の特定」、「検証」、「コードの差分生成」、「修正後のテスト再実行」、そして最終的な「人間の承認」という一連の流れで構成される。これにより、UI自動化テストのメンテナンスにかかる負担を大幅に軽減し、エンジニアがより価値の高い仕事に集中できる環境を作り出すことを目指している。