📝

AI時代のQAは『書いて回す』から『生成・解釈・判断する』へ ─ 仕様駆動 × 探索駆動の二刀流

に公開
AI
Playwright
QA
Model Context Protocol
Claude Code
idea

はじめに

QAエンジニアの仕事は「テストケースを手で起こし、手で回し、結果を Excel に貼る」だった時代から、ここ1〜2年で大きく形を変えつつあります。Playwright のような自動化基盤、Claude Code のようなAIエージェント、そして MCP（Model Context Protocol）を通じてブラウザを操作するAI──これらが揃ったことで、テストは「人が書いて回すもの」から「AIに生成・実行させ、人が解釈・判断するもの」へシフトしてきました。

本記事は、弊社で実際に運用している Claude スキル群（spec / generate-page-spec / generate-qa-tests / execute-qa-tests / report-fails / qa-explore / validate）を土台に、AI時代のQAがどうあるべきかを整理したものです。具体的なツールの使い方というより、思想・運用知見にフォーカスします。

AI時代のQAを支える4つの軸

詳細に入る前に結論を置きます。AI時代のQAには次の4軸があります。

  1. 仕様駆動 × 探索駆動の二刀流 — 仕様があるものは仕様起点で網羅、ないものは探索で発掘する。両者は対立ではなく補完。
  2. ナレッジ蓄積ループ — テストするほどAIが対象の癖を学習する。Finding（事実）→ Hypothesis（仮説）→ Probe（検証計画）の3層モデルで、前セッションの気づきが次セッションの起点になる。
  3. AIと人間の役割分担を混ぜない — DOM・遷移・バリデーションはAI、UX判断・モバイル実機・スクリーンリーダー・決済は人間。境界を明確にして、無理に自動化しない。
  4. コードを書く人／書かない人の両立 — 開発者は CLI / AI エージェントで仕様駆動、現場QAは GUI ツールで録画駆動。同じ Playwright 基盤の上で、入口だけが違う世界へ。

以下、それぞれを掘っていきます。

全体パイプライン：QAをどう組み立てているか

弊社のQAパイプラインは、要件から不具合起票までを一本のレールにしています。

要件 (Issue / Asana)
   │
   ▼
[generate-page-spec] ──► spec.md（受け入れ条件 = AC）
   │
   ▼
[generate-qa-tests]  ──► test.md（QAテストシナリオ）
   │
   ▼
[execute-qa-tests]   ──► test-runs_NN_YYYYMMDD.md
   │                     + screenshots/ + recordings/
   ▼
[report-fails]       ──► GitHub Issue（FAIL/WARN）

並走：[qa-explore]    ──► 23観点 × 仮説検証で、仕様にないバグを発掘
横串：[validate]      ──► 要件・設計・実装のギャップ検証

ポイントは「仕様 → テスト → 実行 → 起票」という主線に、並走として探索的テスト、横串として整合性検証が入る点。仕様駆動だけだと仕様外のバグが漏れ、探索駆動だけだと網羅性が担保できないので、両方を回します。

思想その1：仕様駆動 × 探索駆動の二刀流

軸 入力 強み 弱み
仕様駆動（spec → tests → run） spec.md の受け入れ条件（AC） ACのカバレッジを定量管理できる、再現性が高い 仕様にない・想定外のバグは見つからない
探索駆動（qa-explore） URL + テスト意図 仕様未整備サイトでも回せる、仕様外のバグを発掘 観点の網羅性は人間のレビューが必要

新規ページや要件確定済み機能には仕様駆動を、レガシー画面・仕様未整備サイト・「何かおかしい気がする」と感じる箇所には探索駆動を回します。「片方だけ」を選ぶ運用は、どちらの弱みにもハマる結果になりがちです。

仕様駆動は AC（受け入れ条件）の質がそのままテスト品質の上限になるため、AC をきちんと書ける開発・PM 文化こそが自動化効率の肝になります。一方の探索駆動は「ルンバ型」と呼んでいて、AIが自律的に画面を歩き回りながら違和感を拾います。

