バグ票の書き方｜再現手順が伝わる項目とテンプレート

2026 7/15

2026年7月15日

「このバグ、再現しませんでした」——開発者からそう返ってきて、テスト担当者との間で何往復もやり取りが続いた経験はないでしょうか。

不具合そのものよりも、不具合を伝える1枚のバグ票（不具合報告書）の書き方が原因で、修正が遅れることは珍しくありません。書いた本人には自明でも、読み手には状況がまったく伝わっていないのです。

この記事では、開発者や顧客に正確に伝わるバグ票の書き方を、必須の項目構成・再現手順の記述・良い例と悪い例・そのまま使えるテンプレートまで、実務で使える粒度で解説します。少人数で兼任中心のテスト体制でも、今日から標準化できる内容にまとめました。

バグ票は「不具合の記録」ではなく「相手を動かすための文書」です。この視点を持つだけで、書き方は大きく変わります。

なお、欠陥の発見から修正・クローズまでの一連の流れ全体は、欠陥管理プロセスの全体像を解説した記事で扱っています。本記事はそのなかの「1枚のバグ票をどう書くか」に絞って掘り下げます。

バグ票の書き方が開発と顧客対応を左右する理由

バグ票は、テスト担当者と開発者、そして時には顧客をつなぐ「共通言語」です。ここでのすれ違いは、そのままプロジェクト全体の遅延やコストに跳ね返ります。

受託開発では、社内のやり取りだけでなく、顧客への不具合報告や納品物としての品質記録にもバグ票が使われます。つまりその記述の質は、開発効率だけでなく顧客からの信頼にも直結します。

曖昧なバグ票は「情報の往復」でコストを増やす

再現手順が書かれていないバグ票は、開発者に「どうやって出たのか教えてください」という質問を生みます。この1往復に半日かかることもあります。

バグ票1枚の記述が不十分なだけで、1件あたり数十分〜数時間の確認コストが発生します。これが数十件たまれば、無視できない工数になります。

「再現しない」と差し戻され、再調査が発生する
前提条件が抜けており、開発者が別環境で確認して見落とす
期待結果が書かれておらず「仕様通りでは？」と判断が保留される

良いバグ票がもたらす3つの効果

きちんと書かれたバグ票は、次のような効果を生みます。

効果	具体的な内容
修正の高速化	開発者が再現・原因特定にすぐ着手できる
判断の明確化	重要度・優先度が伝わり、対応順序で迷わない
品質の証跡化	顧客への報告や再発防止の分析データになる

書籍『テスト教科書』（布施昌弘）でも、不具合報告書では再現性・重要度・優先度を明記することが重視されると整理されています。この3点は、バグ票の骨格そのものだと考えてよいでしょう。

受託開発ではバグ票が「顧客への説明資料」になる

自社プロダクトの開発と違い、受託開発では顧客への報告義務がついて回ります。テスト工程で見つけた不具合を、いつ・どう伝え、どう対応するかは、そのまま顧客満足に影響します。

このとき、社内向けの雑なメモのようなバグ票では、顧客に転用できません。第三者が読んでも理解できる粒度で書いておけば、報告資料としてほぼそのまま使えます。

バグ票を「開発者にも顧客にも通じる文書」として書いておくと、報告のたびに書き直す手間がなくなります。結果として、テスト担当者・PM双方の負担が軽くなります。

伝わらないバグ票が生む手戻りとコスト

「伝わらないバグ票」には、いくつかの典型パターンがあります。自分やチームのバグ票が当てはまっていないか、まず確認してみてください。

よくある「伝わらないバグ票」パターン

事象だけ書いてある：「ログインできない」だけで、手順も環境も条件もない
主観で書いてある：「なんか変」「たまにおかしい」など再現条件が特定できない
期待結果がない：何が正しい挙動なのかが読み手に伝わらない
複数の不具合を1枚に詰め込む：修正状況を個別に追えなくなる
スクリーンショットが本文と対応していない：どの操作の画面か分からない

バグ票が伝わらない最大の原因は、書き手が「自分の頭の中の前提」を書き落とすことです。読み手はその前提を共有していません。

手戻りが起きる流れを可視化する

伝わらないバグ票は、次のような負のループを生みます。

テスト担当者が事象だけを書いて登録する
開発者が再現できず「情報不足」で差し戻す
テスト担当者が再現手順を追記する（数時間後）
開発者が再度確認し、ようやく着手する

このループが1回転するだけで、着手が1日遅れることもあります。リリース直前にテストが立て込む受託開発では、この遅延が致命的になりがちです。

