game-launch

AlterLab GameForge -- リリース前ローンチパイプライン

「完成」と「ローンチ」の間にある距離は、ほとんどのチームが予想するより長いものです。そして「ローンチ」から「継続」までの距離は、さらに長くなります。機能が完成し、バグがなく、楽しく遊べるゲームでも、ストアページが最適化されていなかったり、プレスキットがなかったり、年齢レーティングを申請していなかったり、初日パッチのパイプラインをテストしていなかったりすれば、失敗する可能性があります。さらに悪いことに、完璧にローンチできたゲームでも、ローンチ後の戦略がなければ2週目に消えてしまうことがあります。

Hadesはローンチ当日に文化的現象になったわけではありません。綿密に計画されたパッチのリズムで、18か月にわたる早期アクセスを経てそうなりました。Stardew Valleyは1.0で止まりませんでした。ConcernedApeによる無料コンテンツアップデートが、8年後もプレイし続けるコミュニティを築きました。このワークフローでは、リリース前の徹底的なパイプラインと、ゲームが最初の週を乗り越えられるかを左右するリリース後の運用、その両面を扱います。

目的とトリガー

次の場合にこのワークフローを使用してください：

• ゲームがリリース前の最終マイルストーンに入り、体系的なローンチ計画が必要な場合
• ストアへの提出期限が近づいており、チームがすべての要件を満たしているか確認する必要がある場合
• マーケティング素材を準備し、各プラットフォームで調整する必要がある場合
• 法務およびコンプライアンス要件（年齢レーティング、プライバシーポリシー、ライセンス）の監査が必要な場合
• ローンチの判断を下すためのGo／No-Goの枠組みがチームに必要な場合
• ソフトローンチまたは早期アクセスリリースを計画している場合（同じプロセスを適用し、範囲を調整します）
• ローンチ当日までにリリース後のサポート体制を整える必要がある場合

次の場合はこのワークフローを使用しないでください：

• 重要な機能が未完成のまま、本格的な開発が続いている場合（まず開発を完了してください）
• 内部プレイテスト用ビルドを公開する場合（代わりに game-playtest を使用してください）
• 商業的な意図のないゲームジャムへの提出である場合（ビルドの検証だけに簡略化してください）

重要なルール

1. すべてのフェーズにゲートがあります。 現在のフェーズの承認が済むまで、次のフェーズへ進まないでください。時間を節約するためにフェーズを省略すると、ローンチは破綻します。Vampire Survivorsはプレスキットなしでローンチしても成功しました。しかし、あれは2021年に起きた一度きりの幸運であり、再現可能な戦略ではありません。
2. ストアページは必須です。 スクリーンショットが不足していたり、説明が曖昧だったり、タグが間違っていたりするストアページは、見つけてもらえる可能性を損ないます。ストアページはゲームの第一印象そのものです。チェック項目ではなく、デザイン成果物として扱ってください。
3. 法令遵守は任意ではありません。 年齢レーティングやプライバシーポリシーが欠けていると、ローンチ後にゲームが販売停止になることがあります。これは完全に防止できる、壊滅的な結果です。
4. 失敗に備えてください。 ローンチ計画にはロールバック戦略を含める必要があります。「ローンチがうまくいかなかったらどうする？」への答えが「慌てる」なら、ローンチ計画は不完全です。
5. 初日パッチは想定されるものであり、恥ずべきものではありません。 ゴールドマスターの確定からローンチ当日までに、新たな問題が見つかります。問うべきなのは「必要になるか？」ではなく、「どれだけ早く配信できるか？」です。
6. ローンチ当日は1日目であり、ゴールではありません。 Dead Cellsは1.0をリリースした後、4年間で6つの大型コンテンツアップデートを提供しました。Hadesは1.0の前に18か月にわたって早期アクセス版のパッチを配信しました。リリース後の戦略は、リリース前のチェックリストと同じくらい重要です。
7. ストアでの見せ方と初回ユーザー体験におけるプレイヤー心理については、docs/game-design-theory.md を参照してください。

ワークフロー

フェーズ1：ビルドの検証

これは技術面における最終ゲートです。ローンチに向けたあらゆる活動を始める前に、ゲームが安定し、十分なパフォーマンスを発揮し、完成していることを証明できなければなりません。 クリーンビルドの検証：

• これまでにプロジェクトをビルドしたことのないマシンで、ソース管理からクリーンビルドを実行します。依存関係の欠落、ローカルにしかないファイル、ハードコードされたパス、環境固有の設定を検出できます。
• ビルド手順が文書化され、再現可能であることを確認します。チーム内で一人しか作成できないビルドは、単一障害点になります。
• ビルドのバージョン文字列が正しく、予定しているリリースバージョンと一致していることを確認します。
• ゲームにランチャーまたは自動アップデーターがある場合、正しい更新サーバーを参照していることを確認します。

自動テストスイート：

• すべての単体テストに合格していること：失敗ゼロ、スキップゼロ（文書化された理由により恒久的に除外されている場合を除く）。
• すべての統合テストに合格していること：ゲームシステムが正しく連携すること。
• すべてのプラットフォーム固有のテストに合格していること：対象プラットフォームごとに、プラットフォーム固有の問題なくビルドおよび実行できること。
• 重要な経路のスモークテスト：新しいゲームの開始、セーブ／ロードのサイクル、メインメニューのすべてのオプション、最終ボスの撃破、スタッフロールの再生。

パフォーマンスの検証：

• 最低仕様のハードウェアで目標フレームレートを満たしていること。開発用ワークステーションで設定を下げてテストするのではなく、実際の最低仕様ハードウェアでテストします。
• ロード時間が予算内であること。初回ロード、レベル遷移、リスポーン時間をすべて測定して記録します。
• プレイセッション全体を通じて、メモリ使用量がプラットフォームの上限内に収まること。2 時間以上の連続プレイセッションを実施し、メモリ割り当てを追跡します。メモリ使用量が単調に増加する場合は、メモリリークが発生しています。
• ディスク容量の使用量がプラットフォームの上限内であること（特にコンソールやモバイルで重要です）。
• ネットワークパフォーマンス（該当する場合）：レイテンシー、帯域幅の使用量、再接続処理。

バグのトリアージ：

