AI駆動開発におけるQAエンジニアの役割事例 〜AI駆動開発の現場から〜

JaSST'26 Kansai（第26回 ソフトウェアテストシンポジウム 関西）の「S6 テクノロジーセッション」での登壇資料です。

AI（LLM）の進化と普及に伴い、QAエンジニアの実務や専門性は「構造化とシステム化」へとシフトしつつあります。本発表では、品質基準をプロンプトとして設計する役割（QE: Quality Engineering）と、それをシステムとして実装・自動化する役割（QAHE: QA Harness Engineering）という2つの新たな専門性を提案し、それぞれの現場での具体的な実践事例をご紹介しました。

【ご紹介した主な事例】
・QEの事例：FMEAやRPN（リスク優先度数）を用いた、リスクベース品質管理の仕組み化
・QAHEの事例：GitHub PRやコードレビュー結果から自律的にルールを蓄積・学習するエージェント自律型学習ループ

■ イベント概要
・イベント名：JaSST'26 Kansai
・セッション：S6 テクノロジーセッション
・登壇者：小林 依光（JSTQB 技術委員&広報担当 / QAマネージャー）
・イベントURL：https://jasst.jp/kansai/26-about/

Transcript

1. AI駆動開発における QAエンジニアの役割事例 AI駆動開発の現場から 1
2. 2 自己紹介：小林 依光 (こばやし よりみつ) • JSTQB 技術委員 & 広報担当 • プロダクト開発組織のQAマネージャー（スキマバイト） • 日科技連コミュニティ ソフトウェア品質保証プロフェッショナルの会 アドバイザー • 書籍「ゼロからはじめるゲームテスト」共著者 担当してきた ドメイン デジタル家電 パソコン / 携帯電話 Androidタブレット スマホゲーム ゲームのエンゲージメント 機能性 / UIUX 人材マッチング 開発生産性 機能適合性 / 信頼性
3. 3 環境変化：AI（LLM）の進化、普及 もともと、QAエンジニアの担当領域は、 上流工程の要求開発からプロセス改善、環境整備、 運用におけるインシデント対応まで業務の幅は広い またその中でテストの戦略、計画、設計、実行が メインであるケースもあると思われるが テストに関しては、AIが計画、設計、実行を担い そのプロセスの仮定や成果を人間がレビュー/承認す る状況へと変わりつつある 予防・プロセス改善（Shift-left） 要件Review、TPI Next テスタビリティの改善 テストハーネスの設計、テストデータ作成 品質トラブルからの改善 バグ分析、インシデント分析 Testing（品質の可視化） テスト戦略・計画・設計・実行 QAエンジニアの実務を構成する主な4つの領域 AI Agents / Copilots
4. 4 参考：6/18開催の 2026 AsiaSTA QA Conference in Seoul KEYNOTE 1 Testing and Verifying Black-Box AI: Interpreting LLM Internals for Trustworthy AI Systems — Prof. Jaesik Choi · Graduate School of AI, KAIST
5. 5 テストをAIが担う時代、 QAエンジニアの専門的なCapabilityは、 「どこ」で価値を生むことができるのか？
6. 6 専門性のシフト：構造化とシステム化 QAエンジニアは、暗黙知（Capability）の言語化とプロセス設計（構造化） 及び、プロセスを自走できる環境整備（システム化）に取り組む テスト工程の各業務 暗黙知の言語化 / ルール策定 リスクの見立てやプロンプトの整備 QA基盤設計 / プロンプト実装 自動化を含むQAインフラ整備
7. 7 2つの専門性：QEとQAHEの提案 QE（Quality Engineering） 品質観点において何が正しいかを定義する QAプロセスの構造化と導入 品質リスクの言語化 プロンプトモデルの設計 QAHE（QA Harness Engineering） 品質を滑らかに実装できる環境を提供する QEが構造化したプロセスをCI/CDに組み込む 外形監視・本番環境のロジック検証 自律型学習ループの構築・本番運営
8. QE（Quality Engineering）の事例
9. 9 QEの実例：リスクベース品質管理の仕組み化 品質リスクをAIが自律的に判断できる仕組みを作る 1.FMEA（故障モード影響分析）: 潜在的なリスクを洗い出し 構造化する。 2.RPN（リスク優先度数）: リスクを数値化・可視化し リストレベルを決定する。 3.Tier Assignment： リスクレベルに応じた オーバーサイトを実現する。 多様な要件 Tier 1 Tier 2 Tier 3
10. 10 リスク優先度（RPN）の算出ロジック例 以下の数式を用いて定量的なスコア（RPN：Risk Priority Number）を算出します。 各項目は1〜5の5段階の評価とします。 Impact：影響度 （ユーザーやビジネスへのダメージの大きさ） Probability：発生確率（本番環境などでその事象が起きる頻度） Detectability：検出難易度（※注意：スコアが高いほど検出が困難）
11. 11 Impact（影響度）の基準例 評価スコア 内容 5（Critical） 人命・安全に関わる事象、大規模なデータ漏洩、システム全体の完全停止、 深刻なコンプライアンス違反（法令違反） 4（High） 主要な機能の喪失、多数のユーザーに影響する機能欠陥・業務ブロック 重大なブランドイメージの毀損（レピュテーションリスク） 3（Medium） 一部の機能低下、回避策が存在する機能欠陥・業務遅延 限定的なユーザーへの影響 2（Low） 軽微なUI/UXの崩れ ユーザーの主目的達成に影響しない軽度な不具合 1（Negligible） ユーザーに気づかれない、 または業務への影響が実質的に存在しない事象 インシデントが発生した際のビジネスおよびユーザーに与えるダメージの大きさを判定します。
12. 12 Probability（発生確率）の基準例 評価スコア 内容 5（Very High） ほぼ確実に発生する 標準的なユーザー操作において頻発することが避けられない 4（High） 高い頻度で発生する 特定の条件下や、やや複雑な操作において高確率で再現する 3（Moderate） 時折発生する エッジケースではないが、日常的な操作の中で一定の確率で遭遇する 2（Low） 発生確率は低い 極めて特殊なデータ入力や、複雑な稀な条件が重なった場合のみに発生する 1（Remote） 奇跡的な確率 発生することは理論上ありえるが、実環境ではほぼ起こり得ない 該当する故障モードが、実際の運用環境でどの程度の頻度で発生するかを判定します。
13. 13 Detectability（検出難易度）の基準例 評価スコア 内容 5（Absolute Uncertainty） 発見不可能 テストや監視システムでは、発生しても検知する手段がない 4（Very Low） 発見が極めて困難 探索的テストで偶然見つける以外に、システマティックな検知網が無い 3（Moderate） 条件次第で発見可能 特定のシナリオテストに含まれているが、漏れるリスクがある 2（High） 高い確率で発見可能 自動化されたE2Eテストや、強固な結合テストのスコープ内に含まれる 1（Almost Certain） 確実に発見可能 ビルド時、静的解析・単体テスト段階で機械的に100%ブロックされる 既存のテスト、CI/CDパイプライン、本番監視において、 その事象をどれだけ確実に捕捉できるかを判定します。 発見が困難 になるほど スコア増大
14. 14 RPNスコアからリスクレベルへのマッピング 算出されたRPN（最大125）に基づき、3つのTierにマッピングします。 Tier 1： 25以上 - システムやビジネスに対する致命的な脅威 Tier 2： 15〜24 - 監視と標準的なテストが必要な一般的なリスク領域 Tier 3： 14以下 – 影響が局所的であり、自動テストで容易に担保できる低リスク領域 Tier 3 Tier 2 Tier 1
15. 15 リスクレベルに応じたQAルールの構造化 Tier 1 Tier 2 Tier 3 HITLを強制 標準プロセス AIパイプラインによる 完全自動テスト QA Skills DB (AI向けプロンプト集) AI Agent RPNを用いてマッピングしたTierにQAの強度を直接接続する QEの判断モデルを、単発の長いプロンプトではなく「再利用可能なSkill」として言語化 体系的なQA Skill として運用することで、組織全体のQA Capabilityを支援する
16. QAHE（QA Harness Engineering）の事例
17. 17 実装例：エージェント自律型学習ループ 手作業によるプロンプトの修正から脱却し、日々のコードレビュー結果から システムが自律的にルールを蓄積し、学習するループを構築します。 失敗の検知と 原因分析・分類 記憶の定着 自己アップデート HITL承認
18. 18 学習ループの詳細①：データ収集と自己評価の突合 外部からの指摘と自信（AIエージェント）のレビュー結果を自動で比較し、 「比較のハーネス」を形成します。 検出済み （Detected） 検出したが却下 （Rejected） GitHub PR コメント （人/Copilot等） /self-code-review の出力 見落とし （Missed） Review-retro スキル
19. 19 学習ループの詳細②：学びの構造化と安全な自己更新 見落としなどの失敗は構造化データとして記憶され、自動的にエージェント定義へ反映。 人間は「学習の承認者」として振る舞います。 chore(.claude): Review-retro… AGENT_LEARNINGS.md （見落とし・原因・改善 の構造化記憶） HITL (Human-in-the-Loop) 承認 エージェント 定義の更新 Code-reviewer.md SKILL.md ※単発の見落としは定義に載せない （累積閾値で判断）
20. 20 QAHEを支えるThree Pillarsの設計思想 1.制御/Control ゲート、制約、ポリシー 品質ルールを満たさない変更を ブロックし、正しいプロセスを 維持する仕組み 2.接続/Connection SSOT、MCP、コンテキスト 各ツールやエージェントが 同じコンテキストとルールを 参照できるようにする 3.回復/Recovery 自己修復、ロールバック、ログ テストやAIエージェントが失敗 した際、安全に再試行・復旧で きる基盤の提供
21. これらの変化に対応するために基礎力をUP
22. 22 従来型QAとの比較 比較項目 従来型QA QE （Quality Engineering） QAHE （QA Harness Engineering） 主な成果物 テスト計画書、テスト仕様書、 バグ報告 プロンプト、ルール CI/CDゲート、監視コード アプローチ リスクベース+手動 リスクベース+Skillカタログ 自動化+プロセス実装 関与モデル バリデーション（妥当性確認） QAプロセスの構造化 QA基盤アーキテクチャの構築 AIの活用 部分的に効率化するツール AIの能力をルール化・部品化 AIエージェントの統制・運用 QAエンジニアは、品質基準をプロンプトとして設計する役割（QE）と、 それをシステムとして実装する役割（QAHE）にシフトしつつあります。