不具合報告の書き方｜伝わる例文とコピペ用テンプレート

不具合報告とは？起きたことを調査する人へ伝える記録

不具合報告とは、システムで想定と違う動きを見つけたときに、起きたことや、そのときの条件をまとめて伝える記録です。「バグ報告」「不具合票」と呼ぶ職場もあります。

読む人が状況を把握し、同じ操作を試したり、原因を調べたりするために使います。修正後に、同じ問題が起きなくなったか確かめるときにも役立ちます。

原因や修正方法が分からなくても、報告できます。不具合かどうかも未確定なら、「不具合か確認したい」と添え、分かっている事実から伝えましょう。

不具合報告を書く流れ

画面の表示と発生日時を残したら、次の順番で整理します。職場に報告用の表や管理画面があれば、その項目に合わせてください。

1. 件名に、どこで何が起きたかを書く。
2. 起きたときの条件と、操作の順番を書く。
3. どうなるはずだったか、実際にどうなったかを分け、画像や影響を添える。

書き終えたら、チームで決められた相手・場所に報告します。データの消失や誤送信など、影響が広がりそうな場合は、書式を埋め終える前に連絡してください。確認のために同じ操作を繰り返さないようにします。

STEP1 件名は「画面・操作・起きたこと」で書く

件名には、どの画面で、何をしたら、何が起きたかを短く書きます。一覧で件名だけを読んでも、問題を見分けられる形が目安です。

• 伝わりにくい例：買い物サイトがおかしい
• 伝わる例：【注文確認画面】数量2を入力して進むと、1と表示される

「至急修正してください」だけでは、内容が分かりません。急ぐ理由は本文の影響欄に書き、緊急の連絡方法はチームのルールに合わせましょう。

STEP2 条件と操作手順を、他の人がたどれる形にする

同じ画面でも、使うアカウントや入力値が違うと、結果が変わることがあります。操作だけでなく、どこで、どんな状態から始めたかを残します。

起きたときの環境と、開始前の状態を書く

ここでいう「環境」は、アプリを動かした場所や組み合わせのことです。たとえば、テスト用サイトの接続先、アプリの版、WindowsなどのOS（端末を動かす基本ソフト）、Chromeなどのブラウザ名と版を書きます。

「最新版」だけでは、後から同じ状態を用意できません。版の番号は、アプリの情報画面などで確認できた値を記録します。確認場所が分からなければ「未確認」とし、担当者に聞いて構いません。

操作を始める前の状態は、「前提条件」と呼ばれる項目です。今回の例なら「テスト用の一般利用者でログイン済み。商品Aの数量入力画面で、数量は1」と書きます。パスワードを報告欄に書く必要はありません。

再現手順は、1行に1つの操作を目安にする

「再現」とは、同じ条件で試したときに、同じ現象が起きることです。そのための操作を「再現手順」といいます。

「数量を変えて進む」では、入力した数字や押したボタンが分かりません。次のように書くと、相手が迷わずたどれます。

1. 商品Aの数量欄に入っている「1」を消す。
2. 数量欄に半角数字の「2」を入力する。
3. 「確認へ進む」ボタンを押す。

手順を短くするために、入力値やボタン名まで省かないことが大切です。先にログインやデータの準備が必要なら、開始前の状態に添えます。

STEP3 期待した結果と実際の結果を分ける

「どうなるはずだったか」を期待結果、「本当に起きたこと」を実際の結果として、別々の欄に書きます。

• 期待結果：注文確認画面の数量欄に「2」と表示される。
• 実際の結果：注文確認画面に進むが、数量欄には「1」と表示される。

期待結果の根拠も添えましょう。システムの動きの決まりを記した仕様書や、確認内容をまとめたテストケースの、資料名・版・該当項目を書きます。決まりが不明なら、自分の予想を確定事項にせず「期待する動きは確認中」と伝えます。

画面で見た事実と、原因の推測を分ける

