バグ報告で気をつけること｜伝わる7つの作法

2026 8/24

2026年8月24日 2026年8月24日

テストを任され始めて、バグを見つけられるようにはなってきた。けれど報告を書くと、開発者から「これだけだと再現できない」「結局どうなればいいの？」と聞き返される。この往復に悩む方は少なくありません。この記事では、バグ報告で気をつけることを7つの作法に整理し、差し戻しを減らして開発者が一発で着手できる書き方を、具体例つきで解説します。

バグ報告で気をつけることの全体像 ― なぜ差し戻しが起きるのか

はじめに、報告がなぜ差し戻されるのか、その構造を押さえておきましょう。ここが腑に落ちると、7つの作法の一つひとつが「なぜ必要か」でつながります。

差し戻しが生まれる構造

バグ報告の差し戻しは、書き手の能力不足ではなく「情報の欠け方」に原因があります。報告を受け取った開発者は、あなたの頭の中を見ることができません。あなたにとって当たり前の前提が抜けるだけで、再現の糸が切れてしまいます。

「再現できない」と返ってくるのは、多くの場合、操作の途中経過やデータの状態が省略されているからです。「結局どうなればいい？」と聞かれるのは、期待する結果が書かれていないからです。

つまり差し戻しは、あなたと開発者のあいだにある「情報の段差」から生まれます。この段差を埋めることが、報告を書くうえでの出発点になります。

差し戻しには、もう一つ見落としやすいコストがあります。1回の聞き返しで失われるのは数分ではありません。開発者は他の作業を中断して確認し、あなたは記憶をたどって追記し、また相手が読み直します。この往復が数回続くと、1件のバグに半日以上かかることもめずらしくありません。最初の報告に手間をかけることは、結果的にチーム全体の時間を守ることにつながります。

良い報告とは「一発で着手できること」

良い報告とは、飾った文章のことではありません。良いバグ報告とは、開発者が読んだだけで一発で再現・着手できる報告のことです。この基準を軸にすれば、何を書き足すべきかが自然に見えてきます。

報告に臨む姿勢も大切です。高橋寿一氏の『知識ゼロから学ぶソフトウェアテスト』第1章では、G. J. Myersの格言として「エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない」が紹介されています。バグは必ずあるという前提に立つからこそ、見つけた欠陥を丁寧に、確実に開発者へ手渡す報告が意味を持ちます。

7つの作法の一覧

この記事で扱う7つの作法と、それぞれが解決する悩み、対応するセクションを最初に整理しておきます。以降の本文と一対一で対応しています。

#	7つの作法	読者の悩み	対応セクション
1	再現手順は粒度をそろえる	どこまで細かく書けばいい？	再現手順の粒度と「1バグ1報告」
2	1件の報告に1つのバグだけを書く	複数の不具合をまとめてしまう	再現手順の粒度と「1バグ1報告」
3	タイトルで一覧から判別できるようにする	一覧で内容が伝わらない	タイトルの付け方と事実・推測の分離
4	事実と推測を分ける	推測が事実に紛れて混乱を招く	タイトルの付け方と事実・推測の分離
5	環境・期待結果・実際の結果・エビデンスをそろえる	書き方が我流で不安	環境情報・期待結果と実際の結果
6	開発者を責めず、現象を主語にする	責めていると受け取られないか心配	開発者を責めず、事実ベースで書く
7	重要度と優先度を事実で示す	どう判断して伝えればいい？	重要度と優先度の伝え方

以降のセクションでは、この7つの作法を順に、具体例とともに掘り下げていきます。

再現手順の粒度と「1バグ1報告」

再現手順は、バグ報告の心臓部です。ここが曖昧だと、他がどれだけ丁寧でも開発者は動けません。まずは書き方の骨格から整えていきましょう。

前提・操作・データの3分割

粒度の基準として、まず3つの要素を分けて書くことを意識してください。

前提条件：ログイン状態、使用アカウント、対象データの状態など「操作を始める前の状況」
操作ステップ：番号を振り、1ステップ1操作で「何を押し、何を入力したか」
使用データ：入力した具体的な値、選択した項目、アップロードしたファイルの種類

