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