「伝わらないコスト」は見えにくいから放置される

やっかいなのは、このコストが数字として表に出にくいことです。差し戻しや問い合わせの往復は、それぞれは小さな時間で、日々の業務に埋もれてしまいます。

しかし、たとえば1件あたり30分の確認往復が、テスト期間中に40件発生したとします。それだけで20時間、およそ2.5人日分の工数が「伝えるためのやり直し」に消えている計算です（あくまで一例です）。

開発者が「これどういう状況ですか」と質問する時間
テスト担当者が状況を思い出し、再確認して回答する時間
やり取りを待つ間、修正が着手されない待機時間

バグ票を丁寧に書くコストより、伝わらないバグ票のやり直しコストのほうが、多くの場合は大きくなります。この構造に気づくことが、書き方を見直す第一歩です。

そもそもバグを追跡・管理する土台として、バグトラッキングシステムを活用する意義も押さえておくと、バグ票の運用がスムーズになります。

バグ票（不具合報告書）に必須の項目構成

ここからは具体的な中身に入ります。まずは、どんなプロジェクトでも共通して必要になる必須項目を押さえましょう。

不具合票の項目は多すぎても記入が形骸化し、少なすぎると伝わりません。以下が「これだけは外せない」核となる項目です。

なお、管理番号・報告者・報告日といった一見地味な項目も、後から効いてきます。管理番号があれば会話が「あのバグ」ではなく「BUG-0012」で通じ、報告者が分かれば追加確認の相手がすぐ特定できます。報告日は、対応スピードや残存期間を振り返るときの基礎データになります。

必須項目の一覧と役割

項目	役割	記入のポイント
管理番号	一意に識別する	自動採番が望ましい
タイトル（要約）	一覧で内容を把握する	「どこで・何が」を一文で
発生環境	再現条件を揃える	OS・ブラウザ・端末・バージョン
前提条件	事象に至る状態を示す	ログイン状態・データ条件など
再現手順	開発者が追体験する	番号付きで1操作ずつ
期待結果	正しい挙動を示す	仕様書の該当箇所も引用
実際の結果	不具合の事象を示す	観測した事実のみを書く
重要度	影響の大きさを示す	客観基準で判定
優先度	対応の緊急度を示す	ビジネス観点で判定
添付資料	証跡を残す	画面・ログ・動画

「発生環境・前提条件・再現手順・期待結果・実際の結果」の5点が揃って初めて、バグ票は再現可能になります。

タイトルは「一覧で内容が分かる」ことを最優先に

タイトルは、バグ票一覧をスクロールする開発者が最初に見る要素です。ここが曖昧だと、それだけで優先順位付けが遅れます。

悪い例：「エラーが出る」
良い例：「注文確定画面で、クーポン併用時に合計金額が0円になる」

「どの画面で・どんな条件で・何が起きたか」を一文に凝縮するのがコツです。「重要度」「優先度」といったテスト用語の定義は、JSTQB（日本のソフトウェアテスト技術者資格認定）の公式サイトの資料も参考になります。

環境と前提条件を省略しない

再現しない不具合の多くは、環境や前提条件の記述漏れが原因です。「自分の環境では出る」が、相手の環境では条件が違うのです。

OS・ブラウザ・アプリのバージョンを明記する
テストデータやアカウントの状態を書く
ネットワークや権限など、特殊な条件があれば添える

とくにWebシステムでは、ブラウザの種類やバージョンによって挙動が変わる不具合が少なくありません。「Chromeでは正常だがSafariで崩れる」といったケースは、環境の記述がないと開発者が永遠に再現できません。

期待結果と実際の結果は必ずセットで書く

初心者のバグ票でもっとも抜けやすいのが「期待結果」です。実際の結果（起きたこと）だけを書いて、期待結果（本来どうあるべきか）を省いてしまうのです。

期待結果が書かれていないと、開発者は「これは不具合なのか、仕様なのか」を判断できません。

実際の結果：「合計金額が0円と表示される」
期待結果：「割引後の合計金額4,500円が表示される」

この2つが並んで初めて、読み手は「あるべき姿」と「現実」のギャップを一目で理解できます。可能であれば、仕様書やチケットの該当箇所を引用し、「どの仕様に照らして不具合と判断したか」を添えると、判断の食い違いを防げます。

添付資料は「本文の裏づけ」として使う

スクリーンショットや動画、ログは、文章だけでは伝わらない情報を補います。ただし、添付するだけで満足しないことが大切です。