この3つを混ぜて一続きの文章にすると、読み手が状況を再構成できません。逆に分けて書くだけで、再現性は大きく上がります。前提条件は特に抜けやすいので、「相手は何も知らない状態から始める」と想像しながら書き出すのがコツです。

粒度のチューニング（粗すぎ・細かすぎ）

粒度のチューニングは、「粗すぎ」と「細かすぎ」の両極を避ける作業です。

粗すぎる例：「予約画面でエラーが出る」→ どの操作で、どんなデータで出たのか不明
細かすぎる例：「マウスを画面右上に移動し、青いボタンにカーソルを合わせ…」→ 本質と無関係な描写でノイズになる
ちょうどよい粒度：「予約画面で日付に過去の日付を入力し、予約ボタンを押すとエラー」→ 誰が読んでも同じ操作を再現できる

布施昌弘氏らの『ソフトウェアテスト教科書』Part3では、記述の粒度を「誰が読んでも同じ解釈ができるレベル」と表現しています。再現手順の粒度は、読み手によって解釈が割れないかどうかで判断するのが最も確実です。

「1バグ1報告」と、追記か新規かの判断

もう一つ重要なのが「1バグ1報告」の原則です。1つの報告に複数の不具合を詰め込むと、修正の一部だけ対応されて残りが宙に浮いたり、ステータス管理が破綻したりします。1つの報告には1つのバグだけを書くことで、差し戻しも管理コストも確実に減らせます。

既存チケットに追記すべきか、新規で起こすべきか迷ったときの判断軸も整理しておきます。

報告前にまず既存チケットを検索する：同じ症状がすでに報告されていないかを確認する
重複していたら新規で起こさずリンクする：「同様の症状を確認」とコメントし、既存チケットへ情報を寄せる
似た症状でも原因や画面が違えば別チケットにする：見た目が近くても、発生箇所や条件が異なれば別のバグとして扱う

報告前に既存チケットを検索するだけで、重複報告（デュープ）による混乱と二重対応を防げます。

各項目の具体的な書式やテンプレートの中身は、バグ票の項目とテンプレートを確認するで詳しく整理しています。型が手元にあると、粒度の判断も安定します。

タイトルの付け方と事実・推測の分離

再現手順が整ったら、次はチケットの「入口」であるタイトルと、報告全体の情報整理に目を向けます。

一覧で判別できるタイトルの型

チケット一覧で最初に目に入るのはタイトルです。ここが弱いと、開発者は中身を開くまで内容を判断できず、優先順位づけも滞ります。タイトルは「画面・操作・症状」の3要素で組み立てると、一覧のまま判別できます。

悪い例：「バグです」「エラー」「動きません」→ 何も伝わらない
悪い例：「予約がおかしい」→ 主観的で範囲が不明
良い例：「予約確認画面で、過去日を指定すると予約完了できてしまう」→ 画面・操作・症状が一目でわかる

タイトルは「どの画面で・何をすると・どうなるか」を一行に収めると、一覧のまま判別できます。

事実と推測を分ける

次に、報告全体を通して守りたいのが「事実」と「推測」の分離です。テストで実際に観測したことと、あなたが頭の中で立てた原因の仮説は、性質がまったく違います。これを混ぜると、開発者は事実確認からやり直すことになります。

仕分けの基準はシンプルです。

事実：画面に表示された文言、実際に押したボタン、返ってきたエラーコード、目で見た挙動
推測：「たぶんキャッシュが原因」「APIのタイムアウトかもしれません」といった原因の仮説
仕分けのコツ：スクリーンショットや録画で裏づけられるものが事実、頭の中の想像は推測

推測はラベリングで価値になる

推測は書いてはいけないものではありません。むしろ現場を最もよく見たテスターの仮説は、調査の手がかりになります。大切なのはラベリングです。

「※以下は推測です」と一言添えるだけで、開発者は事実と切り分けて読めます。推測は消すのではなく、「推測」と明示すれば調査のヒントという価値に変わります。事実に紛れ込ませないことだけを守ってください。

