個人開発の公開後②：「動きません」をどう受け取る？ 不具合報告の聞き方と再現

※本記事にはアフィリエイトリンク（広告）が含まれます。Amazonのアソシエイトとして、ゲームのタネは適格販売により収入を得ています。

「動きません」「途中で止まりました」。公開後に届く不具合報告は、短い一文だけのことがよくあります。そのままでは、どこで何が起きたのか分からず、直しようがありません。

報告してくれる人の多くは、開発に詳しいとは限りません。不具合を直すには、報告しやすい窓口を用意し、再現に必要な情報を無理なく聞き、自分の手元で再現できたかを確かめる流れが必要です。

第1回では、届いた声を「すぐ直す」「調べる」「記録する」に分けました。今回は、その中の不具合報告を扱います。

報告の窓口を一つにまとめる

報告がレビュー、SNS、メールに散らばると、同じ問題かどうかの判断や、対応済みかの管理が難しくなります。配布ページや作品内の分かりやすい場所に、不具合報告の窓口を一つ示します。フォーム、メールアドレス、配布サイトの掲示板など、続けて見られる手段を選びます。

他の場所で報告を見つけたときは、窓口を案内するか、自分で窓口側の一覧に書き写します。報告者に何度も同じ説明を求めないようにするためです。

Godotの報告フォームが聞いていること

ゲームエンジンのGodotは、GitHubの不具合報告フォームで、確認したバージョン、OSなどのシステム情報、何が起きてどうなるはずだったかの説明、再現手順、そして不要なフォルダーを除いた小さな再現用プロジェクトを求めています。エラーメッセージやコードは、画像ではなく文字で貼るよう案内しています。Godotの不具合報告フォーム（GitHub）

これは開発者向けのエンジンの報告フォームで、ゲームやアプリを遊ぶ一般の利用者にそのまま求める内容ではありません。ただ、「どの版で」「どの環境で」「何をしたら」「何が起き、何を期待したか」という骨組みは、自作の報告窓口でも参考になります。

利用者向けに、聞く項目を絞る

項目が多すぎると、報告そのものをやめてしまう人もいます。必須は少なくし、分かれば教えてほしいものは任意にします。

バージョンを聞くなら、作品のどこを見れば分かるかを先に用意しておきます。ログファイルや保存データを送ってもらう場合は、そこに個人情報が含まれないか、受け取ったデータをどう扱い、いつ削除するかも決めて伝えます。

自分の手元で、再現できるかを確かめる

報告を受けたら、まず同じ手順で同じ問題が起きるかを試します。架空の探索ゲームで「洞窟に入ると止まる」という報告なら、報告と同じバージョンで、同じ場所に同じ状態で入ってみます。これは説明用の例です。

手元で再現できないことは、不具合がないことの証明ではありません。報告者の環境でだけ起きる問題もあります。「こちらでは起きません」で終わらせず、分かったことと分からないことを分けて記録します。

報告者への返事は、短く具体的に

報告してくれた人には、受け取ったこと、今の状況、次に何が起きるかを伝えます。すぐ直せない場合も、回避方法があれば知らせます。

• 受け取ったことへのお礼
• 再現できたかどうか
• 追加で教えてほしいこと（あれば一つか二つに絞る）
• 修正の見込み、または回避方法

修正の時期は、確実でなければ約束しません。「次の更新で直します」と書いた後に間に合わないと、信頼を損ねます。「調査中です」「直せたら更新内容でお知らせします」のように、実際の状況に合わせて書きます。

不具合報告の受け取り方を決める

直した不具合をいつ更新として出すかは、第3回で考えます。

不具合の見つけ方を本で学びたい方へ

ソフトウェアテストの入門書では、不具合の再現手順の書き方や、報告を整理する方法が載っているかを目次で確認してみてください。開発者向けの専門書も多いため、対象読者も確かめます。

Amazonでソフトウェアテストの入門書を探す（広告）

リンク先は書籍の検索結果です。特定の本を推薦するものではありません。価格、刊行年、対象読者を確認して選んでください。

Godotの不具合報告フォームは2026年11月8日に確認しました。表の聞き方や判断は説明用の例です。

前回：第1回　連載目次　次回：第3回