「数量が1と表示された」は、確認した事実です。一方、「数量を保存する処理が壊れている」は、原因についての推測です。画面を見ただけでは、データの保存まで間違っているとは言い切れません。

推測を書く場合は「原因の候補」として分けます。思いつかなければ、無理に書かなくて大丈夫です。手順・期待結果・実際の結果を明確にし、観察したことと推測を区別する考え方は、Mozillaの不具合報告ガイドでも示されています。

画像・発生回数・影響を添える

画面を画像として保存したものを「スクリーンショット」といいます。結果が分かる画像を添え、「手順3の後。注文確認画面の数量欄」と説明すると、どこを見ればよいか伝わります。画像だけにせず、表示された値やエラー文面も本文へ書いておきましょう。

同じ操作を試してよい場合は、開始前の状態に戻して確かめ、結果を回数で残します。「初回と再確認1回の両方で発生」のような書き方です。再確認していないなら「初回のみ確認、再確認は未実施」とします。1回見ただけで「必ず起きる」とは書きません。

影響欄には、「数量2の確認ができず、このテストを中断している」のように、実際に困っていることを書きます。他の利用者や本番にも起きるかは、調べていなければ「未確認」です。

不具合報告の記入例とコピー用テンプレート

以下は、説明用に作った買い物サイトの報告例です。日時・資料名・アプリの版などは架空で、実際に発生した不具合ではありません。

記入例：数量2が、確認画面で1と表示される

件名：【注文確認画面】数量2を入力して進むと、1と表示される

発生日時：2026年9月13日 10:20ごろ（日本時間）
対象：テストケース TC-001／商品Aの数量入力から注文確認まで
環境：チーム指定のテスト用サイト
アプリの版：検証版0.9.0
端末・ブラウザ：Windows 11／Chrome（版の番号は未確認）

開始前の状態：
テスト用の一般利用者でログイン済み。
商品Aの数量入力画面を開き、数量は1。エラー表示なし。

操作手順：
1. 数量欄の「1」を消す。
2. 半角数字の「2」を入力する。
3. 「確認へ進む」を押す。

期待結果：注文確認画面の数量欄に「2」と表示される。
根拠：注文画面仕様書 第1版「数量の引き継ぎ」／TC-001
実際の結果：注文確認画面に進むが、数量欄に「1」と表示される。
エラーメッセージは出ていない。

発生回数：初回と再確認1回の両方で発生（計2回中2回）。
再確認は数量入力画面を開き直し、開始前と同じ状態で実施。
影響：数量2の表示確認ができず、TC-001を中断。
注文確定の操作は行っていない。

添付予定：手順2の後の入力画面、手順3の後の確認画面。
未確認：他の商品、他のブラウザ、本番での発生有無。
保存されたデータの確認はしておらず、原因は不明。
依頼：原因の調査と、関連するテストを続けてよいかの判断をお願いします。

実際の報告では、テスト用サイトを取り違えないよう、社内で共有できる接続先URLや環境名まで記入します。「添付予定」は、画像を付けた後で実際のファイル名に書き換えてください。

コピーして使えるテンプレート

角括弧の中を、自分の状況に置き換えます。確認していない項目は「未確認」、試していない操作は「未実施」と書けば、空欄より状況が伝わります。

件名：【画面・機能名】［操作］すると［起きたこと］
発生日時：［日付・時刻・時刻の基準］
対象：［テスト番号／画面・機能］
環境：［テスト用・本番の別、接続先、アプリの版］
端末・ブラウザ：［OS、ブラウザ名と版など］

開始前の状態：［利用者の種類、画面、データの状態］
操作手順：
1. ［具体的な操作］
2. ［入力する値や押すボタン名］
3. ［結果が出るまでの操作］

期待結果：［どうなるはずか］
根拠：［資料名・版・該当項目／確認中］
実際の結果：［表示・値・エラー文面など］
発生回数：［試した回数と発生回数／再確認は未実施］
影響：［止まっている作業、確認できた影響範囲］
添付：［画像や記録のファイル名と、何を示すか］
確認済み・未確認：［試したことと結果／未確認のこと］
依頼：［調査・判断してほしいこと］