• P0 バグがゼロであること（ゲーム進行を妨げる問題：クラッシュ、データ損失、進行不能）。
• P1 バグがゼロであること（重大な問題：主要機能の破損、顕著なビジュアルの不具合、頻発するソフトロック）。
• すべての P2 バグ（中程度）をレビューし、修正するか、文書化した理由とともにリリース可能な問題として明示的に受け入れます。
• P3 バグ（軽微：見た目の問題、エッジケース）を一覧化し、初日パッチの検討対象とします。

セーブ／ロードの整合性：

• リリースビルドで作成したセーブファイルが正しく読み込まれること。
• 直近の公開ビルド（早期アクセスの場合）のセーブファイルが正しく移行されること。
• 破損したセーブファイルを適切に処理すること：ゲームがクラッシュせず、プレイヤーに通知すること。
• クラウドセーブの同期がデバイス間で機能すること（該当する場合）。

長時間のプレイセッション：

• チームメンバーが一人、リリースビルドでゲームを最初から最後までプレイします。これにより、メモリリーク、累積的な状態の破損、プレイヤーの珍しい選択によるソフトロックなど、長時間プレイでのみ発生する問題を検出できます。
• セッション全体を録画し、些細なものも含め、異常があれば記録します。

フェーズ 1 の判定基準： すべての自動テストに合格していること。P0／P1 バグがゼロであること。対象ハードウェアでパフォーマンスが予算内であること。重大な問題なく長時間のプレイセッションを完了していること。

---

フェーズ 2：ストアフロントの要件

ストアフロントごとに、固有のアセット要件があります。アセットが不足していたり、要件に準拠していなかったりすると、申請が遅れたり、却下されたりする可能性があります。 Steam：

• ヘッダーカプセル画像（920x430）
• 小型カプセル画像（462x174）
• メインカプセル画像（1232x706）
• 縦型カプセル画像（748x896）
• ストアページ上部用のヒーロー画像（3840x1240）
• ライブラリ用カプセルアートワーク（600x900）
• スクリーンショットを5枚以上（最低1280x720、推奨1920x1080）。ゲームの核となる体験が伝わるように厳選してください。ゲームプレイを無作為にキャプチャした画像は避けてください。
• ゲームプレイのトレーラーを1本以上（60～90秒、埋め込みまたはYouTubeリンク）
• ストアの説明文：導入段落、特徴一覧、システム要件を含めます。デザイン文書ではなく、マーケティング用の文章として書いてください。特徴の一覧ではなく、感情に訴える体験から始めましょう。
• タグの選択：ゲームに正確に合ったタグを選びましょう。ジャンルXを期待したプレイヤーがジャンルYを見つけることになれば、表示機会を増やすための誤ったタグ付けは逆効果です。
• システム要件（最低および推奨）：記載した仕様に合う実機でテストしてください。
• レビュー／コミュニティ設定：ディスカッション掲示板、レビューの表示設定、ベータブランチの設定を行います。
• Steamworks の統合：実績、クラウドセーブ、トレーディングカード（該当する場合）、Remote Play Together（該当する場合）。
• ウィッシュリストへの登録を増やすため、「近日登場」ページは発売の少なくとも2週間前に公開してください。

itch.io：

• ページバナー画像（推奨630x500）
• スクリーンショットを3枚以上
• 閲覧ページ用のカバー画像（315x250）
• 短い説明文（閲覧ページ用に1～2文）と長い説明文（ページ全体用）
• 価格設定（有料、PWYW、無料）
• プラットフォームのラベルを付けたダウンロードファイルのアップロード（Windows、macOS、Linux）
• コミュニティ設定（コメント、開発日誌、フォーラム）

モバイル — App Store（iOS）：

• アプリアイコン（1024x1024、透明部分なし、角丸なし — 角丸は Apple が適用します）
• 対応するデバイスサイズごとのスクリーンショット（iPhone 6.7インチ、6.5インチ、5.5インチ、iPad Pro 12.9インチ、11インチ）
• アプリのプレビュー動画（15～30秒、任意ですが強く推奨）
• アプリ名（30文字以内）、サブタイトル（30文字以内）、キーワード（合計100文字）
• アプリの説明文（4000文字以内。最初の3行が重要です。残りは「さらに表示」の後ろに隠れます）
• プライバシーポリシーのURL（必須）
• 年齢制限の質問票（Apple 独自のシステム）
• App Store Connect の設定：価格、提供地域、アプリ内課金、サブスクリプショングループ
• 2026年4月28日以降：アプリは iOS/iPadOS 26 SDK でビルドする必要があります。それに応じてビルドパイプラインを計画してください。
• プライバシー開示の強化：個人データをサードパーティのAIサービスと共有する場合は、そのことを明確に記載する必要があります。AI関連のデータを共有する前に、ユーザーの明示的な許可を得る必要があります。
• アクセシビリティ情報ラベル：App Store の製品ページに新たに追加された機能です。開発者は App Store Connect でアクセシビリティのサポート情報を共有します。正確に記入してください。アクセシビリティを重視するプレイヤーに見つけてもらいやすくなります。

モバイル — Google Play ストア：

• アプリアイコン（512x512 PNG、32ビット、アルファチャンネル付き）
• ストアの特集掲載用のフィーチャー画像（1024x500）
• スクリーンショット：最低2枚、最大8枚。対応する各フォームファクター（スマートフォン、タブレット）につき少なくとも1枚
• 短い説明文（80文字）、全文説明（4000文字）
• コンテンツレーティングの質問票（IARC ベース）
• プライバシーポリシーのURL（必須）
• データセーフティセクション：すべてのデータ収集、保存、共有の方法を申告します。
• 対象 API レベルは Google の現在の最低要件を満たす必要があります。**2025年8月31日時点で、対象 API レベル35（Android 15）が必須です。**要件に準拠していないアプリは、新しい Android バージョンのユーザーに表示されなくなります。毎年確認してください。この要件は変更されます。 コンソール――ファーストパーティ認証：
• PlayStation（TRC）：技術要件チェックリストです。コントローラーの動作、システムソフトウェアとの連携、トロフィーの実装、セーブデータの取り扱い、ネットワーク機能が対象です。Sony の QA 審査には 2～4 週間かかります。
• Xbox（XR）：Xbox の要件です。実績の実装、リッチプレゼンス、コントローラー入力、アクセシビリティ機能が対象です。Microsoft の認証には 2～4 週間かかります。
• Nintendo Switch（Lotcheck）：Nintendo のコンプライアンステストです。コントローラーのレイアウトに合ったボタン表示、携帯モードと TV モードの切り替え、スリープモードへの対応が対象です。Nintendo の審査には 2～4 週間かかります。
• すべてのコンソール向けの提出前に、公開されている要件チェックリストに照らした社内の事前認証監査を実施してください。

