不具合データは情報資産！「生成AI」と連携して不具合分析やチャットボットに活用

この記事は「株式会社エス・エム・エス Advent Calendar 2025」の12/17の記事です。

はじめに

介護/障害福祉事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。気づけば入社して4年が経ちました。現在は複数のQAチームに横断的に関わりつつ、チームのサポートや改善活動の推進、組織マネジメントなど幅広い業務を担当しています。

エス・エム・エスでは全社員が生成AIを業務に活用できる環境が整っており、私たちQAエンジニアもテスト活動や業務効率化に活用を進めています。しかし、現状は個人レベルでの活用がメインとなっており、組織的な仕組み化やナレッジの横展開という面では、まだまだ生成AIを活かしきれていないというのが実情です。

こうした課題に対し、今回の記事では生成AIを品質活動に取り入れようとしている具体的なチャレンジ事例について2つ紹介します。まだ充分な成果が出ているフェーズではなく、あくまで試行錯誤している内容として、率直に記載していますのでご了承ください。

事例1. 不具合分析を生成AIで効率化

導入の背景

カイポケでは、不具合データに複数の分類を持たせて、定量的に分析する仕組みを取り入れています。詳細は過去に私が執筆した記事をご参照ください。 tech.bm-sms.co.jp

不具合分析は主に以下のプロセスで進めていますが、生成AIを取り入れたのは「3.JIRAのデータを元に分析する」フェーズです。

不具合をJIRAチケットに起票
JIRAのデータをスプレッドシートで集計・可視化
JIRAのデータを元に分析する ※AI活用ポイント

この「分析する」のフェーズは、分析経験・プロダクト理解・そして熟練者の勘所も必要であり、属人化しやすく時間が掛かってしまうという課題を抱えていました。そこで、構造化された不具合データを生成AIと連携させ、分析の作業効率化とプロセスの標準化を目指すことで、この課題を打破できると考えました。

どう実現しているか？

使用する生成AIはGeminiです。まず、JIRAに蓄積されている分析対象の「不具合データ」を用意し、インプットとしてAIに渡します。次に分析の目的や期待するアウトプットの形式といった具体的な分析指示をプロンプトで入力し、不具合分析を実施していきます。不具合データやプロンプトの詳細は後述します。

不具合データ

不具合データは、普段から集計・活用しているJIRAチケットの情報がベースです。このデータは、不具合の発生状況だけでなく、品質改善に向けた深掘り分析を可能にするため、複数の「分類軸」を持たせてています。

不具合データが持っている主要な情報は以下の通りです。

項目名	説明
基本情報	要約、再現手順、期待値など、不具合の概要情報
テストフェーズ	不具合を検出したテストフェーズ（例：DEVテスト、STGテストなど）
不具合種別	不具合の種別（例：新規、既存など）
検出種別	検出した不具合の内容（例：機能不備、レイアウト不備など）
検出分類	不具合を検出した経路（例：QAテストケース、QAテストケース外など）
原因分類	不具合が混入した原因（例：仕様理解不足、コード実装不備など）

プロンプト

分析の品質を均一化、誰でも悩まずに効率的にアウトプットが得られるよう、「標準プロンプト」を設計しました。この標準プロンプトは生成AIを特定の専門家として機能させるための要素を含んでいます。

標準プロンプトを構成する主な要素は以下の通りです。

構成要素	目的と具体的な指示
役割	ペルソナを設定し、出力のトーンと視点を設定する
背景	分析やテストの目的など、データでは分からない文脈を設定する
ルール	具体的な分析作業を指示、分析軸の指定やアウトプットの構成要素を設定する

※プロンプト例

役割
・経験豊富なQAチームリーダーの視点で分析してください

背景
・分析目的：プロジェクトの品質傾向を把握したい
・プロジェクト名：XXX機能の追加
・テスト目的：追加したXXX機能が正しく動作すること、関連する既存機能に影響がないことを確認する）

ルール
・「検出種別 × 原因分類」の軸で分析をしてください
・不具合から品質傾向を客観的な視点でレポートしてください
・全体を通して「である調」で記述してください
・結論から先に述べる構成にしてください

今後に向けて

