CASE STUDY

Claude Code に「7人の意地悪なQA」を仕込んでテストケースの観点漏れを潰した

AIにテストケースを出させるだけでは、正常系に寄る癖や移行テストの基準ぶれが残る。元記事は、それをClaude Codeのカスタムスキルとして固定した実務QAの記録である。

Problem

出発点は「AIにテストケースを書かせる」ことではなく、「毎回同じ観点で、同じ品質まで持っていく」ことだった。課題文を渡せばそれらしいケースは出るが、レビューで初めて抜けに気づく状態は残っていた。

残っていた課題	現場で起きる症状	固定した対策
観点の抜け	正常系に偏り、DB整合・回帰・仕様突合を毎回頼まないと落とす。	7人のQAペルソナをスキルに埋め込み、各視点から最低1つ疑わせる。
作り方のぶれ	新機能と移行で正解の基準が違うのに、同じプロンプトで処理していた。	新機能用と移行用の2本のスキルに分け、入口と検証基準を変える。
台帳の陳腐化	仕様変更後に、どのケースが今も有効か分からなくなる。	masterを生きた正本、artifactsを課題ごとの履歴として分ける。
回帰の属人化	「ここを触ったらあれも見る」が担当者の記憶に残るだけになる。	回帰対象フラグと自動化優先度をCSVに持たせ、次の設計に引き継ぐ。

Seven Personas

7人のペルソナは、AIに「QAとして考えて」と頼む代わりに、何を疑うかを具体化するためのチェックリストだ。各ペルソナは自分の担当する壊し方を持ち、テスト設計とレビューの両方で使われる。

P1 新人ユーザー

説明を読まずに直感で操作する。誤クリック、空送信、連打で壊れないかを見る。

P2 ベテラン現場担当

キーボードで高速に大量入力する。Tab遷移、ショートカット、IME変換中のEnterを疑う。

P3 悪意ある操作者

境界値、不正値、権限外操作、二重送信を試し、バリデーションと排他制御を確認する。

P4 データ整合性監査役

画面表示を信用せず、CRUD後にDBテーブルへ正しく反映されたかを確認する。

P5 移行担当者

旧システムの既存データを投入する。欠損、異形式、文字コード、件数差分を疑う。

P6 回帰デグレ番人

周辺機能、既存動作、F5後の状態など、今まで動いていたものが壊れていないかを見る。

P7 仕様懐疑者

実装を正しい仕様とみなさず、課題や仕様書などの一次情報と実際の挙動を突き合わせる。

運用ルール

各ペルソナが最低1つは確認観点を残す。正常系だけで終わらせないための強制力にする。

Prompt Shape

あなたは「動いているはず」を信用しない7人のQAです。
各ペルソナの視点で、この機能を最低1つずつ壊しにいってください。
P1 新人 / P2 ベテラン / P3 悪意 / P4 データ整合 / P5 移行 / P6 回帰 / P7 仕様懐疑

Two Tracks

元記事のいちばん実務的な判断は、新機能と移行を同じスキルで処理しないことだ。仕様の出どころが違えば、テストの根拠も、正解の基準も、出すべき成果物も変わる。

観点	新機能用	移行用
仕様の出どころ	課題、受入条件、該当箇所のソースコード。	既存仕様の正本、ヘルプ記事、共通デザインパターン。
正解の基準	要件を満たしていること。	既存仕様どおりに動いていること。
強く効くペルソナ	P3 悪意、P4 データ整合を含むP1からP7。	P5 移行担当者、P7 仕様懐疑者。
主な出力	テストケースCSV。	テストケースCSV、要件カバレッジ表、設定パターン表。

New Feature

課題の受入条件を読み、ソースコードで期待結果のテーブル名やカラム名まで確認する。

Migration

ヘルプ記事と既存仕様を正本にし、画面ごとの仕様と共通UI挙動を1件ずつ確認する。

移行を新機能のつもりで設計すると、「要件は満たすが既存仕様とはズレる」ケースを取りこぼす。入口が違うものは、スキルも成果物も分けたほうが安定する。

Artifacts

スキルの出力は25列のCSVで、区切り文字はセミコロン、セル内改行は<br>、文字コードはUTF-8に固定されている。厳格な形式は、スプレッドシートへの取り込みと後続レビューを安定させるための制約である。品質特性はISO/IEC 25010の2011年版にある8特性を使い、2023年版では「安全性」が加わって9特性になっている点も明記されている。

成果物	役割	設計上のポイント
テストケースCSV	要件、Test Basis、操作手順、期待結果、品質特性、回帰対象、自動化優先度を1行にまとめる。	ISO/IEC 25010の品質特性を入れ、観点の偏りを見えるようにする。
master/{機能}.csv	今も有効なテストケースの正本。次の課題で採番を継続する。	使わなくなったケースも消さず、DEPRECATEDとして履歴を残す。
artifacts/YYYY-MM/...	課題や移行ごとのスナップショット。過去に何をテストしたかを遡る。	スプレッドシートやエクスポートは派生物で、正本はCSV側に置く。
サマリ表紙付きシート	件数、実施率、不具合率、カバレッジ率、設定カバー状況をレビュー用に見せる。	外部へ出す前に、顧客名、メール、電話番号などの機密情報混入をチェックする。

Googleスプレッドシートのサマリ表紙例 — Source image from the Zenn clipping: サマリ表紙で件数、優先度内訳、実施率、不具合率、カバレッジ率を俯瞰する。

Guardrails

AIにそれらしいケースを作らせるほど、根拠のない期待結果や推測で埋めたコード情報が混ざりやすい。元記事では「分からないことを分からないまま残す」ためのルールを明示している。

Test Basis

新機能なら課題番号、移行ならヘルプ記事の見出しまで、一次情報を列に残す。

No Guessing

コードを確認できていない箇所は推測で埋めず、「要静的解析」と明記する。

Coverage Split

移行では要件を洗い出し、テスト可、保留、テスト不可に分類して別CSVに残す。

Review Boundary

レビュー用スキルは指摘だけを出し、勝手に修正しない。越権を避ける。

AIテスト設計で重要なのは、ケース数を増やすことだけではない。根拠のないケースを混ぜないために、空欄、保留、未確認を成果物上で見える形にすることだ。

Takeaways

この仕組みは、QA担当者の判断をAIに丸投げするものではない。AIには観点の展開と構造化を任せ、実行、合否判断、仕様の最終解釈は人間が持つ、という分担に寄せている。

Implementation Checklist

1. 自分のプロダクトで実際に踏んだ不具合からQAペルソナを作る。
2. 各ペルソナが最低1つ観点を残すルールをスキルに入れる。
3. 新機能と移行を、仕様の出どころで別トラックに分ける。
4. CSV列、区切り文字、改行、文字コードを固定する。
5. Test Basisと未確認表示で、根拠のないケースを混ぜない。
6. masterを正本、artifactsを履歴として分ける。
7. AIはテスト設計者、人間は実行者と判定者として使う。

Original source: Claude Code に「7人の意地悪なQA」を仕込んでテストケースの観点漏れを潰した by Ayaka, published on 2026-06-22 at Nexta Tech Blog.