**フェーズ 2 のゲート：**すべてのストアフロント用アセットの準備とレビューが完了していること。各プラットフォームの提出要件をすべて満たしていること。ストアページの草稿を作成し、少なくとも 2 人（正確性を確認する担当者 1 人と、マーケティング効果を確認する担当者 1 人）がレビューしていること。

---

フェーズ 3：マーケティングアセットのチェックリスト

これらのアセットはフェーズ 2 と並行して準備しますが、配信先が異なるため、別途管理します。

プレスキット：

• ファクトシート：ゲームタイトル、開発元、パブリッシャー（該当する場合）、発売日、プラットフォーム、価格、1 文での説明、100 語の説明、主な特徴（5～7 項目の箇条書き）
• キーアート：最低限、ゲームのメインプロモーション画像を利用可能な最高解像度で用意します（印刷用は 300 DPI、ウェブ用は 72 DPI。両方のバージョンを用意してください）
• スクリーンショット集：さまざまな要素（ゲームプレイ、探索、戦闘、物語、環境）を紹介する、厳選したスクリーンショットを 10～15 枚用意します。テーマごとに整理してください。HUD の表示ありと非表示の両方のバージョンを含めてください。
• GIF キャプチャ：ゲームの魅力的な場面を見せる短いループ動画を 3～5 本用意します（各 5～10 秒）。動画の自動再生が安定しないソーシャルメディアやメッセージングプラットフォームでは、特に重要です。
• ロゴ一式：ゲームロゴのフルカラー、白、黒のバージョンを用意します。透明背景の SVG または高解像度 PNG を使用してください。開発元／スタジオのロゴも含めてください。
• チーム紹介：スタジオの概要、チームの規模、過去の主な制作実績、報道関係者向けの問い合わせ先を記載した短い説明
• すべてのアセットを 1 つの URL からダウンロードできるようにしてください（Google Drive、Dropbox、またはスタジオのウェブサイトに専用のプレスページを用意）

トレーラー制作：

• ゲームプレイトレーラー（60～90 秒）：シネマティックなレンダリングではなく、実際のゲームプレイを見せます。プレイヤーは自分が体験する内容を見たいと考えています。最も見栄えのする場面、または独自性の高いゲームメカニクスを冒頭に配置してください。発売日、プラットフォーム、ウィッシュリストへの追加／予約購入リンクなど、明確な行動喚起で締めくくります。
• ローンチトレーラー（30～60 秒）：ソーシャルメディア向けに、より短く、感情に訴えかける内容にします。ゲームプレイとシネマティックな場面を組み合わせてもかまいません。音声なしで自動再生される場合に備えて、重要なメッセージをテキストで重ねるなどの最適化を行ってください。
• プラットフォーム別トレーラー：一部のプラットフォーム（Steam、App Store、Nintendo eShop）には、トレーラーの形式、解像度、コンテンツに関する制限など、固有の要件があります。アップロード前に確認してください。

ソーシャルメディアのローンチ用アセット：

• 各プラットフォーム（Twitter/X、Instagram、TikTok、Reddit、Discord、YouTube Community）向けのローンチ告知投稿を作成します。
• ハッシュタグ戦略：ゲームの主要ハッシュタグ、ジャンルのハッシュタグ、イベントのハッシュタグ（フェスティバル開催期間中にローンチする場合）
• コミュニティへの告知計画：Discord での告知、メーリングリストへの配信、Steam のアップデート投稿
• ローンチ日の投稿スケジュール：最大限のリーチを得られるよう、各プラットフォームでの投稿タイミングを調整します プレスへのアプローチ：
• プレス／メディアのリスト：関連性の高いメディア、YouTuber、ストリーマー、ジャーナリストを最低50件リストアップします。自分のジャンルを取り上げている相手を優先します。
• レビュー用コードの配布：プレス向けにSteamキー、コンソール用コード、または直接ビルドを用意します。キー管理サービス（Keymailer、Woovit）を利用するか、スプレッドシートで手動管理します。
• 情報解禁管理：明確な情報解禁日を設定し、明示して伝えます。レビューの公開とウィッシュリスト獲得を促すため、発売の1～3日前に情報解禁するのが一般的です。
• プレス向けメール：個別にカスタマイズし（一斉送信は避け）、簡潔にまとめます。プレスキットへのリンク、キー／コード、情報解禁日を含めます。発売の2～3週間前に送信します。

フェーズ3の完了条件： プレスキットを完成させ、ホスティングします。すべてのトレーラーを制作してアップロードします。ソーシャルメディアへの投稿を作成し、予約投稿します。情報解禁日を伝えたうえで、プレスへのアプローチを開始します。

---

フェーズ4：コンプライアンスと法務

このフェーズは必須です。コンプライアンス関連のタスクを省略したり先送りしたりすると、法的責任が生じたり、ストアから削除されたりするリスクがあります。

年齢レーティング：

• ESRB（北米）：ESRBのオンラインツールからコンテンツ質問票を提出します。デジタル版のみのリリースでは、通常、処理に1～3営業日かかります。米国で販売する主要なストアでは必須です。
• PEGI（ヨーロッパ）：IARC（International Age Rating Coalition）ポータルから提出します。デジタルストアの大半は、自動化されたPEGIレーティングにIARCを利用しています。
• CERO（日本）：日本でリリースする場合は必須です。処理に時間がかかります（2～4週間）。余裕を持って提出してください。
• USK（ドイツ）：デジタル版のリリースでは、IARCを通じて手続きします。
• ゲームを販売するすべての地域のレーティング証明書を保管してください。

アクセシビリティに関する声明：

• ゲームが対応しているアクセシビリティ機能を記載します。キー割り当ての変更、色覚サポートモード、字幕オプション、スクリーンリーダー対応、難易度オプション、運動機能に関するアクセシビリティ設定などです。
• WCAG 2.1 AAガイドラインおよびGame Accessibility Guidelines（gameaccessibilityguidelines.com）を参照してください。
• 対応していない機能については正直に記載してください。不完全でも正直なアクセシビリティに関する声明は、包括的に見せかけた内容よりはるかに優れています。

