はじめに
「この900件超の不具合チケット、要因別に分類して定量分析してください」
品質改善計画の報告資料を作成するにあたり、こんなタスクが降ってきました。大規模Webサービスのリプレイスプロジェクトで、結合テストにて検出された不具合チケット約900件を、4つの根本要因に分類する必要がありました。
手作業で1件ずつ読んで分類すると、1件あたり1〜2分として少なくとも丸2日。しかも人によって判断がブレます。
そこでLLMを活用して自動分類に挑戦し、未分類ゼロ（100%分類） を達成しました。本記事では、その試行錯誤のプロセスを紹介します。
課題：チケット分類はなぜ難しいのか
プロジェクトの背景
あるWebサービスのフレームワーク刷新プロジェクトで、結合テストにて約900件の不具合が検出されました。品質改善計画を策定するため、これらを以下の4つの根本要因に分類する必要がありました。
| 要因 | 概要 |
|---|---|
| (a) 仕様理解不足 | テスト実施者が期待結果を正しく判定できなかった |
| (b) シナリオ陳腐化 | 古いテスト仕様書が現行仕様に追従していなかった |
| (c) 探索的テスト不足 | 定型シナリオ外の操作パターンをカバーできなかった |
| (d) 移行データ起因 | 新規作成データでは問題なかったが、移行データで問題が発生した |
なぜこの4つなのかというと、テスト工程のふりかえりで「どこで見逃したのか」を議論した際に、チームで合意した分類軸です。つまり、分類先のカテゴリは人間が設計し、900件の振り分け作業をLLMに任せる という分担です。
単純なキーワードマッチの限界
最初に思いつくのは、チケットの題名に含まれるキーワードで振り分ける方法です。
「移行」を含む → (d) 移行データ起因
「表示されない」を含む → (b) シナリオ陳腐化？ (a) 仕様理解不足？
ここが問題です。たとえば「一覧画面が表示されない」というチケットは、原因によって異なる要因に分類されるべきです。
- テスト仕様書のシナリオが古くて検知できなかった → (b) シナリオ陳腐化
- テスト担当者が正しい表示結果を知らずに見逃した → (a) 仕様理解不足
- 通常操作では問題ないが特定条件で発生する → (c) 探索的テスト不足
症状だけでは要因を判別できない のです。
Step 1: 素朴なキーワード分類（分類率 約60%）
まずはベースラインとして、キーワードベースの分類を試しました。
分類ルール（初版）:
- 題名に「移行」「データ移行」「移行データ」を含む → (d) 移行データ起因
- 題名に「仕様書」「テスト項目」を含む → (b) シナリオ陳腐化
- 題名に「特定条件」「組み合わせ」「エッジ」を含む → (c) 探索的テスト不足
- 上記いずれにも該当しない → 未分類
結果は惨憺たるものでした。
| 分類 | 件数 |
|---|---|
| 分類できた | 約550件（60%） |
| 未分類 | 約350件（40%） |
チケットの題名は「○○画面で△△が表示されない」「□□操作でエラーになる」のように、症状しか書かれていないものがほとんどです。題名から根本要因を直接読み取ることは困難でした。
Step 2: 「条件 × 症状」パターンの導入（分類率 約85%）
ここで発想を転換しました。
チケットの題名には、多くの場合 「条件部」と「症状部」 が含まれています。
[注文一覧] 特定カテゴリの商品で「該当データはありません」と表示される
^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
条件部 症状部
この構造に着目し、条件と症状の組み合わせ で分類する方式に切り替えました。
分類マトリクスの設計
LLMへの指示を「条件パターン」と「症状パターン」の2軸で構造化しました。
## 分類基準
### (a) 仕様理解不足と判定する条件
- 症状が「表示内容の正否」「データの反映状況」に関するもの
- かつ、条件が「通常のシナリオ操作」「基本的な画面遷移」であるもの
- → テスト担当者が「何が正しい表示か」を知っていれば検知できた
### (b) シナリオ陳腐化と判定する条件
- 症状が「基本機能が動作しない」「画面が表示されない」に関するもの
- かつ、条件が「標準的な操作手順」であるもの
- → テスト仕様書のシナリオに含まれているはずだが、
仕様書が古く確認観点がズレていた
### (c) 探索的テスト不足と判定する条件
- 条件が「特定の状態で○○した場合」「複数の操作を組み合わせた場合」
- → 定型シナリオでは想定していないパターン
### (d) 移行データ起因と判定する条件
- 条件に「既存データ」「移行データ」「過去に登録したデータ」が含まれる
- → 新規作成データでは発生しない
このマトリクスをプロンプトに組み込んでLLMに分類させたところ、分類率が一気に向上しました。
| 分類 | 件数 |
|---|---|
| 分類できた | 約770件（85%） |
| 未分類 | 約130件（15%） |
25ポイントの改善です。条件部に着目することで、「同じ症状でも文脈が違えば別の要因」という判断がLLMにもできるようになりました。
Step 3: 判定基準の明示と文脈推定（分類率 約95%）
残り15%の未分類チケットを分析すると、2つのパターンがありました。
パターン1: 題名が曖昧すぎるケース
「○○でエラーになる」
「△△が動作しない」
条件部も症状部も具体性が低く、パターンマッチングでは分類できません。
パターン2: 複数の要因に該当するケース
「特定のデータで画面表示が崩れる」
→ (c) 探索的テスト不足？ (d) 移行データ起因？
対策: 判定の優先順位を定義
LLMへのプロンプトに 「迷った場合の優先ルール」 を追加しました。
## 判定に迷った場合の優先ルール
1. 「移行」「既存データ」に関する言及がある → 最優先で (d)
2. 条件部に「特定の状態」「組み合わせ」がある → (c)
3. 症状が「基本機能の不具合」である → (b)
4. 上記いずれにも強く該当しない → (a) （最大のバケツ）
※ (a)は「テスト担当者が仕様を正しく理解していれば、
既存のテスト仕様書の範囲内で検知できたはず」という
消去法的な分類である。
特に重要だったのは (a) 仕様理解不足を「消去法的な分類」と定義した ことです。
他の3つの要因に明確に該当しない場合、テスト仕様書自体には確認観点があったのにテスト実施者が正しく判定できなかった、つまり仕様理解不足として分類します。これにより、曖昧なチケットも迷いなく分類できるようになりました。
| 分類 | 件数 |
|---|---|
| 分類できた | 約860件（95%） |
| 未分類 | 約40件（5%） |
Step 4: 残り5%の個別対応で100%達成
最後の約40件は、分類を阻んでいた具体的なパターンを特定し、追加ルールで対応しました。
追加ルールの例
## 追加判定ルール
- 多言語版（英語版等）固有の不具合で、日本語版では正常
→ (b) シナリオ陳腐化（多言語版のテストシナリオが未整備）
- API関連の不具合で、パラメータ指定に関するもの
→ (b) シナリオ陳腐化（APIのテストシナリオが現行仕様に追従していない）
- 認証・認可に関する不具合で、特定アカウント種別での不具合
→ (c) 探索的テスト不足（アカウント種別の組み合わせパターンが不足）
- 通知・配信関連の不具合で、配信条件に関するもの
→ (a) 仕様理解不足（条件の仕様を正しく理解できていなかった）
これらの追加ルールにより、ついに 全件の分類が完了 しました。
最終結果
約900件の不具合チケット → 4つの根本要因に100%分類
(a) 仕様理解不足 : 約430件（47%）
(b) シナリオ陳腐化 : 約330件（36%）
(c) 探索的テスト不足 : 約120件（13%）
(d) 移行データ起因 : 約30件（ 4%）
分類精度の推移
| ステップ | 手法 | 分類率 | 未分類 |
|---|---|---|---|
| Step 1 | キーワードマッチ | 60% | 約350件 |
| Step 2 | 条件×症状パターン | 85% | 約130件 |
| Step 3 | 判定基準の明示+優先ルール | 95% | 約40件 |
| Step 4 | 個別ルール追加 | 100% | 0件 |
定量分析がもたらした品質改善計画の説得力
この分類結果は、品質改善計画の定量的な根拠として活用されました。
Before: 定性的な報告
「テスト仕様書の見直しと再試験が必要です」
これだけでは、ステークホルダーから「なぜ？」「どのくらい？」と返されてしまいます。
After: 定量的な報告
「不具合約900件の定量分析の結果、最大の要因は "仕様理解不足"（47%・約430件）です。
テスト仕様書への期待結果の明確化により、この47%の再発を防止できます。
全4要因に対して追加試験・対策を計画し、不具合の100%をカバーします」
具体的には以下の4つの対策を、それぞれの要因に紐づけて提案できました。
| 対策 | 対応する要因 | カバー率 |
|---|---|---|
| (A) 移行データを用いた再試験 | 移行データ起因 | 4% |
| (B) 仕様書の古いシナリオの見直しと再試験 | シナリオ陳腐化 | 36% |
| (C) 主要業務フローでの実運用パターン試験 | 探索的テスト不足 | 13% |
| (D) テスト仕様書への期待結果の明確化 | 仕様理解不足 | 47% |
「なぜその対策が必要なのか」「その対策でどれくらいの不具合をカバーできるのか」を数字で示せたことで、ステークホルダーの納得感が大きく違いました。特に、最大要因（47%）への対策 (D) を新たに追加できたのは、定量分析があったからこそです。
実装のポイント
この手法を再現するための4つのポイントをまとめます。
1. 分類基準は「定義」ではなく「判定手順」で書く
LLMに分類基準を伝えるとき、抽象的な定義を渡しがちです。
NG例:
(a) 仕様理解不足: テスト実施者の仕様理解が不十分だったことに起因する不具合
これだと解釈の幅が広すぎて、LLMの出力が安定しません。代わりに、具体的な判定手順 を書きます。
OK例:
(a) 仕様理解不足と判定する手順:
1. 症状が「表示内容の正否」「データの反映状況」に関するものか確認
2. 条件が「通常のシナリオ操作」であるか確認
3. 両方YESなら → (a)
判定理由: テスト担当者が正しい表示結果を知っていれば、
既存のシナリオ内で検知できた
「何を確認して」「どう判定するか」をステップで示すと、LLMは安定した分類をしてくれます。
2. 「消去法カテゴリ」を1つ設ける
今回は (a) 仕様理解不足 を消去法カテゴリに設定しました。他の3要因に明確に該当しなければ (a) に分類するルールです。
これにより「どこにも入らないチケット」がなくなり、100%分類が可能になりました。
消去法カテゴリを設計する際のコツは：
- 最も件数が多くなる要因 に設定する（無理やり感が出にくい）
- 論理的に妥当な消去法ロジック を用意する（「他に該当しないから」だけでは説得力がない）
今回は「テスト仕様書の範囲内で検知できたはずだが、実施者の仕様理解が不十分で見逃した」という論理が成り立つため、消去法でも不自然さがありませんでした。
3. バッチ処理で一貫性を担保する
約900件を一度に処理すると、途中で分類基準がブレることがあります。50〜100件ずつのバッチに分割し、各バッチで同じプロンプトを使い回すことで一貫性を保ちました。
また、各バッチの分類結果をCSVで出力し、全バッチ完了後にクロス集計することで、特定の要因に偏りすぎていないかを検証しました。偏りがあった場合はプロンプトの判定基準を見直す必要があるサインです。
4. 分類結果は必ず人間がサンプルチェックする
LLMの分類はあくまで「判断補助」です。各要因からランダムに20件ずつ抽出して目視確認し、明らかな誤分類がないかチェックしました。
実際にこのサンプルチェックで「APIパラメータの不具合が (a) 仕様理解不足に分類されている」というケースが見つかり、Step 4の追加ルール（API関連 → (b) シナリオ陳腐化）に繋がりました。100%分類の精度は、この人間のフィードバックループなしには実現できなかった と思います。
おわりに
本記事のポイントをまとめます。
- 単純なキーワードマッチでは限界がある: チケットの症状だけでは根本要因を判別できない
- 「条件 × 症状」の組み合わせが鍵: チケット題名の構造を活かした分類が精度を大幅に向上させる
- 消去法カテゴリの設定で100%を達成: 曖昧なケースの受け皿を明示的に用意する
- 定性→定量の転換が品質報告の説得力を変える: 「全件分類」が対策の網羅性を数字で示す根拠になる
900件のチケットを手作業で分類する代わりに、LLMとの対話で分類ロジックを段階的に磨き上げるアプローチは、人間の判断力（分類基準の設計・サンプルチェック）とLLMの処理能力（大量チケットの一括分類）を組み合わせた協働 です。
最終的に重要なのは、LLMが100%分類できたことではなく、その定量データが品質改善計画という実際のアクションに繋がったことだと感じています。同じように大量チケットの分析に悩んでいる方の参考になれば幸いです。