Claudeを利用してテスト要項書から不具合対応チケットを生成する話

はじめに
準備
- テスト要項書のサンプル
- 不具合チケットテンプレートのサンプル
Claudeへプロンプト入力
おわりに

はじめに

🎄フリューAdvent Calendar 2025 の15日目の記事です。

qiita.com

「この間の不具合チケット(PBI)探してるけど見つからない。どこにあるか知らない？」
「あ、そういえば起票忘れてたかも……」

なんてこと、ありませんか？
私は稀によくあります。品質支援課の橋本です。

各種テスト中や開発作業中に不具合を見つけたら、忘れないうちにすぐ対応チケットを起票すべきですが、この「べき」がクセモノではないかと思っています。
したほうがいいのはわかっていても、ちょいちょい後回しにしてしまいがちというか。

チケット起票は下記の要素に分解できます。

チケット起票画面を立ち上げる
テスト要項書の内容をチケットに転記する
再現手順を整理し、記載する
期待結果と実際の動作を記載する

「実施中のテストに戻ってくる」までを要素に加えてもいいです。

これら1つひとつは難易度の高い作業ではありません。書くだけですから。ただただ手間が掛かるだけです。
一度作業を切り上げてチケットを切り、戻ってくる間に集中力が切れ、さて直前まで何をやってたんだっけ、みたいな負荷もかかります。いわゆるスイッチングコストです。
1回, 2回だとたいしたコストではなくても、チリツモですからね。こういうものは。

「チリも積もれば山となる」のイラストを「いらすとや」さんで探しても見つからず、かわりに見つかった「鳩が豆鉄砲を喰らう」イラスト。かわいい。

結果、「今やってるところがひと段落したらやろう」とか「全部まとめて一気にやろう」とかやってしまうと、チケットを切り忘れたり、エビデンスを取り違えたり、再現確認がやりたくても状態が変わっていて現象が再現できなくなっていたりします。時すでにアフターザカーニバルだと古事記にも書いてあります。

これは、そんなつらみを解消したくてClaudeにやらせてみたらうまいことできたよ！　という記事です。
Claudeを選定した理由は日本語の解釈能力の高さです。
文脈を読み取る力が高いのが嬉しいポイントで、テスト要項書作成時も網羅性や表記揺れを確認してくれて捗ります。ありがとうClaude。

準備

Claudeにチケットを生成させるにあたり、必要なものは以下の2つです。

テスト結果記載済みのテスト要項書
- 不具合が発生したテスト項目の情報
不具合チケットのテンプレート
- 起票先のフォーマットに合わせた雛形

テスト要項書のサンプル

弊QAチームではテスト要項書をQaseで管理していますが、Excelでもスプレッドシートでも、一定の構造で管理されていればいい感じに読み取ってくれました。(このサンプルはExcel製です)

qase.io

不具合チケットテンプレートのサンプル

不具合チケットのテンプレートはマークダウン形式で用意してみました。

## 不具合チケットテンプレート
### 基本情報
* 発見日：yyyy/mm/dd
* 発見フェーズ：[ ] 仕様検討 / [ ] 機能テスト / [ ] 結合テスト / [ ] リリース前テスト / [ ] 本番環境

### 不具合ランク
* 不具合ランク：[ ] A / [ ] B / [ ] C / [ ] D
* 修正優先度：
    * A: リリース後の場合即対応必須、リリース前の場合修正対応最優先（基本リリース不可）
    * B: 早めの優先対応が望ましい
    * C: いずれは修正したい
    * D: 許容する、余裕があれば修正

### 詳細
#### 再現条件
（具体的な再現手順を記載）

#### 本来の仕様
（本来の仕様を記載）

#### 受け入れ条件
（受け入れ条件を記載）

### 不具合ランク判定の根拠
#### 重大度
* [ ] Critical - 代替手段なし/ユーザビリティが妨げられる
    * [ ] ビジネスインパクトが大きい（KPIに大きく影響）
    * [ ] 主要機能の正常系/ハッピーパスが通らない
