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

はじめに

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 軸があります。

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

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

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

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

要件 (Issue / Asana)
│
▼
... 

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

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

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

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

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

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

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

Finding（事実）── 2 件以上の同じ匂い ──► Hypothesis（仮設）
▲ │
│ ▼
... 

• 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 つだけ抜粋します。

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

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

旧来の QA vs AI 時代の QA

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

観点	旧来の QA	AI 時代の QA
テスト仕様書	人手で記述・更新が遅延	Issue + コードから生成、鮮度を機械的に判定
...	validate gap で充足率を定量化
QA エンジニアの役割	書く・回す・記録する
設計する・解釈する・判断する（AI に何をやらせるかを決める人）

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

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

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

）の運用整備

おわりに

AI 시대의 QA 는 테스트를 작성하는 일을 빼앗는 것이 아니라, "QA 엔지니어가 본래 하고 싶었던 것 (설계 · 해석 · 판단)" 에 시간을 돌려주는 움직임입니다. 테스트 케이스를 손으로 작성하는 작업에서 해방된 만큼, 무엇을 테스트해야 하는지·왜 실패했는지와 같은 더 상류의 질문에 대한 시간이 늘어납니다.

반대로 말하면, AI 에게 무엇을 지시하고 무엇을 하지 못하게 할지를 설계할 수 있는 사람이 바로 앞으로의 QA 엔지니어의 핵심이 될 것입니다. 도구 선정보다 먼저 사상과 운영 설계를 갖추는 것을 추천합니다.