E2Eテストの最初の第一歩
>100 Views
October 27, 26
スライド概要
関連スライド
各ページのテキスト
E2Eテストの最初の第一歩 「どんなテストをするべきか」をAIと蹴り出す Motoaki Tanaka（@mot0aki） UV Study ｜ テストの手作業、どこまで減らせた？ ｜ 2026.10.27
自己紹介 Motoaki Tanaka X: @mot0aki ▸ 株式会社レッドジャーニー ソフトウェアエンジニア アジャイル開発推進 新規プロダクト開発・プロダクトマネジメント 生成AI開発・導入支援 AIカタリスト @mot0aki #UV_study 2
最近、セキュリティが大変 @mot0aki #UV_study 3
セキュリティのためのアップデートも含めて 恒常的に安定して、安全に保守し続けられる環境が必要 @mot0aki #UV_study 4
例えば、バージョンアップするにしても MUST NOT それでサービスがバグってしまってはいけない MUST NOT 新たなリスクを生んでもいけない @mot0aki #UV_study 5
そのためには？ @mot0aki #UV_study 6
テストを充実化させて いかないといけない @mot0aki #UV_study 7
ユニットテストはできるものの ✓ ユニットテスト 書ける・回せる E2E テスト やはり腰が重い ✗ @mot0aki #UV_study 8
特に E2E で詰まるところ ✓ テストコードの実装 ✗ どういうテストをするべきか AI で高速化できる 考えるのが難しい 書く速度は上がったのに「何をテストするか」で手が止まる @mot0aki #UV_study 9
そこで詰まっていても仕方がない！ 「何をテストするか」も、とりあえず蹴り出してみよう @mot0aki #UV_study 10
どうやって？ Playwright Test Agents を利用する @mot0aki #UV_study 11
Playwright Test Agents planner アプリを探索して テスト計画を作る 入力: 依頼文・ seed.spec.ts ・ PRD 出力: specs/*.md（人が読める 計画） generator 計画を Playwright の テストに変換 入力: specs/*.md 出力: tests/*.spec.ts（セレク タはライブで検証） healer テストを実行して 失敗を自動修復 入力: 失敗したテスト 出力: 通るテスト（壊れた機能は skip） 今回使ったのは planner の部分。「何をテストするか」を考えるところ 出典: https://playwright.dev/docs/test-agents @mot0aki #UV_study 12
使い方 01 02 03 npx playwright init-agents --loop=claude エージェント定義（planner / generator / healer）がプロジェクトに入る。Playwright を上げたら再生成 seed.spec.ts を用意する ログイン済みなど、探索の起点になる状態をつくるテスト Claude Code にお願いする コードと実際のプロダクトを触りながら、シナリオを一緒に考えてもらう --loop は vscode / claude / codex / opencode から選べる @mot0aki #UV_study 13
実際に投げたプロンプト “ このプロジェクトの中で利用しているPlaywrightのE2Eのテストについて、このプロダクトのコードとか 実際のプロダクトとかをいろいろ触りながら、E2Eのシナリオとしてどういうものがあれば必要十分かみ たいなことを一緒に考えたりするっていうのを手伝ってほしいなと思ったりしているんですけど、そういう ことってできそうな感じでしょうか？ まずは対象をfrontendとbackendに絞って考えたい。 @mot0aki #UV_study 14
786 件のケース一覧（Excel）ができる OUTPUT: e2e-cases.xlsx frontend・backend の全画面と全入口から、E2E としてあるべきケースを洗い出し ケース一覧 サマリー 環境タグの説明 対象外とした観点 気づいた点 優先度・正常系/異常系/認可・ローカルで動かせるか・根拠のコード行まで付いてくる @mot0aki #UV_study 15
いいところ 01 たたき台をベースに、チームで話しなが ら選べる どの順番で、どこまでのケースとするか @mot0aki #UV_study 02 ケースやシナリオに不服があれば、生成 AIとケンカしてやりなおせる 「これ本当に E2E でやるべき？」を何度でも 16
生成AIとケンカする（1） ユーザーが意識しないトークン保持のテストって、E2Eでやるべき？ A Cookie や CSRF トークンの保持を、通常の E2E で毎回確認する必要はない Q @mot0aki #UV_study 17
生成AIとケンカする（2） E2Eの中で API のレスポンスス テータスまで検査が必要？ A 基本的に不要。 「他人の情報を 閲覧できない」ことを利用者の 目線で確かめれば十分 Q @mot0aki #UV_study 18
786件は消さずに、層を分ける 786 洗い出したケース 7本 ブラウザ E2E 3本 外部連携スモーク 13 群 API 安全性 重要な業務フローの代表シナリオ 実メール・認証基盤をまたぐものは専用環境で 認可・CSRF・越権アクセスは API を直接たたく 残りは単体・結合・システムテストへ。画面1ケース = Playwright 1本、にはしない @mot0aki #UV_study 19
最小の E2E は 7 本 ログインして一覧・詳細を閲覧できる E2E-02 初回利用時に家族を登録でき、一覧に反映される E2E-03 投稿にコメントし、再読み込み後も残っている E2E-04 ログアウト後、保護された画面を見られない E2E-05 アカウントを切り替えても、前のユーザーの情報が出ない E2E-06 他人のデータの URL を直打ちしても見られない E2E-07 認証の期限更新後も操作を続けられる E2E-01 「主要な体験が続けられること」と「他人の情報を見られないこと」を優先 @mot0aki #UV_study 20
DEMO 実際のエクセルを一緒に見ていく ケース一覧 → 気づいた点 → 最小E2Eシナリオ → 見直しサマリー @mot0aki #UV_study 21
学び LEARNINGS @mot0aki #UV_study 22
01 02 03 04 セキュリティも見てくれる ケースを洗い出すついでに、コードから気になるところも上げてくれる 155 件の「気づいた点」 3 件は【重大】な認可の不備の疑い Mantis のようなハーネスと組み合わせれば、実際に動かしてバグや脆弱性があるかを 生成AIに確かめてもらえる cloud.google.com ／ Mantis のスタートガイド @mot0aki #UV_study 23
01 02 03 04 モノレポがいい AI に動かして確かめてもらうには、そもそもローカルで開発しやすい状態が前提 モノレポ frontend と backend を一度に読める ローカルで動く AI がそのまま起動できる 動かして確かめられる バグや脆弱性の確認まで Developer Experience を高めておくことが、AI に任せられる範囲を広げる @mot0aki #UV_study 24
01 02 03 04 テストケースだけでは文化的な側面が見えない CODE ONLY ドメイン知識や文脈は、コードからは読み取れない + CONTEXT @mot0aki #UV_study 例: モノレポのそれぞれのケースの文脈は読めなかった 文脈を補足して指示すれば、全然いけると思う 25
01 02 03 04 ミニマムは 7 件と言われた AI 最小構成のブラウザ E2E は 7 件 ME 本当にミニマムでいいのか？ には異議があった 結論 ミニマムとしては、まぁいいんじゃないか まず 7 本を置いて、足りないものは後から足していけばいい @mot0aki #UV_study 26
まとめ 「何をテストするか」で 止まらない AI にたたき台を出してもらう たたき台を チームと AI で削る 786件 → 最小の 7 本へ AI が動ける 環境と文脈を用意する モノレポ・DX・ドメイン知識 E2E の第一歩はまず蹴り出してみること @mot0aki #UV_study 27
ありがとうございました 質問・感想は懇親会で！／ X: @mot0aki ／ #UV_study @mot0aki #UV_study