スクリーンショットには、問題箇所を枠や矢印で示す
複数枚ある場合は、再現手順の番号と対応づける
ログは該当する時刻・エラーメッセージの前後を抜粋する

添付資料が本文の再現手順と対応していれば、開発者は「この操作でこの画面になる」という流れを迷わず追えます。

再現手順が伝わるバグ票の書き方【良い例・悪い例】

バグ票の心臓部は再現手順です。ここが伝わるかどうかで、修正スピードは大きく変わります。開発者に伝わる再現手順の書き方を、良い例と悪い例の対比で見ていきましょう。

再現手順は「番号付き・1操作ずつ」が原則

再現手順は、読み手が何も考えずに同じ操作をなぞれる粒度で書きます。文章で長々と書くのではなく、番号付きの箇条書きにするのが鉄則です。

観点	悪い例	良い例
粒度	「注文して決済するとエラー」	操作を1ステップずつ分解
主語	「画面を操作すると」	「どのボタンを押すと」を明示
数値	「大きい金額で」	「99,999円を入力」と具体化
結果	「おかしくなる」	「合計が0円と表示される」

悪い例と良い例を、実際の記述で比べてみます。

悪い例：

> クーポンを使って注文するとエラーになります。金額が変です。

これでは開発者は、どのクーポンで、どの金額で、どの画面で起きるのか分かりません。

良い例：

> 1. 商品A（税込5,000円）をカートに入れる > 2. カート画面で「10%OFFクーポン」を適用する > 3. さらに「送料無料クーポン」を併用して適用する > 4. 「注文を確定する」ボタンを押す > – 期待結果：合計金額が4,500円と表示される > – 実際の結果：合計金額が0円と表示され、注文が確定できる

再現手順は「読み手が一切推測しなくても同じ操作を再現できる」レベルまで具体化します。

事実と推測を分けて書く

テスト担当者はつい「たぶんキャッシュが原因」といった推測を書きがちです。しかし推測が混ざると、開発者の調査を誤った方向に誘導することがあります。

観測した事実（何を操作し、何が表示されたか）を本文に書く
気づいた推測は「所感」として別欄に分ける
スクリーンショットやログで事実を裏づける

再現性を明記する

同じ手順でも、毎回出るのか・時々なのかで対応は変わります。再現性の情報は必ず添えましょう。

常に再現：5回中5回発生
断続的に再現：5回中2回発生（条件を絞り込み中）
再現条件不明：発生を1回確認、条件は特定できていない

断続的な不具合ほど、発生時刻・操作ログ・環境を細かく残すことが、後の原因特定を助けます。テスト結果の記録全般については、テストレポートの書き方をまとめた記事も合わせて参考にしてください。

不具合の種類ごとに「押さえるべき情報」は変わる

再現手順の基本は共通ですが、不具合の種類によって特に重視すべき情報は異なります。代表的なパターンを整理しました。

不具合の種類	特に必要な情報
機能不具合（計算・遷移）	入力値・操作順序・期待結果との差分
表示崩れ（レイアウト）	端末・ブラウザ・画面幅・スクリーンショット
パフォーマンス低下	発生時の負荷状況・処理時間・データ件数
データ不整合	操作前後のデータ状態・該当レコード

たとえば表示崩れは、同じページでも画面幅やブラウザで再現有無が変わります。「Chromeの幅1280pxで発生、375pxでは正常」のように、条件を数値で添えると開発者は一発で状況を再現できます。

パフォーマンス系の不具合では、「遅い」という主観ではなく「一覧表示に8秒かかる（データ1万件時）」のように、数値と前提を必ずセットにしてください。感覚的な表現は、優先度判断のブレを生みます。

重要度と優先度を切り分ける

バグ票でよく混同されるのが「重要度」と「優先度」です。この2つは別の軸であり、分けて記入することで対応順序の判断が明確になります。

重要度と優先度は別の軸

重要度（Severity）：不具合がシステムや業務に与える影響の大きさ。技術・品質の観点で判定する
優先度（Priority）：どれだけ急いで直すべきかという対応の緊急度。ビジネスやリリース計画の観点で判定する

重要度が高くても優先度が低い不具合、その逆もあり得ます。たとえば、めったに使われない管理画面の重大バグは「重要度：高・優先度：中」になることもあります。

判定基準を表で共有する

判定を個人の感覚に任せると、人によってブレます。チームで基準表を決めておきましょう。

