AI駆動開発時代の品質組織設計 -セルフQA基盤の構築-

2026/07/22開催の「ソフトウェア品質保証プロフェッショナルの会 第17期 成果発表会」での登壇資料です。

AI駆動開発に適応するQA組織の役割や、セルフQA基盤の構築、プロセス（Inception / Construction / Operations）における品質保証技術のマッピングについて紹介しています。

■ イベント：ソフトウェア品質保証プロフェッショナルの会 第17期 成果発表会

Transcript

1. AI駆動開発時代の品質組織設計 -セルフQA基盤の構築- ソフトウェア品質保証プロフェッショナルの会 第17期 成果発表会 2026/07/22
2. 自己紹介：小林依光（こばやし よりみつ） エンジニアリング本部 プラットフォームエンジニアリング部 Quality Engineering グループ マネージャー • • 経験分野： ◦ デジタル家電（パソコン、携帯電話、Androidタブレット） ◦ モバイルオンラインゲーム（スマホゲーム） ◦ HR マッチングサービス 社外活動： ◦ JSTQB技術委員 ◦ 日科技連コミュニティ ソフトウェア品質保証プロフェッショナルの会 アドバイザー ◦ Building Quality: ビジネス成長を加速する1人目QAからの品質戦略 共著者 ◦ ゼロからはじめるゲームテスト 共著者 2
3. Quality Engineering グループとは Center of PracticeとしてQA領域の戦略と技術浸透を担う組織 • Capability: プロダクト組織が自律的に品質保証活動を行う • Agility: 変化に適応し高速に価値提供する • Reliability: 高いサービス信頼性を実現する テストの実施やゲートキーパーとしての 自律的なスクラムチームのQAのCapabilityを引き上げ、 役割ではない 開発速度を犠牲にすることなく、品質をスケールさせる 3
4. AI駆動開発に適応したアプローチに変更 QAのCapabilityを「AIエージェント」に実装、提供 4
5. QAプロセスも AI駆動開発に適合した形へ再設計 各プロセスにおいて、 AIエージェントを積極的に活用する 5
6. AI駆動開発の 3つPhaseと8つのProcess 8つのProcessで、QAは各段階で AIが迷わないルールを作成 参考資料（3つのフェーズの概念） awslabs, GitHub https://github.com/awslabs/aidlc-workflows 6
7. Phase1：Inception ドメイン理解 業務認識のズレやハルシネーションの主因を抑制する • • リポジトリ内に構造化されたドメインモデルの定義を置き、AIが必ず最初に参照する 「知識ベース」を作成する。 AIの知識参照プロセスを監視し、不確実性を可視化する。 7
8. Phase1：Inception 要求獲得・分析 初期要求の曖昧さや矛盾を早期に検知し、論点を整理する • • AIとの対話による要求整理と、INVEST基準を用いた内容のチェック・論点抽出をする 過去のバグ・インシデントデータに基づき、リスクシナリオを早期にブレストする 8
9. Phase1：Inception 要求仕様化 曖昧な要求を、 AIエージェントが判断できる仕様へ構造化する Structuring / Spec Gate • • Gherkin構文/EARS等を用い、Spec・AC・DoDを機械可読な形で確定できるようにする。 LLM-as-a-Judgeを導入するための評価軸（ルーブリック）を策定する。 9
10. Phase2：Construction コンテキスト設計 プロンプト指示のバラつきや解釈のブレをなくす • git diff（コードの差分）に連動し、関連するディレクトリのQASKILL.mdを AIへ自動インジェクション（動的ロード）する環境を構築する。 10
11. Phase2：Construction AI実装 保守性を損なうコード（ AI slop）を防止する • • MCP経由のRAGによる、社内ドメイン知識のリアルタイム参照環境を提供する。 自動検証可能な仕様書を基準とした、AI実装の逸脱を防ぐ制御プロセスを構築する。 11
12. Phase2：Construction 自動検証 自己修復ループの構築 エラー発生時にログをAIへ戻して自動修正させる「自律修正ループ」の構築。 Custom Lintやアーキテクチャ（設計構造）テストを強制し、基準未達の成果物が先へ進むのを 自動化ゲートで高精度に抑止する仕組みを提供する。 12
13. Phase3：Operations 承認・マージ 低リスク変更は自動化し、高リスク変更にのみ HITL を集中させる • • 変更差分（git diff）のメタデータに基づく、RPN（リスク優先度）の自動算定アルゴリズムの実装 低リスクは自動マージ、高リスクはシニアエンジニアのレビューを強制する分岐ゲートのCI/CD統制 13
14. Phase3：Operations 運用・学習 開発の高速化に伴う仕様書の陳腐化の防止、既知不具合の再発防止 • • 本番環境の挙動に基づく、AIの定義情報（AGENTS.md）や制約条件（SKILL.md）の自動更新・ 最適化を行う。 インシデントログからの仕様・テストコードの自動改訂、およびポストモーテム生成の自動化。 14
15. 参考：3つのPhaseと主な技術の目的 /手段 技術領域 Inception（計画・アーキ） 知識・基準の確立 Construction（設計・実装） 強制・検証・フローの実装 Operations（デプロイ・監視） 維持運用と自動進化 ドメイン理解 業務認識のズレ・境界曖昧をなくす → 用語・境界・モデルのSSOT 化 コード変更の影響誤認を防ぐ → ドメイン知識の参照基盤（例: MCP経由のRAG） ドキュメントの陳腐化を防ぐ → 本番乖離知見に基づくドキュメント自動書き換え 仕様駆動 + 要求工学 上流の手戻り・差し戻しを最小化する → Gherkin / EARS 等による Spec・AC・DoD の確定 機械可読Specを Ground Truth にして実装を拘束する → AI実装の一次防衛（AI slop 抑制） 既知バグの再発を防ぐ → インシデントログからのSpec 自動改訂 コンテキストエンジニアリング 無駄情報によるコンテキスト浪費を抑える → 参照制約・優先順位ルールの設計（ Scaffolding） プロンプト指示のバラつきをなくす → git diff 連動の SKILL.md 動的ロード環境 運用品質からの逸脱を即時に抑止する → 逸脱パターンの Skills 制約への自動還流 ハーネスエンジニアリング AIが環境・制約不足で詰まる時間をゼロにする → ルール／フック／再現環境の先行整備 リリース前の人手確認負荷を大幅に減らす → Custom Lint / Structural Tests / CIテスト基盤の必須化 見えない技術負債の蓄積を自動抑止する → 自動修正ワークフローの常時稼働（何を直すか） オーケストレーション Dev/QA間の役割・引き継ぎ・自動パスを先に決める → 工程指揮ルール／ゲート配置の設計 大量PRがレビュー待ちで滞留するのを防ぐ → 多Agent間の自律修正ループと段取り制御 改善ループの人手依存をなくす → 継続改善の自律ライフサイクル（誰がいつ回すか） エバリュエーション エンジニアリング（評価工学） AI成果物の合格基準を決定的に担保する → LLM-as-a-Judge の評価軸（ルーブリック）方針策定 基準未達の生成物の流出をブロックする → Eval Suite による多層自動評価 本番の品質指標とテスト基準の乖離を解消する → 本番メトリクスと Eval Suite 評価軸の接続 オブザーバビリティ AIエージェント挙動の不確実性を可視化する → トレーサビリティ・監視項目の設計 エラー発生時の原因特定速度を最大化する → 構造化ログ・トレース埋め込みの仕込み 障害検知から再発防止までの速度を最大化する → 本番乖離／バグの自動検知とポストモーテム連携 15
16. AI駆動開発における QA組織の役割 AIを活用してプロダクトの品質を確保する仕組みを構築する 16
17. AI駆動開発の QA組織のロール例 QEとQAHEの明確な区別はなくメンバーの得意領域を表す ※ここでつかっている「Harness」には ①Test Harness（テスト実行基盤）と、②AI Harness（AIエージェントの制御・監視・評価基盤） の2つの意味が込められており、QA Harness Engineerは独自の役割定義語です。 17