AI時代のPlaywright活用(システムテストを自動化する ー 実行エンジンにPla ywrightを選んだ理由)

自動化が難しいとされてきた新機能のシステムテストを、生成AI(Claude Code)とPlaywrightの組み合わせで「設計→実行→エビデンス→資産化」まで一気通貫で自動化した実践の記録です。

・何を・なぜ自動化したかったのか — 回帰の自動化は回っていて、最も人手を食っていた新機能テストが対象
・実行エンジンの選定 — 金額の精密検証/ロール別認証/CI安定性/資産化/失敗時調査という業務要件からの逆算
・"LLM向け"を謳う新興ツールVibiumとの同一テストケース実測比較(ツールコール116 vs 251)と、役割で組み合わせる使い分けの実運用
・運用の結果 — 実行コード資産約300件・健全率約98%。画面改修で34件が一斉に壊れた際、失敗モードの機械分類で31件をAI追加課金なしで復旧

詳細はZennのTOKIUMテックブログ(実践編・理論編・実測編)で公開しています。

Transcript

1. システムテストを自動化する ー 実行エンジンにPlaywrightを選んだ理由 西田泰明 株式会社TOKIUM QAエンジニア 2021年 一人目QAとして入社しQA組織立ち上げ テストケース⾃動⽣成 実⾏結果を記録 レポートを⾃動作成 設計 実⾏ 報告
2. — TOKIUMのプロダクトと、テストの難しさ ⽀出管理クラウド(SaaS) 経費精算 契約管理 電⼦帳簿保存 テストの難しさ 1 プロダクト間連携 連携が多く、1つの修正の 影響範囲が広く複雑 インボイス 請求書発⾏ 経理AIエージェント 相互連携 2 ⾦額計算 経理業務のため、1円の ミスも許されない AI出張⼿配 AI明細⼊⼒ AI新リース判定 AI経費承認 AI請求照合 AIヘルプデスク 3 会計フォーマット 会社ごとに無数にあり、テスト データ・フォーマット選定が困難 2
3. — ポイント A 何を・なぜ⾃動化 したかったか B どう解決 しようとしたか C なぜPlaywright を選んだか Playwright vs 対抗⾺の⽐較 =選定を確かめる検証 3
4. 回帰テスト — 【A】何を・なぜ自動化したかったのか 狙い: 新機能のシステムテスト(毎回画面構造が違う) 『人が見て判断する』部分が多い → 自動化困難とさ れてきた ゴール: 設計→実行→エビデンスまで一気通貫 同じ画⾯を繰り返す → ⾃動化しやすい 新機能テスト 狙うのはこちら 毎回画⾯構造が違う ⼈がその場で判断 → ⾃動化困難とされてきた 4
5. — 【B】全体像 — 仕様/リポから「設計→実行→報告」を一気通貫 ① インプット 仕様 開発リポ 過去テストケース テスト観点 ② ③ 設計 観点→テストケース (Gherkin) AI＋ナレッジで⽣成 実⾏〔決定論〕 まずPlaywright 状態把握できない所だけ AI探索 テストケース資産 実⾏コード資産 ④ 報告 結果・エビデンス 不具合起票 ⑤ ⑤再利⽤: テストケースと実⾏コードを資産化 → 次回は決定論で再実⾏(AI課⾦ゼロ) 軸: 上流＝設計は有人(判断) / 下流＝実行〜報告は決定論(再現性・低コスト) ※ 概念図まで。「何をテストするか(設計)」までAIが担うのが、従来のE2E自動化との違い 5
6. — 【C】実行エンジンは? 必須条件(実行エンジンに求めたもの)は4つ: LLMが介在できる 運⽤コストが低い (OSS) テストが資産になる ブラウザ操作 実⾏エンジン =? 6
7. — 【C】候補: OSSブラウザ自動化ツール ツール Selenium Cypress Puppeteer Playwright Vibium ブラウザ 多ブラウザ・多言語 Chrome系/FF/Edge・WebKit実験 的 Chrome中心 Chromium/FF/WebKitを1本で Chrome Selenium Cypress Puppeteer Playwright Vibium 位置づけ(要件との相性) 老舗(2004年〜)。自動待機は自前でFlaky寄り DX良。マルチタブは標準非対応・クロスオリジンは cy.origin 軽量。ランナー/アサーション別途 全部入り(自動待機・並列・trace)。LLM介在が最も柔軟にできそう → 本命 “LLM向け”を謳い2025年末登場。約10MB・ランナー/アサーション非搭載 → 対抗馬 必須4条件 OSS・ブラウザ操作 ・資産化・LLM介在 本命 Playwright 対抗⾺ LLM介在が最も 柔軟にできそう “LLM向け”を 謳う新種 Vibium 同⼀テストケース で実測(次ページ) 7
8. — 【C】同一テストケースで実測比較 対象: 特定プロダクトの機械可読なテストケース298件から代表11件を、Claude Code×MCPで両ツール実行 所要時間 短いほど良い 11分22秒 Playwright Vibium うち状態把握コール Playwright Vibium 約20分 (約1.8倍) 総コール数の内訳・差の主因 44 139 (約3.2倍) 総コール数 Playwright Vibium 少ないほど低コスト 116 成功テストケース(11件中) Playwright Vibium 251 (約2.2倍) 多いほど良い 7件 8件 PWがSkipした4件中2件をDOM直接調査で突破(探索⼒) ※ コール = AIからのツール呼び出し回数 ≒ Claudeのトークン利⽤料。バーの⻑さは各パネル内の相対⽐較 差の主因 = 『画面の状態把握』。PWの snapshot が1回で把握+要素探索を完了 『AI向け設計』を謳う ≠ AIが効率よく使える Vibiumの利点 = 探索力(図の右下)。V2で逆転の可能性(日程未定) 8
9. — 【C】決め手は業務要件からの逆算 — だからPlaywright 業務要件 金額の精密検証(1 円単位) ロール別認証 CI/CD安定性 テスト資産化 失敗時調査 Playwright ◦ 専用アサーションで検証 ◦ fixturesで簡潔に切替 ◦ 5年+の実績・Microsoft保守 ◦ 生成コードがそのまま資産(Claude Code / Playwright Test Agents) ◦ 自動スクショ+Trace Viewer 実測の数字ではなく、要件から逆算して選んだ Vibium ✗ アサーション非搭載 △ 定型化の仕組みなし(自前) △ 2025年末登場・実績これから ✗ ランナー非搭載=テストとして再実行 する受け皿がない △ スクショのみ・トレース機能なし 9
10. — 【C】PlaywrightとVibiumの使い分け Claude Code ̶ ⼯数削減の頭脳 設計・可否判断・報告の⾃動化 Playwright ̶ 基盤・定型の回帰 Vibium ̶ 探索的・⾮定型 決定論・資産化・CI安定・精密検証 DOM直接調査で突破する柔軟性 実運⽤: まずPlaywrightで回し、落ちた分だけVibiumで再試⾏ Vibiumでしか通らないものは専用枠として台帳管理 — 1つに決めるより、目的で使い分ける 10
11. — 【C】Playwrightと資産化の仕組みを作った結果① — 資産の積み上がり 実例: ある新機能 (⼀覧のソート)のテスト依頼 テスト設計 24件 初回実⾏ 22/24 Pass ※資産化は優先度の⾼いUI操作から順次(残りは登録候補として管理) Fail 0・当⽇中に24/24 資産化 7件 以降はAI課⾦ゼロで再実⾏ ▼ これをテスト依頼のたびに繰り返した、現時点の積み上がり(社内全体) 実⾏コード資産 健全率 (すぐ使える) 約300件 約98% 設計済み テストケース コード化率 700件超 約2割 →伸びしろ 集計は決定論スクリプトの自動生成 — AIの自己申告は入れない ※2026-07時点の社内集計(丸め値) 11
12. — 【C】Playwrightと資産化の仕組みを作った結果② — 壊れても安く直せる 2026-06の画面リニューアル(検索フォーム再設計)で34件が一斉にbroken → 失敗モードを機械分類 ロールのズレ (⼆重ヒット/剥落) ラベルの喪失 (getByLabelが0件) プレースホルダの変化 開閉状態の判定 その他(個別要因) 34件 broken 1 7 3 0 5 パイロット3件で パターン確⽴ 17 6 10 15 横展開 約8割は「要素の探し⽅」のズレ 検証ロジックは⽣きていた 20 31件復旧・AI課⾦ゼロ 残3件→理由明記で⼈間判断 合否は機械の検証ゲートのみ(AIの自己申告Passから不安定テスト1件を検出) 12
13. — 振り返って（今イチから始めるなら？） 1. 何を自動化したいかを先に言語化(回帰か新機能か、対象の性質) 2. 情報は集約されているか — 散在していればツール選定より前に着手(壁は情報散在) 3. 『テストを育てる』ではなく『テスター(AI)を育てる』設計に — AIと人の領域を線引き 4. 要件(金額精度/認証/CI/資産化/調査性)を先に立て、実行エンジンは最後に逆算で選ぶ 5. AIの自己申告を信じない — 合否は機械検証(実行ゲート)で判定し、人間は監査に回る 1 何を⾃動化 するか ⾔語化 2 情報を ⼀箇所に 集約 3 テスター (AI)を 育てる設計 4 要件から 逆算して 選定 5 AIの⾃⼰ 申告を 信じない 次の⼀⼿: 1機能・ 数テストケースで⼀周 13
14. もっと知りたい方へ / We're Hiring Zennに実践の詳細を公開(TOKIUMプロダクトチーム テック ブログ) 新機能システムテスト自動化の実践編 / Playwrightと Vibiumの比較・実測編 / AIエージェントQA編 TOKIUM QAは一緒に品質と開発生産性に向き合う仲間を募 集中 — 採用ページ(右のQRからも) connpass: yasuaki-nishida ご清聴ありがとうございました — このあとQ&Aでお答えします Zennで実践を公開 ynis_qa 実践編 / ⽐較実測編 / AIエージェントQA編 We're Hiring ̶ 採⽤ページ connpass: yasuaki-nishida 14
15. ――― 付録 15
16. 仕様 ソース 結果 GitHub — 【付録】解決の骨子: GitHubに集約し、設 計→実行→報告を回す GitHubに一元化(仕様・ソース・テストケース・ 結果) Claude Codeで『設計→実行→報告』を回す ツールより先に、情報集約 実行エンジンは未決定のまま → 後半で テストケース Claude Code 設計 実⾏エンジン 実⾏ ? 報告 ※この時点では未決定 →後半で 16
17. — 【付録】発想の転換: 『テストを育てる』→『テスター(AI)を育てる』 従来のE2E（リグレッションテスト） = 一度書いたら繰り返す = 『テストを育てる』 新機能テスト = 過去に作成したテストがない → 固定スクリプトが効かない Claude Codeは会話終了でコンテキストが消える → ナレッジを外に蓄積し『テスター(AI)を 育てる』 テストを育てる ×N ⼀度書いたスクリプトを繰り返す (従来の回帰E2E) 発想の転換 テスター(AI)を育てる ナレッジ テスター 精度が向上 ナレッジを外に蓄積 → 実⾏の度に精度が上がる 17
18. — 【付録】テスター(AI)を育てる5つの工夫 1. アカウント/データは人が事前準備 — .env.staging にロール別 / loginAs(page,"admin") 2. Gherkinで仕様を構造化 — Given=前提(ログイン・遷移) / When=UI操作 / Then=期待結果・アサーション 3. 自動化可否を4分類(◎/◦/△/✗) — ◎◦のみ自動実行して無理 をさせない 4. スクリプト作成前にUI構造を調査 — フロントソース読み・ ARIA属性把握・スクショ 5. ナレッジファイルに累積学習 — 技術ルール集 / NG事例と正し い判断のガイド 1 2 3 4 5 アカウント事前準備 G W T Gherkin構造化 可否4分類 UI事前調査 ナレッジ蓄積 18
19. 仕様書 ? — 【付録】根っこの課題は『情報の散在』 判断材料が一箇所にないと、AIの精度が出ない ボトルネックは『情報の置き場所』 あなたのチームのテスト情報は、今どこにあります か？ ソースコード ? QAのテスト 観点 過去の不具合 ? テストケース 判断材料が 揃わない… 実⾏結果 ボトルネックは『情報の置き場所』 19