■初めに
Susaki皆さん、こんにちは。
今日から私Susakiと、
MisakiMisakiが解説していきます！
よろしくお願いします！
Susakiよろしくお願いします！
今回のテーマは、AIを活用した「テスト分析」についてです！
Misakiテスト分析って、「リスクベース」で進めるのが大事なのはわかるんですけど、過去の情報を引っ張り出したり、リスクを言語化したりするのにすごく時間がかかりませんか？
Susakiそうだね。
以前は半日から1日くらいかかっていて、しかも工数やリスクの算出が開発者やQAメンバーの『経験や感覚』に依存しがちだったんだ。
でも、「Claude」や「Gemini」などのAIツールを導入したら、これが劇的に変わったんだよ！
本記事では、AIツールを活用し、テスト分析にかかる時間を大幅に短縮しつつ、事実に基づいた精度の高い分析を行うための具体的なステップとプロンプト術を解説します。
■AI活用による劇的な変化（Before/After）
Susakiまずは、AIを活用する前と後で、テスト分析のプロセスがどう変わったかを見てみよう。
AIをテスト分析のプロセスに組み込んだ結果、以下のような変化がありました。
| 比較項目 | AI活用前 (Before) | AI活用後 (After) |
|---|---|---|
| 所要時間 | 半日〜1日 （言語化に時間がかかっていた） | 約1時間に短縮！ （言語化や整理もAIがサポート） |
| 分析の根拠 | 開発者やQAの「経験や感覚」で測るしかなかった | 過去データに基づく「事実」に基づいた分析・対策が可能になった |
| 過去データの活用 | 似たプロダクトがあっても情報をうまく活用できず。。。 | 前シーズンのバグ情報、チケット、振り返り情報をフル活用できた！ |
- 作業時間の大幅短縮:
開発対象の工数やリスクを考慮する時間が、1時間でほとんど完了できるようになりました。言語化や情報の整理もAIがサポートしてくれます。 - 「経験・感覚」からの脱却:
開発・QAメンバーの経験則に頼らず、事実に基づいた分析やリスク対策をとれるようになりました。実際にチームリーダーやPMからも「過去の事実に基づいているため納得感がある」と高い評価を得ています。 - 過去データの有効活用:
過去に似たプロダクトの情報、前シーズンのバグ情報、チケット情報、過去のテストレポートや振り返り情報などを併せて分析に活かすことができるようになりました。
Misaki「半日かかっていた作業が1時間になるのはすごいですね！
しかも、事実に基づいているから、PMやリーダーも納得してくれそうです。
Susakiその通り！実際にチームからも『過去の事実に基づいているため納得感がある』と高評価をもらっているよ。
じゃあ、具体的にどうAIに指示を出せばいいか、プロンプトの例を見てみよう。
■実践：AIを「テスト分析の専門家」にするプロンプト例
AIを活用する際の最大のポイントは、AIにロール（役割）を持たせ、「テスト分析の専門家」として分析に当たらせることです。
以下は、実際に現場で使用しているプロンプトのテンプレートです。そのままコピーして、プロジェクトに合わせてインプット情報を書き換えて使ってみてください。
プロンプト例
あなたは、ISTQB/JSTQBのテストアナリストの資格保持者で、QAやテスト業務に携わっているベテランのQA・テストエンジニアです。
「機能AB(仮名)」という機能を開発予定です。
こちらは、既存機能の「機能A」の追加実装となる機能です。 インプット情報を元に、以下の3点を過去のデータを根拠に挙げてみてください。
・必用と思われる概算のテスト工数 (ストーリーポイント)
・プロジェクトリスク
・プロダクトリスク 上記それぞれ「テスト工数」 「プロジェクトリスク」 「プロダクトリスク」は、アウトプットのチケットに書き込んでみてください。
【インプット情報】
・「機能AB」のチケットリンク
・過去開発した「機能A」のエスカレーション情報、不具合チケット情報 (CSV等)
・「機能A」開発からリリースまでかかったテスト工数 (ストーリーポイント)
・「機能A」のテストレポート
・「機能A」開発後の振り返り情報
【アウトプット】
・AI分析による内容を出力するチケットリンク
Misakiなるほど、このプロンプトにチケットや過去データを添えて投げればいいんですね！
Susakiちょっと待って！
一度に大量の指示を出すと、コンテキストが肥大化してAIが混乱したり、トークン消費が増えて利用上限に達してしまう場合があるんだ。
だから、以下の5つのステップで分けて進めるのがコツだよ。
プロダクトリスクとプロジェクトリスクの双方を考慮しつつ、以下の手順で分けて整理していくのがおすすめです。
■AIと協業するテスト分析の5ステップ
一度に大量の指示を出すと、コンテキストが肥大化してAIが混乱したり、トークン消費が増えて利用上限に達してしまう場合があります。
そのため、プロダクトリスクとプロジェクトリスクの双方を考慮しつつ、以下の手順で分けて整理していくのがおすすめです。
インプット情報をもとに、概算の「テスト工数」を算出する。
インプット情報をもとに、優先度・影響度の高いものから「プロジェクトリスク」を挙げる。
インプット情報をもとに、優先度・影響度の高いものから「プロダクトリスク」を挙げる。
テスト工数、プロジェクトリスク、プロダクトリスク内容をレビューして整理する。
AIとやりとりしながら分析内容を精査する（1度では精度が低いため、レビューを繰り返して精度を上げる）。
■Tips：過去データの効果的な読み込ませ方
Misaki過去のエスカレーション情報やバグチケットって、すごい量になりそうですけど、どうやってAIに読み込ませているんですか？
Susakiデータ量によってアプローチを変えているよ。
最近は「MCP」を使った連携がスマートでおすすめだね。
過去のエスカレーション情報や不具合チケットなどの有効なデータを使う際、データ量に応じたアプローチが必要です。
□データが少量（100件〜数百件以内）の場合
AIのMCP（Model Context Protocol）とバグトラックシステム（Jiraなど）が連携可能であれば、AI側でフィルタをかけて収集させるのが最もオススメです。
※MCP（Model Context Protocol）とは：
AIモデルが外部のデータソースやツールと安全に直接連携するための仕組みです。
これにより、AIがJiraなどのチケットから直接文脈を読み取れるようになります。
□データが大量（1,000件以上）の場合
バグトラックシステムからCSVやExcelファイルで一度出力し、該当機能部分または影響ある部分のみをピックアップしてAIに読み込ませます。
■AI活用の課題と対策
AIの活用としては、以下が挙げられます。
□課題１：リストアップが膨大になる
プロダクトやプロジェクトの内容によってはAIが大量の項目を挙げ、精査に時間がかかります。
解決策
優先度や影響度の高いものをピックアップするよう指示します。
□分析内容のブレが生じる
異なるチャットで回数を重ねると分析内容がブレる場合があります。
解決策
それぞれの分析結果を比較し、場数を踏んでデータを蓄積していくことが重要です。
■まとめ
Susakiテスト分析へのAI活用は、時短・効率化だけでなく、ナレッジ化による属人化の防止や、過去の有効なデータをフル活用できる点に大きな価値があるよ。
Misaki結果が肥大化したりブレが生じたりすることもあるから、適時更新し最適化していくための場数やナレッジをチームで蓄積していくことが大切ですね。
テスト分析へのAI活用は、時短・効率化だけでなく、ナレッジ化による属人化の防止や、過去の有効なデータをフル活用できる点に大きな価値があります。
ただし、結果が肥大化したりブレが生じたりすることもあるため、適時更新し最適化していくための場数やナレッジをチームで蓄積していくのが良いでしょう。
最期まで読んで頂き、ありがとうございました。
コメント