生成AIのおかげで、E2Eテストの「最初の1本」を作るハードルはかなり下がりました。
たとえば、ログインして商品を検索し、カートに追加するPlaywrightのコードであれば、要件を文章で渡すだけでもそれなりの形になります。SeleniumやCypressでも同じです。ノーコード系のツールなら、ブラウザ操作を記録したり、自然言語からテストを作成したりできます。
しかし、実際のプロジェクトで難しいのはテストコードを生成することではありません。
難しいのは、半年後もそのテストを信頼できる状態で運用することです。
- UI変更後も修正しやすいか
- CI上で再現性のある結果を出せるか
- 失敗時に原因を説明できるか
- iframeやShadow DOMを含む実画面を扱えるか
- ブラウザ実行環境を誰が管理するか
- テストを作った本人以外も保守できるか
本記事では、AI時代のテスト自動化を「テストを書く技術」ではなく、「信頼できるテストシステムを運用する技術」という視点で整理します。
1. 最初にテストすべきなのは、ログイン画面ではなく難しい画面
テスト自動化ツールの評価では、ログインフォームや単純なCRUD画面から試すことが多いと思います。
ただし、そのような画面で動くことは、実際のアプリケーションで使えることを意味しません。
現代のWebアプリケーションには、次のような要素が含まれます。
- Shadow DOMを使ったWeb Components
- 決済や認証フォームのiframe
- クロスオリジンの埋め込みコンテンツ
- チャット、分析、同意管理などの外部ウィジェット
- 動的に差し替えられるDOM
- SPAの画面遷移中だけ存在する要素
ツールを比較する場合は、簡単な画面ではなく、アプリケーション内で最も扱いにくい画面を使う方が現実的です。
How to Evaluate a Test Automation Platform for Shadow DOM, Iframes, and Embedded Third-Party Widgets では、こうした複雑なブラウザ構造を評価するときの観点が整理されています。
単に「iframe対応」「Shadow DOM対応」と書かれているだけでは不十分です。確認したいのは、失敗時も含めた一連の体験です。
- どのフレームを検索していたか分かるか
- Shadow Rootの内外を正しく移動できるか
- セレクタが壊れた理由を確認できるか
- 外部ウィジェットが遅延した場合に証拠が残るか
- テスト担当者が自分で修正できるか
機能一覧にチェックが付いていることと、実運用で保守できることは別問題です。
2. AIエージェントには「再試行」より「説明能力」が必要
AIテストエージェントには、失敗した操作を別の方法で再試行する機能があります。
たとえば、最初のロケータでボタンが見つからなかった場合に、表示テキストや周辺要素から別のロケータを生成して実行を続ける、といった動作です。
便利ではありますが、再試行後に成功しただけでは原因は分かりません。
- アプリケーションが一時的に遅かったのか
- DOMが変更されたのか
- テストデータが競合していたのか
- AIが別の要素をクリックしたのか
- 最初の失敗が本物の不具合だったのか
What to Log When an AI Test Agent Replays a Failed Run and Still Can’t Explain the Failure では、AIエージェントが失敗を再実行するときに残すべき情報がまとめられています。
最低限、以下は記録しておきたいところです。
{
"step": "Save buttonをクリック",
"expected": "編集内容が保存される",
"original_locator": "[data-testid='save']",
"observed": "element not found",
"fallback_locator": "role=button[name='Save']",
"fallback_reason": "同じラベルを持つbuttonを検出",
"confidence": 0.82,
"application_version": "2026.07.16",
"feature_flags": {
"new_editor": true
}
}
重要なのは、長い思考ログではありません。
「何を期待したか」「何を観測したか」「なぜ別の操作を選んだか」を短く追跡できることです。
自動修復が成功しても、根本原因が見えなければ、単に不具合を隠している可能性があります。
3. フレームワーク比較は、具体的な画面で行う
「Playwright、Selenium、Cypressのどれが一番良いか」という質問だけでは、実用的な答えを出すのは難しいです。
たとえば、動的テーブルをテストする場合、必要になるのは単純なクリックだけではありません。
- API経由で既知のデータを作成する
- テーブルの非同期更新を待つ
- 検索条件を入力する
- 対象行を位置ではなく内容で特定する
- 行内メニューを開く
- 更新結果をUIとAPIの両方で確認する
Endtest vs Cypress for Testing Dynamic Tables, Search Filters, and Inline Row Actions は、このような具体的なユースケースを使ってEndtestとCypressを比較しています。
コードによる細かい制御を優先するチームではCypressが扱いやすい場合があります。一方、QA担当者が直接テストを保守し、ブラウザ実行環境やレポートも含めて一つの製品で管理したい場合は、Endtestのような統合型プラットフォームが候補になります。
ここで大切なのは構文の好みだけで決めないことです。
AIによってコード生成コストは下がりましたが、生成されたコードの所有コストは残ります。
Selenium vs Cypress in the AI Era でも触れられているように、AIがPage Object、fixture、helper、assertionを生成してくれても、次の責任はチームに残ります。
- フレームワーク設計
- ライブラリ更新
- コードレビュー
- テストデータ管理
- CIの安定化
- ブラウザ環境の保守
- flaky testの調査
コードが速く作れることと、長期的に安く運用できることは同じではありません。
4. 状態の準備はAPI、ユーザー体験の確認はブラウザ
ブラウザテストを安定させる最も効果的な方法の一つは、すべてをブラウザで実行しないことです。
たとえば、アーカイブ済みプロジェクトの表示を確認したいテストで、以下を毎回UIから行う必要はありません。
- ユーザー作成
- ログイン
- プロジェクト作成
- 設定変更
- アーカイブ操作
検証対象が「アーカイブ後の表示」であれば、前提データはAPIで作り、ブラウザでは表示だけを確認できます。
How to Combine API Calls with Playwright Tests では、PlaywrightのAPIRequestContextを使って、セットアップ、認証、クリーンアップ、バックエンド検証を行う方法が紹介されています。
簡単な例です。
import { test, expect } from '@playwright/test';
test('archived project is shown in the archive list', async ({
request,
page,
}) => {
const createResponse = await request.post('/api/projects', {
data: {
name: `project-${Date.now()}`,
},
});
expect(createResponse.ok()).toBeTruthy();
const project = await createResponse.json();
const archiveResponse = await request.post(
`/api/projects/${project.id}/archive`
);
expect(archiveResponse.ok()).toBeTruthy();
await page.goto('/projects/archive');
await expect(
page.getByRole('row', { name: new RegExp(project.name) })
).toBeVisible();
});
判断基準はシンプルです。
操作そのものが検証対象ならUIを使う。状態だけが必要ならAPIを使う。
もちろん、サインアップ画面のテストでAPIからユーザーを作成してしまうと、検証対象を飛ばしてしまいます。
しかし、多くのE2Eスイートには、前提条件を作るためだけの不要なUI操作が大量に含まれています。それらをAPIに移すだけでも、実行時間とflaky率を大きく下げられます。
5. Feature Flagを使うなら、リリース方法そのものをテストする
現在のリリースでは、すべてのユーザーに同時に新機能を公開するとは限りません。
- 社内ユーザーのみ
- 特定の契約プランのみ
- 5%のユーザーのみ
- 特定地域のみ
- 新規アカウントのみ
このような段階的ロールアウトでは、完成した画面だけでなく、Feature Flagとロールバックの動作も検証する必要があります。
How to Build a Test Plan for Feature Flags, Rollouts, and Safe Reverts in Web Apps では、Feature Flagを含むテスト計画の考え方が紹介されています。
最低でも、以下の組み合わせは確認したいところです。
| 条件 | 期待結果 |
|---|---|
| Flag OFF | 旧UIが正常に動作する |
| Flag ON | 新UIが正常に動作する |
| 対象ユーザー | 新UIが表示される |
| 対象外ユーザー | 旧UIが維持される |
| セッション中に切替 | 不整合やデータ損失が起きない |
| ロールバック | 新しいデータを壊さず旧UIに戻れる |
また、UIの切り替えにアニメーションを使っている場合は注意が必要です。
CSS View Transitionsやアニメーション付きのルート変更では、要素がDOM上に存在していても、まだクリック可能ではないことがあります。
- 移動中
- 透明
- overlayに覆われている
- 古いページと新しいページの両方に存在する
- document自体が置き換えられている
How to Reduce Flaky Browser Tests Caused by Animated Route Changes and CSS View Transitions では、固定時間のsleepではなく、アプリケーションの意味のある状態を待つ方法が解説されています。
たとえば、次のような待ち方です。
await page.getByTestId('navigation-complete').waitFor();
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
waitForTimeout(1000) を増やし続けるより、「画面遷移が完了したことを表す状態」をアプリケーション側に用意する方が安定します。
6. CI連携は、テストを起動するだけでは不十分
CircleCIからテストを実行できたとしても、それだけではCI連携が完成したとは言えません。
CIが判断できる必要があります。
- 期待したテストがすべて完了したか
- どのビルドを対象にしたか
- テスト失敗か、実行環境の障害か
- スクリーンショットや動画はどこにあるか
- デプロイを止めるべきか
How to Integrate Test Automation with CircleCI では、テストの起動、完了待ち、結果取得、終了コードへの反映までが説明されています。
Playwrightを直接実行する場合の基本形は次のようになります。
version: 2.1
jobs:
e2e:
docker:
- image: mcr.microsoft.com/playwright:v1.55.0-noble
steps:
- checkout
- run:
name: Install dependencies
command: npm ci
- run:
name: Run browser tests
command: npx playwright test
- store_artifacts:
path: playwright-report
- store_test_results:
path: test-results
workflows:
test:
jobs:
- e2e
外部のテストプラットフォームをAPIから呼び出す場合は、実行を開始するだけでなく、完了するまでポーリングし、最終結果をCIの終了コードに変換する必要があります。
テストを実行できることよりも、パイプラインがその結果を信頼して判断できることの方が重要です。
7. ブラウザ実行環境にも保守コストがある
E2Eテストが増えると、どこでブラウザを実行するかという問題が出てきます。
代表的な選択肢は次の二つです。
- Selenium Gridを自社運用する
- BrowserStackのようなクラウドを使う
Selenium Grid vs BrowserStack では、単純な料金比較ではなく、どの障害を自分たちで所有するかという観点で比較しています。
Selenium Gridを運用する場合、チームは以下を管理する可能性があります。
- ブラウザとDriverのバージョン
- Nodeの死活監視
- 並列数とスケーリング
- Dockerイメージ
- 動画やログの保存
- OSアップデート
- セキュリティ
- 障害時の復旧
BrowserStackのようなサービスでは料金が明確に発生しますが、その代わり、こうした運用の一部を外部化できます。
オープンソースのフレームワークが無料でも、実行環境まで無料になるわけではありません。
テスト自動化のコストを考えるときは、ライセンスだけでなく、ブラウザ基盤の保守時間も含める必要があります。
8. 手動リグレッションを置き換えるなら、テストケースの単純変換は避ける
よくある計画に、次のようなものがあります。
300件の手動テストケースを、そのまま300件の自動テストにする。
この方法では、古い手動プロセスをそのまま高コストな自動化に変換してしまう可能性があります。
先に考えるべきなのは、件数ではなくリスクです。
- 毎リリース確認すべき重要なユーザーフローは何か
- ブラウザ差分が問題になる部分はどこか
- APIレベルで確認した方がよい処理は何か
- 手動探索を残した方がよい領域は何か
- 誰がテストを保守するか
Endtest Buyer Guide for Teams Replacing Manual Regression on Fast-Changing Frontends では、変化の速いフロントエンドで手動リグレッションを置き換える際、初期作成速度よりも継続的な保守コストを重視しています。
Endtestのような統合型プラットフォームは、次のような機能を一つの環境にまとめています。
- 編集可能なE2Eテスト
- AIによる作成や修復
- クロスブラウザ実行
- APIステップ
- レポート、スクリーンショット、動画
- CI/CD連携
- QA担当者による直接保守
一方で、コードを完全に所有したいチームや、特殊な内部環境を持つチームでは、PlaywrightやSeleniumを使った自社フレームワークが適している場合もあります。
Best AI Test Automation Tools in 2026: My Practical Shortlist では、Endtestを含むAIテスト自動化ツールが、生成機能だけでなく、作成、実行、デバッグ、保守まで含めて比較されています。
ツール選定では、「AIでテストを書けるか」よりも、「チームがそのテストを運用し続けられるか」を見る方が現実的です。
9. フレームワークかプラットフォームか
すべてのチームに同じ正解があるわけではありません。
次のような条件では、PlaywrightやSeleniumを使った内製フレームワークが合理的です。
- テスト基盤を専門に担当するエンジニアがいる
- 特殊な環境や独自要件がある
- ソースコードの完全所有が必要
- ライブラリやブラウザ基盤の更新を継続できる
一方で、チームの目的が「テスト基盤を作ること」ではなく「回帰不具合を減らすこと」であれば、統合型プラットフォームの方が総コストを下げられる場合があります。
比較材料として、以下の動画も参考になります。
後者では、Endtest、Mabl、testRigor、Ghost Inspector、Reflect、TestMu AIなどが、実際の操作性を中心に比較されています。
まとめ
AIによって、テストコードの最初のドラフトは簡単に作れるようになりました。
しかし、テスト自動化の本当の難しさは別のところにあります。
- 複雑なDOM構造を扱う
- 失敗の証拠を残す
- AIの再試行を説明可能にする
- APIとUIの責務を分ける
- Feature Flagとロールバックを検証する
- CIが判断できる結果を返す
- ブラウザ基盤を保守する
- 作成者以外でもテストを修正できるようにする
最初のテストが動いたことは、まだスタート地点です。
本当に価値があるのは、数か月後もチームが結果を信頼でき、失敗を短時間で理解でき、通常のUI変更に追従できるテストシステムです。
AIはテスト作成を加速できます。
しかし、長期的に成功するかどうかは、テストの周辺にある運用コストをどれだけ減らせるかで決まります。