Playwright × AI Agent でE2Eテストはどう変わるか AI駆動テストの可能性と実用検証の結果 _0721

Transcript

1. Playwright × AI Agent でE2Eテストはどう変わるか AI駆動テストの可能性と実用検証の結果 株式会社dotD 大湯 大河 / Application Engineer
2. Contents 本日の内容 01 自己紹介 02 前提知識整理 03 検証①：テストコード生成をAIで対応 04 検証②：テスト実行（打鍵）をAIで対応 05 まとめ 06 会社紹介・採用情報
3. 自己紹介 名前：大湯大河 所属：Value Delivery (VD) 肩書：アプリケーションエンジニア 大学卒業後、独立系SIerにシステムエンジニアとして入社し、 主に基幹システムを中心にモビリティ・ヘルスケア・ERP・生成AI関連の 開発プロジェクトに携わる。 2025年よりdotDに参画し、経産省主導ウラノスエコシステム関連の CFP・CMP領域における自社プロダクト開発を担当。 趣味：野球観戦（日ハム推し）、サウナ、演劇 Copyright© 2026 dotD All Rights Reserved.
4. 前提知識整理 E2Eテストとは？Playwrightとは？
5. E2Eテストとは何か？ E2Eテスト（End-to-End Test）とは、 対象の機能をユーザが実際に使う流れを最初から最後まで画面を通して確認するテストのこと。 E2Eテストで確認する範囲 画面操作 自社システム 外部システム 期待した業務状態 申請・確認など 画面・状態を更新 処理・連携が進む 反映結果を確認 画面操作・API・データベース・認証などを横断的にテストするため、実際の不具合を見つけやすい反面、 実行に時間がかかり、またテストコードも壊れやすい傾向にある。 Copyright© 2026 dotD All Rights Reserved.
6. Playwrightは、ブラウザE2Eを実行・検証するための基盤 • Playwrightは、Webブラウザを自動操作するためのテストツール。 • Chrome系、Firefox、Safari系のブラウザでテストできる。 • ページ表示やボタンが押せる状態になるまで、 自動で待ってくれるため、比較的安定したテストを書きやすい。 • テスト失敗時に、スクリーンショット・動画・実行記録を残せる。 • JavaScript / TypeScript、Python、Java、.NETなどで利用できる。 テストコード 手順・期待結果 Playwright Test Browser テスト実行 assertion / trace Chromium / Firefox / WebKit 出典：Playwright Introduction Copyright© 2026 dotD All Rights Reserved.
7. Playwright Test Agents/ MCP の違いについて 役割を呼び出す Test Agents planner / generator / healer 生成・修復 Playwright Test runner / assertion / trace 実行 Browser Chromium / Firefox WebKit AIエージェント 目的と指示 Playwright MCP 構造化された操作IF 操作を依頼する 観察・クリック・入力 Playwright Test AgentsはAIにE2Eテストを計画・作成・修復させる仕組み、 Playwright MCPはAIがブラウザを直接操作して調査・検証するための接続方式。 Copyright© 2026 dotD All Rights Reserved.
8. 検証対象：複数アカウントと外部基幹をまたぐ業務E2E レビュー済みテスト仕様書を基に、複数のブラウザ文脈を操作 テスト担当者 テストアカウント① 自社システムサーバ テストアカウント② テストアカウント③ テスト仕様書 Copyright© 2026 dotD All Rights Reserved. 外部システム 自社システムの複数アカウントをそれぞれのブラウザから画面操作し、 自社サーバとのやり取り、および自社サーバ – 外部システム間の 通信を含む全22ステップ以上の複雑な業務シナリオを想定。 一連の操作の流れで正常な動作ができるかどうか、を検証対象とする。
9. 検証①：テストコード生成をAIで対応 Test agents × Playwright Testでテストコード構築
10. 検証①：テストコード生成の検証背景 現状 理想 ➢ アジャイル開発を採用しており、 デプロイ頻度が高い。 ➢ 少人数チームであるため、 テスト工程に十分な時間を割くことができない。 対象 正常系1シナリオ 複数account＋外部連携 Copyright© 2026 dotD All Rights Reserved. 成功条件 第三者粒度の手順から 最後まで自動完走 ➢ 専門家の視点で作成した、一連の業務シナリオを検 証できるテスト仕様書を整備。 ➢ 上記をリリース工程で定期的に実施し、また機能アッ プデートがあった場合は随時テスト仕様書もアップ デートすること。 ➢ 上記を工数をかけずにできること。 次に見ること デプロイ後も繰り返せる 運用負荷まで確認
11. 検証①：22ステップをコード化して完走 設計 ケース 洗い出し healer 修正 生成 第三者粒度へ シナリオ分解 同名データ不可 一意なタイムスタンプで回避 planner 仕様書 generator コード 外部反映待ち 3〜5回retry／待機延長 安定化 認証情報 追加 実行・修正 通信障害 全体再実行で割り切る 人の負荷 起動・監視・保守が残る 生成よりも、認証・待機・データ・再実行を安定して動作させる工程へ作業が集中した。 Copyright© 2026 dotD All Rights Reserved. 安定実行
12. 実際に動作が安定するまでにかかった手間 構築・安定化 成立させるまで シナリオを分解 安定実行へ調整 約22 ステップ 第三者が実行できる粒度まで 待機・再実行 実行ごとに → 安定化 外部反映を待つ 3〜5 約1.5 か月 一連のテストが安定するまで 安全に止める 回 反映遅延に対してretry → 上限で停止 20 分 全体timeoutとして採用した割り切り 実装自体はできたが、安定した環境に持っていくまでに時間がかかった。 また一度失敗すると、それが不具合か、通信環境・テストコードの不備なのか分かりにくかった。 Copyright© 2026 dotD All Rights Reserved.
13. 検証①まとめ：テストコード生成だけでは、運用は成立しない メリット 判明した課題 従来のE2Eテスト実装よりも、工数を抑えて実装できるように なった。 healerを使って実装しても打鍵のトリガーをするのは人なので、 定期的に確認を行う必要があった。 開発担当以外でも簡単な操作で品質点検を行えるようになった。 機能追加や改修を行うたびにテストコードをアップデートして正 常なコードかどうかを確認する必要があり手間だった。 判明した不具合の再現性を簡単に確認できるようになった。 不具合が発生しても、テストコード不備や通信障害など、システ ム品質とは関係のない要因で止まることも多々発生した。 気軽にテストを実施できるようになったものの、機能アップデートに伴うメンテナンス工数の増加など、実用に足るものでは無かった。 Copyright© 2026 dotD All Rights Reserved.
14. 検証②：テスト実行（打鍵）をAIで対応 Playwright MCPによるAI駆動による自律的な打鍵、および結果確認・受入
15. 検証②：AIに仕様書だけ渡して自律的に画面操作をさせる • • 以前の検証ではテストコードのメンテナンスに時間がかかることが判明した。 そこで、AI自身が自律的にブラウザを操作できる点に着目し、テスト仕様書のみを渡してテストさせる手法を思いついた。 定義 詳細化 実行 確認 改善 以前 シナリオを 作成 AIがコードを 生成 人が実行 人が結果を 確認 人が修正を 指示 改善案 期待結果を 確定 AIが仕様を 詳細化 AIが打鍵・ 記録 人が事実を 確認 AIが修正・ 再実行 ▪ 人が正しさを判断 Copyright© 2026 dotD All Rights Reserved. ▪ AIが作業を実行
16. テスト仕様書を元にAIが実行可能な状態にする AIが詳細化する領域 人がテスト観点を固定する 1 テスト観点整理 目的・要求・受入条件 2 テスト仕様書 観点を 具体化 → 検証すべき観点 画面・入力データ・ 期待結果・外部反映 → 承認済みシナリオ 人がレビュー： 業務要件との整合 例：認定試験の要求を満たす Copyright© 2026 dotD All Rights Reserved. 例：申請→外部承認→反映確認 3 テスト詳細仕様書 人が レビュー・ 承認 抜け漏れ・ 妥当性を 確認する 承認済み仕様だけを詳細化 操作順・入力値・ 待機条件・取得する証跡 を1ステップずつ記載 → 実行可能な手順 例：再読込後に状態を確認
17. 改善後は、定義・レビュー・実行・改善を一つの運用にした 1 定義 2 レビュー 3 実行 4 改善 要件・受入条件 テスト担当レビュー AI詳細仕様書 不具合検知 上位仕様書 抜け漏れ確認 直列／並列打鍵 事実確認 具体仕様書 期待結果を確定 ログ記録 修正・再実行 スキル化 レビュー済み仕様だけを実行へ渡す Copyright© 2026 dotD All Rights Reserved.
18. AI詳細仕様書を渡し、AIが実行・人が評価を確定する テスト観点＋仕様書 人間 事実・判断 テスト 打鍵指示 人が結果確認 期待値と比較 最終判断 指し戻し AI 実行・記録 AI詳細 仕様書 AIが打鍵 ブラウザを操作 証跡を記録 ログ / trace 統合報告書 打鍵指示後は、AIが自律的に詳細仕様書作成・画面操作・テスト結果まとめを行い、 完了したら人に結果報告を行う Copyright© 2026 dotD All Rights Reserved. AIが 再実行
19. 並列化は、依存のないシナリオだけに使う 依存あり：順序と待機を守って直列実行 前工程／共有データ 共有準備 レビュー済み仕様書 認証・テストデータ 前工程から 順に実行 外部反映を待ち 次へ進む 実行ログを集約 依存あり？ 依存なし：独立シナリオを同時実行 Agent A ｜ 独立シナリオA 無闇に効率化を測ってAIオーケストレーションを利用すると、 データ処理の前後関係で不具合の原因となることがある。 シナリオに応じて使い分けよう。 Agent B ｜ 独立シナリオB Agent C ｜ 独立シナリオC データと前後関係で直列／並列を決める Copyright© 2026 dotD All Rights Reserved. 人が結果レビュー
20. 『失敗した』を4種類に分けると、次の行動が決まる アプリ不具合 Issue化・修正 テスト 失敗 人が判断 （AIと壁打ちしながら原因調査・および対策を検討する） 証跡を揃える ログ / trace 画面状態 AIが事実確認 観測と期待を 分けて記録 仕様差分 仕様書更新・再レビュー 再実行 原因 分類 データ／環境不足 前提を整備 結果を 再確認 AI操作ミス 指示・スキルを更新 再実行できないときは、人が状況確認・判断 Copyright© 2026 dotD All Rights Reserved.
21. Issue化は、AIの指摘を『確認できる事実』に変える工程 項目 記載例 観測事実 外部承認後、指定待機時間を過ぎても自社側へ反映されない 期待結果 承認済みステータスが自社側で確認できる 再現手順 一意な申請作成 → 外部承認 → 待機 → 再読込 証跡 タイムスタンプ、操作ログ、trace、画面状態 人間の判断 仕様差分・環境遅延・アプリ不具合のどれかを確定 Copyright© 2026 dotD All Rights Reserved.
22. 改善後の価値は、打鍵削減よりレビューへ集中できたこと 変えたこと 運用上の変化 なぜ重要か AIが完了まで進める 張り付き時間を減らす 人は仕様と結果を見る 日本語仕様書を中心にする 関係者がレビューできる 正しさを共有できる Issue形式を固定する 再現確認しやすい 調査の入口が揃う 停止原因をスキル化する 同じミスを減らす 運用が学習する Copyright© 2026 dotD All Rights Reserved.
23. 検証②まとめ：再現性は下がったが、メンテナンスが楽になった メリット 判明した課題 AIが打鍵完了まで自律的に行動してくれるため、張り付かなくて よくなった。 意図しない操作や、テスト仕様書と実際の仕様の違いで止まって しまうことがあったため、その度に確認が必要だった。 日本語でのテスト仕様書レビューに集中することができたので楽。 CLIベースでの指示出し、AI駆動テストだったので、開発者以外 には操作の敷居が高く属人化した。 再現手順などテンプレートを決めておけば、体系立ててissue化 してくれるので、後から再現確認を行いやすかった。 画面を状況に応じて何度も操作をするため、トークンを結構消費 する。（利用したのはclaude codeのPremiumシート） ※スキル化などでナレッジを貯めていくとミスは少なくなっていく ※画面打鍵のみ安いモデルに切り替えるように整備すると多少節約できる 実行者がAIの使い方に慣れている必要はあるが、 ある程度の精度を保ちながら、メンテナンスコストをかなり抑えることができた。 Copyright© 2026 dotD All Rights Reserved.
24. まとめ それぞれの長所・短所
25. まとめ：テストコード生成とAI打鍵、必要に応じて選択 検証①：E2Eテストコードを迅速に生成 ➢ 再現性高く打鍵を行うことができ、また開発者以外でも簡単に自動テストを行うことができる。 ➢ 実用向けに不確実性を考慮して、安定動作するよう整備するのに時間がかかった。またメンテナンスも大変。 検証②：テスト仕様書を渡し、AIに打鍵させる ➢ 不確実性の考慮をAIに負担させることで、メンテナンスの工数をぐっと減らせた。 ➢ ただし、仕様や前提知識の食い違いによる誤検知は、人がテスト仕様・結果を確認する必要がある。 それぞれに長所・短所がある。システムのテスト頻度や開発チーム規模に応じて、 どちらかを選択、もしくは組み合わせて運用をおすすめ。 Copyright© 2026 dotD All Rights Reserved.
26. https://dotd-inc.com/career 一緒に事業・プロダクトをつくる仲間を募集しています！ Copyright© 2026 dotD All Rights Reserved.
27. Thank you! https://dotd-inc.com/
28. 参考情報 Playwright Introduction — 実行基盤・対応ブラウザ https://playwright.dev/docs/intro Playwright Test Agents — planner / generator / healer https://playwright.dev/docs/test-agents Playwright MCP — structured accessibility snapshotsによる操作 https://github.com/microsoft/playwright-mcp/blob/main/README.md dotD Tech Blog — 約22ステップ、約1.5か月、retry、timeout、運用改善 https://zenn.dev/dotdtech_blog/articles/68c9ab9e1ad91c 確認日：2026-07-21 Copyright© 2026 dotD All Rights Reserved.