発売後のゲーム運用｜AIゲーム開発のアップデート・レビュー対応・セール

ゲームは発売したら終わりではありません。発売直後の不具合を直し、更新を重ね、レビューやコミュニティの声に向き合い、セールで新しい買い手に届け、次の作品のための振り返りを残す。これが発売後の運用です。発売（「ゲームの発売（リリース）手順」）の後に続く、いちばん長い工程です（全体は「ゲーム開発の全工程マップ」）。

本記事では、個人〜少人数のインディーゲームを Steam で売る場合を例に、発売後に何を・どの順で・どう判断するかを解説します。Steam の規則と数値は2026年10月時点の公式ドキュメント（Steamworks ドキュメント）で確認したもので、変わることがあります。

発売後の運用とは

ひとことで：発売した作品を直し、育て、売り続け、次の作品のための学びを残す仕事です。

運営型のオンラインゲームでは更新を続けること自体が仕事の中心で、「ライブ運用（LiveOps）」とも呼ばれます。買い切りのインディーゲームでも、規模は小さいながら同じ種類の仕事が生まれます。大きな会社では QA（品質保証）・コミュニティ・マーケティングの担当が分かれていますが、個人や少人数では次の作品の開発と並行して自分たちで回すので、何にどれだけの時間を使うかを先に決めておきます。

時期（例）	主な仕事
発売直後（〜2週間）	不具合の受け付けと急ぎの修正、レビューと掲示板の確認
最初の数か月	小さな更新の積み重ね、最初のセール、数字の確認、振り返り
その後	大きな更新・追加コンテンツ・移植の判断、四季のセール、サポートを続ける期間の判断

発売直後の不具合対応

ひとことで：報告を重さで並べ、急ぎのものだけを小さく直し、ベータブランチで確かめてから一般に配り、だめなら前のビルドに戻します。

報告を集めて、重さで並べる

報告は、Steam の掲示板・レビュー・メール・Discord・SNS など、ばらばらの場所に届きます。まず置き場所を1つに決め、届いたものを転記して重さで並べます。

重さ	例	対応
最優先	起動しない、進行できない、セーブが壊れる、多くの人が遭遇する	急ぎの修正（ホットフィックス）で直す
高	一部の環境だけで落ちる、回避策がある詰まり	次の小さな更新で直す
中	表示の崩れ、翻訳の誤り、操作の不便	まとめて直す
低	要望、好みの違い	記録して、次の計画で判断する

報告の書き方と優先度の付け方は「ゲームのデバッグとQA」で解説しています。

ホットフィックスの進め方

ホットフィックスは、もとは稼働中のシステムに当てる修正のことで、今は「通常の更新の予定を待たずに急いで出す修正」の意味で使われることが多い言葉です。

• ① 再現する：報告どおりに起きるかを手元で確かめ、起きる条件を絞る
• ② 直す範囲を絞る：急ぎの修正に、ほかの改善を混ぜない
• ③ 自動テストと、直した所の確認を通す
• ④ ベータブランチで確かめる：Steam のビルドの配信の仕組み（SteamPipe）では、配信先を「ブランチ」で分けられ、一般の購入者に届く default ブランチとは別に、パスワードも設定できるベータブランチを作れます。協力してくれるプレイヤーには、ライブラリの「プロパティ」→「ゲームのバージョンとベータ」で切り替えてもらいます
• ⑤ default ブランチに出す：default への公開は管理画面で手動で行います（ベータブランチはスクリプトから公開できます）
• ⑥ 知らせる：パッチノート（更新内容のお知らせ）を投稿し、報告してくれた人に返信する

版番号は修正のたびに上げ、パッチノートと報告を版で突き合わせられるようにします。筆者のゲームでは、通信に影響する修正では必ず版番号を上げると決めています。なお SteamPipe は、ファイルを約1MBの塊に分けて変わった塊だけを配りますが、素材をまとめたパックファイルの並びが変わると、小さな修正でも更新が大きくなることがあります（公式ドキュメント）。急ぎの修正で素材の並べ替えはしません。