環境情報・期待結果と実際の結果・エビデンス

「自分の環境では再現しない」という差し戻しの多くは、環境情報の欠落が原因です。ここでは、報告の正確さを支える4つの要素を順に見ていきます。

環境情報チェックリスト

同じ操作でも、OSやブラウザ、アカウントの種別が違えば結果は変わります。報告には、再現に関わりうる環境を添えるのが基本です。

項目	記載する内容の例
OS	Windows / macOS / iOS / Android などと版
ブラウザ・アプリ	種類とバージョン
対象環境	検証環境か本番相当か、URLの区別
アカウント種別	管理者／一般ユーザー／ゲスト等の権限
発生日時	いつ操作したか（ログ突合に必要）
対象データ	使用したテストデータの識別情報

すべてを毎回埋める必要はありませんが、再現条件に関わる環境情報が1つ欠けるだけで、開発者は再現に到達できなくなります。

期待結果と実際の結果を対で書く

正確さのもう一つの柱が、「期待結果」と「実際の結果」を対で書くことです。片方だけでは、開発者は「何が正しい状態なのか」を判断できません。

期待結果：仕様上こうなるはず、という正しい振る舞い（例：過去日はエラーで予約不可）
実際の結果：実際に起きたこと（例：過去日でも予約が完了した）
対で書く理由：ギャップが明確になり、修正のゴールが一意に決まる

期待結果を書くときは、「仕様書のどこにそう書いてあるか」を一言添えると、さらに説得力が増します。仕様が曖昧で判断に迷う場合は、期待結果を断定せず「仕様上の期待が不明のため要確認」と書くのが誠実です。事実（実際の結果）だけは必ず正確に残し、正しさの判断は仕様の確認待ちにしておく。この線引きができると、仕様の解釈違いによる差し戻しも減らせます。

エビデンスとスクリーンショットの作法

エビデンス（証拠）の添え方にも作法があります。目的に応じて使い分けると、余計なやり取りが減ります。

スクリーンショット：エラー画面や表示崩れなど「一瞬の状態」を示すのに最適
ログ：エラーコードやスタックトレースなど「内部で起きたこと」を示す。日時が突合の鍵
動画・GIF：操作の順序が重要なとき、再現の流れをそのまま見せられる

スクリーンショットには、そのまま使える基本の作法があります。

全画面か部分かを目的で選ぶ：文脈が要るなら全画面、要点だけなら該当部分を切り出す
赤枠や矢印で該当箇所を示す：どこを見てほしいのかを迷わせない
URLバーや日時を含める：どの環境の、いつの状態かが一目で伝わる
個人情報や他案件の情報はマスキングする：無関係な情報は黒塗りで隠す

報告に添えたい基本項目

こうしたエビデンスに加えて、報告（インシデントレポート）には管理上の基本要素があります。一意なID、報告者、検出したテストフェーズ、ステータス、既知の回避策、そして再現性の区分（毎回／散発／1回のみ／再現不可）などです。各項目の網羅的な書式は、前掲のバグ票の項目とテンプレートを確認するに委ねますが、「誰が・いつ・どの段階で見つけ、いまどの状態か」を残す意識を持っておくと報告が締まります。

布施氏らの『ソフトウェアテスト教科書』では、要件→仕様→テスト→結果を紐づける「追跡性」の重要性が説かれています。報告における環境・期待結果・エビデンスは、この追跡性を報告の粒度で担保する仕組みだと考えると腑に落ちます。なお、用語の意味に迷ったときはJSTQBの用語集など公的な定義を確認すると、チーム内で言葉の解釈がぶれません。

開発者を責めず、事実ベースで書く

バグ報告は、開発者の仕事を否定する場ではありません。しかし書き方ひとつで、意図せず「責めている」印象を与えてしまうことがあります。角が立つ報告は、往復を増やし、チームの空気も悪くします。

感情語・断定・皮肉を避ける