プライバシーポリシー：

• あらゆるデータ（分析データ、クラッシュレポート、クラウドセーブ、アカウント作成に伴うデータを含む）を収集するゲームでは必須です。
• 収集するデータ、その利用方法、共有先、保存期間、プレイヤーが削除を請求する方法（GDPRにおける消去権）を明記する必要があります。
• ゲーム内からアクセスできるようにする必要があります（通常は設定メニューまたはメインメニューからリンクします）。
• 13歳未満のプレイヤーを対象とするゲーム（ESRB EまたはE10+）では、COPPAへの準拠が必須です（データ収集には保護者の同意が必要です）。

EULA／利用規約：

• オンライン機能を備えたゲームでは必須です。商用リリースではすべて推奨されます。
• ライセンスの許諾、制限、責任の制限、紛争解決、契約終了の条件を含めます。
• ユーザー生成コンテンツがある場合、EULAでコンテンツの所有権とモデレーションの権利を扱う必要があります。

著作権とライセンスの確認：

• すべてのサードパーティ製アセット（音楽、効果音、フォント、ミドルウェア、テクスチャ、モデル）を監査します。
• すべてのアセットについてライセンス条件を確認します。商用利用は許可されていますか？クレジット表記は必要ですか？収益に関するしきい値はありますか？
• すべてのミドルウェアのライセンスを確認します。物理エンジン、ネットワーキングライブラリ、UIフレームワーク、分析SDKなどが該当します。タイトルごと、または収益に基づくライセンスが必要なものもあります。
• オープンソースライセンスへの準拠：ゲームでオープンソースコードを使用している場合は、ライセンス上の義務を確認します。MITとBSDは制約の少ないライセンスです。GPLではソースコードの開示が必要です。Apache 2.0ではNOTICEファイルが必要です。
• 必要な帰属表示をすべて含めたクレジット画面またはテキストファイルを作成します。

フェーズ4の完了条件： すべての年齢レーティングを取得します。プライバシーポリシーを公開し、ゲーム内からアクセスできるようにします。EULAを法務知識のある人（できれば弁護士）に確認してもらいます。すべてのサードパーティ製アセットについて、ライセンスに準拠していることを確認します。クレジットを完成させます。

---

📊 市場の背景 競合環境を把握することは、現実的なローンチ時の見通しを立て、マーケティング活動の規模を調整するうえで欠かせません。次の数字は厳しいものですが、知っておく必要があります。

• 2025年だけで、Steamでは20,017本のゲームがリリースされました。 あなたのゲームは、毎日およそ55本の新作と注目を奪い合うことになります。
• そのうち83％は、初年度の収益が10,000ドル未満でした。 売上のロングテールは非常に長く続きます。
• 40％は、Steam Directの出品手数料100ドルを回収できませんでした。 リリース作品のほぼ半数は、市場で実質的に認知されていません。
• ローンチ当日にアルゴリズムから十分な露出を得るには、少なくとも7,000～10,000件のウィッシュリスト登録が必要です。 Steamのアルゴリズムは勢いを評価します。最初の48時間にすばやく売れたゲームは、より多くのストアフロントやおすすめフィードで紹介されます。このウィッシュリスト数に達していないと、アルゴリズムはあなたのゲームをほとんど取り上げません。
• インディーゲームの上位1％が、インディーゲーム全体の収益の90％を獲得しています。 勝者がすべてを手にするのではなく、勝者が大半を手にする構図ですが、収益の集中は極端です。
• インディーゲームの70％が経済的に失敗しています。 商業インディーゲーム10本のうち7本は、次のプロジェクトの資金を賄えるほどの収益を得られません。これは諦める理由ではなく、開発と同じくらい真剣にマーケティングを計画する理由です。

これらの数字は、意欲をくじくためのものではありません。ローンチ計画に十分なマーケティング活動、現実的な収益予測、そしてあなたのプロジェクトにとっての「成功」の意味を明確に含めるためのものです。500本を売り、ゲームジャムの続編を制作する資金を賄えたゲームは、ある基準では成功です。一方、5,000本を売っても損益分岐点に達するには50,000本売る必要があったゲームは、別の基準では失敗です。ローンチ前に、成功の基準を定めておきましょう。

---

⚖️ 法令遵守のチェックポイント

年齢レーティングやプライバシーポリシーに加え、ゲームを取り巻く規制環境は急速に拡大しています。以下の項目があなたのタイトルに適用されるか、それぞれ確認してください。

