AI時代の品質はテストプロセスの作り直し #scrumniigata

「AIのテスト技法」だけではなく「品質判断のプロセス」をどこまで検討すべきか

AIを組み込んだプロダクトでは、仕様適合だけで品質合意を作りにくいことが多いです。出力が分布になり、運用で振る舞いが変わりうるためです。

それらに対応するテスト技法が徐々に生まれています。一方で、とあるスナップショットとしての品質判断や個別の技術に対応する技法だけでは、産業革命のような大きな技術革新には対応できません。それは自分たちの役割だけにはおさまらず、事業の在り方や生活のありかたから変わるためです。

企業では事業戦略とその実装であるプロセスの改善が必要です。QAにおいてはまさにテストプロセス、QAプロセス（主張・証拠・閾値・例外時の決定者）がそれらに該当します。
本セッションではテストプロセスの設計を、PdM・QA・SREのベン図として扱い、より継続的なプロセス設計手法及びプロセスの実装例を紹介します。

Transcript

1. AI時代の品質はテストプロセスの作り直し 第四次産業革命はテスト技法の変化におさまらない kyon_mm/naco_mm/ito jumpei < Confidential >
2. 1. AI時代のQAの難しさ 2. AIプロダクトに対するテスト技法：QA4AI 3. テストやQAにおけるAIの活用方法：AI4QA 4. 2030年にあるべきテストプロセスとはなにか 1.前提：NIST AI RMF、ISO42001、ISO23894 2.QA、PdM、SREからみたこれらの実装例と現場のギャップ 3.チームでの会議体と改善プロセスイメージ 5. 社内会議での導入イメージ 1.アジェンダ例 2. 一言目、二言目、そして質問 3. QA中心でのエクストリームスモールパターン 6. まとめ =>4で代替 アブストラクト AI時代の品質はテストプロセスの作り直し -第四次産業革命はテスト技法の変化におさまらない-
3. 自己紹介 3 AI時代の品質はテストプロセスの作り直し
4. 4 • 所属：合同会社デロイトトーマツ OI&DS 47機関 執行役員 • 大規模システム開発、新規事業開発、アジャイル組織変革のご 支援 • 新卒、大学生へのアジャイル教育：筑波大学 enPiT2 • 防災DX : SmartBosaiConnect Product Manager AI時代の品質はテストプロセスの作り直し 自己紹介 kyon_mm/きょん
5. キャディ株式会社 QAエンジニア カンファレンスの運営をしたり、参加したりするのが好きで、スク フェス新潟のスタッフもやってるよ！ 好きな飲み物はクラフトビール 、最近日本酒にも目覚めつ つあります 好きな絵文字は です！ よろみ！！！ 5 AI時代の品質はテストプロセスの作り直し 自己紹介 naco_mm / X(Twitter) : 750_naco
6. 伊藤 潤平(@jp_110) 6 • ウイングアーク１ｓｔ株式会社 ソフトウェアプロセス＆品質改善部 マネージャー • 社外活動 Scrum Fest Niigata 実行委員会 代表 JaSST Niigata アドバイザー SigSQAメンバー YouTube翻訳活動 • プロフィール AgileTD Zone Keynotes in Japanese AgileTD Zone Keynotes in Japanese テ キ ス ト , 新 聞 , 記 号が 含 ま れ て い る 画 像 自 動 的 に 生 成 さ れ た 説 明 https://niigatabase.shabellbase.com/engineer_01/ 6 AI時代の品質はテストプロセスの作り直し
7. AI時代のQAの難しさ 7 AI時代の品質はテストプロセスの作り直し
8. 8 仕様とテストケースに基づき、 「どれだけテストしたか」 「どれだけバグが残っていそうか」 暗黙の前提 • 仕様が比較的安定している。 • 入力データの分布がある程度予 測できる。 • 実装の振る舞いは決定的である （同じ入力→同じ出力）。 品質説明の典型パターン • テストケース数・網羅率 • 発見バグ数と重大度 • 性能・可用性などのSLA達成度 AI時代の品質はテストプロセスの作り直し 第３次産業革命までの品質説明 第４次産業革命からの品質説明 AIやデータ中心のシステムが増える中で、従来のテスト指標だけでは品質に関する意思決定に 必要な情報を経営に十分に伝えにくくなっている 「データ」 「運用状況」 「モデル更新」が品質を左右する。 特徴１ 非構造データ・多様な入力画像・音声・テキスト・セン サーデータなど、人間の解釈が必要なデータが多い。 特徴２ データ中心構造モデルの振る舞いが、訓練データ・評価 データ・運用データの性質に強く依存する。 特徴３ 不確実性と変化入力分布の変化・モデルの更新・外 部APIや生成AIの挙動変化が前提になる。 この変化に対して、説明の型が追いついていないのではないか？
9. AI時代の品質はテストプロセスの作り直し 9 構造の変化 品質を説明する際の材料が「仕様とテスト結果」から「仕様・データ分布・モデル・運用シナリ オ」に広がった結果として、経営が見ている軸との間に構造的なギャップが生じている 使用できる説明材料が変化 従来: 仕様・テストケース・コード 現在: 仕様＋データ分布＋モデル構造＋運用シナリオ 説明相手の視界とのギャップ 経営層は、売上・コスト・リスク・責任範囲を軸に意思決定する。QA側が 持っている情報は、テスト指標や技術的リスクに偏りがち。 結果として、「同じ品質」を見ているのに見えているものがずれる。 説明が難しいのは“スキル不足”ではなく“構造の変化”への対応不足。 意思決定のタイミングごとに増 える“わからない” 企画時点:AIの適用余地・データ入手性・初期投資規模が不明瞭。 開発・PoC時点:どの程度の精度／誤判定率であればビジネス的に許容か が曖昧。 本番・運用時点:データドリフト・モデル劣化・サイバーリスクの発生確率が読 みにくい。 構造データから非構造データへ 業務中心からデータ中心へ ビジネスの不確実性とシステム の確率論的挙動の増加 現在の事象 構造的変化
10. AI時代の品質はテストプロセスの作り直し 10 判断の再現性を支える要素 AI時代のQAでは、評価結果だけでなく評価判断を再現するための条件群の設計の重要性が 高くなっている 品質判断 評価基準 評価データ 評価者 評価手順 判断ログ 合意形成
11. AIプロダクトに対するテスト技法 QA4AI 11 AI時代の品質はテストプロセスの作り直し
12. AIを含むプロダクトそのものの品質を いかに保証するかの基準・手法 QA4AIとは何か AIを組み込んだプロダクトの例：ウイングアーク１ｓｔ製品のAIスタック 利 用 者 ア プ リ AI ス タッ ク デ ー タ 基 盤 一般ユーザー 製品連携 （SaaS） 製品連携 （オンプレ） テナント管理者 システム管理者 管理コンソール AI API AI OCR テナント管理 システム管理 Azure OpenAI OpenAI API Anthropic API Local LLM （将来的に） 他AIモデル Aurora PostgreSQL OpenSearch S3 CloudTrail / Watch WingArc1stが提供するマルチLLM対応 のAIプラットフォーム。単一モデルに 依存せず、OpenAIやローカルLLMを組 み合わせて、AIを安全に業務へ組み込 める。 ウイングアーク１ｓｔ製品のAIスタック
13. AI時代の品質はテストプロセスの作り直し 13 QA4AIガイドラインを自社プロダクトで適応してみる QA4AIガイドラインの5軸に合わせてみるとデータ整合性・モデル頑健性 は現時点では 対象外（独自モデル訓練・学習データ管理を行わないため）となる。また5軸では適応できな い箇所もあるため独自に軸を追加してみる。 データ整合性 Data Integrity データがきちんとしているか 0% 対象外 モデル頑健性 Model Robustness 精度が高く頑健性が確保されたモデルであるか 0% 対象外 システム品質 System Quality システム全体として品質が確保できているか 80% 決定論的 プロセス俊敏性 Process Agility 開発プロセスは機動的か 55% ←決定論的／確率論的→ 顧客期待 Customer Expectation 顧客の期待は高いか 70% 確率論的 その他（横断補完） 説明可能性・透明性 ／ Human Oversight ／ 機能的正 確性 ／ 公平性・バイアス 65% データ整合性 モデル頑健性 システム品質 プロセス俊敏性 顧客期待 その他（横断補 完）
14. AI時代の品質はテストプロセスの作り直し 14 システム品質（System Quality） 連携製品が増えても壊れないシステムとしての安定稼働 検証領域 検証項目 具体的な確認内容 セキュリティ・耐攻撃性 プロンプトインジェクション耐性 悪意ある入力によってシステムプロンプトや他ユーザーのデータが露出しないか確 認する ユーザー・テナント間のデータ分離 複数ユーザー・組織が利用する際に他者のデータが混入・出力されないか 機密データのプロンプト混入防止 LLMへ送信するプロンプトに個人情報・機密データが不必要に含まれていないか 信頼性・可用性 AI応答失敗時のフォールバック動作 LLM応答失敗・タイムアウト発生時にユーザーへ適切なエラーメッセージが返るか 大量データ入力時の安定性 大規模データセット（複数テーブル・長期データ・高次元データ等）を入力した 際に出力精度・安定性が落ちないか AI出力品質の継続的モニタリング 本番運用中にAI出力品質が継続的に低下した場合にアラートが出る仕組みが あるか 監査ログ・追跡可能性 AI出力の記録保持 いつ・どのプロンプトで・何が出力されたかが記録・参照できるか ユーザーの最終判断の記録 AIの出力に対してユーザーが何を採用・修正・棄却したか記録・追跡できるか データフロー・プライバシー 入力データの伝送経路・保存先の検証 ユーザーが入力したデータおよびLLMに渡したデータが、どのサービス・サーバーを経 由し、どこに保存されるかをアーキテクチャ設計通りに動作していることを確認する
15. AI時代の品質はテストプロセスの作り直し 15 プロセス俊敏性（Process Agility） LLMが変わってもデグレードさせない回帰テストを中心としたプロセス設計 検証領域 検証項目 具体的な確認内容 自動化・デプロイ CI/CDパイプラインへの品質ゲート組み込み コード変更・プロンプト変更時に自動で品質チェックが実行される仕組みがある か 迅速なロールバック体制 AI出力品質が急激に低下した場合に前バージョンへ迅速に切り戻せるか 専門性・体制 チームへのドメイン専門家の関与 ツールが扱う業務領域のドメイン知識を持つ専門家がAI出力の妥当性評価に 関与しているか 変化対応（応用） LLMバージョンアップ時の回帰テスト 基盤LLMが更新された際にゴールデンデータセットで出力品質が劣化しないか検 証できるか データ定義・業務要件変更への追従プロセ ス データ構造・業務定義・指標定義の変更時にプロンプト・評価基準を更新でき る体制があるか
16. AI時代の品質はテストプロセスの作り直し 16 顧客期待（Customer Expectation） 信頼して使い続けてもらうためにAIの透明性と顧客期待の品質 検証領域 検証項目 具体的な確認内容 AIの限界・特性共有 AIであることの明示 出力がAI生成であることがUI上で明確に表示されているか 確率的動作・出力ブレの説明 同一データを入力しても出力が変わりうることをユーザーが理解しているか 免責・限界事項の提示 AI出力はあくまで参考情報であり最終判断は人間が行う旨がUI・ドキュメントに 明記されているか 期待値管理・フィードバック ユーザーとの品質基準合意 ユーザーとAI出力の許容精度・品質水準についてユースケースごとに事前合意が あるか ユーザーフィードバック収集の仕組み AI出力の良否をユーザーが評価・報告できる仕組み（フィードバックボタン等） があるか 誤出力の事後分析プロセス 誤った出力が報告された場合の調査・原因分析・改善プロセスが定義されてい るか データ取扱い・合意形成 入力データの学習利用禁止の説明、入力 データの保存可否と保存場所の説明 ユーザーが入力したデータおよびLLMに渡したデータが基盤モデルの学習に使用さ れないこと、入力したデータが保存されるのか、保存される場合はどこに保存され るかをユーザーに説明されているか
17. AI時代の品質はテストプロセスの作り直し 17 横断補完 5軸では賄えないが、外せないシステムとして必須の品質観点 検証領域 検証項目 具体的な確認内容 説明可能性・透明性 分析根拠・参照データの明示 AIがどのデータソース・どのレコード・どの条件をもとに出力したか明示されているか 不確実性・推定値の明示 予測・推定・外挿を含む出力に対して「推計値」「確信度が低い」等の旨が表 現されているか 分析前提条件の明示 分析期間・集計単位・フィルタ条件・データ更新日時等の前提がユーザーに表 示されているか Human Oversight AI出力の修正・棄却機能 ユーザーがAIの出力結果を修正・上書き・棄却できるUIが存在するか 確信度・信頼度の可視化 AIが自信の低い出力に対してユーザーが気づける表示（警告・スコア・注記 等）があるか 機能的正確性 出力値・指標計算の正確性 AIが提示する集計値・指標・分析結果がデータソースから正しく導出されている か ハルシネーション検出 実在しない指標・架空のデータ・存在しない分析結果等をAIが生成していない か 公平性・バイアス データ偏りによる分析バイアスの確認 特定の条件・属性・期間に偏った分析傾向がAI出力に生じていないか
18. AIシステムをミドルウェアとして提供するプラットフォームビジネスだからこそ、「AIだけ」ではなくシス テム全体の品質に焦点を当てる システム品質（System Quality） 顧客期待（Customer Expectation） 1. 連携製品が増えても壊れないシステム品質 2. ミドルウェアとして複数製品が接続される構造では「AIの精度」よ り先に問うべき品質がある 3. 問い：新しい製品がAIスタックと連携したとき、別テナントのデー タが混ざらないか？ログは追えるか？ 4. 観点：テナント間データ分離・AI出力の記録保持・データフロー/ 伝送経路検証 5. 結論：プラットフォームとしての品質保証＝連携製品すべてへの 信頼の確保 1. お客様がAIを信頼して使い続けられるか 2. エンドユーザーはAIスタックの存在を意識しない。ただ「使えるか」 「信頼できるか」だけを見ている 3. 問い：AIが何か変な答えを返したとき誰がどう責任を取れる か？ 4. 観点：AIであることの明示・入力データの学習利用禁止説明・ 誤出力の事後分析プロセス 5. 結論：顧客期待の品質＝エンドユーザーとの「信頼契約」
19. 19 AI時代の品質はテストプロセスの作り直し 優先度：高 （リリース前に必須） 優先度：中 （今後対応・仕組み化） QA4AIガイドラインの活用法 ― 優先度別アクションマップ 現時点で最低限検証したい項目（高）と今後対応したい項目（中）に分類した システム品質 プロセス俊敏性 顧客期待 横断補完 プロンプトインジェク ション耐性 ドメイン専門家の関 与 AIであることの明 示 分析根拠・参照データ の明示 テナント間データ分 離 データ定義・業務要 件変更への追従 確率的動作の説 明 分析前提条件の明示 機密データのプロン プト混入防止 免責・限界事項 の提示 出力値・指標計算の 正確性 フォールバック動作 入力データの学習 利用禁止説明 ハルシネーション検出 システム品質 プロセス俊敏性 顧客期待 横断補完 大量データ安定性 CI/CD品質ゲート 品質基準合意 不確実性の明示 AI品質継続モニタ リング ロールバック体制 フィードバック収集 AI出力の修正・棄却 機能 ユーザー判断の記 録 LLMバージョンアップ 回帰テスト 誤出力の事後分 析 確信度の可視化 バイアス確認
20. テストやQAにおけるAIの活用方法 AI4QA 20 AI時代の品質はテストプロセスの作り直し
21. 21 QAプロセスそのものにAIを取り込み、テスト活動を高度化・効率化す る 今回事例として参考にするプロダクト「CADDi Quote」は、製造業の 見積業務を起点に、サプライヤー選定・見積依頼・比較などの調達 プロセスをAIとデータで効率化・標準化するクラウドアプリケーションで す。 AI時代の品質はテストプロセスの作り直し AI4QAとは何か 参考とする弊社プロダクト概要 プロダクトの品質保証におけるAI活用でテスト活動を高度化・効率化する
22. テスト計画・戦略 テスト分析 テスト設計 テスト実装 テスト実行 テスト評価・報告・ 完了 概要 テストの目的、範囲、進め方、 体制、優先順位を定める。何 をどの方針で、どこまで検証す るかを明確にする 要求仕様や設計書を確認し、 何をテストすべきかを洗い出 す。テスト観点やテスト条件 を整理する 分析で整理した観点をもと に、具体的なテストケースや 期待結果を作る。どの入力 で何を確認するかを定義す る テストケースを実行可能な 形に落とし込む。テスト手 順書、テストデータ、環境、 必要に応じて自動化スクリ プトを準備する 設計した内容に沿ってテスト を実施し、結果を記録する。 期待結果との差異や不具 合を検出する 実行結果を集計・評価し、品質 状況や残課題を関係者へ報告 する。終了可否を判断し、成果 物を整理してテストを完了する AI活用によって 変わる部分 過去の不具合履歴・変更履 歴・テスト実行履歴・テストオ ラクルの収集により、テストの 選択や優先順選択や優先順 位付けをデータ駆動で行いや すくなる。 要求仕様の書き換え・正規 化・品質診断を支援による、 分析工程での「観点抽出」と 「条件候補の洗い出し」 自然言語要求を入力として 複数 LLM のテストケース生 成能力を比較する研究も 現れており、設計工程は 「人がゼロから書く」より「AI が候補を出し、人がレ ビュー・補正」する。 テストケースを実行可能な 形へ落とし込む速度は大き く上がる。既存の人手によ るテストを土台に追加テスト を生成・改善する。 バグを「見つける → 原因を 当てる → 場所を絞る → 対 応方針を決める」という流れ を部分的に補助する。 実行結果の集計、障害票の要 約、類似不具合の分類、報告 書ドラフト作成 AI活用によって 変わらない部分 テスト目的、対象範囲、優先 順位の最終決定、終了基準、 残余リスク受容、go/no-go 判 断 要求の曖昧さ解消、業務文 脈の解釈、利害関係者との 意味合わせ 期待結果の妥当性、境界 値・例外系・業務上重要な 組合せの十分性、カバレッ ジの妥当性確認 実装済みテストが「ビルドで きるか」「安定して通るか」 「本当にカバレッジや検出 力を改善するか」は検証が 必要 実行支援には有効だが、テ スト実行のエビデンス確認は 必要。 品質状況の最終評価、未解決 課題の受容可否、リリース可否 判断、完了宣言 弊チームでの AI活用 × 〇 〇 △ △ △ AI時代の品質はテストプロセスの作り直し 22 出典：ISTQB, Certified Tester Foundation Level Syllabus, Version 4.0.1. ISO/IEC/IEEE 29119-2:2021, Software testing — Part 2: Test processes. より筆者作成 AI活用によって変わる部分と変わらない部分 AI活用によりテスト工程の効率と網羅性は向上するが、品質判断と最終責任は人が担う必 要がある 本日は上記赤枠を説明
23. 23 • QAが担当していたACレビューで特に重かった作業は「情報収集」 と「収集した情報の理解」 であり、ボトルネックはレビュー前の準備 だった。 • QA業務には、判断そのものと、その前段の準備作業がある 。 • その結果、レビューが追いつかず、着手遅れや認識ズレの後ろ倒し が起きていた。 • このときの狙いは、QAを「情報を探す人」から「判断する人へ寄せ ること」だった。 AI時代の品質はテストプロセスの作り直し 受け入れ基準(AC)のレビューの当時の課題 既存業務フローイメージ 要求仕様や設計書を確認し、何をテストすべきかを洗い出し、テスト観点やテスト条件を整理 する作業をAIによって効率化できるのではないか
24. 24 ① QAの考えを型にする • レビュー観点をMarkdownやPlantUMLで 構造化 • QAの頭の中をAIが再利用可能な形にする。 • 効果：判断の一貫性、属人化の低減 ② 正しいデータと文脈を渡す • 設計、仕様、実装などにAIが当たりに行け る状態を作る。 • 前提がズレると、もっともらしいが外れたレ ビューになる。 • 効果：レビューの前提安定、手戻り削減 ③ 人とAIの役割分担を明確にする • AIは一次レビュー・下書き • 人は妥当性判断・採否判断・最終責任 • 効果：過信も軽視も避けられる。 AI時代の品質はテストプロセスの作り直し 受け入れ基準(AC)のレビュー半自動化の成立条件 AIを使用してACレビューを回すには「観点の型化」「文脈・データの接続」「人とAIの役割分担」 が必要である
25. 25 Before：QAが情報収集・理解・レ ビュー・テスト化まで広く抱える After：AIが情報収集と理解の下準備を 担い、人はレビュー判断に集中 変化 • ACレビューの追いつかなさの緩和 • レビュー品質のばらつき縮小 • QAが改善活動へ再投資しやすくなる 。 今後 • 中長期では、浮いた時間をプロセス定 義などの次の施策に再投資できる。 AI時代の品質はテストプロセスの作り直し Before / After 業務範囲の変化 AIによる下準備の自動化により、QAはレビュー判断に集中できるようになった。
26. AI時代の品質はテストプロセスの作り直し 26 AIとQAの役割 テスト分析におけるAI4QAの要点は、要件定義の時点から「誰が見ても、同じ根拠で、同じよ うに品質判断できる状態」を作ることである AIの役割：一次レビュー・リスク候補を出す QAの役割：採否判断・優先順位・最終責任を持つ 観点 AC・要件をレビュー可能な構造に整理 観点・基準の妥当性を決める 文脈 仕様・設計・過去バグを参照して下準備 情報・解釈・条件が、文脈と合っているかを確認する 本取り組みの詳細は、こちらのスライドをご覧ください https://speakerdeck.com/naco/faster-development-but-slower-releases-qa-uses-gemini-to-automate-acceptance-criteria- reviews
27. 2030年にあるべきテストプロセスとはなにか 27 AI時代の品質はテストプロセスの作り直し
28. AI時代の品質はテストプロセスの作り直し 28 AIに関するQA活動の規格抜粋 国際標準を中心に関連する論文やツールを見ていると「プロダクト周り」のQA活動（品質特 性やテスト技法）の解像度と比較して、プロセスとしてどうすべきは現時点では粗い ガバナンス・ライフサイクル・リスクのQA AIをどう開発・提供・利用するか、どのリスクを管理するか、どの工程で 品質保証を入れるかを定義する ISO/IEC 42001 AIマネジメントシステム ISO/IEC 23894 AIリスク管理 ISO/IEC 5338 AIシステムライフサイクルプロセス ISO/IEC/IEEE 29119-2/3 テストプロセス/テスト文書 テストマネジメント・品質ゲート・監視のQA 計画したQAプロセスを、テスト実行、判定、報告、再評価、運用監視 として回す ISO 29119-2 動的テストを含むテストプロセス ISO 29119-3 テスト文書化 ISO 29119-4 テスト設計技法 ISO 42119-2 AIシステムに対する29119シリーズの適用をリスクベースで 示す 品質要求・受入基準・設計レビューのQA プロダクトに求める品質特性、AI固有の品質特性、受入基準、説明 可能性・バイアス・非決定性などの観点を定義する ISO/IEC TR 29119-11 AIシステムに対するテスト技法や品質特性 ISO/IEC 25059 AIシステムもふくめた品質特性 ISO/IEC 25010 品質特性 ISO/IEC TS 42119-2 AIシステムに対する29119シリーズの適用をリスク ベースで示す 実行結果・ふるまい・性能のQA AIシステムを実際に動かして、性能、公平性、説明性、非決定性、ド リフト、環境変化への適応などを評価する ISO/IEC TR 29119-11 AIシステムに対するテスト技法や品質特性 ISO/IEC TS 42119-2 AIシステムに対する29119シリーズの適用をリスク ベースで示す ISO/IEC/IEEE 29119-4 AIシステムに対するテスト技法や品質特性 ISO/IEC 25059 AIシステムもふくめた品質特性 ISO/IEC 25010品質特性 静 的 な QA 活 動 動 的 な QA 活 動 プロダクト プロセス
29. 29 1. テストプロセスにおける変化点がほぼ言及されていない 1. どのような基準が必要になるのか 2. どのような設計行為がどの時点で必要になるのか 3. どのような意思決定がどの時点で必要になるのか 2. テストプロセスの変化が何に影響するのかがほぼ言及されていな い 1. どのような情報をもらうべきか 2. どのような情報を発信するべきか 3. どのようKPIを追うべきか 1. 柔軟性／適用性 Flexibility and adaptability 2. 自律性 Autonomy 3. 進化 Evolution 4. バイアス Bias 5. 複雑性 Complexity 6. 透明性／解釈性／説明性 Transparency, interpretability and explainability 7. 非決定性 Non-determinism 出典：ISO 29119 Part11 より筆者作成 AI時代の品質はテストプロセスの作り直し テストプロセスの解像度の低さ ISO 29119 Part11の品質特性より抜粋 静的かつプロダクトのなかでもAI製品に特徴的なものとして７つの品質特性が上がっており、こ れらに対応するテストプロセスを想定した事業推進が必要ではないか 1. ブラックボックステスト 1. 組み合わせテスト、Back2Backテスト、A/Bテスト、メタモルフィックテスト、探索的テ スト 2. ホワイトボックステスト 1. ニューラルネットワーク構造化とカバレッジ 1. ニューロンカバレッジ、閾値カバレッジ、符号変化カバレッジ、値変化カバレッジ、 符号間カバレッジ、レイヤーカバレッジ 3. AIシステムのためのテスト環境 ISO 29119 Part11のテスト技法より抜粋
30. AI時代の品質はテストプロセスの作り直し 30 テストプロセスによる開発全体の再定義：進化への対応案 AIシステムではデータの意味が変化することに対応する必要があり、QAの基準も時間変化する 例：１つのシステムで「エモい/やばい」という言葉の意味の変化に対応する必要性がある PdM活動 QA活動 SRE活動 企画・要件 開発・評価 運用・改善 データの意味づけの変化への対応を どの範囲でテストするのか 基準作り データの意味づけの変化の見える化 の仕組みづくり データの意味を予測できないことに 対するリスクマネジメント 意味のスコアリング 意味の継続的な判定 リリース後に変わることへの対応案 開発 意味の再判定からシステムへの新し いユースケースの提案 意味の変化に対応したピボットもし くは全体調整 意味の変化のアラート
31. AI時代の品質はテストプロセスの作り直し 31 QA4AIを中心としたプロセス変化イメージ 2030年のテストプロセスは継続的判断の運用であり、QA4AIがベースでありつつ、QAが使うAI ツールの信頼性がテストプロセス設計に大きな影響を及ぼす PdM活動 QA活動 SRE活動 AS-IS GAPと改善案 TO-BE 始める前 世の中にTrustDataの仕組みがほ ぼないので、コンサルとしての論理 的な整理（勘と経験）で妥当 性を評価している 信用できるデータの選別と活用に おける高品質を保ち続ける事業 戦略策定 AIで追加された品質特性を踏ま えたテストプロセス設計 （プロダクトデータ）だけではなく、 AIが扱うデータまでを含めた信頼 性向上の仕組みづくり 29119-11を参考にしつつ、AIが関 連している/していないのグラデー ション作りが難しい 検討し始めている（Open Data SpacesによるTrust Data含めた アーキテクチャ再設計） AS-ISの効率化 世の中でTrust Dataが普及したら それらに対応する 事例をたくさん集めて類型化 チェックリストからプロセステンプ レートを生成 Open Data Spacesアーキテクチャ の実装 2022年までに出版された書籍を 元にした行動基準（決定論的 & 意味の変化なし） 決定論的テスト設計 最低限のDevSecOps
32. AI時代の品質はテストプロセスの作り直し 32 QA4AIを中心としたプロセス変化イメージ 2030年のテストプロセスはモデルとプロンプトの組み合わせテスト設計が肝であり、マルチLLM・ プロンプト／アウトプットのバージョニングによりユーザーの選択肢を広げ、「意味の変化」に追従 する PdM活動 QA活動 SRE活動 AS-IS GAPと改善案 TO-BE 始める前 マルチLLM構想・ ローカルLLMで モデル固定対応を検討中 ユーザーがモデルを選べる設計へ。 プロンプト・アウトプットのバージョニ ングをロードマップに組む ユーザーの選択肢拡大により「進 化」に追従するプロダクト設計 モデルごとの品質検証が個別対 応。品質基準は都度担当者が 判断 プロンプトバージョン単位でテスト設計。 差分検知を仕組み化。品質基準自 体をバージョン管理し意味の変化に合 わせて更新するプロセスを設ける 意味の変化を検知・再判定でき るQAプロセス。品質基準が時間 軸を持って進化する マルチLLM切替時の挙動・流量 記録の整合性確認 アウトプットのバージョニングによる 変化検知アラート設計 意味の変化に自動対応できる運 用基盤 モデル選定は単一LLM固定が前 提 テストケースは固定仕様に対して 書く。品質基準は不変が前提 単一モデルの可用性・レイテンシ 監視
33. AI時代の品質はテストプロセスの作り直し 33 AI4QAを中心としたプロセス変化イメージ AI活用しやすい基盤を整えつつ、QAが意思決定をもち、同じ根拠でシステムの 品質を保っていくことが求められる PdM活動 QA活動 SRE活動 AS-IS GAPと改善案 TO-BE 始める前 AIを使って、要求整理、リスク候補、顧 客影響の洗い出しができる。短期的に は作業は高速化したが、AIがどの情報 に依存して判断したか、プロンプトや参 照データが変わったときに出力がどう変 化するかは管理できていない 要求の背景や顧客価値、業務ルール 、制約条件、優先順位、成功指標、 過去の判断内容を、AIが参照しやす く整理し、出力結果と妥当性もデータ 化する。 AIがどの情報に依存して判断したか、プロン プトや参照データが変わったときに出力がどう 変化したかが明確になった上で、プロダクト文 脈に基づいた要求改善案、リスク候補案、 顧客影響案をAIが出す。 このデータを精度の高いテスト要求として使っ たり、リリース可否・スコープ調整・優先順位 変更・リスク説明の材料として使える AIがテスト観点、テストケース候補、リ スク候補を出せる。ただし、モデル・プロ ンプト・参照データが変わると結果も変 わる テスト要求・テストオラクル・テスト観 点・評価ルーブリック・メタモルフィック 関係・過去バグを活用し、AI出力を評 価する基盤を整備する。 最終的な判断は人がする 人・モデル・時期が変わっても、同じ根 拠で品質判断できる インシデントの再発防止観点を、次の 要求・レビュー・テスト分析へ組み込む 仕組みが弱い インシデント、アラート、問い合わせ、 暫定対応、恒久対応を参照しやす い形で整理し、再発防止観点として レビュー観点や、テスト分析に反映す る 障害から得た知見がAI4QAを通じ て次のレビュー観点やテスト観点に反 映され、同種障害の再発リスクを下 げられる 要求、ユーザー課題、顧客価値、優先 順位などは管理しているものの、それら はチケット、議事録、Figma、Slack、 過去の判断ログに分散しており、AIが 同じ文脈を再利用しにくい QAの観点・経験・レビュー基準が個人 に閉じている。AI利用も個人の使い方 に依存しやすい 障害対応やポストモーテムは行うが、 得られた学びがテスト観点やレビューに 十分反映されない