はじめに：QAエンジニアの悩み 📝
こんにちは！QAエンジニアのAyakaです。
QAエンジニアなら不具合報告書作成も業務の1つで、「読み手に分かりやすい不具合報告書にするためには、専門用語をどんな表現にしたらわかりやすいか・・・？」と不具合報告書の作成のたびに頭を悩ませていました。
そこで、全社で導入したGeminiを不具合報告書の作成で使ってみると・・・
専門用語だらけだった生産管理システム「SmartF」の不具合報告書を、お客様にも"伝わる"言葉で語れるようになるまでの、Geminiへの弟子入り挑戦の記録です。
師匠（AI）との出会い：果てしない報告書の道 🛤️
QAエンジニアとしての日常業務の中で、不具合報告書の作成は避けて通れない道です。
しかし、「書けども伝わらず、お客様や社内関係者からの問い合わせが絶えない…」そんな悩みを抱えている方も少なくないのではないでしょうか。
特に、私たちが担当する生産管理システム「SmartF」は、中小企業の製造業の現場で日々活用されています。ユーザーは生産管理のプロフェッショナルですが、必ずしもITシステムの専門家ではありません。そのため、技術者目線の報告書では、内容が十分に伝わらないという課題がありました。
「この状況、AIで何とかならないかな…？」
そんな淡い期待を胸に、GoogleのAIであるGeminiを試してみることに。これが、私のAI「弟子入り」の始まりでした。（少し大げさかもしれませんが、それくらいのインパクトがあったのです！）
この記事では、AI (Gemini) を活用して、お客様にとって分かりにくい不具合報告書をどのように改善していったのか、その具体的なプロセスと得られた学びを共有します。AIはQA業務の強力なパートナーになり得る、その可能性を感じていただければ幸いです。
弟子入り前の日常：なぜ私の報告書は魔術書化していたのか？ 📜
改善前の不具合報告書は、今思えば開発者側の視点に偏っており、システムに詳しくない方にとってはまるで「魔術書」のように難解だったかもしれません。
Beforeの状態：従来の報告書の典型例（たとえ話）
例えば、こんな報告書が作成されていました。
従来の報告書例（クリックして展開）
報告書タイトル例：
受注引当モジュールにおける XX_TBL と YY_MST のデータ不整合起因の在庫更新時 NULL参照エラーについて
事象・原因の記述例：
受注データ登録後、引当バッチ実行時にXX_TBLの特定フラグが期待値と異なるため、YY_MSTとのリレーションシップが成立せず、関連するクエリがNULLを返し、後続処理でNullPointerExceptionが発生。結果、該当受注IDの在庫引当ステータスが『処理中』のまま停止。
どうですかね？ これでは、ユーザーである生産管理担当者の方は「意味わからないもの出してきた」と思いますよね？
この報告書が伝わらない主な問題点は以下の通りです。
- 専門用語の壁： テーブル名 (XX_TBL)、SQL関連用語 (クエリ、NULL)、プログラミングエラー名 (NullPointerException) など、IT知識がないと理解が難しい単語が頻出。
- システム内部動作中心の説明： ユーザーが直接触れる画面や操作ではなく、システムの裏側の動きを中心に説明している。
- ユーザー視点の欠如： 「この不具合が自分の業務にどう影響し、何をすれば良いのか」が即座に理解できない。
結果として、顧客サポート部門がユーザー向けに内容を「翻訳」し直したり、ユーザーから同じような内容の問い合わせが何度も寄せられたり、といったコミュニケーションコストが発生していました。
弟子入り修行："伝わる"報告書への道 🤝
この課題を解決すべく、AI (Gemini) を活用した不具合報告書の改善に取り組みました。
ステップ1：師匠への情報提供（インプットの準備）
まずは、Gemini師匠に「学習」してもらうための材料を準備しました。
- ユーザーから問い合わせがくるシステムヘルプの関連箇所： AIにとっての教科書です。
- 上記システムの不具合発生を報告するSlackスレッドの内容： 発生時の具体的な状況やユーザーの声を把握するために重要です。
- 開発担当者との「なぜなぜ分析」ミーティングの議事録： Google Meetで実施し、AI議事録機能でテキスト化。これが原因究明と対策立案の核となる情報源です。
ステップ2：師匠への問いかけ（実際に使用したプロンプト大公開！）
これらの情報を元に、Geminiに指示を出します。以下が、実際に使用して効果があったプロンプトです。このプロンプトが、報告書改善の大きな鍵となりました。
あなたはQAエンジニアです。
不具合が発生した報告Slackのスレッド内容と開発担当者と行ったなぜなぜ分析議事録に基づいて、以下の成果物を作成してください。
成果物:
システム不具合報告書（非エンジニア向け）
対象読者:
システムに詳しくない担当者（顧客や社内関係者など）
※添付ファイルの記載項目を参考にする。（ブログ注：あらかじめ定義しておいた報告書のフォーマット・項目構成に沿って出力するよう指示しています）
目的:
不具合の内容、原因、および今後の対策を分かりやすく伝え、理解と協力を得ること。
記載項目:
1. どのような問題が起きましたか？（事象）: 具体的な不具合の内容。
2. （発生条件）: わかれば記載。
3. なぜ問題が起きたのですか？（原因）: 根本原因を専門用語を避け、論理的かつ簡潔に説明してください。技術的な詳細よりも、プロセスや判断、確認のどこに問題があったのかが伝わるようにしてください。（最大2つ。1つでも可）
4. 今後どうしますか？（再発防止策）: 同様の不具合を繰り返さないための具体的な対策（プログラムの修正内容だけでなく、テスト方法の見直し、チェック体制の強化、情報共有の改善など、プロセスに関わる内容も含む）を記述してください。（最大2つ。1つでも可）
留意事項:
- 専門用語（例: Hotfix, キャッシュ, デグレ, バックログ, SQL, APIなど）は極力使用せず、やむを得ず使用する場合は平易な言葉での言い換えや補足説明を行ってください。
- 事実に基づき、客観的かつ誠実なトーンで記述してください。
- 顧客名や内部的なデータベース名、担当者名は適宜マスキングまたは一般的な名称に置き換えてください。
このプロンプトのポイント解説 ✨
このプロンプトが効果的だったポイントは以下の通りです。
-
役割設定 (
あなたはQAエンジニアです。)： AIに適切なペルソナを与えることで、出力のトーンや視点をコントロールします。 -
入力情報の明示 (
Slackのスレッド内容と...なぜなぜ分析議事録に基づいて)： AIがどの情報を参照すべきかを明確化します。 -
成果物と対象読者の定義 (
システム不具合報告書（非エンジニア向け）,システムに詳しくない担当者)： これにより、AIは専門用語を避け、分かりやすい言葉を選ぶようになります。 -
目的の共有 (
不具合の内容、原因、および今後の対策を分かりやすく伝え...)： AIが何のために文章を生成するのかを理解させ、目的に沿ったアウトプットを促します。 -
具体的な記載項目と指示 (
どのような問題が起きましたか？など)： 報告書の骨子をAIに伝え、必要な情報を網羅させます。特に「原因」の項目で「技術的な詳細よりも、プロセスや判断、確認のどこに問題があったのか」と深掘りする視点を与えているのが重要です。また、原因と対策の数を制限することで、冗長さを防ぎ、要点を絞った報告を促しています。 - 詳細な留意事項： 専門用語の扱い、トーン、マスキングといった具体的な指示は、出力品質を大きく左右します。
ステップ3：弟子の務め（QAエンジニアによるレビューと最終調整）
Gemini師匠からの回答は非常に参考になりますが、それをそのまま使うわけではありません。ここからがQAエンジニアの腕の見せ所です。
- 内容の正確性・適切性の厳密なチェック： AIの出力に誤りがないか、SmartFの実際の仕様やお客様の状況と照らし合わせて確認します。
- 表現の微調整： お客様にとってより自然で理解しやすい言葉遣いや表現に修正します。時には、AIが生成した文章を元に、大幅に書き換えることもあります。
- 「これは本当に伝わるか？」の自問自答： 常にお客様の視点に立ち、報告書が独りよがりになっていないかを確認します。
改善の成果："伝わる"報告書 🎉
このようなプロセスを経て、不具合報告書は大きく改善されました。
Afterの状態：AIを活用して改善された報告書の例（たとえ話）
改善された報告書例（クリックして展開）
報告書タイトル例：
【SmartF不具合報告】在庫引当処理でエラーが発生する件（〇月〇日発生分）
1. どのような問題が起きましたか？（事象）
ネクスタSmartFの「受注管理」画面から在庫引当を実行した際に、「SF-E00123:処理を継続できません」というエラーメッセージが表示され、処理が完了しない事象が発生しました。
2. （発生条件）
特定の商品コード（例：ABC-001）が登録されている受注伝票で、特定のタイミング（例：月末月初などデータ処理が集中する時間帯）に在庫引当操作を行った場合に発生することを確認しています。
3. なぜ問題が起きたのですか？（原因）
システム内部で商品情報を参照する際に、一時的にデータの食い違いが発生し、正しい在庫情報を引き当てられなかったことが原因です。これにより処理が安全に停止していました。
（詳細：以前のバージョンアップ時のデータ移行プロセスにおいて、一部の関連データにわずかな不整合が生じるケースがあり、特定の条件下でその不整合が顕在化しました。）
4. 今後どうしますか？（再発防止策）
ユーザー様に行っていただく暫定対応：
お手数ですが、エラーが発生した場合は、一度時間をおいてから（例：5分程度）再度同じ操作をお試しください。それでも解決しない場合は、弊社サポート窓口までご連絡いただけますようお願いいたします。
システム開発チームが行う恒久対応：
データ参照のロジックを見直し、同様の事象が発生しないようシステム改修を進めております。次回のアップデート（〇月予定）にて修正版をリリース予定です。また、今後のデータ移行プロセスにおいては、確認手順を強化し、同様の不整合が発生しないよう再発防止に努めます。
Before/After比較（改善ポイント）
| 項目 | Before（従来の報告書） | After（AI活用後の報告書） |
|---|---|---|
| タイトル | 専門的で長い | 具体的で分かりやすい |
| 事象説明 | システム内部の挙動中心 | ユーザーの操作と画面表示から説明 |
| 原因説明 | 技術用語が多く、根本原因が掴みにくい | 平易な言葉で、プロセス上の問題点にも触れ、論理的 |
| 対策説明 | システム改修内容が中心 | ユーザーが行うべき暫定対応と、システム側の恒久対応を明確に区分 |
| 専門用語 | 多用 | 極力排除、または平易な言葉で補足 |
| 読者視点 | 開発者寄り | ユーザー（非エンジニア）寄り |
顧客サポート部門からも、「以前より格段にお客様に説明しやすくなった」「問い合わせの内容が具体的になり、対応がスムーズになった」といった肯定的なフィードバックを得られるようになりました。
弟子入り修行で習得したもの：AI活用のメリットと実感 💪
AI (Gemini) を活用することで、以下のようなメリットを実感しています。
-
報告書作成時間の大幅な短縮：
従来、情報の整理から文章作成、レビューまで平均3時間ほどかかっていた作業が、AIのアシストにより平均1時間程度に短縮されました。これにより、他の重要なQA業務に時間を割けるようになりました。 -
コミュニケーションの質の向上：
分かりやすい報告書になったことで、顧客サポート部門の手戻りが減少し、ユーザーからの問い合わせも、以前のような「これはどういう意味？」といった内容から、より具体的な状況確認や次のアクションに関する質問へと変化してきました。 -
報告書の標準化と品質向上：
AIがベースを作成することで、報告書の品質が安定しました。今後は担当者ごとのばらつきが少なくなりそうです。 -
QAエンジニア自身のスキルアップ：
効果的なプロンプトを考えることは、問題の本質を捉え、情報を整理し、相手に分かりやすく伝える訓練になります。これは、QAエンジニアにとって非常に重要なスキルだと再認識しました。
師匠（AI）と付き合う上での心得：注意点と工夫 💡
AI記事では必ず記載されていることで重複してしまいますが、AIは非常に強力なツールです。しかし万能ロボット、なんでも屋さんではありません。
活用する上で注意すべき点や、よりうまく付き合うための工夫があります。
-
AIはなんでも屋さんではない、最終判断は人間が：
AIの出力には、誤情報や不確実な情報が含まれる可能性があります。
必ず人間がファクトチェックを行い、最終的な内容の正確性や適切性を担保する必要があります。AIはあくまでアシスタントであり、責任者は私たち人間です。 -
プロンプトは「師匠への上手な質問術」であり「設計図」：
今回ご紹介したように、AIに期待するアウトプットを得るためには、具体的かつ明確な指示（役割、入力情報、出力形式、制約条件など）をプロンプトに落とし込むことが非常に重要です。
一度で完璧な出力を期待せず、AIの回答を見ながらプロンプトを微調整していく「対話的な改善」が効果的です。 -
AI議事録の特性を理解して活用：
Google MeetなどのAI議事録機能は非常に便利ですが、100%正確ではありません。
特に専門用語や固有名詞で誤認識が起こり修正していることもあります。
重要な箇所はメモを取るようにし、あくまで「叩き台」や「要点把握の補助」にしています。
今後の修行、そしてQAエンジニアの未来：AIと共に歩む道 🚀
今回の経験を通して、AIはQAエンジニアの業務を効率化し、品質を向上させるための強力なメンバーになり得ると確信しました。
今後は、不具合報告書だけでなく、
- テストケースの原案作成支援
- テストデータ作成のアイデア出し
- ソースコードからのテスト設計書の作成
など、他のQA業務へもAIの活用範囲を広げていきたいと考えています。
AI技術は日々進化しています。その進化を恐れるのではなく、ひたすら使いなれていくことで、QAエンジニアはより創造的で高度な分析業務や品質戦略の立案といった本質的な業務に注力できそうな予感がします。
生産管理システム「ネクスタSmartF」の品質向上に向けて、AIという新たな武器を最大限に活かしていきたいと考えています。
まとめ：あなたもAIに「弟子入り」してみませんか？ ✨
今回の記事では、AI (Gemini) を活用して、専門用語が多く分かりにくかった生産管理システムの不具合報告書を、非エンジニアの顧客にも"伝わる"内容に改善した具体的なプロセスと、そこから得られた学びをお伝えしました。
AIは、私たちの仕事を奪うものではなく、私たちの能力を拡張し、より質の高い仕事をするための「師匠」であり「相棒」です。
「うちのドキュメントも分かりにくいんだよな…」「報告書作成にもっと時間がかからなくなれば…」
そう感じているQAエンジニアの皆さん、そしてドキュメント作成に携わる全ての皆さん。
まずは小さなことからでも、AIを業務に取り入れてみてください。
AIをペアプロの相手だと思っていくと共に成長していく。
最後までお読みいただき、ありがとうございました！
この記事が役に立ったと思ったら、ぜひ「いいね」やコメントをお願いします！
ご自身のAI活用事例などもあれば、ぜひ教えてくださいね。
Discussion