■ 1. 背景と目的
- 開発速度とテスト能力のギャップ:
- AIにより開発ライフサイクルが速くなり、E2Eテストのスコープは広がり、リリースサイクルは短くなる傾向
- 本記事のE2Eテストは自動と手動を含めたLargeサイズのテストを指す
- 開発速度は加速し続けるが、テスト能力が追いついておらず、このギャップを埋めることが急務
- 開発スピードに追いつく速さでQA人材を確保することは現実的ではない
- 重要となる2つの対応:
- シフトレフトしてE2Eテストへの依存度を減らすこと
- E2Eテストの品質を落とさずにリードタイムを削減すること
- 本記事のテーマ:
- 後者のリードタイム削減のために進めているエージェントQAの取り組み
■ 2. e-dashのE2Eテストプロセス
- スプリント内のテストプロセス:
- スクラム開発のため、スプリント内でQAが一連のテストプロセスを実施
- テスト設計書の作成からテストケースの管理ツール（Qase）への登録までを行う
- その後、マニュアルとPlaywright E2Eによるテスト実施を経てテスト仕様書を更新する
- このプロセスにAIエージェントを導入し、エージェントQAを目指す
- テストプロセスはトイルではない:
- テストアプローチはスプリントごとに変わる
- QAエンジニアはリスクベースドテストの考え方で、ケアすべきリスクや優先する観点を都度多角的に考える
- インプロセスQAとして活動するQAエンジニアの暗黙知もテストアプローチを決める要素となる
- AIエージェントに持たせるべき2つのプロセス:
- テスト技法を活用するプロセス
- 暗黙知を形式知に変えるプロセス（SECIモデル）
- 現在の段階:
- 実装フェーズに入ったばかりの段階で、解決したい課題と設計思想を整理している
■ 3. これまでのテスト資産の活用
- 積み上げてきた改善活動が前提:
- AIエージェントの設計はこれまでの改善活動があってこそ成り立つ
- 主な改善活動:
- テストドキュメントのGitHub管理
- 各ストリームアラインドチームのテストプロセスの統一
- Gherkin記述でのテスト設計
- テスト設計書の標準化
- テスト仕様書のナレッジ蓄積
- Playwright E2Eテストの基盤整備
■ 4. AIエージェントの導入ポイント
- 対象とするアクティビティ:
- テスト設計書からテスト仕様書を作る作業
- テスト設計書からテストケースを作成しQaseに登録する作業
- テスト仕様書からリグレッションテストケースを作成しQaseに登録する作業
- リグレッションテストケースから自動化テストコードを実装する作業
- AIに担わせる理由:
- これらはスプリントのたびに繰り返し発生する作業
- 丁寧にやるほど品質は上がるが、その分テスト戦略やリスク分析に集中できなくなる
- QAの知識と判断が必要な作業だからこそAIに担わせ、人はより高次な思考に集中できる
- 品質と人員数の切り離し:
- エージェントQAにより、テストカバレッジをQAチームの規模ではなくAIの能力に応じて拡張できる
- 迅速に人材を確保できない現実において、QAリソースが限られたチームにとって大きな意味を持つ
■ 5. AIエージェントの設計
- 基本的な考え方:
- AIに単純な変換作業をさせるのではなく、QAエンジニアとして思考させる
- ブラックボックステスト技法（境界値分析・同値分割・デシジョンテーブルなど）をSkill（プロンプト）として定義する
- 経験ベースの技法（エラー推測）もSkillとして定義し、AIエージェントの思考品質を継続的に高める
- 設計原則1 単一責務:
- 1エージェントにつき1つの明確なアウトプットとする
- 責務を分けることで品質問題の所在を特定しやすくなる
- 設計原則2 ドキュメント駆動:
- エージェント間のやりとりは必ずMarkdownファイル経由とする
- ファイルがエージェント間の「契約（インターフェース）」となる
- 人がいつでもファイルを読める状態の維持がHuman-in-the-loopの前提となる
- 設計原則3 Human-in-the-loopの最小化:
- EvaluatorがOKを出したものだけを人がレビューする
- 人の承認（PRレビュー・マージ）が次フェーズへのトリガーとなる
- QAスキルを持つ人の存在が前提:
- Human-in-the-loopの原則が機能するのはレビュアーにQAエンジニアとしてのスキルがある場合に限られる
- AI成果物の観点漏れや判断のズレに気づき、Skillへの反映内容を判断するにはテスト設計の知見が必要
- 人がいれば機能するのではなく、QAスキルを持つ人がいることで機能する仕組み
■ 6. 4つのサブエージェント
- 振る舞い起点のテスト設計をそのまま担わせる構成:
- QAチームはGherkin形式でAC（受け入れ条件）を書き、そこからテスト設計に展開するスタイルをとる
- この流れをそのままAIエージェントに担わせる
- 共通のレビューとフィードバック:
- 各エージェントの出力は人がPRレビュー・マージや登録内容確認で確認する
- レビューで得た知見はSkillに反映する
- TestDesign Agent:
- 人が書いたテスト要求.md（AC・Gherkin記述）からテスト設計書.mdのドラフトを生成する
- 単なるフォーマット変換ではなく、境界値分析・同値分割・異常系パターンなどQA観点で肉付けする
- TestSpec Agent:
- 確定したテスト要求.mdとテスト設計書.mdから、リグレッションテスト仕様書.mdを作成または差分更新する
- QASE Import Agent:
- テスト設計書.mdとリグレッションテスト仕様書.mdからテストケースを作成し、Qaseに登録する
- AutoCode Agent:
- 確定したリグレッションテスト仕様書.mdから、Playwright E2Eテストコードのドラフトを実装する
■ 7. 共通の設計パターン
- 5つの構成要素:
- 4つのサブエージェントはすべてOrchestrator → Planner → Generator → Hooks → Evaluatorの同じパターンで実装する
- Orchestratorはループを制御する
- Plannerは何を作るかを定義する
- Generatorは実際に作る
- Hooksは絶対NGを機械的にブロックする
- Evaluatorは品質を総合判定する
- Hooksの役割:
- スクリプトによる確定的な判定を行う
- 禁止用語・必須フィールド・フォーマット違反など、プロダクト固有の条件をチェックする
- NG時はGeneratorに差し戻す
- Evaluatorの役割:
- AIによる判断ベースの判定を行う
- 境界値の妥当性・観点の網羅性・優先度の整合性を評価する
- NG時はGeneratorを最大3回再実行する
- HooksとEvaluatorを分ける理由:
- Hooksを前段に置くことで、Evaluatorを品質の総合判定に集中させる
- 絶対NGのチェックをAIに任せると判定コストが上がり、ブレも生まれる
- 確定的なルールは確定的なスクリプトで弾く
- プロダクト固有ルールの組み込み:
- 本番バグの教訓などをそのままHooksの検証ロジックに変換する
- 同じミスを二度繰り返さない仕組みとなる
■ 8. Skillは育てる資産
- Skillのフィードバックループ:
- このアーキテクチャで最も重要な考え方
- レビューのたびにSkillが成長し、AIの出力品質が上がっていく設計
- 2種類の資産:
- Skillはレビューのたびに更新する
- Hooksは絶対NGルールの発見時に更新する
■ 9. おわりに
- QAエンジニアの役割の変化:
- QAエンジニアの役割は実行者からオーケストレーターへ進化する
- 戦略立案・探索的テスト・エッジケースの発見など、文脈と創造性が必要な思考に人の力を集中させる
- それがエージェントQAの目指すところ
- AIを使うほどQAのスキルが問われるというのが現在の実感
- 今後の進め方:
- まずAIエージェントを動かし、現実の壁にぶつかりながら設計を磨いていく
- 続きは「やってみた」記事で書く予定