ランク	重要度の目安	優先度の目安
高	業務停止・データ破損・金額誤り	次のリリースで必ず修正
中	一部機能が使えない・回避策あり	計画的に修正
低	表示崩れ・軽微な文言誤り	余力があれば修正

金額の誤りやデータ破損は、たとえ発生頻度が低くても重要度「高」で扱うのが安全です。顧客の信頼に直結するためです。

重要度と優先度がねじれる具体例

2つの軸を分けると、次のような「ねじれ」を正しく表現できます。

重要度：高／優先度：低：年に一度しか使わない年次レポート機能でデータ破損。影響は大きいが、次の実行まで時間があるため急がない
重要度：低／優先度：高：トップページの会社名に誤字。実害は小さいが、全ユーザーの目に触れるためすぐ直したい

このように、「影響の大きさ」と「対応の急ぎ度」は必ずしも一致しません。1つのランクだけで管理すると、この判断が潰れてしまいます。

優先度の決め方をさらに詳しく知りたい場合は、バグ修正の優先度を決めるプロセスを解説した記事が参考になります。

顧客報告では「影響範囲」を言語化する

受託開発では、顧客に不具合を報告する場面もあります。その際は重要度・優先度に加えて、「誰の・どの業務に・どんな影響が出るか」を平易な言葉で添えると、顧客も判断しやすくなります。

影響を受けるユーザー（例：一般会員のみ／管理者のみ）
影響を受ける業務（例：決済のみ／閲覧全般）
暫定的な回避策の有無

顧客は技術用語よりも「自分たちの業務にどう響くか」を知りたいものです。「決済処理でエラーが発生」ではなく「一部の会員が商品を購入できない状態」と言い換えるだけで、顧客は状況の深刻さを正しく受け止められます。バグ票の内容を、そのまま報告文面に転用できる形で書いておくと、この翻訳の手間も減らせます。

そのまま使えるバグ票テンプレート

ここまでの項目を1枚にまとめた、バグ報告のテンプレートを示します。ツールのカスタムフィールドや、スプレッドシートの列としてそのまま流用できます。

標準バグ票テンプレート

【管理番号】BUG-0001

【タイトル】注文確定画面でクーポン併用時に合計金額が0円になる

【報告者 / 報告日】山田 / 2026-07-15

【発生環境】iOS 18 / Safari / アプリ v2.3.1 / 本番相当の検証環境

【前提条件】一般会員でログイン済み、カートに商品1点あり

【再現手順】

商品A（税込5,000円）をカートに入れる
「10%OFFクーポン」を適用する
「送料無料クーポン」を併用して適用する
「注文を確定する」ボタンを押す

【期待結果】合計金額が4,500円と表示される

【実際の結果】合計金額が0円と表示され、注文が確定できる

【再現性】常に再現（5回中5回）

【重要度】高（金額誤り・売上に直結）

【優先度】高（次リリースで必須）

【添付】screenshot_01.png / api_response.log

【所感（推測）】クーポン併用時の割引計算が二重適用されている可能性

テンプレートを固定し、全員が同じ枠に沿って書くだけで、バグ票の品質は驚くほど安定します。

項目のカスタマイズ指針

プロジェクトの性質に応じて、項目は増減させて構いません。ただし、次の原則は守りましょう。

必須項目は削らない：環境・前提・手順・期待・実際の5点は残す
任意項目は分ける：所感・関連番号・回避策などは補助欄にまとめる
記入例をテンプレートに埋め込む：空欄より記入例があるほうが迷わない

なお、不具合の証跡（スクリーンショットやログ）の残し方については、テストエビデンスの管理方法を解説した記事が実務の助けになります。

バグ管理ツールに落とし込むときの注意

上記のテンプレートは、紙やスプレッドシートだけでなく、バグ管理ツールのカスタムフィールドとしてもそのまま使えます。ツールを使う場合は、次の点に気をつけましょう。

必須フィールドを設定する：再現手順や期待結果を「任意」にすると、記入漏れが常態化します
重要度と優先度を別フィールドにする：ひとつのフィールドにまとめると、後から集計・分析ができません
ステータスの遷移ルールを決める：「起票→調査中→修正中→再テスト→クローズ」など、誰が見ても進捗が分かる状態設計にします

ツールを導入しても、記入する項目の質が低ければ効果は限定的です。まずはテンプレートで「何を書くか」を固め、その上でツールに乗せる順番が失敗しにくい進め方です。

記入チェックリスト

登録前に、書き手自身が次の項目を確認する習慣をつけましょう。

