品質保証・QAエージェント：リリース前に、壊れ方を想像する

QAを分解する

QAは、最後に触ってバグを見つける仕事ではない。要件、仕様、ユーザー行動、例外、過去不具合から「どう壊れうるか」を先に考える職能である。

分解した能力	AIの役割	成果物
受け入れ条件	仕様の完了条件を明確にする	ACレビュー
テスト設計	正常、異常、境界、権限、状態を出す	テストケース
回帰確認	既存機能への影響を整理する	回帰観点表
バグ分類	重要度、再現条件、影響範囲を整理する	バグレポート
リリース判定	残リスクと確認済み範囲をまとめる	リリース判定メモ
品質改善	不具合傾向から予防策を出す	品質改善リスト

Role

基本ロールは「テスト設計・品質確認補助エージェント」とする。

仕様の曖昧さを見つける
テストケースと回帰観点を作る
バグの再現条件を整理する
リリース前の残リスクをまとめる
不具合傾向から予防策を作る

最終的なリリース可否、顧客影響判断、障害公表、品質基準変更は人間に戻す。

Tools

Tool	用途
issue管理	仕様、バグ、修正状況の確認
テスト管理	テストケース、実行結果、回帰範囲の管理
CI/CD	自動テスト、ビルド、デプロイ状況の確認
Git	変更差分、影響範囲の確認
監視/ログ	エラー、障害、実利用での問題確認
ドキュメント検索	仕様書、過去不具合、リリースノートの参照

Thinking

思考法	チェックする問い
仕様曖昧性	完了条件は明確か
境界値	上限、下限、空、重複、長文はあるか
状態遷移	下書き、公開、削除、失敗、復旧はあるか
権限	誰が見られ、誰が操作できるか
回帰	既存機能に影響しないか
顧客影響	壊れた時に誰が困るか

Output

項目	内容
テスト対象	機能、変更、影響範囲
観点	正常、異常、境界、権限、回帰
ケース	手順、期待結果、前提
バグ	再現条件、実結果、期待結果、重要度
残リスク	未確認、既知不具合、許容条件
判定材料	出せる理由、止める理由

KPI

受け入れ条件未定義数
テストケース作成時間
リリース後不具合数
回帰漏れ数
バグ再現情報の不足率
自動化候補テスト数

エスカレーション

顧客データ、決済、権限、セキュリティに関わる
リリースを止めるべき可能性がある
重大障害、データ破損、情報漏えいの疑い
仕様と実装の判断が割れている
顧客や広報への説明が必要

発生しうる業務

頻度	業務	AIに任せる粒度
日次	issue確認、PR影響範囲、バグ整理	観点、再現メモ
週次	回帰テスト、品質傾向、未解決バグ確認	QAレポート
月次	不具合傾向、自動化候補、品質基準見直し	改善リスト
随時	新機能テスト、緊急修正、リリース判定	テストケース、判定メモ

学習方法

学習材料	学ぶこと
過去不具合	壊れやすい機能、原因
仕様書/PRD	期待動作、受け入れ条件
テスト結果	漏れやすい観点
障害報告	顧客影響、初動、再発防止
コード変更履歴	影響範囲、回帰ポイント

能力の磨き方

リリース後不具合を、テスト観点漏れとして分類する
人間が追加したテストケースをテンプレートへ戻す
バグレポートの不足情報をチェックリスト化する
自動化すべき反復テストを抽出する
月1回、品質基準とリリース判定基準を見直す

作り方

受け入れ条件テンプレートを作る
テスト観点チェックリストを作る
issue、PR、CI、テスト管理を参照させる
バグレポートの必須項目を固定する
リリース判定は人間承認にする
不具合を再発防止ナレッジへ戻す

作れない場合は、「テストケースbot」「回帰観点bot」「バグ整理bot」「リリース判定メモbot」に分ける。

最小実装

最初から自律実行させるのではなく、読み取り、下書き、承認付き更新の順に広げる。品質保証・QAエージェントの最小実装は、テスト設計、回帰観点、バグ分類、リリース判定材料を整理するための「入力を読む場所」「出力を残す場所」「人間が承認する場所」を固定することである。

層	最小構成
入力	issue管理、テスト管理、CI/CD、Git、ログ、仕様書から読み取り専用で参照する
処理	事実、推測、未確認、次アクションを分けて整理する
承認	外部送信、重要判断、台帳更新、金銭・契約・人事に関わる操作は人間承認にする
記録	出力、採否、修正理由、次回改善点を同じ場所に残す

入力データ

仕様、受け入れ条件、変更差分
既存テスト、CI結果、過去不具合
操作手順、期待結果、実結果
リリース範囲、顧客影響、既知不具合

入力データには、取得日、参照元、更新者を残す。古い情報や未確認情報を混ぜると、AIはもっともらしいが危ない判断を出す。

出力フォーマット

フィールド	内容
`test_plan`	テスト計画
`cases`	正常、異常、境界、権限
`regression`	回帰観点
`bug_report`	再現条件と重要度
`release_risk`	残リスク
`unknowns`	未確認事項、追加で人間が見る点
`human_review`	承認者、判断期限、エスカレーション条件

この形式で残すと、後から「AIが何を見て、何を出し、人間がどこを直したか」を追える。

サンプルプロンプト

あなたは品質保証・QAエージェントです。
目的は「テスト設計、回帰観点、バグ分類、リリース判定材料を整理する」ことです。

入力:
- 対象: [対象名]
- 参照データ: [参照元]
- 期限: [期限]
- 制約: [承認条件、禁止事項、守るべきルール]

指示:
1. 事実、推測、未確認事項を分けてください。
2. 出力フォーマットに沿って整理してください。
3. 判断できない点を無理に結論づけず、human_reviewに戻してください。
4. 外部送信、重要更新、金銭・契約・人事に関わる操作は実行せず、承認依頼にしてください。

出力:
- 要約
- 構造化データ
- 次アクション
- human_review

ワークフロー

受け入れ条件の曖昧さを先に洗う
変更差分から回帰観点を出す
テストケースとバグレポートを構造化する
リリース可否は人間判断に戻す

この流れを固定すると、AIは単発の相談相手ではなく、業務の一部として改善できる。

失敗パターン

最後に触るだけのテストにする
再現条件なしでバグを起票する
顧客影響を見ずに重要度を決める

失敗パターンは、禁止事項としてプロンプトに入れるだけでは足りない。出力レビュー時に「今回どの失敗に近かったか」を記録し、次の入力データや評価基準へ戻す。

評価ルーブリック

受け入れ条件がテスト可能
回帰観点が変更差分に基づく
残リスクが明示されている
事実、推測、未確認が分離されている
人間に戻すべき判断がhuman_reviewに出ている

5段階評価にする場合は、3を「人間が軽く直せば使える」、4を「そのまま業務で使える」、5を「次回のテンプレートに採用できる」と定義する。