ロールバック（前のビルドに戻す）

直したつもりで別の不具合を出してしまったら、管理画面で以前のビルドを default に設定し直して戻せます。戻すかどうかは、「新しい不具合の重さ」と「戻すと再び出る古い不具合の重さ」を比べて決めます。

戻すときに危ないのがセーブデータです。新しい版で保存したセーブを古い版が読むと、壊れたり上書きされたりすることがあります。筆者のゲームでは、セーブデータを次の方針で守っています。

• 全ファイルに版番号を持たせる
• 安全に書き込む（一時ファイルに書く→控えを取る→入れ替える）
• 自分より新しい版のファイルは読み取り専用で扱う
• 壊れたファイルは隔離し、プレイヤーには一度だけ知らせる
• 過去の版のセーブを凍結して保存し、テストで読み込む

ブラウザ版のゲームでは、公開する版を日付ごとのフォルダに分け、旧版を戻し用に残しています。霧将棋は、公開から翌日の未明までに5つの版を出しました。

アップデートの計画と告知

ひとことで：直す・足す・磨くを小さな単位に分けて予定を立て、更新のたびに Steam のイベント投稿で知らせます。

何をいつ出すか

更新の中身は、不具合の修正、遊びやすさの改善、バランスの調整、追加の内容、対応言語や対応機種の追加などです。発売直後は小さな修正を短い間隔で出し、落ち着いたら中身をまとめた大きめの更新を無理のない間隔で出す、という流れになることが多いでしょう。今後の予定（ロードマップ）を見せるとファンの期待を保てますが、日付や機能を約束しすぎると、遅れたときに信頼を失います。

Steam のイベント投稿

Steam では、更新のお知らせを「イベント」として投稿します。更新の種類は3段階です（公式ドキュメント）。

種類	使いどころ	主な表示
パッチノート（Small Update / Patch Notes）	小さな修正	ダウンロード画面の更新内容、ニュースとライブラリの簡易表示、ストアページからのリンク。ライブラリ上部の「What’s New」には出ない
通常の更新（Regular Update）	中くらいの更新	3段階の中間の扱い
大型アップデート（Major Update）	その年の大きな節目になる更新	ストアページ・コミュニティハブ・ライブラリ。フォロワーに届き、「What’s New」に出る対象にもなる

イベントの投稿にはカバー画像（800×450px）が要ります。大きな更新は、Update Visibility Rounds（更新の露出枠）を使うと、ストアのトップページで、その作品を持っている人とウィッシュリストに入れている人に紹介されます。2026年10月時点の公式ドキュメントでは、使えるのは1作品5回（早期アクセスと正式版で共通）、1回は最長30日か表示100万回まで。直近30日以内のお知らせが必要で、四季のセール中は表示されず（その日数も30日に数える）、発売時の露出の期間が終わってから使えます。カプセル画像に「大型アップデート」などの文字を入れたいときは、期間限定の差し替え（最大1か月・対応言語すべてに翻訳）を使います。

早期アクセス中の運用

早期アクセスでは、12か月以上、default ブランチへのビルドの適用も、更新の種類のイベント投稿もないと、ストアページに「しばらく更新されていない」旨の注意書きが付きます。公式は、更新でセーブが引き継げなくなるとわかっているなら前もって伝えること、大きな更新や予想外の遅れはお知らせで共有することを勧めています。

パッチノートの書き方

パッチノートは、版番号と日付のあとに「新しく入ったもの」「変わったこと」「直した不具合」「既知の不具合」「セーブや互換性の注意」の順で書くと読みやすくなります。直した不具合は「3章のボス戦で、敵が画面の外に出て進めなくなる不具合を直しました」のように、どこで・何が起きて・どうなったかをプレイヤーの言葉で書き、社内の呼び名や関数名は書きません。Steam のパッチノートは題名と本文を埋めるだけで投稿でき、箇条書きをそのまま貼れます。