• EAA（欧州アクセシビリティ法）：2025年6月から施行されています。コミュニケーション機能（チャット、音声）または E コマース機能（ゲーム内購入）を備え、EU で販売されるゲームに適用されます。主要なインタラクションには、アクセシブルな代替手段が必要です。準拠しない場合、EU 域内での市場アクセスが制限される可能性があります。
• CVAA（21 世紀の通信と映像アクセシビリティ法）：テキストチャットとボイスチャットの機能は、障害のあるプレイヤーも利用できる必要があります。コミュニケーション機能を備え、米国で配信されるゲームに適用されます。違反 1 件につき最大 140 万ドルの罰金が科されます。コミュニケーション機能におけるリアルタイムテキスト、字幕表示、UI の操作性が対象です。
• COPPA（児童オンラインプライバシー保護法）：重大――準拠期限は 2026 年 4 月 22 日（目前）。 FTC の COPPA 最終規則の改正により、「個人情報」に生体識別子が含まれるようになります。新たな要件として、正式な情報セキュリティプログラムが必須となり、サービスに「不可欠」ではない第三者へのデータ開示には、別途、保護者の同意が必要になります。ゲームが子どもを惹きつける可能性が合理的にある場合（E または E10+ のレーティング、カートゥーン調のアートスタイル、教育コンテンツなど）、COPPA への準拠が必須です。更新された規則に照らして、データ収集の慣行をただちに見直してください。
• PEGI 2026 年更新：2026 年 6 月に施行されます。新たに審査へ提出されるゲームのみが対象です。ルートボックスの仕組みを含むゲームには、PEGI 16 以上のレーティングが付与されます。NFT またはブロックチェーンとの統合を含むゲームには、自動的に PEGI 18 のレーティングが付与されます。さらに、期間限定オファー（バトルパス、季節限定アイテム）には PEGI 12 以上、デイリークエストと連続ログインには、新たなエンゲージメントメカニクスの記述子とともに PEGI 7 以上のレーティングが付与されます。ブロック／通報システムのない無制限のコミュニケーション機能には、自動的に PEGI 18 のレーティングが付与されます。これらのレーティングへの影響を考慮して、マネタイズモデルとソーシャル機能を計画してください。注： ESRB は PEGI のインタラクティブリスクカテゴリ方式の採用を明確に拒否し、「コンテンツに関連しない機能がレーティングカテゴリの割り当てに影響すると、混乱を招く可能性がある」と述べています。北米のレーティングは、引き続きコンテンツのみを対象とします。
• ESA アクセシブルゲームイニシアチブ：標準化された 24 個のアクセシビリティタグが、Xbox ストアフロント（コンソール、PC、モバイル、ウェブ）で利用可能になりました。創設メンバーは EA、Google、Microsoft、Nintendo of America、Ubisoft です。追加メンバーには Amazon Games、Riot、Square Enix、Warner Bros. が含まれます。これらのタグを正確に入力することで、アクセシビリティを重視するプレイヤーから見つけてもらいやすくなり、新たに整備されるアクセシビリティ基準への誠実な準拠を示せます。他のストアフロントも、Xbox の実装に続くと予想されます。
• Steam の AI 開示（2026 年 1 月の 3 層フレームワーク）：
  • 事前生成 AI コンテンツ：ゲームファイルに組み込まれた AI アセット（テクスチャ、アート、ボイスライン、世界設定のテキスト）。ストアページのコンテンツ記述子でフラグを立てる必要があります。
  • リアルタイム生成 AI コンテンツ：実行時に AI がコンテンツを生成するもの（動的な NPC の台詞、プロシージャルクエスト）。違法または不快な出力を防ぐ安全対策と、プレイヤーが報告できる仕組みが必要です。
  • 開発者ツール：コードアシスタント、デバッグツール、社内パイプラインの AI。開示は明示的に免除されます。 開発ワークフローで AI を使用しても、ストアフロントでの開示は不要です。
  • ストアフロントごとに適切な開示を行えるよう、AI の使用区分を @templates/ai-content-policy.md に記録してください。
• itch.io の AI 開示：生成 AI コンテンツには明示的なタグ付けが必要です。手作業で編集した AI 出力も対象です（AI 生成アートを編集しても、開示義務は免除されません）。タグのない AI コンテンツは、閲覧ページと検索結果から除外されます。AI タグ付きのプロジェクトは、専用の「AI Assisted」閲覧ページに表示されるため、見つけてもらいやすさが実質的に低下します。大量生産された AI ページはスパムとして扱われます。タグ付け要件は、ゲームページのメタデータとゲームの説明の両方に適用されます。
• コンソール認証：各ファーストパーティープラットフォーム（Sony、Microsoft、Nintendo）では、専用の認証審査が必要で、2～4 週間かかります。少なくとも 1 回の却下と再提出のサイクルを含めて、提出スケジュールを計画してください。初回提出で一度に審査を通過することは、ほとんどありません。発売スケジュールには、コンソール認証用として合計 4～8 週間を確保してください。 このチェックリストは、発売予定日の少なくとも8週間前に、チームで（個人開発の場合は自分自身で）確認してください。規制要件が直前になって判明することは、防げたはずの発売遅延の最も一般的な原因です。

---

フェーズ5：初日パッチの計画

認証審査やストア審査に提出するビルドが、初日にプレイヤーが体験するビルドと同じであることはほとんどありません。提出から発売までの間に、問題が見つかります。その前提で計画してください。

既知の問題リスト：

• ゴールドビルドに含まれてリリースされた既知の問題をすべてリストアップします。重大度とプレイヤーからの見えやすさで分類してください。
• 初日パッチで対処する問題と、そのまま許容する問題（理由も含む）を明記します。
• このリストはコミュニティ管理にも役立ちます。発売日にプレイヤーから既知の問題が報告された場合、サポートチームは「この問題は把握しており、初日パッチに修正が含まれています」とすぐに回答できます。

初日パッチの範囲：

• 発売当日に場当たり的に決めるのではなく、発売前にパッチの内容を定義します。
• 初日パッチの一般的な範囲：認証期間中に見つかったバグ修正、後期プレイテストに基づく最終的なバランス調整、ローカライズの修正、直前のパフォーマンス最適化。
• 初日パッチで機能を追加してはいけません。機能追加はパッチではなく、発売後のアップデートに含めます。
• 初日パッチは、ゴールドビルドと同じ検証プロセス（フェーズ1の簡略版）でテストしてください。新たなバグを引き起こす初日パッチは、パッチを出さないよりも悪い結果になります。

ホットフィックスのプロセス：

• 緊急ホットフィックスのパイプライン（コード修正、ビルド、テスト、デプロイ）を確立します。「重大なバグの報告」から「全プラットフォームで修正が反映される」までの最短所要時間を把握してください。
• PC（Steam）の場合：ホットフィックスは通常、数時間以内にデプロイできます。Steam のビルドアップデートを公開する手順を文書化してください。
• コンソールの場合：ホットフィックスは認証を受ける必要があります（問題が深刻な場合は、簡略化された迅速審査プロセスを利用します）。各プラットフォームの迅速認証プロセスと連絡先を把握してください。
• モバイルの場合：App Store の審査には24～48時間かかることがあります。Google Play は通常、それより早く（数時間で）完了します。対応時間の見積もりに反映してください。
• 緊急ホットフィックスのデプロイを承認する権限を持つ担当者を指定します。そのためにチーム全員で会議を開く必要がないようにしてください。発売週に24時間いつでも対応できる意思決定者を1人置きます。

モニタリング基盤：

