Claude Codeのカスタムスキルに「7人の意地悪なQA」を仕込むことで、AIが正常系に偏るという課題を解決した実践レポート。テスト観点漏れを構造的に排除し、一人QAでも品質を安定させる方法を解説する。
元記事：zenn.dev/nexta_/articles/be13a2395a5d2a
背景：AIに任せると正常系に偏る
AIにテストケースを書かせること自体は難しくなくなった。しかし「毎回同じ観点で、同じ品質で書かせる」ことが問題として残った。
具体的には次の2つの課題があった。
| 課題 | 症状 |
|---|---|
| 観点の抜け | 正常系に偏り、DBの裏側確認・回帰・仕様突合が毎回こちらから頼まないと漏れる |
| 作り方の軸がぶれる | 新機能と移行で「正解の基準」が違うのに同じやり方で処理していた |
解決策1：7人のQAペルソナを仕込む
「動いているはず」を信用しない7人のQAペルソナをスキルに組み込んだ。開発チームを擬似的に再現する「AI工場」の発想をQAの観点出しに転用したものだ。
| ペルソナ | 疑う点（代表観点） |
|---|---|
| P1 新人ユーザー | 説明を読まず直感で操作。誤クリック・空送信・連打で壊れないか |
| P2 ベテラン現場担当 | キーボードで高速・大量入力。Tab遷移／ショートカット／IME変換中のEnter |
| P3 悪意ある操作者 | 境界値・不正値・権限外・二重送信。バリデーションや排他制御が効くか |
| P4 データ整合性監査役 | 画面を信用せず裏のDBテーブルを直接確認。CRUDの整合性 |
| P5 移行担当者 | 旧システムの既存データを投入。欠損・異形式・文字コード・件数の一致 |
| P6 回帰デグレ番人 | 「今まで動いていた何か」が壊れていないか。周辺機能やF5後の挙動 |
| P7 仕様懐疑者 | 「実装＝正しい仕様」を信用しない。一次情報（課題・仕様書）と挙動を突合 |
スキルへの組み込み方は次のようなプロンプトを埋め込む形だ。
あなたは「動いているはず」を信用しない7人のQAです。
各ペルソナの視点で、この機能を最低1つずつ壊しにいってください。
- P1 新人：説明を読まず直感で操作。誤クリック・空送信・連打
- P2 ベテラン：キーボードで高速・大量入力。Tab遷移・IME変換中のEnter
- P3 悪意：境界値・不正値・権限外・二重送信
- P4 データ整合：画面でなく裏のDBテーブルを直接確認
- P5 移行：旧データを投入。欠損・異形式・文字コード・件数
- P6 回帰：今まで動いていた周辺機能が壊れていないか
- P7 仕様懐疑：実装を信用せず、一次情報（仕様）と挙動を突合ロールは具体的に書くほど効く。「QAの人として」より「不具合を見逃さない、疑り深いシニアQAとして」、さらに7人に分けるほど、出てくる指摘が具体的になる。
解決策2：新機能用と移行用でスキルを2本に分ける
同じ「テストケースを作る」でも仕様の出どころが違えば、正解の基準も変わる。1本のスキルで両方を捌こうとした結果、出力がちぐはぐになっていた。
| 観点 | 新機能用 | 移行用 |
|---|---|---|
| 仕様の出どころ | 課題（PBI）＋ソースコード | 既存仕様の正本（ヘルプセンター）＋デザインパターン |
| 正解の基準 | 要件を満たしていること | 仕様どおりに動いていること |
| 主役ペルソナ | P1〜P7（特にP3・P4） | P5移行担当＋P7仕様懐疑者 |
| 出力 | テストケースCSV | テストケースCSV＋要件カバレッジ表＋設定パターン表 |
新機能トラックの使い方
# 1. 設計に入っていいか判定
/pbi-review PBI-XXX
# 2. テスト計画書を作成して課題管理ツールに起票
/test-plan-creation PBI-XXX
# 3. テストケースCSVを生成し、台帳に追記
/test-case-creation PBI-XXX
# 4. 品質レビュー（指摘のみ。修正はしない）
/test-case-review （作成したCSVのパス）
# 5. サマリ表紙付きスプレッドシートに変換
/gsheet-export移行トラックの使い方
# 1. ヘルプ記事（Kブック）を起点にテストケースCSVを生成
/migration-test-creation （ヘルプ記事のURL）
# 2. 品質レビュー（指摘のみ。修正はしない）
/test-case-review （作成したCSVのパス）
# 3. サマリ表紙付きスプレッドシートに変換（要件カバレッジ表も同梱）
/gsheet-export入力はBacklog MCPで課題番号を渡すだけ。コピペミスがなくなり、テーブル名・カラム名の確認は自作MCPでClaudeが直接スキーマを読みに行くため打ち間違いも消えた。
CSVの設計：25列とISO 25010
スキルが出力するのは25列のCSVだ。区切り文字はセミコロン、セル内の改行は <br>、文字コードはUTF-8で固定している。
要件ID;要件説明;Test Basis;テストケースID;テストタイトル;優先度;テストタイプ;
品質特性（ISO25010）;リスク;テスト観点;Test Data;前提条件;実施画面;操作手順;
期待結果;コードモジュール;自動化(YES/NO);自動化優先度;回帰テスト対象(YES/NO);
最終更新日;結果;内容;エビデンス;テスター;テスト実施日品質特性に ISO/IEC 25010 を使うのは「なんとなく網羅した気になる」のを避けるためだ。機能適切性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性という語彙（2011年版の8特性）を必ず埋めさせることで観点の偏りが見えるようになる。なお、2023年版では「安全性（Safety）」が加わり9特性になっているため、スキルはその方向に更新予定とのこと。
根拠のないケースを出させない
AIにテストケースを作らせる際に最も気をつけたのが、「それらしいけれど根拠のない」ケースを排除することだ。
- Test Basisの列に一次情報を引く — 新機能なら課題番号、移行なら「ヘルプ記事のどの見出しか」を節まで書かせる
- コードを確認できていない箇所は推測で埋めない — コードモジュールの欄に「※要静的解析（未実施）」と正直に書かせる
- 要件はテスト可否で仕分ける — 「テスト可／テスト可（保留：実装が未検出）／テスト不可（仕様が不足）」に分類して要件カバレッジ表に残す
「分からないことは分からないと書かせる」。これがいちばん効いた。
masterとartifactsの二層管理
成果物は2層で管理する。
qa-repo/
├── master/{機能}.csv # 生きた正本。使わなくなったケースはDEPRECATEDに
└── artifacts/YYYY-MM/ # 課題・移行ごとのスナップショットスプレッドシートはこの2層から派生させるものであって、正本ではないという整理だ。
やってみてわかったこと
- 「やらないこと」を明示すると安定する — 「テストレビューは修正しない」「コードを確認できていない箇所は埋めない」という制約がAIの越権やでっち上げを抑える
- フォーマットは厳格に決めておく — 列の構成・区切り文字・改行のルールをスキルに明記してから、スプレッドシートへの取り込みが無修正で通るようになった
- AIはテスターではなく「テスト設計者」として使う — 観点の網羅とCSVの構造化まではAI、実行と合否の判断は人間という分担が一人QAにはちょうどよい
プロンプトを毎回書き直し続けるより、7人のペルソナと2トラックのスキルという仕組みに固定してしまうほうが、観点の品質が安定する。テスト設計の発想がスキル設計にそのまま使えるのが、この取り組みの面白いところだ。