※本記事にはアフィリエイトリンク（広告）が含まれます。Amazonのアソシエイトとして、ゲームのタネは適格販売により収入を得ています。
作品を公開すると、ひと区切りついた気持ちになります。ところが公開した直後から、思っていなかった環境で起動しない、操作に迷う、反応がほとんどない、といったことが分かってくる場合があります。
公開後に何でも一度に直そうとすると、手が回らなくなります。最初の1週間は、何を見て、何をすぐ直し、何を記録だけにするかを決めておくと、慌てずに対応できます。
この連載では、ゲームやアプリを一人や小さなチームで公開した後の対応を、全5回で考えます。「作る範囲」第5回で決めた公開条件と既知の問題を、ここから使います。
公開直後に見る場所を、先に決めておく
反応は、配布ページのコメント、レビュー、SNS、問い合わせフォーム、メールなど、いくつもの場所に届きます。全部を常に見ようとすると、見落としと疲れが増えます。公開前に、確認する場所と頻度を決めておきます。
| 見る場所 | 何が分かるか | 確認の目安（例） |
|---|---|---|
| 不具合報告の窓口 | 起動できない、進めない、データが消えるなどの問題 | 公開直後は1日に数回 |
| レビュー・コメント | 分かりにくい点、期待とのずれ、気に入られた点 | 1日1回 |
| 配布ページの数値 | 見られた数、入手された数の推移 | 数日ごと |
| SNSや外部の話題 | 紹介のされ方、自分の窓口に届かない声 | 余裕があるときに |
頻度は例です。仕事や学業と並行しているなら、無理のない回数にします。大事なのは、重大な問題が届く窓口を一つ決めて、そこだけは見落とさないことです。
最初に確かめるのは「使い始められるか」
公開直後に最も影響が大きいのは、入手した人が使い始められない問題です。起動しない、最初の画面から進めない、保存データが壊れる、といった報告は、細かな見た目の指摘より先に確認します。
架空の探索ゲームなら「特定の環境で起動直後に止まる」、架空の画像ツールなら「保存時に元の画像を上書きしてしまう」といった報告です。これは説明用の例で、実際の報告ではありません。こうした問題は利用者が時間やデータを失うため、原因が分かるまでの間、配布ページで状況を伝えることも考えます。
報告を「すぐ直す」「調べる」「記録する」に分ける
届いた声は、受け取った順ではなく影響の大きさで並べます。迷ったときは、次のように三つに分けます。
| 分類 | 状況の例 | 対応の例 |
|---|---|---|
| すぐ直す | 多くの人が起動できない、進行不能、データの消失や上書き | 再現を確かめ、修正版を出す。直せない間は回避方法を知らせる |
| 調べる | 一部の環境だけで起きる、条件がまだ分からない | 報告者に環境や手順を聞き、再現を試す |
| 記録する | 好みの違い、追加機能の要望、軽い表示の乱れ | 一覧に残し、次の更新を考えるときに見直す |
表は判断例です。「記録する」は「無視する」ではありません。同じ要望が繰り返し届けば、優先度を見直すきっかけになります。報告の受け取り方は第2回で詳しく扱います。
Steamの公式ガイドは、修正の早さと告知を勧めている
Steamworksのドキュメントは、アップデートやパッチの配信を顧客とのコミュニケーションの最良の方法の一つとし、問題が報告されたら、妥当な範囲でできるだけ早く直すことに勝る対応はないとしています。また、更新を配信するたびにコミュニティハブでお知らせを出し、何が変わったのかをプレイヤーが分かるようにすることを勧めています。Steamworksドキュメント：アップデート
これはSteamで配信する場合の公式の助言です。他の配布サイトやアプリストアでは、使える機能や手順が異なります。また、早く直すことを勧めるもので、確認を省いてよいという意味ではありません。直した版も、公開前と同じように配布物で確かめます。
修正したら、何を直したかを伝える
修正版を出しても、利用者には何が変わったか分かりません。更新のたびに、短い更新内容を書きます。
- バージョン番号と公開日
- 直した問題（利用者から見た症状で書く）
- まだ残っている既知の問題と、回避方法
- 報告してくれた人へのお礼（個人を特定しない形で）
「軽微な修正」とだけ書くと、報告した人は自分の問題が直ったのか分かりません。症状で書けば、同じ問題で困っていた人も更新を試せます。
最初の1週間の確認表
| 書き出すこと | 自分の作品のメモ |
|---|---|
| 不具合報告を受け付ける窓口 | ＿＿＿＿＿＿＿＿ |
| 見る場所と、確認する頻度 | ＿＿＿＿＿＿＿＿ |
| 「すぐ直す」に入れる問題の条件 | ＿＿＿＿＿＿＿＿ |
| 公開時点の既知の問題と回避方法 | ＿＿＿＿＿＿＿＿ |
| 更新内容を知らせる場所 | ＿＿＿＿＿＿＿＿ |
| この1週間で対応できる時間 | ＿＿＿＿＿＿＿＿ |
対応できる時間を書いておくと、すべてに応えようとして疲れ切ることを防げます。費用や対応時間から続け方を見直す考え方は、値付けと収益化 第5回も参考にしてください。
公開後の運営を本で学びたい方へ
個人や小さなチームでのゲーム開発を扱う本では、公開後の不具合対応、更新、利用者とのやり取りまで書かれているかを目次で確認してみてください。
リンク先は書籍の検索結果です。特定の本を推薦するものではありません。価格、刊行年、対象読者を確認して選んでください。
Steamworksドキュメントは2026年11月8日に確認しました。表の頻度や分類は説明用の例で、特定の作品の実績ではありません。本記事でSteamworksの機能を実際に操作した検証は行っていません。