まず避けたいのが、感情語・断定・皮肉です。事実の記述に置き換えるだけで、同じ内容がずっと伝わりやすくなります。

NG表現	言い換え例
「画面がひどい」	「ボタンが枠からはみ出して表示される」
「完全に壊れている」	「予約ボタンを押しても反応せず、画面が変わらない」
「なんでこうなるんですか？」	「期待結果と実際の結果に差異があります」
「またこのバグですか」	「同様の症状を〇〇画面でも確認しました」

主語を人でなく現象にする

コツは、主語を「人」ではなく「現象」にすることです。「あなたのコードが」ではなく「この画面の挙動が」と書くだけで、報告は個人攻撃ではなく事実共有になります。

主語を人ではなく現象（バグ・挙動）にするだけで、報告は非難ではなく事実共有に変わります。

チャットでの即時報告の作法

緊急のバグは、チケットを起こす前にSlackなどのチャットで一報を入れる場面もあります。このときも型を押さえると、伝達ミスを防げます。

要点を先に書く：「予約が過去日でも完了してしまいます」と結論から始める
チケットURLを添える：詳細はチケットに集約し、チャットは入口にとどめる
緊急時の一報の型：「【要確認】どの画面で・何が起きたか・影響範囲」を一行で

チャットは速報、チケットは正式な記録、と役割を分けると、情報が散らばりません。

心理的安全性が品質に効く

こうした配慮は、単なるマナーではありません。安心して指摘し合える関係、いわゆる心理的安全性は、報告文化そのものを支えます。責められると人は防御的になり、バグを隠したり、報告をためらったりします。

事実ベースで淡々と、しかし敬意をもって書く。この積み重ねが、結果的にチーム全体の品質を押し上げます。伝え方をさらに磨きたい方は、開発チームとのコミュニケーションロスを減らす方法を読むもあわせて参考にしてください。

重要度と優先度の伝え方

7つ目の作法は、重要度と優先度を事実で示すことです。ここは誤解が多く、テスターが最もつまずきやすい領域なので、丁寧に整理します。

重要度(Severity)と優先度(Priority)は別物

「重要度」と「優先度」は、似ているようで別物です。ここを混同すると、報告を受けた側の判断が狂います。

重要度（Severity）：そのバグが与える影響の大きさ。データ消失や機能停止は高く、軽微な表示崩れは低い
優先度（Priority）：どの順番で対応すべきか。リリース時期やユーザー数など、状況で変わる

重要度は影響の大きさのみで判定し、再現頻度とは独立して決まります。業務やデータに致命的なバグは、めったに起きなくても重要度は高いのです。発生頻度の低さは「起きにくさ」であって、「起きたときの深刻さ」を下げるものではありません。

影響度×再現頻度で「対応リスク」を見立てる

では、テスターは何を材料に示せばよいのでしょうか。影響度と再現頻度という2つの事実をそろえると、対応の優先順位づけ（トリアージ）の見立てが立てやすくなります。ただし、この掛け合わせが示すのは重要度そのものではなく、あくまで対応リスクの目安である点に注意してください。

影響度＼再現頻度	毎回発生	ときどき発生	まれに発生
業務・データに致命的	対応リスク：高	対応リスク：高	対応リスク：中
一部機能が使えない	対応リスク：高	対応リスク：中	対応リスク：中〜低
表示崩れ等の軽微	対応リスク：中	対応リスク：低	対応リスク：低

この表の「高・中・低」は、対応リスク（トリアージの優先度の目安）であって、重要度の確定値ではありません。テスターは影響度と再現頻度という事実をそろえて示し、最終的な確定はトリアージで調整されます。

Lee Copeland氏の『ソフトウェアテスト技法』第15章には、「欠陥が生じた場合に顧客にどんな影響を与えるか、そして最終的には自分の組織にどんな影響があるかも、常に評価することを忘れないでください。影響の小さい欠陥は、追跡して修正する必要性が薄いのです」とあります。重要度の判断は、こうした影響の見立てに支えられています。

再現できないバグの切り分けと再現性の区分

