AI
E2Eテスト 自己修復の仕組み｜PayPay事例と導入判断の基準
E2Eテストの自己修復について、AIがロケータ候補を探す仕組みをPayPayの事例から解説します。保守時間を減らし、不具合の見逃しを防ぐために、適用範囲、人による承認、評価指標、情報管理など、導入前に決める項目と小規模に試す手順を整理します。
はじめに
画面を変更しただけで、E2Eテストが止まることがあります。 機能は正常でも、ボタンの名称や画面内部の構造が変わると、テストが操作対象を特定できなくなるためです。
この問題に対処する仕組みが、AIによるE2Eテストの自己修復です。 自己修復機能は、特定できなくなった操作対象の代替候補を提示し、テストを続行させます。 UI変更が多く、担当者がテストの修正に時間を取られている組織では、保守作業を減らせる可能性があります。
ただし、失敗したテストをAIで通過させればよいわけではありません。 AIが別のボタンを選ぶと、担当者が製品の不具合を見落とすおそれがあるためです。
E2Eテストは、ログインから申込完了までのように、利用者が実際にたどる一連の操作を確認するテストです。 重要な業務をまとめて検証するため、テストが止まると担当者の原因調査が増え、リリースの判断も遅れます。 その結果、品質向上に充てるはずの人員を、テストコードの修正へ回すことにもなります。
事業責任者は、失敗件数だけでなく、保守時間と誤修復による見逃しも確認します。 これらの記録がなければ、導入の可否を判断できません。
E2Eテスト 自己修復ではAIが代替ロケータを探す
E2Eテストが操作対象を特定できなかったとき、自己修復機能は画面情報から代替候補を探します。 主な対象は機能の故障ではなく、名称や識別子の変更によって生じたテスト側の失敗です。
画面上のボタンや入力欄を特定する手掛かりを、ロケータと呼びます。 「申込ボタン」という表示名、HTML上のID、画面内の位置などがロケータにあたります。
PayPayのセルフヒーリング事例↗では、ロケータによる特定に失敗すると、システムがページソース、スクリーンショット、現在のロケータ、エラーログ、対象要素の説明、言語、実行環境を大規模言語モデル（LLM）へ渡します。 LLMは新しい候補と信頼度を返し、設定された条件を満たした場合にテストを続行します。
事業上の判断に置き換えると、この処理は次の四段階に分かれます。
- テストが操作対象を見つけられず、停止する
- AIが画面と失敗時の情報から候補を探す
- 担当者が定めた信頼度や禁止条件に基づき、システムが候補を採用するか決める
- システムが修復履歴を残し、担当者が後から妥当性を確認する
AIが担うのは、候補の探索です。 「画面変更として許容できるか」「製品の不具合ではないか」という判断まで、無条件にAIへ委ねる仕組みではありません。
効果は修復件数ではなく保守時間と見逃しで測る
テスト保守の時間が減れば、QA担当者や開発者は、品質確認や新しいテストの追加に時間を使えます。 リリースを判断するまでの待ち時間も短くなり、限られたQA人員を重要な検証へ配分しやすくなります。
実際にPayPayは、フロントエンド変更によるロケータ破損などを「テスト実装起因の問題」と分類しています。 セルフヒーリングの導入後、この問題による失敗率の低下が続いたと報告しました。
ただし、PayPayの記事では絶対件数や削減率を公開していません。 そのため、自社でも同じ効果を得られるとは判断できません。 担当者は、自社の失敗原因と保守時間を記録し、効果を測る必要があります。
期待する変化と確認する指標は、次のように対応します。
| 期待する変化 | 事業へのつながり | 確認する指標 |
|---|---|---|
| ロケータ修正の減少 | QAと開発者の保守時間を抑える | 月間修正件数、原因調査時間 |
| テスト停止の減少 | リリース可否を早く判断する | 完走率、判定までの時間 |
| 新規テスト作成の余力 | 重要業務の検証範囲を広げる | 追加シナリオ数、未検証の重要経路 |
| 失敗原因の分類 | 対応先を早く決める | テスト、環境、製品不具合ごとの件数 |
AIが修復した件数だけでは、費用対効果を測れません。 担当者は、削減できた調査時間と、不具合を見逃さなかったかどうかを併せて記録します。
誤ったロケータを選ぶリスクは検証と承認で抑える
候補の信頼度が高くても、AIにそのまま任せるのは危険です。 担当者は、修復後も本来の業務結果を確認できるようにテストを組む必要があります。
たとえば、購入を確定するボタンをテストが見つけられなかったとします。 AIが見た目の近い「カートへ戻る」ボタンを選んでも、クリック操作自体は成功します。 その後に注文番号、金額、在庫、通知などを確認しなければ、誤った操作でもテストが通ったという結果だけが残る可能性があります。
このような誤修復を見つけるため、運用担当者は次の条件を設定します。
- システムが元のロケータ、採用候補、信頼度、スクリーンショットを履歴に残す
- 候補が複数ある場合や信頼度が低い場合は、システムがテストを停止する
- テストが修復後の画面遷移や保存結果など、本来の期待値を検証する
- 同じ箇所の修復が繰り返されたら、担当者がテストコードを直す
- 担当者が本番データの更新、決済、削除、権限変更を自動修復の対象から外す
これらの条件を設定しても、影響の大きい操作まで自動採用するかは別に判断します。 決済や権限変更などの経路では、担当者による承認を残す方が安全です。
AIを使わず、担当者が壊れにくいテストへ直せる場合もあります。 Playwrightのロケータ指針↗は、画面内部の構造に強く依存する長いCSSやXPathより、利用者が認識する役割や名称、明示的なテストIDを優先するよう勧めています。 SeleniumのPage Object Model解説↗では、画面固有のロケータを一か所に集約し、UI変更時の修正範囲を限定する考え方を解説しています。
自己修復を導入しても、壊れやすいテストを放置してよいことにはなりません。 既存の安定化策を施した後に残る保守作業が、AIの適用を検討する範囲です。
導入前に決める項目
導入担当者は、適用する業務、AIへ渡す情報、自動採用の条件、最終責任者を先に決めます。 精度だけでは、AIへ任せられる範囲は決まりません。
全テストへ一括で導入すると、担当者が効果の出た箇所と危険な箇所を判別しにくくなります。 まずは影響が限定された画面に絞り、誤修復率と削減時間を測るのが現実的です。
導入前の判断項目は、次の表に整理できます。
| 判断項目 | 導入しやすい状態 | 慎重に扱う状態 |
|---|---|---|
| UI変更の頻度 | 表示名や配置の変更が多い | 画面がほぼ固定されている |
| 失敗の内訳 | ロケータ破損が多い | 製品や環境の不具合が多い |
| 業務影響 | 閲覧や検索など更新を伴わない | 決済、削除、権限変更を伴う |
| レビュー体制 | 修復履歴を定期確認できる | 誰も採用結果を確認しない |
| 情報管理 | 送信情報を絞り、保存条件を管理できる | 個人情報や機密情報が画面に含まれる |
情報管理では、スクリーンショットやページソースの扱いを確認します。 これらには、顧客名、取引情報、認証情報が含まれる可能性があります。 導入担当者は、マスキング、送信先、保存期間、学習利用の有無、アクセス権を事前に確認します。
小規模な試行では、次の順序で判断材料を残します。
- 担当者が過去のテスト失敗を分類し、ロケータ破損の比率と修正時間を測る
- 更新を伴わない数十件程度のテストに対象を限定する
- AIの候補を自動採用せず、担当者の承認結果を記録する
- 誤修復率、確認時間、削減できた保守時間を比較する
- 基準を満たした範囲だけ自動採用へ移し、重要経路は承認制を保つ
この試行では、AIの精度に加えて、自社の画面変更、テスト設計、リスク許容度に合う運用を担当者が作れるかを確かめます。
まとめ
E2Eテストの自己修復では、AIがUI変更で壊れたロケータの代替候補を探します。 UI変更が多く、原因調査によってリリース判断や品質確認が遅れている組織では、テスト保守の負担を減らせる可能性があります。
ただし、自動修復後にテストが完走しても、本来の業務結果が正しいとは限りません。 導入を判断するには、担当者が次の項目を自社の記録で確かめる必要があります。
- ロケータ破損が保守負担の大きな部分を占めているか
- 修復後の業務結果をテストで検証し、担当者が誤修復を検知できるか
- 担当者が送信データと修復履歴を安全に管理できるか
まず担当者が、過去一か月から数か月分の失敗を「テスト実装」「環境」「製品不具合」に分類します。 ロケータ修正に使った時間が分かれば、壊れにくいロケータへの改修で足りるのか、限定的な自己修復の試行へ進むのかを事業責任者が判断できます。