レビューとコミュニティへの向き合い方

ひとことで：レビューは傾向をつかむ材料として読み、返信は事実の補足に絞り、話し合いの場はルールを決めて育てます。

Steam のユーザーレビュー

レビューは誰のものも読めますが、評価の点数に数えるのは、Steam で購入して遊んだアカウントのレビューだけです（キーの有効化は数えません）。開発者は、レビューの詳細を開いて「公式の開発者の返信」を書けます。

公式ドキュメントは、返信について次のように案内しています。

• 返信が向くのは、レビューを書いた人が大事な情報を知らない場合や、すでに直した不具合に当たった場合
• すべてに返信しない。意見に反論しない（返信は元のレビューより注目を集めやすく、小さな話を大きな議論にしかねない）
• レビューを読む時間に上限を決め、大事な傾向をつかんだら開発に戻る
• 内容と関係のないレビューが急に集中した場合は、Valve に連絡する

読むときは、不評の理由を「不具合」「難しさ」「価格」「期待とのずれ」などに分けて数え、直せるものは更新の計画へ、期待とのずれはストアページの見直しへつなげます。返信は「ご報告ありがとうございます。3章で進めなくなる不具合は 1.0.3 で直しました」のように、事実だけを短く書きます。

コミュニティ運営

Steam のコミュニティハブ（作品ごとの交流の場）は、近日登場にした時点から使え、掲示板・スクリーンショット・ガイド・ニュースなどのタブがあります。掲示板は名前・公開範囲・投稿の権限を設定でき、モデレーター（管理を手伝う人）を任命できます。利用者から通報された内容は Valve のモデレーターが確認します。Discord や SNS へのリンクは、ストアページの設定（Basic Info）の External Links 欄に入れます。

掲示板には「よくある質問」「既知の不具合」「不具合報告のテンプレート（版番号・OS・手順・ログの場所）」を固定しておくと、同じやり取りが減ります。大きな会社ではコミュニティマネージャー（コミュニティ担当）が付きますが、個人なら見る時間を決め、毎日すべてに返さなくてよいことをルールに書いておきます。

セールの考え方

ひとことで：30日ルールの中で、四季のセールとテーマ別のイベントを軸に予定を組みます。

Steam の割引には、発売から30日・値上げから30日・割引の終了から次の割引まで30日、という3つの間隔の規則があります（詳しくは「ゲームの発売（リリース）手順」）。四季の大型セールは3つ目の規則の例外で、開始日の30日以上前に発売した作品が参加できます（値上げから30日の間は不可）。発売から30日の期間がセール中に明けた場合は、その時点から割引を設定して加われる、と公式は説明しています。

機会	2026年10月時点の公式情報
四季の大型セール	冬 2026年12月17日〜2027年1月4日、春 2027年3月18日〜25日、夏 2027年6月24日〜7月8日（予定）
テーマ別のイベント（フェス）	ジャンルや題材ごとに年に何度もある。割引した作品が優先だが、無料・近日登場・体験版のある作品も参加できる（条件はイベントごと）
ウィークロングディール	毎週月曜の10時（太平洋時間）から7日間
Valve が選ぶ特集枠	Daily Deal・Midweek Deal・Weekend Deal は2026年9月29日に新しい予定の受け付けを止め、2027年初めに手作業の掲載予定表をやめる予定

割引すると、ウィッシュリストの登録者に通知が届きます。条件は、20%以上の割引で、最も安いパッケージを含み、8時間を超えること。同じ作品の通知には2週間のクールダウンがあります。Valve の2016年の分析では、ウィッシュリスト経由の購入の63%が割引の時期でした（古い数字です）。割引率は、通知の届く20%以上か、過去の割引と比べてどうかを記録しながら決めます。早期アクセス中は常時割引ができない点にも注意します。

