QA業務にAIを組み込む構想マップと、現在の実践結果

はじめに

QA（品質保証）業務において、「属人化」はどうしても避けて通れない課題ではないでしょうか。

• ドメイン知識豊富なベテランしか気づけないテスト観点
• 担当者によって粒度が異なる不具合報告……

弊社のQAチームは現在も円滑に機能していますが、組織が拡大する中で、この「人による品質のバラつき」をどう標準化していくかは、常に頭にあるテーマでした。

そこで今回、「QA業務にAIをどこまで組み込むことができるか？」という全体構想を描き、まずは実装しやすい部分から着手してみました。
まだ道半ばですが、現時点での我々の「地図」と「実践結果」を共有します。

目指す全体像と「AI導入の狙い目」

まず、我々が描いているQAプロセスとAI活用ポイントの全体図がこちらです。

【実践 1】入り口：バグチケットからの「ストーリー」生成

開発・テストフェーズで発生したバグチケットは、貴重なナレッジです。
しかし、チケットには「現象」と「修正内容」しか書かれていないことが多く、そこだけを見てリグレッションテストを行うと、「本来どうあるべき機能なのか」 という全体像を見失い、影響範囲の確認漏れが発生するリスクがあります。

そこで、テストケース作成の前段階として、「まずはその機能がどんな機能かを正しく理解する」 ために、バグチケットの内容から 「 ストーリー （利用シナリオ）」を生成させる試みを行いました。

1. 入力した情報

以下のような、現象と手順のみが書かれたチケットを入力しました。

タイトル： 【記録】特定の操作で削除時にシステムエラーが発生する
詳細： PCで記録を削除して、同期を取る前にモバイルで削除を実行すると、連携時にシステムエラーが発生する。
手順：

1. PC：記録をつける → ゴミ箱ボタンを押して確認モーダルを開く
2. モバイル：記録を表示して削除ボタンを押して確認モーダルを開く
3. PC：削除 → モバイル：削除
   対応： 後から削除した側でエラーが発生しないように修正。

2. 段階的な生成実験

最初は、単純にチケットの「タイトル」と「詳細」だけをAIに渡して生成させてみました。

▼ 最初の生成結果（タイトル＋詳細のみ）

【ストーリー概要】
ユーザーとして、PCとモバイルの両方で同じ記録を削除しようとした際に、システムエラーが表示されることなく、スムーズに削除処理を完了（あるいは同期）させたい。

内容は間違っていませんが、「ユーザー」という主語が曖昧で、QAとしては具体的にどう検証すればいいかが分かりにくい状態です。

3. 工夫した点（プロンプトの改善）

そこで、「機能の振る舞いをより詳細に理解したい」 という意図を込め、プロンプトに以下の定義を追加しました。

• アクター（登場人物）の定義
  • 「ユーザー」を細分化し、PC操作側を「管理者」、モバイル操作側を「スタッフ」と定義しました。
• 粒度の指定（シナリオとユースケース）
  • 漠然としたストーリーだけでなく、具体的な状況を表す「シナリオ」と、詳細な「ユースケース」の2段階で出力させました。

4. 改善されたアウトプット

定義を追加した結果、以下のように出力が変化しました。

【シナリオ】
PCで操作している管理者とモバイルで作業中のスタッフが同時に通所記録の削除対応をする。

【ユースケース】

• 管理者がPC側で通所記録を削除実行中、同じタイミングでスタッフがモバイル側でも削除を試みる。
• 反対に、スタッフがモバイル側で通所記録を削除実行中、同じタイミングで管理者がPC側でも削除を試みる。

5. 成果と考察

「操作手順」や「曖昧な要望」が、明確な 「ストーリー （競合時の振る舞い）」に変換されました。

これにより、QA担当者は「これは排他制御の機能である」という本質を即座に理解でき、単なるバグ確認に留まらず、「PC→モバイル」だけでなく「モバイル→PC」の逆パターンも必要だ、といった影響範囲の考慮が可能になりました。