再現頻度を事実として示すには、再現性の切り分けが欠かせません。「10回試して2回発生」のように、試行N回中M回という形で記録するのが基本です。再現条件を絞り込むときは、次の観点を一つずつ潰していきます。

データ状態：特定のデータでのみ起きるのか
タイミング：連続操作や待ち時間で変わるのか
キャッシュ：再読み込みやシークレットウィンドウで消えるのか
並行操作：他の操作と同時に行うと起きるのか
環境差：別のOS・ブラウザ・権限で再現するのか

どうしても再現しないときも、報告する価値はあります。再現不可の場合は、発生時刻・ログ・録画・直前の操作といった手がかりをできるだけ多く残してください。優先度づけの流れはバグ修正の優先度を決めるプロセスを詳しく見るで詳しく解説しています。

良いバグ報告の完成サンプルと報告後の流れ

ここまでの7つの作法を、1件の報告に落とし込むとどうなるのか。そのまま真似できる完成サンプルと、Before/After、そして報告後の流れを見ていきます。

そのまま真似できる完成サンプル

題材は「予約確認画面で、過去日でも予約完了できてしまう」バグです。実際のチケット体裁で、各欄を埋めた1枚を示します。

タイトル：予約確認画面で過去日を指定すると予約完了できてしまう
前提条件：検証環境にログイン済み／一般ユーザー権限／予約可能な商品が1件以上ある状態
再現手順：
トップから予約画面を開く
予約日に前日（過去日）を入力する
内容を確認し、予約ボタンを押下する
期待結果：過去日はバリデーションエラーとなり、予約は完了しない
実際の結果：過去日のままエラーが出ず、予約が完了してしまう
環境：検証環境（該当URL）／対象ブラウザと版／該当日時を明記
エビデンス：入力画面と完了画面のスクリーンショットを添付（該当箇所を赤枠、日時を含める）
再現性：5回試行し5回とも発生（毎回）
重要度(影響)：中（誤った予約データが確定するが復旧は可能）／対応リスク：高
※推測：日付の下限バリデーションが未実装の可能性（未確認・要調査）

各欄が埋まった1枚があれば、開発者は事実確認をやり直さず、その場で着手に入れます。

同じバグのBefore→After

同じバグでも、書き方でここまで変わります。7つの作法を反映した改善例です。

項目	NG（Before）	改善（After）
タイトル	予約がバグってる	予約確認画面で過去日を指定すると予約完了してしまう
再現手順	適当に日付入れたら通った	1.ログイン 2.予約画面へ 3.日付に前日を入力 4.予約ボタン押下
期待・実際	おかしい	期待：過去日はエラーで予約不可／実際：予約が完了する
環境	（記載なし）	検証環境／一般ユーザー権限／該当日時を明記
エビデンス	（なし）	完了画面のスクリーンショットを添付
重要度・対応リスク	ヤバい	重要度(影響)：中／再現頻度：毎回 → 対応リスク：高
文面トーン	なんでこんな作りに？	事実のみを記述、原因の推測は「※推測」と明示

報告後のライフサイクル

報告は出して終わりではありません。バグは一般に、次の流れをたどります。

起票：テスターが事実をそろえて報告する
修正：開発者が原因を特定し、コードを直す
再テスト：修正版でテスターが再確認し、直っていればクローズする

ただし、すべてが修正で終わるわけではありません。再現不可・仕様通り・重複といった理由でクローズされることもあります。「仕様通り」でクローズされたときは、報告が無駄だったわけではありません。仕様への疑問を可視化できたこと自体に価値があります。納得できなければ、仕様の意図を確認する良い機会にもなります。

大切なのは、修正されたと聞いても、確認するまで「直った」と決めつけないことです。修正が別の箇所に影響していないか、周辺の機能まで含めて再確認する。いずれの場合も、テスターの役割は再テスト（回帰確認）まで続きます。報告後の追跡まで含めた全体像は欠陥管理プロセスの流れを把握するが参考になります。品質や欠陥データの客観的な傾向は、IPAのソフトウェア開発分析データなどの公的資料も判断の後ろ盾になります。