ゲームの不具合報告の書き方｜バグ報告書テンプレートと例文で一発で伝わる

「不具合報告を出したのに、追加質問が何往復も来る」「再現できないと言われて手戻りが増える」——デバッグの現場ではよくある悩みです。
原因はシンプルで、報告に必要な情報が揃っていないか、伝わる順番になっていないことがほとんどです。

この記事では、今日からそのまま使えるように

• 不具合報告で必須の項目
• 伝わる書き方のコツ
• コピペで使えるテンプレート
• 良い例と悪い例
• 再現しないときの書き方
• 提出前のチェックリスト
• よくある質問

までを、1記事にまとめました。
社内のバグ報告だけでなく、問い合わせ文を書くときにも「必要情報の型」は共通なので、不要部分だけ削って使えます。

まず結論：不具合報告で必須の項目

この見出しでわかること：不具合報告で最低限そろえるべき情報が、ひと目で分かります。

不具合報告の質は「文章力」より「項目の漏れがないか」で決まります。まずは次の8項目を、毎回そろえるのが最短です。

1. タイトル
2. 発生手順
3. 実際の結果
4. 期待する結果
5. 発生頻度
6. 実行環境
7. バージョン
8. 添付資料

タイトルは原因ではなく現象を書く

タイトルは、原因を決め打ちせず「起きた現象」を短く書きます。

• 良い：ガチャ結果画面で確定ボタンが反応しない
• 悪い：確定ボタンの実装が壊れている

原因は調査しないと分からないことが多いので、報告の段階では「何が起きたか」を主語にします。検索もしやすくなり、重複報告の統合にも役立ちます。

再現手順は短文で分割する

再現手順は、長文よりも「短文の番号付き」が強いです。
1つの手順に複数の操作を詰め込むと、読む側が同じ操作を再現できません。

• 1：ホームからガチャを開く
• 2：10連を実行する
• 3：結果画面で確定ボタンを押す

このように「1行1操作」を意識すると、追加質問が減ります。

実際の結果と期待する結果をセットで書く

「何が問題なのか」は、実際の結果だけだと伝わりにくいです。
必ず「期待する結果」をセットにします。

• 実際の結果：確定ボタンを押しても反応せず、画面が進まない
• 期待する結果：確定ボタン押下で結果が確定し、次の画面へ遷移する

この2つがあるだけで、仕様確認も調査も一気に速くなります。

発生頻度と条件の情報を添える

発生頻度は、優先度判断の材料になります。回数が曖昧でも構いません。

• 3回中3回、毎回起きる
• 10回中1回くらい、たまに起きる
• 初回起動だけ起きる、2回目以降は起きない

加えて「特定条件がありそう」なら、その仮説も“推測として”添えると調査が進みます（例：通信が不安定なときだけ起きる気がする、など）。

実行環境とバージョンを書き切る

実行環境は「端末名」だけだと不足します。最低限、以下を埋めます。

• 端末（例：iPhone 13）
• OS（例：iOS 17.x）
• 回線（例：Wi-Fi／4G）
• 画面設定や言語（影響しそうなら）
• アプリ・ゲームのバージョン（例：1.2.3）

「どれが必要か分からない」と迷うなら、最初は多めに書いてOKです。削るのは読む側ができますが、後から聞き直すのはコストが高いです。

スクリーンショットやログで一次情報を残す

文章より、一次情報が強いです。

• 画面キャプチャ（現象が分かる1枚）
• 動画（操作とタイミングが分かる）
• 端末ログ／エラーログ（取得できる範囲で）

添付する場合は「どの瞬間の画像か」を一言添えるだけで、読む側の迷子が減ります。

伝わる不具合報告の書き方のコツ

この見出しでわかること：必要項目をそろえたうえで、さらに“手戻りを減らす書き方”が分かります。

事実と推測を分けて書く

報告が荒れる最大の原因は、事実と推測が混ざることです。
次のように、行を分けるだけで伝わります。

• 事実：確定ボタンを押しても反応しない
• 事実：他のボタンは反応する
• 推測：確定ボタンの当たり判定がズレている可能性がある

推測は歓迎ですが、必ず「推測」と分かる書き方にします。

一つの報告に対して一つの不具合にする

「ついでにここもおかしい」を1チケットにまとめると、担当が増えた瞬間に破綻します。
原則は1報告1現象。関連があるなら「関連チケット」として紐付けます。

重要度と影響範囲を言語化する