💡 視野を強制的に広げる効果
また、シナリオ化には 「視野を強制的に広げる効果」 があると感じています。
特定の機能修正を行う際、人間はどうしても「そのチケットの修正箇所」だけに意識が集中し、視野が狭くなりがちです。しかし、AIが全体像（シナリオ）を提示してくれることで、ふと一歩引いて「あ、この機能はあそこの業務フローにも関わっていたな」と気づくきっかけになります。

今回は比較的分かりやすいチケットを例に挙げましたが、この効果はチケットの内容が複雑になればなるほど大きくなると考えています。
仕様が複雑で入り組んでいる時ほど、人間は細部に埋没してしまいがちです。そんな時こそ、AIに「要するにこういう話ですよね？」とシナリオとして可視化してもらうことが、影響範囲の考慮漏れを防ぐ命綱になると期待しています。

---

【実践 2】出口：不具合・CS問い合わせ分析

情報の「入り口」に加え、「出口」である不具合や問い合わせデータの分析においても、AI活用を検証しました。
ここでは、「1. 手動作業（分類）の代替」 から始め、そのデータを踏まえて 「2. 考察の壁打ち（分析）」 へとステップを進めました。

1. Step 1：AIによる「分類作業」の代替検証

まず、人間（開発者全体）が手動で行っている「不具合チケットの分析・分類作業」を、AIが同様の基準で実施できるか検証しました。

• 実施内容:

  • 過去のチケットデータを読み込ませ、人間が行っているのと全く同じ以下の5項目で分類を出力させました。
    1. 顧客影響（リスク基準①）
    2. 顧客影響（リスク基準②）
    3. 不具合種別
    4. 発生要因
    5. 品質特性

• 検証結果（精度）:

  • 人間が行った分析結果との一致率は、およそ 50%程度 でした。

• 考察:
  • 半分は一致するものの、残りの半分には、チケットの文面には現れない 「暗黙知（これまでの経緯やドメイン知識）」 が判断基準として強く影響していることが分かりました。完全自動化には、判断基準の言語化やチューニングが不可欠です。

2. Step 2：分析結果の「壁打ち相手」として活用

次に、Step 1で得られたデータや、別途集計したグラフ画像などを用い、私の導き出した考察が正しいかどうか、AIを「セカンドオピニオン」として利用しました。

• 実施内容と狙い:

1. 指示なし分析（答え合わせ）

• 全体のデータやグラフ画像を読み込ませ、あえて 「特に細かい指示をせず」 に分析を依頼しました。
• 狙い: 私のバイアスが入っていない状態でAIに分析させ、私の考察の方向性と一致するか（的外れではないか）を確かめるためです。

2. 反対意見の提示（抜け漏れチェック）

• 全体の分析結果に対し、 「私の考察に対する『反対意見』を3つ挙げてください」 と依頼しました。
• 狙い: 人間では見落としがちな視点や、考察の抜け漏れがないかを客観的にチェックするためです。

3. 成果

「作業者（Step 1）」としてはまだチューニングの余地がありますが、「分析パートナー（Step 2）」としては非常に優秀でした。
自分一人では気づきにくい視点（反対意見）をもらえることで、最終的な分析レポートの品質と説得力を高めることができました。

おわりに

正直なところ、冒頭で掲げた「構想マップ」のすべてを緑色（実装済み）にするには、まだ道半ばというのが現状です。

しかし、今回ご紹介した「入り口（ストーリー生成）」と「出口（分析）」の部分だけでも、確実な工数削減と、属人化の解消に貢献し始めています。
今回の検証を通して、AI活用には以下の3つのレイヤーがあることが明確になりました。

1. そのまま実用化できる領域
   • 少しの調整（チューニング）で、すぐに業務効率化に直結する部分。（例：品質特性の分類など）
2. アプローチの転換が必要な領域
   • 単なるプロンプト改善だけでは限界があり、参照させるデータの種類や視点を変える必要がある部分。（例：発生要因の特定など）
3. 未開拓の領域
   • リスク分析やテスト設計など、まだAI導入が行えていない、これから挑戦すべき部分。

まだまだAI活用の効果が見えきっていない工程もありますが、「AIはQAの敵ではなく、最強のパートナーになり得る」という手応えは掴めています。
今後もこの活動を止めることなく継続し、プロセスを進化させながら、QA業務の新しい形を模索していきたいと思います。