「守りたい体験」を渡すだけで E2E を生成させられるようになった話

Transcript

1. Findy「AI時代の Playwright活用」 「守りたい体験」 を渡すだけで E2E を生成させられるようになった話 2026/07/21 Ubie May / 浦山 さつき
2. 課題 品質を見る QA が、AI と "願ったら叶った " を積み重ねてきた May / 浦山 さつき (@hinac0) • Ubie株式会社 / QA Engineer 2023/06から • JaSST東北実行委員 • コミュニティのみんなで書きました！ • ◦ ソフトウェアテスト技法練習帳 ◦ システムテスト自動化標準ガイド 最近よく、 AIに願っている 2025年10月 2025年12月 今回 自律的にテストをする AIテストエージェント 組み合わせ爆発と戦う "ぶんまわしくん" 守りたい体験を渡して E2E を生成 2
3. 会社概要 医療機関・製薬企業との連携で好循環エコシステムを構築し、 患者さんへのより適切な医療提供の貢献を目指しています 適切な治療に 1日も早く出会える 月間利用者数 1300万人以上 患者さんへ適切な 医薬品を届ける 患者さんと向き合う 時間を創出できる グローバルメガファーマ AI問診：導入医療機関 1800以上 企業との取引 9割 以上 生成AI：導入医療機関 100以上 3
4. 課題 提供したい価値は増え続けるのに、 E2E テストが追いつかない E2E テストが追いつかない 守りたい価値 • どんどん生まれ・変わる • 品質を数字で守りたい 守るべきユーザー体験＝ CUJ （Critical User Journey）を見 つけて守る ⇔ 人手で書くと、量も追いつかず、人によっ てバラつく 「壊れてから直す」受け身では、増える価値を守りきれない 4
5. 願い だから、願った "守りたい体験 " を渡したら 、 E2E を作ってほしい • 足りない体験を "先に・どんどん " 守りたい • 人が書くのは "テストの中身 " でなく "守りたい体験（価値＋実現点） " にしたい 5
6. 願い だから、願った "守りたい体験 " を渡したら 、 E2E を作ってほしい 医師がプリセットストアから「紹介状」プ リセットを自分用にインストールでき、イ ンストール後にそれが自分のプリセット 一覧に表示される（＝使える状態にな る）ことを守りたい できました！ 1.患者画面へ遷移し、「プリセット管理」ボタンが有効に なることを確認 2.プリセット管理ドロワーを開く 3.プリセットストアを開き「紹介状」を選択 4.「インストール」タブで名前と共有設定を入力 5.・・・ 6
7. 叶った（何を作ったか） 守りたい体験を渡すと AIが実アプリを探索し "戦略に沿った "E2Eを作って PRを出す GitHub Actions 人 生成 守りたい体験 を渡す 戦略 Doc に 沿って生成 探索 Playwright MCP で実アプリ 実行確認 その場で 実行して確認 PR PR を出す 人 PR をレビュー して承認 7
8. なぜこの形 How を全部決めるのではなく、ゴールと制約を定義した Before ＝ How を全部指定 After ＝ ゴールと制約を定義 手順・ツール・段取りを すべて人が決める 実装の形は対話から立ち上がる • • AIに渡したのは、 "やりたいこと " と "制約" だけ ◦ やりたいこと = 守りたい体験を CI で守る ◦ 制約 = 認証を漏らさない・戦略に沿う・レビューに載せる … HowをAIに任せた結果、既にある足場に薄く一枚載せる方法に決まった ▪ 普段使っている AI ツール ▪ CI ▪ レビュー導線 8
9. 守りたいもの・ AI の見え方・テストの中身・レビュー対象が同じ層で揃う 守りたい体験 ユーザーが価値に到達する旅（人が知覚できる層） AI の知覚 アクセシビリティ情報（ role / name / 表示テキスト） テスト getByRole('button', { name: 'ログイン' }) レビュー PR（同じ言葉のまま載る） 4層を貫く 1本 ＝ 同じ言葉（翻訳ゼロ） 9
10. シナリオ生成 AI に "書かせる " より、判断基準（テスト戦略）を言語化して渡す Before ＝ 暗黙知でバラつく After ＝ 戦略 Doc を参照 戦略が暗黙。人により基準が バラバラなテストになる 戦略 Doc を "最優先で" 読ませ、 全生成が同じ基準で揃う • E2Eテストは flakyでメンテも大変。数はむやみに増やさない • E2Eのテスト戦略ドキュメントを用意し、シナリオ生成のばらつきを減らす 例：提供価値をユーザーシナリオで再現／最小限／ "価値が実現したか " までアサート／実ユーザーの入 口を再現 etc… • 依頼者が書くのは "守りたい体験（価値＋実現点） " だけ。手順は探索に任せることができた 10
11. 探索・実装 AI はコードから "それらしいコード " を書けるが、実物のほうが正確 • Before ＝ コードから推測で書く After ＝ 実画面を見て書く 認証を突破できず、実物を見ずに コードから推測（脆いセレクタ） 認証済み状態を注入 → 実 DOM （role/名前）由来の堅いセレクタ Playwright MCPなしで、コードから画面の操作や要素を特定してテストスクリプトを作成することはでき た。動作確認もパスはしたが、 flakyさが残る • Playwright MCPを使うと、実際に読み込んだ画面で要素を特定できるため、テストスクリプトが堅牢に なった 11
12. 実行確認 完了基準は動作確認完了まで Before ＝人が実行し、修正する After ＝ 自律的にgreenを目指す 実行する間待ち、間違えたら直して再実 行。気づいたら時間を消費する greenになるまで確認を繰り返す。結果は 人が確認しやすいように録画付き Passするまで動作確認を繰り返す • 動作確認がパスしてこそ、完成といえる。結果が • 人があとからエビデンスを確認できるよう、動画付きのレポートを残す • 無限ループに陥らないよう、時間制限を設ける。時間を越えたら、できたところまでで PRを作成する 12
13. レビュー 生成物に要件（守りたい体験）を添えて、 AI ＋ 人の二段レビュー AI レビュー (CodeRabbit) 人レビュー 要件 × テスト の照合 仕様理解者が確認 依頼の "守りたい体験 " 原文を PR に載せて突き合わせる ＋ 動作確認を見える化： 実行レポート＋録画を成果物に 残す 承認は人 AI は提案、 マージは人間のゲート 13
14. 成果 「手が空いた人が書く」から「願えば増やせる」へ 観点 人がやっていた頃 いま 誰が書く 人が手で調べて書く 守りたい体験を渡すと AI が探索して書く 起点 気づいた人・手が空いた人 CI のフォームから誰でも （PR で残る） 一貫性 人ごとにバラつく 人もAIも戦略 Doc を参照 追従 増える価値に追いつかない 追従のペースが変わる （レビューは人が握る） 14
15. まとめ・次の願い HowはAIにまかせて、人はゲームのルールとゴールテープを握る まとめ • 判断基準（テスト戦略）を言語化して渡す ＝ バラつきの本質はツールでなく基準の不在 • 役割分担：人は "守りたい価値の言語化 " と "レビュー "、AI は "探索と実装 " • ツールは "機能" でなく "現場の制約（認証・可観測性・時間・レビュー）に手が届くか " で選ぶ 次の願い（ロードマップ）＝ "PR の時点で守る " へ 現在地：失敗を拾って自動分析しコメントする仕組み + 願えばE2Eが実装できる仕組み ① 自律 "修正"：変更がE2Eに影響する時に、 PR の時点で自律的に直して出す ② CUJ ↔ SLO/SLI ↔ リリースゲート を接続（数字で守り、毀損する変更を止める） 15