現場では、直す順番が命です。重要度は、次のように“ユーザー影響”で書くのが伝わりやすいです。

• 進行不能：メイン導線が止まり、継続ができない
• 期待値の毀損：報酬が受け取れず不公平感が出る
• 軽微：見た目の崩れだが操作はできる

「誰が困るか」「どの範囲に広がるか」まで書けると、優先度の合意が速くなります。

再現しないときの書き方で差がつく

再現しない報告は、書き方が雑だと“再現なしで終了”になりがちです。
後半で詳しく扱いますが、先にコツだけ言うと次の3点です。

• いつ起きたか（時刻、回線、端末温度など）を残す
• 起きた直前までの流れを時系列で書く
• 「起きた証拠」を添付する（動画、ログ、サーバー側の履歴など）

原因切り分けの考え方もあわせて知りたい人は、こちらが役立ちます。
原因切り分けのコツはこちら

デバッグの基本の進め方も整理しておくと、報告の質が安定します。
デバッグの進め方の基本はこちら

不具合報告書テンプレート（コピペOK）

この見出しでわかること：コピペで使えるテンプレと、埋め方の型が分かります。

まずは、テンプレを「毎回この順番で埋める」だけでOKです。文章が苦手でも、項目がそろえば十分に伝わります。

テンプレート本文（テキスト）

そのまま貼って使える形にしています。不要な行は削ってください。

ポイントは「発生手順→結果→期待」の流れを崩さないことです。読む側が同じ順番で検証できます。

表形式テンプレート（スプレッドシート向け）

スプレッドシートや表で管理している場合は、列を固定すると漏れが減ります。

• タイトル
• 環境
• バージョン
• 手順
• 実際の結果
• 期待する結果
• 頻度
• 影響範囲
• 添付

表にすると「手順」と「結果」が短くなりがちなので、手順だけは別セルで番号付きにするのがおすすめです。

タイトルの型テンプレート

タイトルは迷いがちなので、型を作っておくと速いです。

• 画面名で起きる現象
  例：結果画面で確定ボタンが反応しない
• 条件と現象
  例：回線が4Gのとき、ログイン後に画面が真っ白になる
• 操作と現象
  例：アイテムを使用すると所持数が減らない
  

例文でわかる良い報告と悪い報告

この見出しでわかること：同じ事象でも“伝わる報告”と“手戻りが増える報告”の違いが分かります。

悪い例は何が問題か

悪い例（よくある形）です。

結果として「環境は？」「手順は？」「頻度は？」と追加質問が増え、修正が遅れます。

良い例はどこが良いか

同じ内容でも、こう書けると一発で伝わります。

良い例のポイントは、読む側が同じ順番で再現できることです。
また、影響範囲が書かれているので、優先度判断が速くなります。

提出前チェックリストで漏れを潰す

「テンプレは埋めたつもり」でも、抜けが出るのは普通です。提出前に次だけ確認すると、追加質問が減ります。

• 端末／OS／バージョンが書けている
• 手順が「1行1操作」になっている
• 実際の結果と期待する結果がセットになっている
• 頻度が入っている
• 画像や動画が“現象の瞬間”になっている

再現しない不具合の書き方

この見出しでわかること：再現しない不具合でも“調査が進む報告”にする方法が分かります。

再現しない不具合は、報告が難しいぶん「情報の残し方」で勝負が決まります。
ポイントは「条件の当たりを付ける」「仕様の可能性も逃がす」「回避策があれば共有する」です。

条件の当たりを付ける書き方

再現しない場合、完璧な手順は書けなくてOKです。代わりに、次のように“起きたときの状況”をできるだけ残します。

• いつ：日時、時間帯
• どこ：画面名、シーン
• 直前：直前までの操作の流れ
• 状態：回線、端末の発熱、バックグラウンド状況、ストレージ残量
• 兆候：動作が重い、読み込みが長い、音が途切れた など

書き方の例はこんな感じです。

ここまで書けると、調査担当は「通信」「画面遷移」「キャッシュ」などの当たりを付けやすくなります。

仕様の可能性があるときの書き方

仕様か不具合か分からないときは、断定せずに“確認したい点”として書きます。

• 期待する結果：〇〇になる想定
• 確認したい点：仕様として〇〇が正しいか

この形にすると、仕様確認の回答が返ってきやすく、無駄な議論が減ります。

一時回避策がある場合の書き方

回避策がある場合は、ユーザー影響を下げられるので重要です。