* [ ] Major - 代替手段あり/ある程度の影響
    * [ ] Critical相当だが代替手段あり（代替手段：        ）
    * [ ] 主要機能ではないがユーザーへの影響あり
* [ ] Minor - 影響小
    * [ ] 機能不具合の影響が小さい
    * [ ] UI表示崩れ（操作可能）、誤字脱字など

#### 発生率
* [ ] 高頻度（80-100%）- 特定条件なし/よくある条件
* [ ] 中頻度（30-79%）- 特定条件なし/よくある条件
* [ ] 小頻度（6-29%）- 特定条件で発生
* [ ] 極小（5%以下）- 極めて特殊な条件

テンプレートサンプル内の「不具合ランク」は重大度 × 発生率のマトリクス表から大まかな対応優先度を算出する仕組みです。
開発作業に着手する大まかな目安になるので、プランニング時に参考になります。

Claudeへプロンプト入力

テスト実施中に不具合を見つけたら、要項書の「テスト結果」欄に記載し、Claudeにチケット作成をお願いします。

ticket_template.mdは不具合対応チケットのテンプレートです。
malfunction_level.csvは不具合ランクを決定するマトリクス表です。
test_result.csvをもとにテンプレートに沿った不具合対応チケットを作成してください。
事象ごとに不具合対応チケットを起票してください。

1件ずつチケットを切る場合は テストNo2の項目の などと指定すれば良いですし、テンプレートだけでなく「主要機能のリスト」や「重点KPI」なども入力に渡せば、より精度を高めて重要度の評価をしてくれます。

クリップボードからコピペして渡しても構いませんが、プロンプト例のようにファイルごと渡すほうが手間がなくて便利だと思います。途中で内容が切れちゃってた、なんてことも防げますし。

こうして生成された内容を目視で確認・調整してチケット管理システムに起票すれば完了です。
チケット管理システムのAPIを叩けば、完全に自動化して起票完了までできます。
そこまでしなくても、下書きをざっくり書いてくれるだけでもだいぶ楽にはなります。

最終的な確認と判断は人間が行うことで、精度を担保しつつ工数を削減できそうです。

ちょっとした工夫

ちょっとした工夫ポイントとしては、不具合対応チケットのテンプレートをしっかり作っておくこと が挙げられます。
きっちりと『型』を決めておくことで、良かれと思って(?)AIが余計な情報を付け足したり、虚空からなにかを読み取って作文をしちゃったりといった、信頼性を下げる行動を取りにくくなります。
それでもたまに変な解釈が入ることがあるので、人間が最終判断するのが2025年冬時点では無難だと思います。

フォーマットがきっちり決まりきっていると、起票されたチケットを読み取る側のコストも軽くなります。三方よし、ですね。ヨシ！👈

次の展望

「発見フェーズ」や「不具合ランク」をチケットに記載することで、品質の可視化に役立ちます。
「10月はAランクが0件、Bランクが2件、本番環境で見つかった問題は0件なので品質は改善傾向にあります」みたいな感じです。
品質、コスト、リリース頻度のバランス(いわゆるQCD)を見る際にも定量評価できて役立つんじゃないかと思います。

もう一工夫したいこと

不具合発生時のスクリーンショットや動画などの、いわゆるエビデンスもチケット起票に付随させたいのですが、これが少し厄介です。スクリーンショットをテストNoと連動する名前にリネームし、 img/ にエビデンスがあります。ファイル名はテストNoと紐づいています。対応するチケットに添付してください みたいにプロンプトしないといけない。

おわかりいただけるだろうか……

これ、Claudeに作成してもらったチケットに、人間がエビデンスをぺいっと貼り付けるほうが楽です。お刺身にたんぽぽを乗せる職人の気分です。

なにか良い方法があれば知りたいです。