バグ報告をAIで整理するプロンプトテンプレート 再現手順・期待結果・優先度まで伝わる形にする
不具合を見つけたとき、開発者に伝わる報告にするには「何が起きたか」だけでは足りません。再現手順、期待した結果、実際の結果、発生環境、影響範囲までそろえると、確認や修正の初動が速くなります。
この記事では、ChatGPT、Claude、Gemini などの汎用LLMで使える、バグ報告整理用のプロンプトテンプレートを紹介します。対象は、開発チームに不具合を報告するビジネス担当者、CS、QA、ディレクター、プロダクト担当者です。
- 使い道: メモ書きの不具合報告を、開発者が確認しやすい形式に整える
- 出力形式: 箇条書き、チケット文面、Slack・メール共有文
- 向いている場面: Webサービス、業務システム、アプリ、管理画面の不具合報告
- 注意点: 個人情報、顧客情報、社内秘密は入力前に伏せる
ここがポイント: AIに「バグを直して」と頼むのではなく、開発者が再現確認できる材料に整理してもらうのが目的です。
何に使うプロンプトか
このテンプレートは、散らかった不具合メモを「開発チケットとして読める報告」に変えるためのものです。
たとえば、次のようなメモだけでは、受け取った側が確認に時間を使います。
- ログイン後に画面が変
- 注文一覧でエラーが出た
- スマホだとボタンが押せない
- たぶん昨日から発生している
これをAIにそのまま投げると、きれいな文章にはなっても、再現に必要な情報が抜けたままになることがあります。そこで、最初から「不足情報を指摘する」「報告形式を固定する」「推測と事実を分ける」と指示します。
完成イメージは、次のようなバグ報告です。
- 件名: 注文一覧で検索実行時に500エラーが表示される
- 発生画面: 管理画面 > 注文一覧
- 再現手順: ログイン、注文一覧を開く、検索欄に注文番号を入力、検索ボタンを押す
- 期待した結果: 対象の注文が一覧に表示される
- 実際の結果: 500エラー画面が表示される
- 発生環境: Chrome、Windows 11、管理者アカウント
- 影響: 注文確認作業が止まる
- 不足情報: 発生日時、他ブラウザでの再現有無、スクリーンショット
大事なのは、AIに結論を作らせすぎないことです。 不具合の原因推定よりも、まず事実を並べて、確認すべき点を明確にします。
コピペ用プロンプトテンプレート
以下をそのままコピーして、{} の部分を自分の状況に合わせて書き換えてください。
あなたは開発チームに伝わるバグ報告を整理するアシスタントです。
以下のメモをもとに、開発者が再現確認しやすい不具合報告に整えてください。
# 目的
- 不具合の内容を、事実と推測に分けて整理する
- 再現手順、期待結果、実際の結果、発生環境、影響範囲を明確にする
- 情報が足りない箇所は「不足情報」として質問形式で列挙する
# 入力情報
- 不具合メモ: {ここに手元のメモを貼る}
- 発生した画面・機能: {例: 管理画面の注文一覧}
- 利用環境: {例: Chrome / Windows 11 / スマートフォン / 社内VPNあり}
- 発生日時: {例: 2026年7月8日 10:30頃。不明なら不明}
- 操作した人の権限・役割: {例: 管理者、一般ユーザー、営業担当}
- 期待していた動作: {本来どうなるはずだったか}
- 実際に起きた動作: {画面表示、エラー文、止まった箇所など}
- 添付情報: {スクリーンショット、動画、ログ、URLなど。不明なら不明}
# 出力形式
次の見出しで整理してください。
1. 件名
2. 概要
3. 再現手順
4. 期待した結果
5. 実際の結果
6. 発生環境
7. 影響範囲
8. 事実として確認できていること
9. 推測・未確認のこと
10. 不足情報
11. 開発チームへの確認依頼文
# 制約
- 原因を断定しない
- 入力にない事実を作らない
- 個人情報や顧客情報が含まれる場合は、伏せ字にするよう注意書きを入れる
- 開発者が次に確認しやすいよう、短く具体的に書く
このテンプレートは、チケット管理ツールに貼る文面だけでなく、Slack やメールで一次報告するときにも使えます。
入力時に変える部分と固定したい部分
バグ報告では、毎回変える情報と、毎回固定したほうがよい指示を分けると出力が安定します。
毎回変える部分
次の項目は、報告する不具合ごとに差し替えます。
{不具合メモ}: 手元のメモ、問い合わせ文、スクリーンショットから読み取れる内容{発生した画面・機能}: どの画面、ボタン、処理で起きたか{利用環境}: OS、ブラウザ、端末、アプリ版、ネットワーク条件{発生日時}: 正確な日時。不明なら「不明」と書く{操作した人の権限・役割}: 管理者、一般ユーザー、顧客、社内担当者など{期待していた動作}: 本来どうなるはずだったか{実際に起きた動作}: エラー文、表示崩れ、処理停止、保存失敗など
ここで空欄を無理に埋める必要はありません。不明なものは「不明」と書いたほうが、AIが勝手に補う余地を減らせます。
固定したい指示
一方で、次の指示は毎回入れておくと便利です。
- 原因を断定しない
- 入力にない事実を作らない
- 事実と推測を分ける
- 不足情報を質問形式で出す
- 個人情報や顧客情報の扱いに注意する
特に「原因を断定しない」は重要です。報告者が「サーバー障害だと思う」と書いても、実際にはブラウザの拡張機能、権限設定、入力値、キャッシュなど別の要因かもしれません。AIには、推測を推測として残させます。
NG例と改善例
バグ報告プロンプトで失敗しやすいのは、AIに「いい感じにまとめて」とだけ頼むことです。
NG例
このバグ報告をわかりやすく直してください。
ログイン後に注文一覧を検索するとエラーになります。急ぎです。
この指示では、AIは文章を整えることはできますが、開発者が必要とする情報を十分に引き出せません。何を出力すべきか、どこまで推測してよいかも曖昧です。
改善例
以下の不具合メモを、開発チーム向けのバグ報告に整理してください。
# 不具合メモ
ログイン後、管理画面の注文一覧で注文番号を検索するとエラー画面になる。
Chromeで確認。昨日は使えていた気がする。急ぎで注文確認が必要。
# 出力してほしい項目
- 件名
- 概要
- 再現手順
- 期待した結果
- 実際の結果
- 発生環境
- 影響範囲
- 不足情報
# 注意
- 原因は断定しない
- 「昨日は使えていた気がする」は未確認情報として扱う
- 開発者が追加で確認すべき質問を最後に出す
改善例では、出力項目と注意点を先に決めています。そのため、AIは単なる文章修正ではなく、報告に必要な情報を整理できます。
出力を安定させるコツ
バグ報告は、整った文章よりも再現性が大事です。AIに頼むときは、見た目のきれいさより「確認できる情報が残ること」を優先します。
1. 「事実」と「推測」を分けさせる
不具合メモには、事実と推測が混ざりやすくなります。
- 事実: 検索ボタンを押すと500エラーが表示された
- 推測: 昨日のリリースが原因かもしれない
- 未確認: 他のブラウザでも起きるかは不明
これらを分けると、開発者は先に確認すべき情報を判断しやすくなります。プロンプトには、必ず「事実として確認できていること」と「推測・未確認のこと」を分ける指示を入れます。
2. 再現手順は番号付きにする
再現手順は、箇条書きより番号付きが向いています。
再現手順は、1、2、3の番号付きで書いてください。
1ステップに複数の操作を詰め込まず、画面遷移やボタン操作ごとに分けてください。
番号付きにすると、開発者が「3番の操作までは再現するが、4番では再現しない」と返しやすくなります。報告後のやり取りも短くなります。
3. 優先度は断定させず、判断材料を出す
AIに「優先度を決めて」と頼むと、実際の事業判断より強い表現になることがあります。おすすめは、優先度そのものではなく、判断材料を整理させる書き方です。
優先度は断定せず、判断材料として以下を整理してください。
- 影響を受ける利用者
- 止まっている業務
- 回避策の有無
- 発生頻度
- 売上、顧客対応、法務、セキュリティに関わる可能性
これなら、AIが勝手に「最優先」と言い切るのを避けつつ、担当者が優先度を決める材料をそろえられます。
4. 個人情報や機密情報を入れない
不具合報告には、顧客名、メールアドレス、注文番号、社内URL、ログ、スクリーンショットなどが含まれることがあります。AIに入力する前に、必要に応じて伏せ字にします。
例:
- 顧客名:
株式会社サンプル→{顧客A} - メールアドレス:
user@example.com→{メールアドレス} - 注文番号:
123456789→{注文番号} - 社内URL: 実URLではなく
{管理画面URL}
OpenAI、Anthropic、Google など主要な提供元も、AI利用時のデータ管理やプライバシーに関する説明を公開しています。業務で使う場合は、会社のAI利用ルールと合わせて確認してください。
活用例: 場面別の追加プロンプト
基本テンプレートに、場面別の一文を足すと実務で使いやすくなります。
Slackで一次共有したい場合
上記のバグ報告を、Slackで開発チームに共有する短い文面にしてください。
冒頭に結論を置き、詳細は箇条書きにしてください。
緊急度は断定せず、影響範囲と回避策の有無を判断材料として書いてください。
Slackでは、長い説明よりも「どの画面で何が止まっているか」が先に見えるほうが読まれます。詳細な再現手順は、後続のチケットやスレッドに置くと見やすくなります。
チケット管理ツールに登録したい場合
上記の内容を、チケット管理ツールに貼り付けやすい形式に整えてください。
件名は40文字以内を目安にし、本文は次の見出しで整理してください。
- 概要
- 再現手順
- 期待結果
- 実際の結果
- 発生環境
- 影響範囲
- 添付情報
- 不足情報
チケットでは、あとから検索しやすい件名が大事です。「エラーが出る」だけでなく、画面名と操作を入れると探しやすくなります。
顧客向けの返信文にしたい場合
上記の不具合報告をもとに、顧客向けの一次返信文を作ってください。
以下の条件を守ってください。
- 原因を断定しない
- 調査中であることを簡潔に伝える
- 追加で確認したい情報を3つ以内で質問する
- 技術用語を使いすぎない
- 謝罪表現は過度に重くしない
顧客向けの文面では、開発者向けの細かい再現手順をそのまま出す必要はありません。相手に確認してほしい情報と、次の対応予定が伝わる形に変えます。
障害報告の下書きにしたい場合
以下の不具合報告を、社内向けの障害報告の下書きにしてください。
ただし、原因が未確定の部分は「調査中」と明記してください。
出力項目:
- 発生日時
- 対象機能
- 影響範囲
- 現在の状況
- 暫定対応
- 未確認事項
- 次に確認すること
障害報告では、原因よりも「誰にどんな影響が出ているか」が先に必要です。未確定の情報を断定しないよう、プロンプト側で制限します。
JSON形式で出したい場合の追加指定
開発チームや自動化フローで使うなら、JSON形式で出力させる方法もあります。
上記のバグ報告を、次のJSON形式で出力してください。
値が不明な場合は空欄にせず、"不明" と入れてください。
入力にない事実は追加しないでください。
{
"title": "",
"summary": "",
"steps_to_reproduce": [],
"expected_result": "",
"actual_result": "",
"environment": {
"device": "",
"os": "",
"browser": "",
"app_version": ""
},
"impact": "",
"confirmed_facts": [],
"assumptions_or_unconfirmed": [],
"missing_information": [],
"questions_for_reporter": []
}
JSONで出す場合は、項目名を固定できるのが利点です。一方で、AIの出力は完全な機械処理に使えるとは限りません。システムに取り込む前提なら、JSONとして正しいか、人が確認する工程を残してください。
使う前のチェックリスト
最後に、AIへ投げる前と出力後に確認したい項目です。
- 個人情報、顧客情報、社内秘密を伏せたか
- 発生画面と操作が書かれているか
- 期待した結果と実際の結果を分けたか
- 再現手順が番号付きになっているか
- 「たぶん」「かもしれない」を推測として扱っているか
- 不足情報が質問として出ているか
- 原因や優先度をAIが断定していないか
- 開発チーム、顧客、社内共有のどれ向けの文面か分かるか
バグ報告の質は、文章のうまさよりも、次の人が同じ状況を確認できるかで決まります。AIには報告の型を整えさせ、最終的な事実確認と共有判断は人が行う。この分担にすると、報告の抜け漏れを減らしながら、開発チームとのやり取りを短くできます。