思想その2：ナレッジ蓄積ループ（テストするほどAIが賢くなる）

ここが本記事で一番伝えたいパートです。「テストするほどAIが対象の癖を学習する」エージェントを作るために、私たちは3層モデルを使っています。

Finding（事実）── 2件以上の同じ匂い ──► Hypothesis（仮説）
   ▲                                         │
   │                                         ▼
   └────────── 検証結果フィードバック ──── Probe（検証計画）
  • Finding: テスト中に観察した事実（バグ／観察／仮説確認・棄却）
  • Hypothesis: 複数の Finding から立てた弱点・癖の仮説（状態管理／バリデーション／フォーカス制御 等）
  • Probe: 仮説を検証する具体的なテスト計画

たとえば、ある画面で「フォームの戻るボタンを押すと入力が消える」「タブ切替でも入力が消える」という Finding が2件揃ったら、「この画面は状態保持の設計が弱いのでは」という Hypothesis に昇格します。次に Probe として「リロード／タブ切替／戻る／別ルートからの遷移」を網羅的に試す検証計画を立てる──という流れです。

セッションの最後に「次セッションへの申し送り」を1〜3行で書いておくのが大事で、これが前セッションの気づきが次セッションの起点になる仕組みになります。これは熟練QAエンジニアが頭の中で自然にやっている「対象を知る」プロセスを、エージェントが共有・継承できる形に構造化したものに過ぎません。

ナレッジは qa-knowledge/targets/<slug>/findings.md のようにプロジェクトごとにファイル化されるので、人間がレビューしたり、別プロジェクトに横展開する場合の参照資産にもなります。

思想その3：AIと人間の役割分担を混ぜない

qa-explore スキルの定義に明記している分担表を引用します。AI時代のQAの肝は、ここを混ぜないことです。

領域 担当 理由
HTML/JS で再現できる振る舞い、バリデーション、遷移、DOM状態 AI Playwright で安価・高速に大量実行可能
同時実行 / レースコンディション 人間 自動化が高コスト、観察判断が必要
実機モバイルUX（タッチ・ソフトキーボード・日付ピッカー） 人間 エミュレータでは再現不能
スクリーンリーダーでの主観評価 人間 主観品質はAIには判定できない
長時間放置・大量データ 人間 コスト的に自動化が割に合わない
決済・本物のメール送信 人間 副作用が不可逆、安全性最優先

自動化が困難なテストは、無理に Playwright で書かず manual-tests.md に手順を起票して人間に渡します。「AIで全部やる」を狙わないことがコツです。

ここを混ぜると何が起きるか。AIは「画面に文字が出ているか」は判定できても、「ユーザーがその文字を読んで安心するか」は判定できません。前者と後者を一緒くたに自動化しようとした結果、緑色のテスト結果が並ぶ一方で、リリース後に UX 起因のクレームが出る──というのが、AI時代のQAで最も警戒すべき失敗パターンです。

「変わったこと」と「変わらないこと」

整理すると、AIが代替する作業と、引き続き人間が担う作業は次のように分かれます。

変わったこと（AIが代替する作業）

  • テストケース設計の初稿作成 — spec.md の AC からシナリオを機械生成
  • テストの実行と証跡記録 — Playwright MCP がスクショ・録画・DOM スナップショットを自動取得
  • 不具合の一次起票 — FAIL 検出 → GitHub Issue 起票まで自動
  • 観点の網羅チェック — 23観点 × カバレッジ管理で「未着手／消化済み／再訪推奨」を機械的に追跡
  • テスト仕様書の鮮度管理 — spec 更新日 vs テスト作成日の比較で、自動的に再生成判定