生成AIが最初に出してくるアウトプットはあくまで「下書きレベル」であるため、人間によるレビューやAIとの対話が多く必要になっています。今後は、チーム全体での積極的な活用とフィードバックを通じて分析精度の向上を図り、レビューのコストを削減できればと考えています。また、データ集計から言語化までのプロセスをより効率化するため、スプレッドシートのAI関数なども活用し、シームレスな連携を実現できるよう改善を進めていくことも検討していきます。

事例2. 不具合情報を持ったチャットボットの活用

導入の背景

テスト設計において、過去の不具合情報やドメイン知識は重要な参考情報ですが、情報が膨大ゆえに探索コストが高く情報が漏れてしまうというリスクがありました。生成AIはこれらの課題解決に加え、テスト観点の提案やレビュー効果も期待できるため、対話式のチャットボット作成を目指すことにしました。

どう実現しているか？

GeminiのGem機能を使い、「カスタム指示」と「知識」に必要な情報を設定することで専用のチャットボットを作成しました。プロンプトは入力に迷わないようにいくつかサンプルを作成して公開しています。運用イメージは下記図をご参照ください。

カスタム指示

ドメイン知識を持ったQA専門のアシスタントとして機能するように設定しています。カスタム指示には、AIが回答の際に参照すべき「役割」「ドメイン」「ルール」を詳細に定義しています。

カスタム指示に設定した内容は以下の通りです。

構成要素	目的と具体的な指示
役割	ペルソナを設定し、出力のトーンと視点を設定する（例：あなたは過去不具合とドメイン知識に精通したQAアシスタントです）
ドメイン	サービスの業界、業務領域、技術的・制度的な制約といった、背景知識を設定する
ルール	行動指針（情報検索方法、事実に基づいた回答の徹底）と、アウトプットの構成要素を設定する

知識

知識には事例1で紹介した不具合データを設定します。

チャットボットとの対話例

実際にチャットボットとやりとしている内容の例を紹介します。最終的な判断は人が行う必要がありますが、叩きとしては充分な内容で高速で出力されることもあり非常に効率的です。

目的	プロンプト例	回答概要
1. リスク分析と観点抽出	ログイン機能に変更が入るので、過去の不具合から見て注意すべき観点を教えて	過去の不具合事例に基づき、認証・セッション安定性、セキュリティ（権限昇格）、連携機能への影響など、最もリスクの高い重点観点を提示
2. テストケースの提案	勤怠管理の改修が入るので、具体的なテストケースを提案して	過去事例を反映し、境界値テストや機能連携テストなど、具体的な操作手順を含むテストケースの例を提案
3. 不具合発生時の対応支援	特定のデータで画面が真っ白になったけど、過去に似た事象はある？	類似する過去の不具合事例や想定される原因を特定し、調査の方向性を提示
4. ドメイン知識の問合せ	請求情報と勤怠情報の連携で、過去にどんな問題が起きた？	特定の機能連携に関して、過去に発生したデータ不整合のリスクや、それに対する現在のシステム対応状況を説明

今後に向けて

実運用はまだQAチームに閉じていますが、今後は広く展開し不具合データだけでなく、膨大なドメイン情報や社内の知見も取り込み、QAや品質に関するあらゆる「困りごと」の相談相手となるAIアシスタントに育てていきたいと考えています。

さいごに

本記事では、カイポケQAチームの生成AIを使った具体的な取り組み事例を紹介させていただきました。技術の進化を「絵に描いた餅」で終わらせず、品質活動に積極的に取り入れるモチベーションを持って日々業務に取り組んでいます。その他、GitHub CopilotやClaude Codeを使って、プロダクトコードやPRの情報からテスト観点を効率的に抽出する活動もトライしています。

私たちQAエンジニアは単にバグを見つけるだけでなく、プロセスのデザインやチームの知識を構造化したり、最新のテクノロジーを活用してプロダクト全体の品質を高める役割を担っていると考えています。そういった新しい技術を品質活動に取り入れることにワクワクし、試行錯誤できるモチベーションがある方を積極募集中ですし、一緒に仕事をしたいと思っています。

興味がある方は、ぜひカジュアル面談でお話ししましょう！！