DLC・続編・移植

ひとことで：本編の数字と反応を見て、追加で売るか、次を作るか、別の機種に広げるかを決めます。

DLC（追加コンテンツ）は、Steam では本編の管理画面から作り、DLC ごとに別の AppID（Steam での作品の番号）が付きます。無料・有料のどちらも作れます。Valve のドキュメントは、発売日に DLC を同時に出すと、本編から内容を削って売っていると受け取られるおそれがある、と注意しています。DLC の返金は、購入から14日以内で、購入後の本編のプレイが2時間未満、かつ DLC を使っていなければ受け付けられます。

続編か DLC かは、後で述べる数字と振り返りで判断します。筆者は麻雀ゲームのエンジンを複製して、カードゲームなどの派生作を作りました。複製した直後に全テストが通る状態を足場にして、壊れた期間を作らない進め方です。別の機種やブラウザへの移植は「ゲームの移植とマルチプラットフォーム」で解説しています。

数字の見方

ひとことで：主な数字を同じ時間軸に並べ、「何をしたら・どう動いたか」をレビューと合わせて読みます。

数字	どこで見るか	見方
ウィッシュリスト	売上レポート（Sales & Activations Reports）の Wishlists（追加・購入・削除。前日分まで毎日更新、地域別もあり）	発売・セール・更新の前後の増減を見る
販売本数・売上	同じ売上レポート（地域別も）	発売週・セール・大型更新の前後を比べる
返金	売上レポートのパッケージごとの Refund Data（返金率と理由・コメント）	返金率＝期間中に返金された数÷その期間に買われた数。理由とコメントから、不具合・難しさ・期待とのずれを探す
プレイ時間	Steamworks の管理画面の数字や、ゲーム内の記録	中央値を、返金の条件の2時間や想定した1周の長さと比べる
ストアの流入	Store and Platform Traffic（表示回数・訪問・クリック率）と UTM の計測	外部リンクに UTM（流入元を見分ける印）を付けると、クリックから72時間以内のウィッシュリスト登録や購入を数えられる

Valve は「ウィッシュリストから売上を正確に予測する式はない」と明言しています。Valve の2016年の分析では、通知メールから1週間以内に買う割合は平均3.4%、ウィッシュリストの平均23%が最終的に購入・有効化につながりました。GameDiscoverCo の Simon Carless 氏の2024年4月の調査では、発売時のウィッシュリスト件数に対する発売1週目の販売本数（ウィッシュリスト経由以外も含む）は中央値で0.2倍で、2021年の同じ調査では作品により10分の1から5倍以上までばらつきました。返金率は、公式は目安を出しておらず、作品の経緯・価格・期待で大きく違い、発売直後やセールの後は週ごとに大きく動くと説明しています。

ポストモーテム（振り返り）の進め方

ひとことで：うまくいったこと・いかなかったことを事実と数字で集め、次の作品で変える行動にまで落として残します。

ポストモーテムは、ゲーム業界では主に、完成後の開発の振り返り（うまくいったこと／いかなかったこと）の記事や講演を指すことが多い言葉です。業界誌 Game Developer（旧 Gamasutra）の看板記事の形式で、その155本を分析した研究（Washburn ほか、2016年）もあり、日本のゲーム開発者向けの技術会議 CEDEC でも講演の分野の一つです。IT の運用では障害の振り返りの意味で使われ、Google の SRE（サービスの信頼性を保つ技術）の本は、誰も責めない（blameless）書き方を勧めています。

時期は、発売後の数字が落ち着いた頃（例えば1〜3か月後）に1回、大きな更新や事故の後に小さく1回、と決めておくと続けやすくなります。材料は、計画と実際の日程、決定の記録、計測の記録、レビューと返金の理由、不具合の件数、売上とウィッシュリストの推移、宣伝の時系列です。

