Claude Codeに「7人の意地悪なQAペルソナ」を仕込んでテストケースの観点漏れを防ぐ

Claude Code は Anthropic が提供するエージェント型コーディングツールです。コードベースを読み込み、複数ファイルにまたがる変更を行い、テスト実行からコミットまでを自動化します。公式ドキュメントでは「説明できれば構築できる」と紹介されています。

📑目次

Claude Codeを使ったテストケース作成の背景と課題
7人の意地悪なQAペルソナの定義と各役割
新機能トラックと移行トラックのスキル分離
25列CSV仕様とISO/IEC 25010品質特性の活用
実際の運用パイプラインと成果事例
まとめと今後の展望
比較表: 新機能トラック vs 移行トラック

Claude Codeを使ったテストケース作成の背景と課題

AI によるテストケース生成は正常系に偏りやすいという問題があります。直感的な操作や境界値、DB整合性、悪意ある操作といった観点が抜け落ち、回帰テストや移行時の網羅性が不足しがちです。筆者の現場でも、AI出力だけに頼った結果、後工程で大量の欠陥が発覚した経験があります。

そこでClaude Codeに固定の「意地悪なQAペルソナ」をcustom skillとして組み込み、観点漏れを体系的に防ぐ方法を採用しました。Zennの記事（https://zenn.dev/nexta_/articles/be13a2395a5d2a）で紹介された実践例を基に、運用フローを整理します。

7人の意地悪なQAペルソナの定義と各役割

7人のペルソナを定義し、プロンプト冒頭に常に固定記述します。各ペルソナは最低1つの破壊的視点を提供します。

P1 新人ユーザー：直感操作ミスやempty submitを指摘
P2 ベテラン現場担当：キーボードエッジケースを想定
P3 悪意ある操作者：境界値や不正アクセスを試す
P4 データ整合性監査役：DBテーブル状態の矛盾を検出
P5 移行担当者：レガシーデータの整合性を確認
P6 回帰デグレ番人：既存機能の破壊を警戒
P7 仕様懐疑者：実装と仕様の乖離を指摘

この構成により、正常系偏重を多角的に是正できます。

新機能トラックと移行トラックのスキル分離

新機能トラックはPBIとソースコードを入力とし、P3/P4を重視します。一方、移行トラックは既存ヘルプセンターとデザインパターンを基に、P5/P7を主役に据えます。仕様の出どころが異なるため、1つのスキルに統合すると出力の軸がぶれるため、分離が有効です。

25列CSV仕様とISO/IEC 25010品質特性の活用

出力は25列のCSV形式とします。要件ID、要件説明、Test Basisからエビデンスまでを網羅し、ISO/IEC 25010の8特性（機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性）を必ず埋めることで、偏りを可視化します。Test Basisに一次情報を明記する点が重要です。

実際の運用パイプラインと成果事例

運用では /test-case-creation PBI-XXX や /migration-test-creation コマンドを使用します。受注移行プロジェクトでは200件を超えるテストケースをこの方法で作成し、観点抜けを大幅に低減できました。CSV出力後、手動レビューで最終調整を行います。

まとめと今後の展望

7人の意地悪なQAペルソナをClaude Codeに固定することで、テストケースの網羅性が向上します。今後はさらにペルソナを追加し、自動化範囲を拡大する予定です。詳細はZenn記事およびAnthropic公式（https://www.anthropic.com/product/claude-code）を参照してください。

よくある質問（FAQ）

Q: なぜ7人のペルソナが必要なのか？

AIが正常系に偏りがちで、DB整合性や回帰、悪意操作などの観点が抜けやすいため、意地悪な視点を持つ複数のペルソナを固定することで網羅性を担保する。

Q: 新機能と移行でなぜスキルを分けるのか？

仕様の出どころ（PBI+ソース vs 既存ヘルプ+デザインパターン）が異なり、正解基準や主役ペルソナが違うため、1スキルでは出力の軸がぶれる。

Q: CSVの列数はなぜ25列か？

要件IDからエビデンスまでを網羅し、Test Basisに一次情報を明記、ISO 25010の8特性を必ず埋めることで偏りを可視化するため。

Q: ペルソナはどのようにスキルに組み込むか？

プロンプト冒頭に「あなたは動いているはずを信用しない7人のQAです。各ペルソナの視点で最低1つずつ壊しにいってください」と固定記述。

Q: 移行トラックで200件超のテストケースを作成した実績はあるか？

はい、受注移行プロジェクトで200件を超えるテストケースをこの方法で作成し、観点抜けを大幅に低減した。

比較表: 新機能トラック vs 移行トラック

項目	新機能トラック	移行トラック
仕様出どころ	課題(PBI) + ソースコード	既存ヘルプセンター + デザインパターン
正解基準	要件を満たすこと	仕様どおりに動くこと
主役ペルソナ	P1〜P7 (特にP3悪意・P4データ整合)	P5移行担当 + P7仕様懐疑者
出力	テストケースCSV	テストケースCSV + 要件カバレッジ表 + 設定パターン表
入力例	/test-case-creation PBI-XXX	/migration-test-creation (ヘルプURL)

出典: Zenn記事 (https://zenn.dev/nexta_/articles/be13a2395a5d2a) および Anthropic公式ドキュメント

関連記事:

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →

📚 次に読む