• 回避策：アプリ再起動で復帰する
• 回避策：別回線に切り替えると発生しない

「回避策がある＝優先度が下がる」とは限りませんが、判断材料として価値が高いです。

報告を出す前に確認するチェックリスト

この見出しでわかること：提出前に見落としがちなポイントを、短時間で点検できます。

再現手順を短く切って再チェックする

自分で読み返して「同じ操作ができるか」を確認します。
手順に「など」「いろいろ」「適当に」が入っていたら、ほぼ追加質問が来ます。

環境とバージョンを書き切る

端末、OS、回線、バージョンが入っているか確認します。
迷ったら「多めに書く」でOKです。

添付資料の抜けを潰す

添付がある場合は、次を確認します。

• 現象が写っている（前後だけ、真っ黒だけになっていない）
• 操作が分かる（指の動き、タップ位置が分かる）
• どの瞬間の添付か説明がある（例：確定ボタン押下の瞬間）

仕様の可能性があるときの書き方を添える

仕様疑いのときは「断定しない」一文があるだけで、チーム内の摩擦が減ります。
「不具合だと思う」ではなく「仕様として正しいか確認したい」を使います。

初心者がやりがちな抜けを、さらに網羅的にチェックしたい人は、こちらも役立ちます。
初心者がやりがちな抜けを減らすチェックリスト

不具合報告の質を上げると評価が上がる理由

この見出しでわかること：不具合報告が上手くなると、仕事の評価や次のチャンスにどう繋がるかが分かります。

役割の説明で迷う人は、まず「デバッグとテストの違い」を整理すると話が通りやすくなります。
デバッグとテストの違いを整理したい人はこちら

報告の質は修正コストを下げて信頼になる

不具合報告が分かりやすい人は、チーム全体の時間を増やします。

• 追加質問が減る＝調査の着手が早い
• 再現が速い＝修正までのリードタイムが短い
• 情報が揃う＝優先度判断がしやすい

結果として「この人に任せると速い」という信頼が積み上がります。
評価は、派手な成果だけでなく“手戻りの少なさ”でも上がります。

面談で使えるアピール例

経験者の人は、面談で次のように言語化できると強いです。

• 不具合報告では、手順・環境・頻度・期待結果をテンプレで統一していた
• 再現しない事象は、発生時の状況や証拠を残して調査が進む形にしていた
• 影響範囲を言語化して、優先度調整に使える情報を出していた

よくある質問（FAQ）

この見出しでわかること：現場で詰まりやすい疑問を、短く解決できます。

再現しない場合はどう書く

完璧な再現手順が書けなくても大丈夫です。
代わりに「起きたときの状況」と「証拠（動画・ログ）」を残し、条件の当たりを付けられるようにします。本文の「再現しない不具合の書き方」のチェック項目を、そのまま使ってください。

仕様か不具合か分からない場合はどうする

断定しないで、「仕様として正しいか確認したい」と書きます。
期待する結果と、確認したい点を分けると、議論が荒れにくくなります。

スクリーンショットが撮れない場合はどうする

撮れない事情がある場合は、その理由と代替を添えます。

• 代替：文章で画面の文言をそのまま書く
• 代替：動画が難しければ、現象前後の複数枚を添付する
• 代替：ログが取れるならログを添付する

「一次情報が何もない」状態だけは避けるのがコツです。

端末情報が分からない場合はどうする

分かる範囲でOKです。端末名が曖昧なら「メーカーと機種」「OSのメジャー番号」だけでも書きます。
あとで追記できるように「端末情報は確認中」と一言添えるのも有効です。

動画やログを共有できない場合はどうする

社外共有が禁止などの制約があるなら、報告に明記します。

• 共有制約：社外共有禁止のため添付なし
• 代替：現象の瞬間の画面文言、発生時刻、操作ログ（書ける範囲）を記載

制約があるだけで“情報不足”扱いされないよう、先に書いておくのがポイントです。

まとめ：テンプレで最短で伝わる不具合報告を書く

不具合報告は、才能ではなく型です。今日からは次の流れで十分です。

• まず必須の8項目をそろえる
• 手順は短文で分割する
• 実際の結果と期待する結果をセットにする
• 再現しないなら状況と証拠を残す
• 提出前にチェックリストで漏れを潰す

報告の質が上がると、現場の信頼が増え、任される範囲も広がります。
デバッグ経験を活かして次のキャリアにつなげたい人は、こちらも参考にしてください。
デバッグ経験を活かせる仕事の探し方