「テスト設計から実行まで」をつなぐ — Playwrightを自己拡張するリグレッション基盤にした話
参考になった
0
株式会社TOKIUM / YNishidaQA
チームリーダー / QAエンジニア / 従業員規模: 101名〜300名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 11名〜50名 | 2026年2月 | B to B |
| ツールの利用規模 | 11名〜50名 |
|---|---|
| ツールの利用開始時期 | 2026年2月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
【背景】 テスト自動化を「一度書いて終わり」ではなく、プロダクトごとに自動実行できる範囲が時間とともに広がっていく仕組みにしたい、というのが出発点でした。当初は、静的なテストランナーとAIエージェントによる実行を別々のツールで並行運用する案もありましたが、2系統・2言語を並行で保守するコストを避けるため、1つの基盤に統合する判断をしました。
【選定の意図】 中核にPlaywrightを据えたのは、「安定して安く回す経路」と「AIに新しいケースを開拓させる経路」を、同じツールの上で両立できるからです。具体的には、
- 蓄積済みのテストは Playwright の静的実行（
npx playwright test）で、API消費ゼロで何度でも回す - まだ蓄積のない新規ケースは Claude Code ＋ Playwright MCP で、AIエージェントにブラウザを操作させる
という2モードです。AIに操作させた結果は Playwright のコード（spec.ts）として保存できるため、AIが開拓した成功がそのままコード資産になり、次回からは静的実行へ回せます。この「成功を資産化して静的化する」ループを回せることが、Playwrightのコードベース性を選んだ決め手でした。
【工夫】
- AI実行が不確定に終わったケースは、AI-nativeなVibiumへのフォールバックや自動リトライで立て直し、実質的に何も検証していない弱いテストは品質ゲートで弾いてから資産化しています。
- 金額を扱う業務系SaaSでAIにブラウザを触らせるため、安全層を後付けではなく前提として組み込みました。本番環境を設定上そもそも選べないようにする・本番URLへのアクセスを遮断する・破壊的な操作や個人情報を検出したら停止する、という多層の防護です。
- 蓄積済みかどうかの判定の誤りや、生成コードの脆さに備え、初期は人間レビューを挟み、連続して成功したものだけ信頼度を上げて静的実行に昇格させる運用にしています。
- AIエージェントの駆動部はPython、生成する静的テストはTypeScript（Playwright標準）という構成で、両者を一つのリポジトリにまとめています。
導入の背景・解決したかった問題
導入背景
導入の背景・解決したかった課題
株式会社TOKIUMでQA課の課長を務めている西田です。テスト実行の自動化に取り組んできましたが、出発点は「うまくいっていない状態の整理」からでした。
もともとテスト自動化にはノーコードツール（Autify）を使っていました。手軽さはありましたが、テストを「資産」としてコードで蓄積し、AIエージェントとの連携まで視野に入れたとき、コードベースの基盤へ移す必要を感じました。
扱っているのは金額を扱う業務系SaaSです。自動化を進めたい一方で、AIエージェントによる事故を起こすリスクは避けたい。この緊張関係をどう設計に落とすかが、最初からの宿題でした。
ツール導入前の課題
- ノーコード（Autify）では、テストをコード資産として蓄積し、AIと連携させていく方向に制約があった
- テスト「観点」の設計と、実際の「実行」コードが分断されていた
どのような状態を目指したか
テスト観点の設計 → テストケース化 → Playwrightによる実行 → 成功パターンの資産化までを一本の流れにし、その流れを回すほど自動実行できる範囲が広がる状態です。さらに、AIエージェントにブラウザ操作を任せても本番事故が起きない安全層を、設計の前提として組み込むことを条件にしました。
比較検討したサービス
- Autify
- Vibium
比較した軸
一般的なOSS・並列実行・自動待機に加えて、(1) テスト設計の観点をテスト資産としてそのまま表現・蓄積できるか、(2) AIエージェント（Claude Code / MCP）との連携余地があるか、の2点を重視しました。
特にAIエージェントの連携はかなり重点的な検討項目だったため、できればClaude Codeと連携できることが前提でした。
選定理由
実行の中核にはPlaywrightを据えました。理由は次の通りです。
- コードベース（spec.ts）で管理でき、生成したテスト資産がそのままCIで再利用できる
npx playwright testによる静的実行は、一度確立すればAPI消費ゼロで何度でも回せる- 失敗時にtrace / screenshot / videoが残り、デバッグ体験が良い
@playwright/mcpを使えば、AIエージェントにブラウザを操作させる経路も同じ世界観で確保できる
ノーコードからコードベースへ移す以上、移行コストに見合う「資産化」の効果を最重視しました。安定して安く回す経路（静的実行）と、AIに任せて新しいケースを開拓する経路（MCP実行）の両方を、Playwrightという一つの土台の上で持てることが決め手でした。
導入の成果
正直に書くと、自己拡張するリグレッション基盤というアーキテクチャ自体は稼働済みですが、生成されるテストケースの精度・品質評価は現在検証中で、「高精度で自動的に正しいテストが出る」とはまだ言えません。生成 → 人間レビュー → フィードバックの改善ループを回している段階です。
そのうえで定性的な手応えとして、一度静的実行に乗せた範囲は反復コストがほぼゼロになり（同じケースを何度回しても追加のAPI費用が出ない）、手動で回していたリグレッションの一部を夜間の定期実行に移せました。具体的な削減率や蓄積件数は社内で精査中のため、本稿では数値を控えます。
定量的に公開できるのは、PlaywrightとVibiumの実測比較です（出典: Zenn「Playwright vs Vibium 実測編」西田泰明・2026-04-14。条件: 11件のテストケースセット / Claude Opus 4.6 / @playwright/mcp 0.0.70 / Vibium v26.3.18 / macOS 26.4 / Node v25.6.1）。
| 計測項目 | Playwright MCP | Vibium MCP |
|---|---|---|
| AI処理時間 | 11分22秒 | 約20分 |
| MCPツールコール合計 | 116回 | 251回（約2.2倍） |
| 画面状態把握のコール | 44回 | 139回（約3.2倍） |
同じ仕事をさせたとき、Playwright MCPのほうがツールコール数が少なく処理時間も短いという結果でした。効率面ではPlaywrightに分があります（突破力の話は「課題点」で触れます）。
導入時の苦労・悩み
定番のPOM（Page Object Model）の粒度設計やFlaky対策はもちろんありました。固有の学びとしては、夜間の定期実行が「成功表示なのに中身は空回り」していた件です。CIの必須シークレットが未登録のまま走ると、ジョブは成功扱いなのにテストは軒並み実行不能になる——表示はグリーンなので、しばらく気づけませんでした。実行の冒頭で必須シークレットの空欄を検知して即fail（fail-fast）させて対処しましたが、「成功表示の裏で何もしていない」状態は、自動化を任せるほど怖いと痛感しました。
もう一つは、テスト観点を実行コードに落とす設計です。観点を素直にケース化すると「1観点=1ケース」に過剰単純化されがちで、ここは今も改善を続けています。
導入に向けた社内への説明
上長・チームへの説明
導入にあたって重視したのは、ツールを増やすこと自体を目的にせず、「安定して安く回す経路（静的実行）」と「AIで新しいケースを開拓する経路（MCP実行）」を1つの基盤に集約する、という設計の狙いを共有することでした。
特に時間をかけたのが、属人化を最初から「人ではなく仕組みで解く」ことです。テストケースの記述は観点マスターとスタイルガイドに準拠させて書き手が変わっても粒度がぶれないようにし、生成・蓄積されたコードはレビューを通してから資産として登録し、基盤のメンテナンスは担当と手順を明文化する。「誰が書いても一定の品質になり、誰がレビューし、誰が直すか」を先に決めておくことを、設計の前提に置きました。
もう一つは、安全設計を導入の条件として先に合意したことです。AIにブラウザを触らせる以上、本番事故防止は後付けではなく前提だ、と。これを最初に握れたことで、その後の実装判断がぶれませんでした。
活用方法
自然言語のテストケースを、2つのモードで実行する
入力は、Gherkin（Given/When/Then）形式で書いた自然言語のテストケースです。テスト設計で作ったケースが、そのまま実行入力になります。これを2つのモードで回しています。
- 静的実行（
npx playwright test）: 過去に成功して蓄積済みのコード（spec.ts）を実行する経路。API消費がゼロなのが利点です。 - MCP実行（
@playwright/mcp＋ Claude CLI）: AIエージェントにブラウザを操作させる経路。まだ蓄積されていない新規ケースが対象で、Given/When/Thenを自然言語プロンプトに展開して実行します。
どちらを使うかは、蓄積済みかどうかでコード側が機械的に振り分けています（この判定はコードで答えが出るので、LLMには任せていません）。
失敗を立て直し、成功を資産化する（自己拡張ループ）
ここが、Playwrightをコードベースで選んだ理由に直結します。
MCP実行は一度で成功するとは限りません。決着しなかったケースは自動で再試行し、立て直せたものだけを品質ゲート（実質的に何も検証していない弱いテストは登録拒否）に通します。通ったケースはPlaywrightのコード（spec.ts）として蓄積し、次回からは静的実行＝API費用ゼロで回せるようになります。
つまり、AIに開拓させた成功が「資産」としてコードに積み上がり、回すほど静的実行できる範囲が広がっていく設計です。属人的なノウハウを人の頭ではなくコードリポジトリに蓄積し続ける、属人化解消の仕掛けでもあります。CI（GitHub Actions）で毎日深夜に定期実行し、蓄積に差分が出ればPRを自動生成して人がレビューする運用です。
ただし正直に補足すると、この仕組みは回り始めた段階で、静的化が十分な規模で積み上がったとはまだ言えません。
AIにブラウザを触らせるための安全層
金額を扱う業務系SaaSでAIにブラウザを操作させる以上、安全層は妥協できません。本番環境を設定上そもそも選べないようにする、本番ドメインへのアクセスを遮断する、破壊的な操作（全件削除など）や個人情報を検出したら停止する——といった防護を多層で前提に組み込み、課題管理ツールへの自動起票もデフォルトでオフにしています。安全設計を「あると便利」ではなく「ないと出せない」前提機能として最初に据えたのが要点です。
よく使う機能
- Trace Viewer / screenshot / video: MCP実行で新規ケースを開拓するとき、失敗の原因を追うのに不可欠です。
@playwright/testの静的実行: 蓄積済みケースをAPI消費ゼロで回せる、運用の土台。@playwright/mcp: AIエージェントにブラウザ操作を任せる経路。- storage_state（セッション共有）: ログインコストの高いプロダクトで効きます。鮮度が切れたら警告するようにしています。
ツールの良い点
生成したテスト資産がそのままCIで再利用できる。AIに作らせたものを「資産」に変換できるのは、コードベースであることの恩恵で、ノーコードから移行した一番の見返りでした。
- 静的実行のAPI消費がゼロになる。AIを使う自動化はコストが論点になりがちですが、成功を静的化してしまえば反復コストはほぼゼロです。
- trace / video / screenshot のデバッグ体験。他社レビューでも高評価の通り、実感としても良いです。
- 2モードを一つの土台で持てる柔軟性。「安定して安く回す」と「AIで開拓する」を同じPlaywright上で両立できます。
ツールの課題点
設計スキルが前提。Playwright自体が優れている分、POMの粒度設計やテスト設計の落とし込みは人に依存します。放置すればコードは肥大化し、属人化します。設計の良し悪しまでは自動化しきれません。
- AI生成テストの精度は未検証。前述の通り、生成ケースの品質評価は現在進行中で、「1観点=1ケース」になりがちな過剰単純化が課題として残っています。
- ノーコードからの移行には書き換えコストがかかる。ノーコードで作った資産はコードへそのまま移せるわけではなく、コード化の手間と資産化のメリットを天秤にかける判断は必要です。
- 生成AIを噛ませて運用を再構築している関係で、いっそこの際包括的なリグレッションテストを自動設計し、その精度向上させていく方がやりやすいとまで考えています。
- AIにブラウザを触らせる経路は、安全設計とコスト管理が必須。何も考えずにMCP実行を解放すると、本番事故やAPIコストのリスクがあります。これらは「あると便利」ではなく「ないと出せない」前提でした。
- AI-native系との棲み分けは残課題。効率はPlaywrightが優る一方、Vibiumのほうが「突破力」で勝る局面があります。実測では、Reactのcontrolled input、HttpOnly Cookieの操作、複数タブ、DOMを直接調べる必要があるケースで、PlaywrightがSkipしたものをVibiumがPassできました（出典: 前掲Zenn記事）。どちらか一方では足りない、というのが現実です。
※他ツールとの棲み分けが必要、という点で−0.5ポイントしています
ツールを検討されている方へ
QA組織としてPlaywrightを導入するなら、以下の3点が重要だと考えています。
- 「何を自動化するか」の設計を先に。ツール選定より、テスト観点とケース設計を整える方が長期的に効きます。
- 属人化対策を最初から組み込む。POM設計や資産の蓄積方針、レビュー体制とメンテ責任を、個人の工夫に委ねず仕組みにする。
- AIを使うなら安全層を「導入の条件」にする。特に金額を扱う業務系SaaSでは、本番事故防止を後付けにしないことです。
ノーコードから移ってきた立場で言えば、移行は「楽になる」ためというより「テストを資産として育てられるようにする」ための投資でした。手軽さを手放す分、コードとして積み上がる価値を取りにいく判断です。
今後の展望
自動テストケース生成の精度検証を進め、生成物をどこまで信頼できるかを見極めること。そして、CI/CDのリグレッションはPlaywright、探索的・即席の確認はVibiumのようなAI-native側、という棲み分けを深めること。この2つが当面のテーマです。
Playwrightは「速くて安いE2Eツール」という以上に、AIに作らせたテストを資産化し、組織知としてコードに蓄積していくための土台として優れていると感じています。派手な工数削減数値はまだ控えますが、テスト設計から実行・資産化までを一本につなぎたいチームには、検討する価値が十分にあるツールだと思います。
株式会社TOKIUM / YNishidaQA
チームリーダー / QAエンジニア / 従業員規模: 101名〜300名
よく見られているレビュー
株式会社TOKIUM / YNishidaQA
チームリーダー / QAエンジニア / 従業員規模: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法