新作週は、友人から「ここで落ちる」「このUIだけズレる」というゲームのバグ報告がDiscordに飛んでくることが増えます。スクショはあるのに、開発側が欲しいのは再現手順・ビルド番号・入力デバイスまで揃ったIssue文です。私はWeb制作の合間に小規模ゲームのQA手伝いをすることがありますが、Cursor ゲーム バグ報告を毎回ゼロから書くより、スクショと箇条書きメモをCursorに渡してGitHub向けの体裁に整える方が、報告の抜け漏れが減りました。
この記事でわかること
- バグ報告用の最低限フィールド（環境・手順・期待結果・実際の結果）
- スクショ付きメモをCursorでIssue Markdownに整形する流れ
- 公開テスト版やオンライン対戦で書いてはいけない情報のマスク方
先に結論
- 向いている人: インディー開発のQA手伝い、フリーランスでゲームUIのフィードバックをGitHubに上げる人。PS5・Switch・Win11など複数環境の報告を1つのリポジトリに集めたい人
- 向いていない人: 公式のバグ報告フォームだけ使う大規模タイトル（フォーム項目が固定で、GitHubを使わない案件）
- 私のおすすめ: Issueテンプレ1枚とCursor用の短いプロンプトをリポジトリに置き、スクショは
attachments/かIssueドラフトにまとめてから整形する
私は再現できないバグほど、手順の番号を細かくします。感覚メモをそのまま送るより、Cursorで「手順だけ箇条書きにして」と頼む方が早いです。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
エディタをそろえるならCursorでリポジトリを開き、.github/ISSUE_TEMPLATE/bug_report.ymlがあるか先に確認してください。Win11側のスクショ整理はShareXでクリップをSSDへ自動整理、ゲーム中の誤キー対策はWindowsキー誤爆を止める手順が近い文脈です。制作フロー全体はFigma制作フローの柱も参照してください。
GitHub Issueに載せる最低限の項目
開発者が再現しやすい報告は、次の5ブロックに分かれていることが多いです。
| ブロック | 書く内容 | 抜けやすい例 |
|---|---|---|
| 環境 | OS／機種／ゲームバージョン／表示言語 | パッチ日だけでビルド番号が無い |
| 手順 | 番号付きで操作順（3〜7步が目安） | 「たまに」だけで操作が曖昧 |
| 期待 | 本来どう見える／動くべきか | 仕様未確認の推測 |
| 実際 | 落ちる／ズレる／音が出ない等 | スクショだけで文章が無い |
| 補足 | セーブデータ・周回数・オンライン可否 | 個人名・フレンドコード |
オンライン対戦やクロスプレイが関係する場合は、NATや音声設定の記事（例:PS5対戦前のNATと音声）と矛盾しないよう、「ソロで再現するか／マルチ限定か」を最初の段落に書きます。
スクショとメモの集め方（Cursorに渡す前）
- 再現直後にスクショ（Win11はWin+Shift+S、PS5はシェアボタン）
- 同じセッションで音声メモまたはDiscordの自分用スレに、操作を短く喋る
- ファイル名は
20261004_stage3_boss_ui_01.pngのように日付＋場所＋連番 - クラッシュなら直前の操作だけをテキストでも残す（ログ全文は別添）
個人情報はここで削ります。ユーザー名・部屋ID・IP・請求メールは黒塗りまたはトリミング。私はCursorに渡す前に、画像から文字が読める部分だけPaintで塗りつぶしてからフォルダに入れます。
スクショは「現象」、テキストは「手順」に分けると、Cursorの出力がIssue向きにまとまりやすいです。
CursorでIssue文に整える手順
Cursorでバグ報告用リポジトリを開き、次の流れで進めます。
reports/draft/にスクショとnotes.txt（箇条書きメモ）を置く- チャット（Agentまたは通常）に、リポジトリ内の
docs/bug-report-prompt.mdを参照させる - 出力を
reports/issue-draft.mdに保存し、人間が手順の順序だけ読み直す - GitHubの「New Issue」に貼り付け、スクショをドラッグ添付
- ラベル（
bug/platform:win11等）をテンプレに従って付与
プロンプト例（docs/bug-report-prompt.md に置く用）:
notes.txt と同フォルダのスクショファイル名を参照し、GitHub Issue用Markdownを日本語で書いて。
見出しは ## 環境 / ## 再現手順 / ## 期待する結果 / ## 実際の結果 / ## 補足。
再現手順は番号リスト。推測は「未確認」と明記。個人情報は出力しない。
ビルド番号が取れないコンソール版は、パッチ公開日とソフトのバージョン表示画面のスクショを補足に入れます。Steam版ならライブラリのプロパティからビルドIDを控えると、開発側が助かることが多いです。
Issueを閉じるまでの運用（重複を減らす）
小規模チームでは、同じ現象が別スレッドで何度も上がりがちです。私は次のルールをREADMEに書いてからCursor運用に入ります。
- 新規報告の前に、GitHubのIssue検索でキーワード（ステージ名・エラー文言）を探す
- 既存Issueがある場合はコメントで再現率だけ追記し、新規は作らない
- 修正版が配信されたら、同じ手順で再テストし、結果をコメントに残す
- クローズは開発側の判断に任せ、QAは「再現不可」になったらログ用にコメントする
Cursorには「既存Issue #12 と同一か判定し、同一なら追記コメント案だけ出す」と指示すると、重複Issueの量産を防げます。タイトル案は 【Win11】ステージ3でUIがはみ出す のように環境を先頭に置くと、後から検索しやすいです。
テンプレをリポジトリに置く（再利用）
.github/ISSUE_TEMPLATE/bug_report.yml が無い小規模リポジトリでは、Markdownテンプレを1枚足すだけでも報告品質が揃います。
| フィールド | 必須 | 入力例 |
|---|---|---|
| プラットフォーム | はい | Win11 / PS5 / Switch2 |
| バージョン | はい | v1.0.3（2026-10-03パッチ後） |
| 再現率 | 任意 | 3/3回、初回のみ等 |
| セーブ共有 | 任意 | 不可／要相談 |
FigmaでUIズレを報告する案件では、期待する見た目の参照フレームリンクを補足に付けます。書き出しルールはFigmaの9スライス書き出しと同じく、数値メモがあると開発側が早いです。
プラットフォーム別の追記ポイント
Win11（PC）
- フルスクリーン／ボーダーレス、解像度、リフレッシュレート
- GPUドライバのおおよその版（設定画面のスクショ可）
- Xbox／Steam／Epicのどの起動経路か
PS5
- パフォーマンスモード／品質モード
- 外部SSDインストールか内蔵か
- コントローラーは純正／背面ボタン付きか
Switch2（該当時）
- 携帯／TVモード、ドック経由の有無
- ローカル通信かオンラインか
クラウドゲーム・リモートプレイ
画質や入力遅延は環境依存が大きいので、回線種別（有線LAN／Wi-Fi 6）と、クラウド側のデータセンター地域が分かる範囲で書きます。iPhone経由のリモートプレイ設定はiPhone 17のPS Remote Play通信量のように、別記事で整えた値を環境欄にコピーすると矛盾が減ります。
ここは体験と仕様の境界をはっきり書きます。「公式フォーラムでは未記載」「自分の環境だけ」など、調べた範囲と推測を分けます。私が触った範囲と、公式ドキュメントで確認した範囲は、Issue文の末尾に1行ずつ分けて書くようにしています。
複数機種で試した結果は表にすると、Cursorの下書きを直すときも議論が短くなります。
よくある失敗と直し方
- スクショだけ送って手順が無い … notes.txtに音声メモを書き起こし、Cursorで番号リスト化
- 「バグです」だけで期待結果が無い … 仕様ページやチュートリアル画面のスクショを「期待」に添付
- セーブデータ丸ごと添付 … 個人情報と容量の問題。再現手順で足りるか先に聞く
- 同じバグを毎回別文体 … Issueテンプレとプロンプトを固定し、Cursorの出力を土台にする
よくある質問
Q. 再現できないバグはどう書きますか？
A. 再現率（例: 1/5回）と、試した手順のバリエーションを列挙します。「たまに」だけにせず、プレイ時間・周回数・特定ボス前後など、分かる範囲の条件を補足に書きます。開発側がログを仕込む判断材料になります。
Q. Cursorにスクショを直接読ませるべきですか？
A. 現象の説明やUI文言の転記には向きますが、個人情報の混入リスクがあるので、私はマスク後の画像だけ渡します。手順と環境はテキストを正本にし、画像はGitHub Issue添付で送ります。
Q. フリーランス契約で報告内容がクライアント資産になりますか？
A. 契約次第です。報告リポジトリの権限・Issueの公開範囲は、着手前にディレクターへ確認してください。経費やツール契約の整理はゲームソフトをfreeeで仕訳の文脈とも切り離して考えます。
Q. 英語のIssueに翻訳すべきですか？
A. 海外開発チームなら英語が無難です。日本語下書きをCursorに「技術用語はそのまま、手順だけ英語」と指示し、人間が固有名詞を最終確認する運用が現実的です。
まとめ
Cursor ゲーム バグ報告は、スクショと短いメモをIssue用Markdownに揃える作業を短縮するためのワークフローです。テンプレとプロンプトをリポジトリに置き、環境・手順・期待・実際の4点を毎回同じ見出しにそろえるのが肝です。
今日やること（チェック項目）
- 直近で見た不具合1件を選び、スクショと notes.txt を1フォルダにまとめる
docs/bug-report-prompt.mdをコピーし、Cursorで issue-draft.md を生成する- 手順の順序と個人情報マスクを人間が確認してからGitHubに貼る
- ラベルとプラットフォーム名がテンプレと一致しているか見直す
制作フロー全体は制作フロー入口、コンソール設定の柱はゲーム機の選び方もあわせて参照してください。
