なぜフォーマットは内容より軽視されるのか
バグレポートのフォーマットとは、4 つのブロックに並んだ 10 の固定フィールドです：識別情報 → 環境 → 症状 → 証拠。 順番を固定すれば、開発者はどこを見ればよいかを即座に判断でき、二度聞き返す必要がなくなります。以下ではフィールドの全一覧、各フィールドの書き方と良い例・悪い例、そして、それ以外はきちんと書けているレポートを静かに台無しにする 7 つのフォーマットミスを紹介します。
同じ情報でもフォーマットが違うと、処理にかかる時間は倍になります。フォーマットが統一されていないと、次の 3 つの問題が生じます。
フォーマットの価値は見た目の整い方ではなく、同じフィールドが常に同じ位置にあることにあります。
バグ報告の標準フォーマット：10 のフィールド
| # | フィールド | 目的 | 必須か | 書き方 |
|---|---|---|---|---|
| 1 | タイトル | チケットを開くかどうかを開発者が判断できる | 必須 | コンポーネント + 操作 + 予期しない結果 + 条件（バグタイトル例参照） |
| 2 | ID | 全員が同じ記録を参照できる | 必須（自動採番） | BUG-0042。「さっきのやつ」は使わない |
| 3 | 重大度 / 優先度 | 計画の根拠 | 推奨 | 重大度は被害、優先度は業務上の緊急度 — 分けて管理します |
| 4 | 環境 | 再現できるかどうかを決める | 必須 | URL、ブラウザのバージョン、OS、端末、解像度、アカウント |
| 5 | 前提条件 | 再現の開始状態 | 推奨 | 「法人アカウントでログイン済み、カートに商品が 2 点ある」 |
| 6 | 再現手順 | 同じ画面まで他人を導く | 必須 | 番号付き、1 ステップ 1 アクション（再現手順の書き方参照） |
| 7 | 期待結果 | 「これは不具合か」の判断基準 | 必須 | どうなるべきかを書く。「正常に動作しません」は不可 |
| 8 | 実際の結果 | 事実の記述 | 必須 | 事象 + 数値 + エラー文そのまま。推測は書かない |
| 9 | 証拠 | 開発が再実行せずに済む | 強く推奨 | 注釈付きスクリーンショット、画面録画、コンソールログ、失敗したリクエスト |
| 10 | 備考 | 補足の文脈 | 任意 | 発生頻度、回避策、関連チケット |
各フィールドの書き方
識別情報：タイトル、ID、重大度と優先度
- タイトル：どこで、何をして、何が起きて、どの条件かを 1 行にまとめます。良い例と悪い例 40 組の比較は バグタイトル例 をご覧ください。
- ID：システムに採番させます。手作業の採番は必ず重複します。
- 重大度と優先度：もっとも頻繁に 1 つのフィールドにまとめられてしまう組み合わせです。
| フィールド | 答える問い | 誰が決めるか | 例 |
|---|---|---|---|
| 重大度 | その不具合自体の被害はどれくらいか | テスター / 報告者 | データ損失 = 致命的、誤字 = 軽微 |
| 優先度 | いつ直すのか | プロダクト / 技術リード | ローンチ週のヒーロー領域の誤字 = 優先度は高い |
環境：環境と前提条件
環境フィールドは 6 項目すべてを埋めます：URL、ブラウザとバージョン、OS、端末、解像度またはビューポート、アカウント種別。「Chrome」だけでは何も書いていないのと同じです。Web ではブラウザのバージョン差による挙動の違いは日常的に起きます。
もっとも忘れられやすい前提条件はログイン状態ではなくデータの状態です。「カートに 2 点ある」「アカウントはトライアル 3 日目」「この注文はすでに 1 回返金済み」——こうした記述こそが再現を止めている原因です。
症状：再現手順、期待結果、実際の結果
- 再現手順：番号付き、1 ステップ 1 アクション、実際のデータ。詳しい方法は 再現手順の書き方 にまとめています。
- 期待結果：どうなるべきかを書き、できれば根拠を示します（要件、受け入れ基準の ID、あるいは一般的な業務ルール）。「ちゃんと動くはず」では判断を開発者に押し戻すことになります。
- 実際の結果：観察した事実だけを、数値とエラー文そのままで書きます。推測は書きません — 「おそらくキャッシュの問題」といった推測は備考に移し、「推定」と明記します。
証拠：スクリーンショット / 録画 / ログ、そして備考
- スクリーンショットは注釈を入れます：問題箇所を囲み、矢印やテキストを追加して、全画面キャプチャを探し回らせないようにします。
- 画面録画は 10〜30 秒に収め、必要な瞬間だけを残します。5 分の録画はまず見られません。
- ログは必要な部分だけを示します：エラーレベルのコンソール出力、失敗したネットワークリクエスト（HTTP 400 以上）、該当エンドポイントのリクエストとレスポンスのボディ。
- 備考には 2 つを書きます：発生頻度（必現 / 断続的 + 確率）と回避策の有無。
3 つのチャネルによるフォーマットの違い
| チャネル | フィールドの見え方 | つまずきやすい点 |
|---|---|---|
| 課題管理ツール（Jira / Linear / GitHub Issues） | カスタムフィールド + 説明欄のテンプレート | 環境情報を説明の末尾に書いて長文に埋もれさせる。環境はカスタムフィールドに置くべきです |
| メールやチャット（顧客・外部協力者へ送る場合） | プレーンテキストのブロック | TL;DR がなく、添付ファイル名も場当たり的なので、受け手が十数個のファイルを探す羽目になります |
| 表計算（Excel / Google Sheets / Feishu Bitable） | 1 行 1 件、列 = フィールド | 列の順序が上記 10 フィールドと一致せず、絞り込みも並べ替えも機能しません |
チャネルが変わってもフィールドは変えません。メールで送ったからといって、情報の欠落が許されるわけではありません。
レポートを台無しにする 7 つのフォーマットミス
screenshot-1.png — 3 日後には報告者自身も対応が取れません。フォーマットのチェックリスト
送信前に 1 行ずつ確認します。
- 10 のフィールドが揃い、前回と同じ順序になっているか？
- 環境の 6 項目（URL / ブラウザ / OS / 端末 / 解像度 / アカウント）が埋まっているか？
- 期待結果と実際の結果が分けて書かれているか？
- 再現手順に番号があり、1 ステップ 1 アクションか？
- スクリーンショットに注釈があり、録画は 30 秒以内か？
- 実際の結果に未確認の推測が混じっていないか？
- 発生頻度（必現 / 断続的 + 確率）が明記されているか？
よくある質問（FAQ）
バグレポートに「標準フォーマット」はありますか？
強制力のある業界標準はありませんが、事実上の共通解はあります。タイトル、環境、再現手順、期待結果、実際の結果、証拠の 6 項目は、ほぼすべての枠組み（IEEE 829、ISTQB、商用の不具合テンプレート）に登場します。本記事の 10 フィールドは、その中核に識別情報と備考を足したものです。
フィールドの順序は変えてもよいですか？
構いませんが、チーム内で一貫して安定していることが条件です。順序を固定する狙いは筋肉記憶にあります。頻繁に変えるほうが、最適でない順序を選ぶよりも悪影響が大きくなります。
重大度と優先度の本当の違いは何ですか？
重大度は不具合そのものの客観的な被害（テスト側が判断）、優先度は修正の緊急度（プロダクト側が判断）です。両者はずれます。ヒーロー領域の誤字は重大度が低くても、3 日後にローンチなら優先度は高くなります。
単純なバグでも 10 フィールドすべてが必要ですか？
いいえ。単純なバグはタイトル・環境・実際の結果の 3 つで足ります。ただし環境は決して省かないでください。「再現できない」の最大の原因です。フィールドは任意ですが、位置は任意ではありません。
「フォーマット」と「テンプレート」の違いは何ですか？
フォーマットはフィールドの仕様です。どのフィールドがあり、どの順序で、それぞれどう書くか。テンプレートはコピーして埋める骨組みのファイルです。両者は組み合わせて使います — フォーマットでフィールドを定義し、テンプレートとして配布します。すぐに使える骨組みは バグ報告テンプレート（Word 版・Markdown 版）をご覧ください。
フォーマットは自動化できる。判断はあなたに残る
境界をはっきりさせておきます。BugCapturer は何が不具合かを判断せず、タイトルも書きません — それは目撃した事象への理解が必要だからです。ただし、忘れがちな項目と時間を食う項目は自動で埋められます。
- 技術情報の自動取得：URL、ブラウザ、OS、画面解像度、ビューポートサイズを環境フィールドに直接書き込みます。手で写す必要はありません。
- 診断データ：エラーレベルのコンソールログと、失敗したネットワークリクエスト（HTTP 400 以上）を収集し、機密パラメータ（トークン、パスワード、API キー）は自動でマスクします。
- 注釈付きスクリーンショット：範囲を選んで矢印・枠・テキストを追加し、「どこがおかしいか」を画像に固定します。
- 画面録画：現在のタブを録画してトリミングし、検証できる短い動画として渡せます。
- 共有・同期：外部の協力者が登録なしで開ける共有リンクを発行、または Feishu の多次元テーブルや汎用 Webhook へ送信できます。
判断はあなたに。残りはツールが担います。
関連記事
- バグ報告テンプレート：全フィールドとコピー可能な骨組み
- バグタイトル例：良い例と悪い例 40 組の比較
- 再現手順の書き方：5 つの完全な例
- 効果的なバグ報告の方法
- Web サイト QA チェックリスト