• クラッシュレポート：クラッシュレポートサービス（Sentry、Backtrace、Crashlytics、またはエンジン標準の機能）を統合します。リリースビルドで有効になっていることを確認してください。
• アナリティクス：プレイヤーの進行状況、セッション時間、離脱ポイントに関する基本的なテレメトリーを収集します。このデータは、発売後のバランス調整やコンテンツ計画に非常に役立ちます。
• コミュニティの反応の追跡：Steam のレビュー、ソーシャルメディアでの言及、Discord のアクティビティ、Reddit の投稿を監視します。発売週にこの役割を担うコミュニティマネージャーまたはチームメンバーを割り当ててください。
• サーバーのモニタリング（該当する場合）：プレイヤー数、サーバー負荷、エラー率、レイテンシを確認できるダッシュボードを用意します。異常な動作を検知するためのアラートしきい値を設定してください。

**フェーズ5のゲート：**既知の問題リストが完成していること。初日パッチの範囲が定義され、テスト済みであること。ホットフィックスのパイプラインが最初から最後までテストされていること（ステージング環境にテストパッチをデプロイします）。モニタリング基盤が稼働し、検証済みであること。

---

フェーズ6：Go／No-Go の判断

これが最終ゲートです。これまでの各フェーズの状況をすべて確認したうえで、チーム全体で発売の判断を下します。

チェックリストの確認：

• 各フェーズの担当者が、完了状況を報告します。「完全に完了」「例外ありで完了（例外を列挙）」「未完了（阻害要因を列挙）」のいずれかを示します。
• すべての例外を確認し、明示的に承認するか、上位にエスカレーションします。
• 未完了のフェーズは、発売を阻害する可能性があります。未完了項目を抱えたまま発売するリスクが許容できることに、チーム全体が合意する必要があります。

リスク評価： 以下のリスクカテゴリーを評価します：

リスクカテゴリ	質問	発生した場合の影響
技術	一般的なハードウェア構成でゲームがクラッシュする可能性はありますか？	レビューが台無しになります。返金が急増します。
パフォーマンス	最低動作環境でフレームレートが許容範囲を下回る可能性はありますか？	第一印象が悪くなります。Steam でレビュー爆撃を受けます。
コンテンツ	不快なコンテンツ、誤解を招くコンテンツ、または不足しているコンテンツはありませんか？	PR 危機。ストアページからの削除。
法務	未解決のライセンスやコンプライアンス上の問題はありませんか？	DMCA による削除要請。法的責任。
サーバー（該当する場合）	リリース当日のトラフィックでインフラが過負荷になる可能性はありますか？	プレイヤーがプレイできなくなります。返金リクエストが発生します。
マーケティング	ストアでゲームを見つけてもらえますか？	ゲームの品質にかかわらず売上が低迷します。

各リスクについて、発生可能性（低／中／高）と影響度（低／中／高）を割り当てます。発生可能性と影響度がともに高いリスクは、チームリーダーが明示的に受け入れない限り、リリースを阻止する要因とします。

ロールバック計画： リリースが壊滅的な失敗に終わった場合の対応を定めます。

• ストアページを一時的に非公開にできますか？その手順は何ですか？
• 問題のあるビルドを以前のバージョンに戻せますか？どのくらいの時間がかかりますか？
• 誰がプレイヤーに連絡しますか？どのようなメッセージを伝えますか？「問題を認識しており、修正に取り組んでいます」という告知文のテンプレートを作成します。
• どの時点でリリースを「中止」し、「問題はあるが続行」と判断しますか？その基準を定めます。

リリース当日の対応体制：

• リリース当日とその後48時間のオンコール担当者を決めます。チームが分散している場合は、すべてのタイムゾーンをカバーします。
• 連絡手段を整備します。主要な連絡手段（Slack／Discord チャンネル）、エスカレーション手段（電話）、公開向けの連絡手段（ソーシャルメディア、コミュニティフォーラム）を定めます。
• エスカレーション経路を定めます。誰がホットフィックスのデプロイを決定しますか？誰がビルドの取り下げを決定しますか？
• 確認のタイミングを設定します。リリースから1時間後、4時間後、12時間後、24時間後、48時間後です。各確認時に、クラッシュレポート、プレイヤーからのフィードバック、売上データ、サーバーの状態を確認します。

判断：

• GO：すべてのフェーズが完了している（または、明示的に受け入れた例外を除いて完了している）。発生可能性と影響度がともに高いリスクがない。ロールバック計画が整っている。対応体制が整っている。
• 条件付き GO：特定の条件付きでリリースを進めます。例：「リリース当日の午前6時までに初日パッチのデプロイが成功することを条件に GO とする」。条件が満たされない場合の対応も定めます。
• NO-GO：リリースを阻止する要因が1つ以上未解決です。新たな目標日と解決までの手順を特定します。延期について率直に伝えます。適切な状態でリリースされた延期作品は、急いでリリースされて不具合だらけの作品よりも好意的に記憶されます。

---

フェーズ7：リリース後の運用

リリース当日は始まりであり、終わりではありません。リリース後の最初の30日間で、ゲームの勢いが増すか、Steam の墓場に埋もれるかが決まります。このフェーズでは、ライブ運営を維持するための運用サイクルを取り上げます。

パッチ配信計画

リリースサイクルの異なる、3段階のアップデートを定義します。

PATCH CADENCE MODEL
-------------------------------------------------
HOTFIXES (days 1-7 post-launch, then as needed):
  Scope: Crash fixes, progression blockers, data loss bugs, critical
  balance breaks (one weapon doing 10x intended damage)
  Turnaround: 24-72 hours from report to live
  Process: Fix → abbreviated QA → deploy → verify
  Communication: "We are aware. Fix incoming." posted within 2 hours
  of confirmed report. Players tolerate bugs. They do not tolerate silence.

CONTENT PATCHES (every 2-4 weeks for first 3 months):
  Scope: Balance tuning based on live data, quality-of-life improvements,
  bug fixes batched from the tracker, minor content additions (new items,
  cosmetics, challenges)
  Turnaround: 1-2 sprint cycles
  Process: Plan → build → QA → staging → deploy → monitor
  Communication: Patch notes published 24 hours before deployment.
  Write patch notes for players, not developers. "Sword damage reduced
  15%" means nothing. "The Iron Sword was trivializing mid-game bosses,
  so we brought its damage closer to other tier-2 weapons" tells a story.

  Dead Cells' patch cadence: biweekly during Early Access, monthly after
  1.0, with each update clearly themed (the "Rise of the Giant" DLC,
  the "Bad Seed" expansion). Every patch had a narrative identity.