職場の書式に「重要度」「優先度」がある場合、重要度は問題の影響の大きさ、優先度は対応する順番の目安です。区分や決める担当者は職場ごとに異なるので、基準に従います。迷ったときは、作業が止まっている範囲などの事実を添えて相談しましょう。

完成した報告書の見本を見たい方へ

目次・操作手順・結果・影響のまとめ方を、記入済みのサンプルPDFで確認できます。全3ページで、1ページ目が目次例、2〜3ページ目が報告書の記入例です。

　
※架空の不具合を使った記入例です。職場の書式に合わせて参考にしてください。短い報告では、目次ページを省略して構いません。

報告前に気をつけたいこと

別の問題を、1つの報告に詰め込まない

数量の表示違いと、別の画面のログイン失敗など、別々に確認・修正する問題は報告を分けます。同じ原因かは、まだ分からないためです。関連しそうなら、相手の報告番号を添えてつなげます。

登録前には、同じ画面名や現象で既存の報告を探します。似た件名でも条件が違うことがあるので、本文も確認してください。同じ問題か迷ったら、既存の番号を添えて担当者に相談します。

添付画像やログの共有範囲を確かめる

ログとは、システムの動作を残した記録です。画像やログに、氏名・メールアドレス・パスワードなどが含まれていないか確認し、チームのルールに従って共有します。

必要な情報を勝手に消して元の記録を失わないよう、原本は指定の場所に保管し、共有用のコピーで隠す方法もあります。社内の報告だからといって、閲覧できる人が多い場所へそのまま貼らないようにしましょう。

書き終えたら、読む人の立場で確認する

• 画面名・入力値・ボタン名が具体的で、操作の順番が分かるか。
• 期待結果と実際の結果が別々に書かれ、違いが分かるか。
• 未確認のことを、確認済みのように書いていないか。
• 添付が開けるか、画像と説明が対応しているか。
• 誰に何を確認してほしいかが分かるか。

報告後に追加で分かったことは、元の記録を消さず、確認日時と条件を添えて追記します。テスト結果の記録にも報告番号やリンクを残すと、後から対応状況をたどれます。

よくある疑問

一度しか起きず、再現しない場合も報告してよい？

報告して大丈夫です。「初回のみ発生。再確認1回では発生せず」のように、回数と結果を正直に書きます。初回の日時・操作・画像が、調査の手がかりになります。再現するまで延々と試す必要はありません。

原因が分からないと、報告してはいけない？

原因不明のまま報告できます。「ここまでは確認した」「ここから先は未確認」を分けて伝えましょう。不具合か判断できない場合も、その旨を添えて相談できます。

チャットで短く伝えるだけでもよい？

最初の連絡には使えます。たとえば「テスト用の注文確認画面で、数量2を入力すると1と表示されます。TC-001を中断しています。詳細は報告番号○○です」と伝えます。

詳細の保存先は、チームのルールに合わせます。チャットだけで流れてしまわないよう、正式な報告が必要なら後から記録を残しましょう。緊急時は指定の連絡経路を使ってください。

まとめ・関連記事

不具合報告は、条件・操作・期待した結果・実際の結果をそろえると伝わりやすくなります。画像や発生日時、作業への影響を添えれば、調査する人が状況を把握しやすくなります。

最初から原因を言い切る必要はありません。まずはテンプレートを使い、手元で確認できた事実から1件書いてみましょう。

• テストで想定と違う結果が出たら？不具合か判断できないときの確認手順：報告前に、何を確かめればよいか迷ったときに。
• テストケースの書き方｜入力値・操作手順・期待結果を具体例で解説：操作や期待結果の根拠になる、テストの計画を整理したいときに。
• エラーログの読み方｜初心者が最初に確認するポイント：報告に添える動作記録の、見る場所を知りたいときに。