バグ票とは？IT業務初心者向けに書き方・記載項目・報告例をわかりやすく解説
バグ票とは、システムやアプリケーションで見つかった不具合の内容、発生条件、再現手順、影響範囲などを記録し、修正状況を管理するための資料です。
「不具合票」「障害票」「バグチケット」「インシデント票」と呼ばれる場合もあります。名称や書式は会社によって異なりますが、目的は同じです。
バグ票を正確に作成すると、開発担当者が問題を再現しやすくなり、原因調査や修正を効率よく進められます。IT業務初心者は、単に「動きません」と書くのではなく、誰が読んでも同じ状況を確認できる内容を記録することが重要です。
バグ票とは
バグ票とは、テストや運用中に発見した不具合を関係者へ共有し、対応状況を追跡するための記録です。
一般的には、次の流れで使用します。
- テスト担当者や利用者が不具合を発見する
- 発生状況を確認する
- バグ票を作成する
- 開発担当者が原因を調査する
- 修正を実施する
- テスト担当者が再テストする
- 問題がなければ完了にする
バグ票が必要な理由
口頭やチャットだけで不具合を伝えると、情報が不足したり、認識違いが発生したりします。バグ票として記録することで、必要な情報を整理し、対応漏れを防げます。
| バグ票がある場合 | バグ票がない場合 |
|---|---|
| 発生状況を正確に共有できる | 担当者によって認識がずれる |
| 修正状況を追跡できる | 対応漏れが発生しやすい |
| 再発防止に活用できる | 過去の不具合を調べにくい |
| 品質分析に利用できる | 不具合の傾向を把握できない |
どのような場面で使われるか
バグ票は、システム開発だけでなく、社内SEやヘルプデスク、運用保守の業務でも使用されます。
- 単体テストや結合テストで不具合を発見したとき
- 受入テストで仕様と異なる動作を確認したとき
- 本番稼働後に利用者から問い合わせがあったとき
- Windows Update後に業務アプリが起動しなくなったとき
- 共有フォルダやプリンターを利用できなくなったとき
- サーバー監視で異常を検知したとき
バグ票に記載する主な項目
| 項目 | 記載内容 |
|---|---|
| 管理番号 | バグを識別する番号 |
| タイトル | 不具合の内容を簡潔に記載する |
| 発見日 | 不具合を確認した日時 |
| 発見者 | 不具合を発見した担当者 |
| 発生環境 | OS、端末、ブラウザー、バージョンなど |
| 事前条件 | 不具合が発生する前の状態 |
| 再現手順 | 不具合を再現するための操作手順 |
| 期待結果 | 本来どのように動作すべきか |
| 実際の結果 | 実際に発生した現象 |
| 再現率 | 毎回、数回に1回、1回のみなど |
| 重要度 | 業務への影響の大きさ |
| 優先度 | 修正対応を行う順番 |
| 証跡 | 画面、ログ、動画、エラー番号など |
| 対応状況 | 新規、調査中、修正済み、完了など |
良いバグ票の書き方
タイトルは現象が分かるように書く
タイトルには、対象機能、操作、発生した現象を含めます。
悪い例：ログインできない
良い例：一般ユーザーが正しいパスワードを入力してもログインエラーになる
再現手順は番号を付ける
再現手順は、初めて見る担当者でも同じ操作ができるように記載します。
- Windows 11の端末で業務システムを起動する
- 一般ユーザーのIDとパスワードを入力する
- 「ログイン」ボタンを押す
- エラーメッセージが表示されることを確認する
期待結果と実際の結果を分ける
期待結果：メニュー画面が表示され、システムを利用できる。
実際の結果：「認証に失敗しました」と表示され、ログインできない。
この2つを分けることで、仕様との差が明確になります。
バグ票の記載例
| 項目 | 記載例 |
|---|---|
| タイトル | 一般ユーザーが正しい認証情報でもログインできない |
| 発生日時 | 2026年7月18日 10時15分 |
| 環境 | Windows 11、Microsoft Edge、業務システムVer.3.2 |
| 事前条件 | 一般ユーザーのアカウントが有効である |
| 再現手順 | ログイン画面で正しいIDとパスワードを入力し、ログインボタンを押す |
| 期待結果 | メニュー画面が表示される |
| 実際の結果 | 認証エラーが表示される |
| 再現率 | 5回中5回 |
| 影響範囲 | 一般ユーザー全員 |
| 重要度 | 高 |
| 添付資料 | エラー画面、イベントログ、操作時刻 |
重要度と優先度の違い
初心者が混乱しやすいのが、重要度と優先度の違いです。
| 項目 | 意味 | 例 |
|---|---|---|
| 重要度 | 不具合がシステムや業務へ与える影響 | 全利用者がログインできないため重要度は高い |
| 優先度 | どの不具合から対応するか | 翌日の本番稼働に必要なため優先度は高い |
重要度が高くても回避策がある場合は、優先度が下がることがあります。反対に、重要度が低くてもリリース直前の問題であれば、優先して修正する場合があります。
再現率とは
再現率とは、同じ操作を行ったときに不具合が発生する割合です。
- 毎回発生する
- 10回中3回発生する
- 特定の端末だけで発生する
- 特定のユーザーだけで発生する
- 1回だけ発生し、その後は再現しない
「たまに発生する」と書くよりも、「10回中2回発生した」と記載した方が正確です。
不具合を発見したときの確認順序
- 操作手順をもう一度確認する
- 同じ操作で再現するか確認する
- 別のユーザーでも発生するか確認する
- 別の端末でも発生するか確認する
- ネットワーク接続を確認する
- Windowsやアプリケーションのログを確認する
- 画面やログを証跡として保存する
- 影響範囲を整理してバグ票を登録する
原因を切り分けるポイント
| 確認対象 | 確認内容 |
|---|---|
| ユーザー側 | 入力内容や操作手順に誤りがないか |
| 端末側 | 特定のWindows端末だけで発生していないか |
| ネットワーク側 | 通信断や遅延が発生していないか |
| サーバー側 | サービス停止やリソース不足がないか |
| Active Directory側 | アカウントロックやグループ設定に問題がないか |
| DNS側 | サーバー名を正しく名前解決できるか |
| 権限 | 必要なアクセス権が付与されているか |
| アプリケーション | 設定値やバージョンに違いがないか |
GUIで確認する方法
Windows 11では、次の画面から端末やアプリケーションの状態を確認できます。
- 設定画面でWindowsのバージョンを確認する
- タスクマネージャーでプロセスやCPU使用率を確認する
- イベントビューアーでエラーを確認する
- エクスプローラーでファイルやアクセス権を確認する
- ブラウザーの開発者ツールで通信エラーを確認する
イベントビューアーでログを確認する方法
- WindowsキーとXキーを押す
- 「イベント ビューアー」を選択する
- 「Windows ログ」を開く
- 「アプリケーション」または「システム」を選択する
- 不具合が発生した時刻のエラーや警告を確認する
- イベントID、ソース、メッセージをバグ票へ記録する
ログの内容をすべて貼り付けるだけでなく、発生時刻やイベントIDを整理して記載すると、担当者が調査しやすくなります。
CUIで確認できる内容
コマンドプロンプトでは、次のコマンドが原因の切り分けに役立ちます。
- ipconfig：IPアドレスやDNSサーバーを確認する
- ping：対象サーバーとの通信を確認する
- nslookup：DNSの名前解決を確認する
- whoami：現在のログインユーザーを確認する
- systeminfo：Windowsのバージョンや更新状況を確認する
PowerShellでは、次の確認ができます。
- Get-Service：サービスの稼働状態を確認する
- Get-Process：実行中のプロセスを確認する
- Get-WinEvent：Windowsのイベントログを確認する
- Test-NetConnection：ポート単位で通信を確認する
コマンドの結果には、ユーザー名、端末名、IPアドレスなどの情報が含まれる場合があります。社外へ送付するときは、機密情報が含まれていないか確認してください。
バグ票で使用するステータス
| ステータス | 意味 |
|---|---|
| 新規 | バグ票が登録された状態 |
| 調査中 | 原因や影響範囲を調べている状態 |
| 対応中 | 修正作業を行っている状態 |
| 修正済み | 修正が完了し、確認待ちの状態 |
| 再テスト中 | 修正結果をテストしている状態 |
| 差し戻し | 修正後も問題が残っている状態 |
| 完了 | 問題が解消し、対応を終了した状態 |
| 対応しない | 仕様、重複、影響が小さいなどの理由で修正しない状態 |
バグ票の管理に使われるツール
- Excel
- Redmine
- Backlog
- Jira
- GitHub Issues
- Azure DevOps
- ServiceNow
ツールが異なっても、再現手順、期待結果、実際の結果、影響範囲、証跡といった基本項目は共通しています。
筆者の経験談
現場で「画面がエラーになります」とだけ記載されたバグ票を受け取ったことがあります。発生した画面、操作手順、利用者、時刻が分からず、原因調査を始めるまでに何度も確認が必要になりました。
その後、再現手順、期待結果、実際の結果、環境、証跡を必須項目にしたところ、開発担当者がすぐに調査へ着手できるようになりました。バグ票は文章の長さより、必要な情報が具体的にそろっていることが重要です。
初心者がやりがちなミス
- 「動かない」「エラーになる」だけで登録する
- 期待結果を書かない
- 発生日時を記録しない
- 利用したユーザーや端末を書かない
- 再現確認をせずに登録する
- 画面だけ添付して説明を書かない
- 重要度をすべて「高」にする
- 修正後の再テストを行わず完了にする
バグ票を書くときの注意点
推測と事実を分けて書くことが重要です。
事実：2026年7月18日10時15分、ログインボタンを押すと認証エラーが表示された。
推測：Active Directoryの認証処理に問題がある可能性がある。
原因が確定していない段階で「サーバー障害が原因」と断定すると、調査の方向を誤らせる可能性があります。
また、バグ票にパスワード、秘密鍵、個人情報、社外秘データを記載してはいけません。証跡を添付する前に、不要な情報を隠す必要があります。
上司へ報告するポイント
- いつ、どの環境で発生したか
- 何ができないのか
- 誰に影響しているか
- 再現するか
- 業務を継続できる回避策があるか
- 現在の調査状況
- 修正や復旧の担当者
- 次回の報告予定
エスカレーションするタイミング
- 複数の利用者が業務を継続できない
- 重要なシステムへログインできない
- データ消失や破損の可能性がある
- 情報漏えいの可能性がある
- 本番リリースの可否に影響する
- 回避策がなく、原因も特定できない
- 同じ不具合が繰り返し発生している
現場で評価されるバグ票のポイント
- タイトルだけで不具合の概要が分かる
- 再現手順が具体的である
- 期待結果と実際の結果が明確である
- 影響範囲が整理されている
- ログや画面などの証跡がある
- 事実と推測が分けられている
- 第三者が同じ不具合を再現できる
関連するIT用語
- バグ
- 不具合
- 障害
- インシデント
- 再現手順
- 重要度
- 優先度
- デバッグ
- 再テスト
- 回帰テスト
- 品質管理（Quality Control：QC）
- 品質保証（Quality Assurance：QA）
よくある質問（FAQ）
バグ票と障害票の違いは何ですか？
会社によって定義は異なります。一般的に、バグ票はシステムの不具合を管理し、障害票は本番環境で発生した業務影響のあるトラブルを管理する場合に使われます。
再現しない不具合もバグ票に登録しますか？
業務への影響がある場合や、重大なエラーが発生した場合は登録します。その際は「再現せず」と記載し、発生日時、環境、ログ、利用者の操作内容をできる限り残します。
スクリーンショットだけでもよいですか？
スクリーンショットだけでは不十分です。発生環境、再現手順、期待結果、実際の結果、発生時刻を文章でも記載します。
仕様どおりの動作でもバグになりますか？
仕様どおりであれば、一般的にはバグではありません。ただし、仕様自体に問題がある場合は、仕様変更や改善要望として別に管理します。
バグ票は誰が完了にしますか？
一般的には、修正担当者ではなく、テスト担当者や不具合の登録者が再テストを行い、問題が解消したことを確認して完了にします。
まとめ
バグ票とは、システムやアプリケーションで発見した不具合を記録し、調査、修正、再テストまで管理するための資料です。
良いバグ票には、発生環境、事前条件、再現手順、期待結果、実際の結果、再現率、影響範囲、ログなどが具体的に記載されています。
IT業務初心者は、「誰が読んでも同じ状況を再現できるか」を意識してください。事実と推測を分け、必要な証跡を残すことが、迅速な原因調査と品質向上につながります。
コメント