項目	書くこと
目標と結果	最初に決めた目標（発売日・品質・売上など）と実際
うまくいったこと	事実と数字で3〜5個。なぜうまくいったか
うまくいかなかったこと	同じく3〜5個。人ではなく、仕組みや手順の問題として書く
次にやること	具体的な行動（チェックリストに足す・手順を変える・道具を作る）と、いつ・誰が
続けること	次の作品でも残す習慣

大事なのは最後の「次にやること」です。チェックリストや作業手順に書き足して、次の作品の最初から使える形にして初めて、振り返りが学びになります。

AIゲーム開発での発売後の運用

ひとことで：報告の仕分け・再現・修正・文章の下書きは AI に任せ、何を直すかと、プレイヤーへの言葉は人が決めます。

AI に任せやすいこと

• 報告とレビューの仕分け・要約・翻訳：掲示板・メール・レビューの文面を集め、不具合・動作の重さ・難しさ・価格・翻訳・要望に分けて数え、既知の不具合と結び付けます。外国語のレビューも同じ表にまとめられます
• 再現手順と修正：報告から再現の手順を書き、直した不具合が再発していないかを確かめる回帰テストを先に書いてから直します
• パッチノートの下書き：変更の記録から、プレイヤーの言葉のパッチノートを各言語で下書きします
• ポストモーテムの材料集め：決定の記録・計測の記録・日程を時系列に並べ、「うまくいった／いかなかった」の候補を出します

筆者の麻雀ゲームでは、発売前の試し遊びとして Codex に実際のビルドをマウスで遊ばせ（隔離した環境・3人の仮想プレイヤーの視点）、6件の指摘を受けました。「実行時のエラーがテストの失敗に数えられていない」問題も見つかりました。それを Claude Code が全件コードで裏取りし（誤報は0件）、優先順に直しています。AI の報告を、別の AI が根拠で確かめる二段構えです。

翻訳は、日本語だけで開発し、翻訳した時点の控えとの差分を節目でまとめて訳す方式です。未翻訳の所は英語→日本語の順で代わりに表示されるので、緊急の修正では英語だけを同時に訳し、ほかの言語は次の節目に回しています。日々の決定は、メモ・計画書・計測の記録の3か所に残しているので、振り返りの材料もそこから AI に集めさせられます。

毎朝、前日の報告とレビューをまとめる作業は、定期実行の仕組みに載せることもできます（「Claude Code 自動化」参照）。ただし、自動にするのはまとめるところまでで、投稿や公開は含めません。

人が決めること

AI と人の分担は、次のように分けると迷いません。

作業	AI がすること	人が決める・確かめること
報告の仕分け	分類・件数・既知の不具合との対応づけ・翻訳	重さの判断、直すかどうか
修正	再現テスト・修正・全テストの実行	ベータブランチでの手触り、default に出すか・戻すか
文章	パッチノート・お知らせ・返信の下書きと翻訳	言葉づかい、できない約束をしていないか
振り返り	記録を時系列にまとめ、候補を出す	何を学びとして残すか

特に「何を直さないか」は人が決めます。「難しすぎる」のような声に全部応えると、作品の芯がぶれるからです。セールの時期と割引率も人の判断です。

AI で修正が速くなると、重心は「直す」から「確かめる・選ぶ」に移ります。外国語のレビューも AI の翻訳で同じ表に並ぶので、拾える声が増える分、どの声を優先するかの判断も増えます。直せる速さに任せて更新を出しすぎると、更新のたびに新しい不具合を持ち込む危険も増えます。

落とし穴