MAJOR UPDATES (every 3-6 months):
  Scope: New content (areas, enemies, bosses, mechanics), system overhauls,
  seasonal events, paid DLC
  Turnaround: Full milestone planning cycle
  Process: Design → prototype → build → extended QA → marketing push → deploy
  Communication: Announce 2-4 weeks in advance with trailer or dev blog.
  Time major updates with Steam sales for maximum visibility.

  Stardew Valley model: free major updates as community-building investment.
  ConcernedApe shipped 1.1, 1.2, 1.3, 1.4, and 1.5 as free updates over
  5 years, each one reigniting press coverage and sales. The free updates
  generated more revenue through base game sales than paid DLC would have.
-------------------------------------------------

コミュニティ管理戦略

コミュニティは最も強力なマーケティングチャネルであると同時に、最も危険なリスク要因でもあります。計画的に運営しましょう。

COMMUNITY CHANNELS (priority order for most indie games)
-------------------------------------------------
Discord:
  Set up BEFORE launch. Have channels for: announcements, bug reports,
  feedback, general discussion, fan art/content. Assign moderators.
  Respond to bug reports within 4 hours during launch week.
  Run a "known issues" pinned post updated in real-time on launch day.

Steam Forums:
  Monitor daily for the first month. Steam forum sentiment directly
  influences store page visibility. Respond to negative posts with
  empathy and specifics -- "We hear you. This is on our radar for
  the next patch" turns a detractor into a watcher.

Reddit:
  Post launch announcement in relevant subreddits (r/indiegaming,
  genre-specific subs). Be present in comments. Do NOT astroturf.
  Reddit detects and punishes corporate-feeling engagement instantly.

Twitter/Social:
  Share GIFs of satisfying moments, patch previews, player
  achievements. The Vampire Survivors social strategy was almost
  entirely player-generated content retweets -- free, authentic,
  and more effective than any marketing campaign.
-------------------------------------------------

指標モニタリングダッシュボード

リリース後最初の30日間は毎日、その後は毎週、以下の指標を追跡します。

POST-LAUNCH METRICS
-------------------------------------------------
Retention:
  D1 retention (% who play again within 24 hours): Target 40%+
  D7 retention: Target 20%+
  D30 retention: Target 10%+
  If D1 < 30%, the first-time experience has a critical problem.
  If D7 drops sharply from D1, mid-game content is failing.

Engagement:
  Median session length: Compare to your design target
  Sessions per week per active player
  Completion rate: % who reach credits (for narrative games)
  Compare to Hades benchmarks: ~20 hours median to first clear

Revenue (if commercial):
  Daily revenue and 7-day moving average
  Revenue per user (RPU) by acquisition source
  Refund rate: above 10% is a red flag, above 20% is a crisis
  Wishlist conversion rate on launch day: industry average ~15-20%

Sentiment:
  Steam review score: track daily. Below 70% "Mixed" threshold
  triggers a community response plan.
  Review keyword frequency: what are players praising/complaining about?
  Net Promoter Score from in-game surveys (if implemented)

Stability:
  Crash rate: target < 0.5% of sessions
  Average FPS across hardware tiers
  Error log volume (trending up = new bugs introduced by patches)
-------------------------------------------------

リリース後のコンテンツロードマップのテンプレート

リリース前に作成します。チームの集中を保ち、コミュニティに今後の楽しみを提供できます。

POST-LAUNCH ROADMAP
-------------------------------------------------
Month 1: Stability & Balance
  - Hotfixes for launch issues
  - Balance pass based on live data (not dev intuition)
  - Quality-of-life improvements from community feedback
  - "Thank you" patch with 1-2 small community-requested features

Month 2-3: First Content Update
  - [Themed content addition: new area/mode/characters]
  - Major balance overhaul if needed
  - Accessibility improvements from player feedback

Month 4-6: Major Content Drop
  - [Significant expansion: new mechanics, story content, or game mode]
  - Align with a Steam sale or seasonal event for visibility
  - Press outreach for "now with [new feature]" coverage

Month 6-12: Sustained Operations or Sunset
  Decision point: Is the game growing, stable, or declining?
  - Growing: Plan next content year, consider DLC or expansion
  - Stable: Maintain with quarterly patches, shift team to next project
  - Declining: Ship a final "definitive edition" patch, communicate
    honestly with community, redirect resources

The Hades model: 10 major content updates during Early Access,
each one adding weapons, characters, story content, and systems.
Each update had a themed identity and generated fresh press coverage.
By 1.0, the game had 18 months of community investment behind it.
-------------------------------------------------

---

出力形式

## Launch Readiness Report: [Game Title]
## Target Launch Date: [YYYY-MM-DD]
## Report Date: [YYYY-MM-DD]
## Report Author: [Name/Role]

### Executive Summary
[3 sentences: Overall readiness state, biggest remaining risk, recommendation (GO/CONDITIONAL GO/NO-GO)]

### Phase Completion Status

| Phase | Status | Exceptions | Owner |
|-------|--------|-----------|-------|
| 1. Build Validation | Complete / With Exceptions / Incomplete | [list] | [name] |
| 2. Storefront Requirements | Complete / With Exceptions / Incomplete | [list] | [name] |
| 3. Marketing Assets | Complete / With Exceptions / Incomplete | [list] | [name] |
| 4. Compliance & Legal | Complete / With Exceptions / Incomplete | [list] | [name] |
| 5. Day-One Patch | Complete / With Exceptions / Incomplete | [list] | [name] |

### Blocking Issues
| ID | Issue | Phase | Severity | Resolution Path | ETA |
|----|-------|-------|----------|----------------|-----|
| L1 | [desc] | [phase] | Blocker | [plan] | [date] |

### Risk Assessment

| Risk | Likelihood | Impact | Mitigation | Accepted? |
|------|-----------|--------|-----------|-----------|
| [risk] | H/M/L | H/M/L | [plan] | Y/N |

### Rollback Plan
- Build reversion process: [description]
- Storefront takedown process: [description]
- Public communication template: [drafted message]
- Abort threshold: [criteria]

### War Room Configuration
- On-call team: [names and roles]
- Communication channels: [primary, escalation, public]
- Check-in schedule: [times]
- Escalation path: [who decides what]