[ ] タイトルだけで「どこで・何が」が伝わるか
[ ] 第三者が手順どおりに操作して再現できるか
[ ] 期待結果と実際の結果が両方書かれているか
[ ] 重要度と優先度を別々に判定したか
[ ] 事実と推測が混ざっていないか

バグ票の運用を定着させるコツ

良いテンプレートを用意しても、運用が伴わなければ形骸化します。少人数のチームでも定着させるための、現実的なコツを紹介します。

まず「1枚1不具合」を徹底する

1枚に複数の不具合を書くと、修正状況を個別に追えなくなります。面倒でも、不具合ごとに票を分けることが管理の基本です。

「1枚1不具合・1手順1操作」を守るだけで、バグ票の追跡性は大きく向上します。

レビューの観点をチームで揃える

登録前に、書き手以外がタイトルと再現手順だけ軽く確認するだけでも、差し戻しは大きく減ります。全項目を精査する必要はありません。

タイトルで内容が分かるか
再現手順が具体的か
重要度・優先度に違和感がないか

このレビューは、時間をかけて全項目を精査するものではありません。1件あたり数十秒で「読み手として引っかかる点がないか」を見るだけで十分です。兼任中心のチームでも、この軽さなら習慣化できます。

新メンバーには「良い例」を先に見せる

バグ票をうまく書く力は、ルールを渡すだけではなかなか身につきません。抽象的な規約より、実際の良い例・悪い例を1組見せるほうが早く伝わります。

過去の「よく書けたバグ票」を2〜3件、見本として共有する
ありがちな悪い例と、その改善版を並べて見せる
最初の数件は登録前に一緒に確認し、フィードバックする

最初にひと手間かけておくと、その後の差し戻しが大きく減り、結果的にチーム全体の工数が下がります。

蓄積したバグ票を分析に活かす

バグ票は書いて終わりではありません。溜まったデータは、品質改善のための貴重な情報源になります。

どの機能でバグが多いか（欠陥の偏在を把握する）
どの工程で作り込まれたか（原因工程を分析する）
再発している不具合はないか（再発防止策につなげる）

ソフトウェア開発の品質に関する定量的なデータは、IPAのソフトウェア開発分析データ集のような公的資料も参考になります。自社の傾向と照らし合わせることで、改善の優先順位が見えてきます。

標準化はドキュメント規約に位置づける

バグ票の記述ルールは、テストドキュメント全体の一部です。国際標準のISO/IEC/IEEE 29119でも、テストドキュメントの項目が体系化されています。自社の規約として明文化し、新メンバーがすぐ書けるようにしておきましょう。

定着のステップ	具体的なアクション
標準化	テンプレートと記入例を用意する
教育	新メンバーに良い例・悪い例を共有する
レビュー	登録前の軽いチェックを習慣化する
改善	溜まったバグ票を定期的に振り返る

バグ票を書くときによくある疑問

現場でよく挙がる質問を、実務目線で整理しました。テンプレートを運用に落とし込む際の判断材料にしてください。

バグ票はどこまで細かく書くべきですか

判断基準は「自分がいなくても、他人が読んで再現・修正判断できるか」の一点です。細かさそのものが目的ではありません。

自明に見える操作でも、読み手には自明ではありません。迷ったら「初めてこのシステムを触る人が読む」と想定して、一段だけ丁寧に書くのが目安です。

再現しない不具合はどう報告すればよいですか

再現条件が特定できない不具合こそ、記録の価値があります。次の情報をできるだけ多く残しましょう。

発生した日時と、その直前に行っていた操作
使用していた環境・アカウント・データの状態
スクリーンショットやエラーログ、画面録画

「再現できないので報告しない」が最も危険です。断片的でも情報を残せば、同種の事象が再発したときに点と点がつながります。

スクリーンショットだけで手順は省略してよいですか

省略は避けるべきです。画像は状態を示せますが、「そこに至るまでの操作」は文章でしか表現できません。手順が言葉で書かれていれば、開発者はコードを追いながら該当処理を特定できます。

誰がバグ票を書くべきですか

不具合を最初に見つけた人が、その場で書くのが原則です。時間が経つと、環境や操作の記憶が薄れて再現条件が失われます。テストを兼任している場合でも、発見直後に最低限の項目だけは埋めておきましょう。

疑問	実務上の答え
どこまで細かく	他人が再現・判断できる粒度まで
再現しない不具合	日時・環境・証跡を残して報告する
画像だけでよいか	手順は必ず文章で書く
いつ書くか	発見直後にその場で書く