• AI の返信を自動で投稿しない：返信は元のレビューより注目を集めやすい、と公式も注意しています。AI の下書きは、皮肉を読み違えたり、できない修正や日付を約束したりしかねないので、1件ずつ人が確かめてから出します
• 急ぎの修正で別の所を壊す：修正は必ず自動テストを通してから出します。筆者の麻雀ゲームは提出時に約3.2万件の自動テストを失敗0で通し、小さな変更は約30秒の簡易版で確かめています（最初に全スクリプトの文法チェックを走らせ、壊れたテストが見かけだけ合格になるのを防ぐ）
• 報告どおりに直して、仕様から外れる：AI は報告の文面に合わせて直そうとするので、「敵が強すぎる」という報告から、意図した難しさまで下げてしまうことがありえます。仕様と設計の意図も一緒に渡します
• テストが本物のデータを汚す：筆者は、テストが自分の実際のセーブデータを汚す事故（設定を既定値で上書き・実績を書き込み）を経験し、退避と隔離の仕組みを入れました
• 個人情報を渡しすぎる：報告にはメールアドレスやアカウント名が含まれることがあります。AI に渡すのは必要な部分だけにします

依頼文の例

書き方の基本は「Claude Code プロンプト設計」「Codexプロンプト設計」で解説しています。

Goal: 発売後に届いた不具合報告を仕分けし、再現できたものから直す
Context: 報告の写しは reports/inbox.md（掲示板とメール）。既知の不具合は docs/known_issues.md。
  セーブの互換性の方針は docs/save_policy.md
Done when: 報告を「再現した／情報不足／仕様どおり」に分けた表がある。再現したものは失敗するテストを先に書いてから直し、
  全テストが通っている。パッチノートの下書き（日本語と英語）がある
Constraints: ビルドのアップロード、default ブランチの切り替え、掲示板やレビューへの返信はしない（筆者が行う）

よくある失敗と対処

ひとことで：急ぎすぎ・反応しすぎ・記録しないの3つが、発売後の失敗の多くを占めます。

失敗	起きること	対処
急ぎの修正に改善を混ぜる	別の所が壊れる	修正を絞り、自動テストとベータブランチを通す
すべてのレビューに返信し、反論する	小さな話が大きな議論になる	返信は事実の補足だけにする
セーブの互換性を考えずに更新・ロールバックする	進行が消える	版番号つきのセーブと、新しい版のファイルを上書きしない方針
更新を告知しない	直ったことが伝わらない。早期アクセスでは注意書きが付く	更新ごとにイベントを投稿する
割引の予定が30日ルールと合わない	参加したいセールに出られない	予定表に30日の期間を書き込む
振り返りをしない・人を責める	同じ失敗を繰り返す	仕組みと手順の問題として書き、次の行動にする

チェックリスト

ひとことで：発売後の運用で続ける9つの習慣です。

• [ ] 報告の置き場所を1つに決め、重さで並べている
• [ ] 急ぎの修正は範囲を絞り、自動テストとベータブランチで確かめてから default に出している
• [ ] 前のビルドに戻す手順と、セーブの互換性の方針を決めている
• [ ] 更新ごとに版番号を上げ、パッチノートを投稿している
• [ ] レビューへの返信は事実の補足に絞り、AI の下書きは人が確かめてから出している
• [ ] 掲示板に、よくある質問・既知の不具合・報告のテンプレートを固定している
• [ ] 30日ルールを踏まえて、四季のセールと割引の予定を立てている
• [ ] ウィッシュリスト・売上・返金・プレイ時間・流入を同じ時間軸で見ている
• [ ] ポストモーテムを書き、次にやることをチェックリストに足した

次に読む記事

ひとことで：移植と、運用に関わる工程の記事です。

• ゲームの移植とマルチプラットフォーム：別の機種・ブラウザへ広げる判断
• ゲームの発売（リリース）手順：価格・30日ルール・発売当日
• ゲームのデバッグとQA：不具合報告と回帰テスト
• ゲームのローカライズ：更新のたびの翻訳
• インディーゲームの宣伝：ウィッシュリストと告知
• ゲーム開発の全工程マップ：工程の全体像