### Post-Launch Operations Plan
- Patch cadence: [hotfix/content/major schedule]
- Community channels: [platform list with owners]
- Metrics dashboard: [tool and key metric targets]
- Content roadmap: [month-by-month plan]

### Decision: [GO / CONDITIONAL GO / NO-GO]
**Conditions (if CONDITIONAL GO):** [list]
**Reasoning:** [2-3 sentences]
**Next Steps:** [immediate action items]

品質基準

• フェーズの網羅性：適用対象外の場合も、その理由を含め、すべてのフェーズに対応していること。
• 曖昧な説明がないこと：すべての例外と受容したリスクについて、理由を明記すること。ローンチ準備状況レポートに「今後検討します」と記載するのは認められません。
• ロールバック計画の検証：ロールバック計画は理論上のものではなく、ステージング環境でテスト済みであること。実行したことのないロールバック計画は、計画ではなく希望にすぎません。
• ウォールームの人員配置：重要な各機能（エンジニアリング、コミュニティ管理、プラットフォームとの連携）について、担当者を明確にし、オンコール対応が可能であることを確認していること。
• 法務確認の完了：第三者のアセットが未確認のまま残っていないこと。未達成のコンプライアンス要件が残っていないこと。この領域に曖昧さが一切ないこと。
• ローンチ後の計画があること：パッチの頻度が定義され、コミュニティチャンネルが確立され、メトリクスダッシュボードが設定され、コンテンツロードマップが作成されていること。ローンチ後の計画なしにローンチすれば、ゲームの寿命は1週間で終わります。
• 意思決定の追跡可能性：Go／No-Go の決定を、具体的な完了状況とリスク評価までたどれること。将来の事後検証で、決定時点で把握していた内容を正確に再構成できる必要があります。

MCP 統合

ローンチワークフローは、リリース管理、マーケティングアセットの作成、プレスへのアプローチ、デプロイのために MCP サーバーと連携し、単一のセッションから一貫したローンチパイプラインを実現します。

接続済み MCP サーバー

MCP サーバー	ローンチでの用途	役立つ点
GitHub（接続済み）	リリース管理	変更履歴を含むリリースタグと GitHub Releases の作成、初日パッチ用ブランチの管理、マイルストーンラベルによるローンチを阻む課題の追跡、PR ワークフローを通じたホットフィックスパイプラインの調整
Gmail（接続済み）	プレスへのアプローチ	プレスキットのリンク、情報解禁日、レビューコードを含む、相手に合わせたプレス向けメールの下書きと送信。ジャーナリストやストリーマーとのフォローアップのやり取りを管理します。
Canva（接続済み）	マーケティングアセット	ストアページ用のグラフィック、ソーシャルメディア向けのローンチ告知、プレスキット用のキービジュアルのバリエーション、ローンチ当日のカウントダウン用アセットを生成します。
Vercel（接続済み）	ウェブのデプロイ	ゲームのマーケティングサイト、プレスキットページ、ウェブゲームのビルドをデプロイします。コンパニオンアプリ、コミュニティポータル、ウェブデモのデプロイに役立ちます。
Cloudflare（接続済み）	CDN とストレージ	ダウンロード可能なビルドやプレスキット用の R2 ストレージを設定し、リーダーボードやコミュニティ機能用の D1 データベースをセットアップし、ウェブ経由で配信するゲームアセットの CDN キャッシュを管理します。
Slack（接続済み）	ウォールームの調整	チームチャンネルへのローンチ状況の投稿、ウォールームのチェックインスケジュールの調整、クラッシュレポートのアラートとセンチメント監視の概要の共有
Notion（接続済み）	ローンチチェックリストの追跡	フェーズの完了状況、ローンチを阻む課題、チームが照会できるリスク評価を含む、構造化された Notion ページとしてローンチ準備状況レポートを管理します。

ワークフローの例

リリースタグ付けと変更履歴：

1. GitHub MCP を使って、ゴールドビルドのコミットからリリースタグを作成します
2. 前回のリリース以降にマージされた PR の説明から変更履歴を生成します
3. 変更履歴を含む GitHub Release を作成し、既知の問題と初日パッチの対象範囲へのリンクを追加します
4. 初日パッチのデプロイ後、パッチの内容をリリースノートに反映します

プレスキットの配布：

1. Canva を使って、ストアページ用のカプセル画像とソーシャルメディア向けの告知グラフィックを作成します
2. プレスキットのダウンロードリンクと報道解禁日を記載した、個別対応のプレス向けメールを Gmail MCP で作成します
3. すっきりとしたブランドイメージのダウンロード体験を提供するプレスキットページを Vercel にデプロイします
4. 返信を追跡し、Gmail のスレッドを通じて関心を示した媒体にフォローアップします

ローンチ当日の対策ルーム：

1. ローンチ後 0 時間の時点で、ローンチ状況のテンプレートを Slack に投稿します
2. GitHub を監視し、P0/P1 とタグ付けされたバグ報告を確認します
3. 各チェックインの間隔（+1h、+4h、+12h、+24h、+48h）で、クラッシュレポートの要約とユーザーの反応データをまとめます
4. 現在のリスク評価とともに、最新の状況を Slack と Notion に投稿します
5. ホットフィックスが必要な場合は、GitHub MCP を通じて PR とデプロイを管理します

ユースケースの例

1. 「インディーゲームの機能は完成しており、6 週間後に Steam でローンチしたいと考えています。ローンチまでの全工程を説明し、スケジュールの作成を手伝ってください。」
2. 「初めて App Store に申請します。満たす必要がある具体的な要件と、避けるべき一般的な却下理由を教えてください。」
3. 「ゲームのローンチは来週の金曜日ですが、重大なバグが見つかりました。これはローンチを妨げる問題か、初日パッチで対応する項目か、判断を手伝ってください。」
4. 「次回のリリースに向けてプレスキットを準備する必要があります。何を含め、どのように構成すればよいですか？」
5. 「残っているバグを修正するためにローンチを 2 週間延期するか、予定どおりにリリースして初日パッチを提供するか、検討しています。適切なリスク評価を含め、実施可否の判断として整理するのを手伝ってください。」
6. 「先週ローンチしましたが、レビューの評価はまちまちです。パッチの提供間隔、コミュニティへの対応戦略、レビューの評価を改善するためのコンテンツロードマップを含む、ローンチ後の運用計画の作成を手伝ってください。」