バグ報告トリアージ
受け取った不具合報告を、そのまま開発チームに流す前に整理し、確認の優先順位を付けるためのプロンプトです。
想定用途
- サポート窓口から開発への一次連携
- QA 起票前の情報不足チェック
- 障害調査の初動整理
デモ動画
プロンプト本文
text
あなたはソフトウェア開発チームのトリアージ担当です。
以下のバグ報告を読み、事実ベースで整理してください。推測は「仮説」として明示してください。
出力要件:
- 1) 要約（3行以内）
- 2) 事実情報の整理（環境 / 再現手順 / 実際の結果 / 期待結果）
- 3) 不足情報（確認すべき質問を優先順で）
- 4) 再現性の見立て（高・中・低 + 理由）
- 5) 影響範囲の見立て（ユーザー影響 / 業務影響 / 技術影響）
- 6) 初期優先度案（P0-P3のいずれか + 理由）
- 7) 次のアクション提案（サポート・QA・開発それぞれ）
判断ルール:
- 情報不足が大きい場合は、優先度を断定しない
- セキュリティ/データ消失/課金影響の可能性があれば高優先で明記
- 回避策がある場合は書く
- ログの抜粋から読み取れることは、根拠付きで短く示す
入力:
- バグ報告本文:
- 発生環境:
- 再現手順:
- 実際の結果:
- 期待結果:
- ログ/スクリーンショット:
- 関連チケット:使い方
- 受領した報告をそのまま貼る
- 空欄は空欄のままでよい（不足情報として抽出させる）
- 生成結果をもとに、問い合わせテンプレートやチケット本文を整える
- 優先度はチーム基準に照らして最終決定する
入力例
text
- バグ報告本文: 管理画面の注文一覧でステータスを「発送済み」に変更すると、まれに画面が固まって保存されない。再読み込みすると変更前に戻ることがある。
- 発生環境: Windows 11 / Chrome 132 / 管理画面 v2.8.1
- 再現手順:
1. 注文一覧を開く
2. 任意の注文のステータスを「発送済み」に変更
3. 保存を押す
4. 数秒後にUIが応答しなくなることがある
- 実際の結果: ローディング表示のまま操作不能。ブラウザ再読み込み後、変更が反映されていない場合がある。
- 期待結果: 数秒以内に保存完了し、一覧に反映される
- ログ/スクリーンショット: フロントログに `PATCH /api/orders/{id}` が 504 の記録あり（2件）
- 関連チケット: INC-231, CS-882出力例
text
1) 要約
- 管理画面で注文ステータス変更時にUIが固まり、保存未完了になる事象の報告
- Chrome/Windows環境で発生、API 504ログの記録あり
- 注文更新処理またはAPIタイムアウト起因の可能性
2) 事実情報の整理
- 環境: Windows 11 / Chrome 132 / 管理画面 v2.8.1
- 再現手順: 注文一覧 > ステータス変更 > 保存
- 実際の結果: ローディング継続、操作不能、再読み込み後に未反映のケースあり
- 期待結果: 保存成功して一覧に反映
3) 不足情報（優先順）
- 発生頻度（何件中何件か）
- 特定注文条件の有無（件数、商品数、配送方法など）
- APIサーバーログの同時刻記録
- 他ブラウザ/他ユーザーでの再現性
4) 再現性の見立て
- 中: 手順は明確だが「まれに」のため条件未確定
5) 影響範囲の見立て
- ユーザー影響: 管理者が注文更新できない可能性
- 業務影響: 出荷処理遅延の可能性
- 技術影響: 注文更新APIのタイムアウト/ロック競合の疑い
6) 初期優先度案
- P1: 受注業務への影響があり、更新失敗の可能性があるため（データ消失ではなく未保存）
7) 次のアクション提案
- サポート: 発生時刻・対象注文ID・頻度を追加確認
- QA: ステージングで大量注文/同時更新条件の再現試験
- 開発: API 504発生時刻のサーバーログとDB待機状況を確認注意点
- LLM の優先度判断は補助であり、運用定義を上書きしない
- ログに個人情報・機微情報が含まれる場合はマスキングする
- セキュリティ事故の可能性がある場合は通常トリアージを飛ばして即時エスカレーションする
- 再現性が低い不具合ほど、発生条件の聞き返し設計が重要