変わらないこと（人間が引き続き担う仕事）

  • 何をテストすべきかの判断 — 受け入れ条件の妥当性、リスクベースの優先順位
  • 失敗の解釈 — 仕様バグか実装バグかテストコードのバグかの最終判断
  • 仮説の妥当性レビュー — AIが立てた Hypothesis を「筋がいいか」評価する
  • 手動テストの実施 — モバイル実機・スクリーンリーダー・決済系
  • 品質の意思決定 — リリース可否、リグレッションリスクの受容判断
  • 顧客視点の主観品質 — 使い心地、わかりやすさ、安心感

QAエンジニアの仕事は消えません。書く・回す・記録する仕事から、設計する・解釈する・判断する仕事へ重心が移るだけです。

やってはいけないこと（守るべき原則）

運用の中で痛い目を見て言語化された禁則を、5つだけ抜粋します。

  1. AIにバグの修正をさせない — QAの仕事は原因を見つけて報告するまで。修正は開発スキル側に渡す。境界が曖昧になるとテストと実装の独立性が崩れる。
  2. 本番DB書き込み・本物の決済・本物のメール送信は絶対にしない — 副作用の不可逆性は最優先。テストでうっかり顧客にメールが飛んだら終わり。
  3. 「とりあえず動くテスト」を量産しない — 観点を消化するために中身のないテストを書くと、緑色の安心感だけ残ってバグは漏れる。狙うバグ（欠陥仮定）を明確にしてから書く。
  4. 失敗を即「テストの不備」と決めつけない — まず実装のバグを疑う。AIが書いたテストだから怪しい、という先入観で本物のバグを潰す事故が起きやすい。
  5. データ汚染を理由に SKIP しない — テスト実行後にクリーンアップする。SKIP の理由は「Playwright MCP で技術的に不可能」または「E2E テスト対象外」のみ許可。

3 番が一番効きます。観点リストを「消化する」ことが目的化すると、テストは増えるのにバグ検出力は下がる、という最悪の状態になります。

旧来のQA vs AI時代のQA

最後に対比表で整理します。

観点 旧来のQA AI時代のQA
テスト仕様書 人手で記述・更新が遅延 Issue + コードから生成、鮮度を機械的に判定
テストケース 手で書き起こす AC → シナリオを自動生成、差分更新で結果列を保持
テスト実行 手動 or 個別自動化スクリプト Playwright MCP で証跡込み自動実行
失敗報告 手で Issue 起票 FAIL 検出 → 画面単位でまとめて自動起票（録画・スクショ URL 付き）
探索的テスト 個人技に依存 23観点 × Finding/Hypothesis/Probe で構造化、ナレッジが蓄積する
仕様 vs 実装 レビューで人がチェック validate gap で充足率を定量化
QAエンジニアの役割 書く・回す・記録する 設計する・解釈する・判断する（AIに何をやらせるかを決める人）

これから取り組むべきこと

導入してきて見えた、次の打ち手を3つだけ挙げます。

  1. AC の質を上げる投資 — 何度でも書きますが、AC がテスト品質の上限を決めます。Issue テンプレ・PR テンプレ・受入観点のチェックリスト整備は、自動化基盤の整備より先に効きます。
  2. 失敗解釈のレビュー文化 — AIが「FAIL」と判定しても、それが仕様バグ／実装バグ／テストバグのどれかは人間が決める。判断ログを残す習慣をつけると、後から「あの時の判定は間違いだった」を検出できる。
  3. 手動テスト手順書（manual-tests.md）の運用整備 — 「AIに無理させない」運用は、人が拾う側のフローが整って初めて機能します。AIの能力を伸ばす前に、AIに渡さないテストの行き先を作るほうが優先度は高い。

おわりに

AI時代のQAは、テストを書く仕事を奪うのではなく、「QAエンジニアが本来やりたかったこと（設計・解釈・判断）」に時間を返す動きです。テストケースを手で起こす作業から解放されたぶん、何をテストすべきか・なぜ失敗したのかという、より上流の問いに向き合う時間が増える。

逆に言うと、AIに何をやらせ、何をやらせないかを設計できる人こそが、これからのQAエンジニアの中核になります。ツール選定よりも先に、思想と運用設計を揃えることをおすすめします。

Discussion