steam-store-launch-ops

Steam ストアローンチ運用

このスキルは、パケット優先の Steam ローンチルーターとして使用してください。

目的は、一般的なマーケティングのアドバイスを並べることではありません。目的は次のとおりです。

1. 現在の Steam での訴求ポイントを特定する
2. 最適なパケットを 1 つ選ぶ
3. 認知度、訴求内容、根拠、タイミング、運用を誠実に切り分ける
4. Steam における一度きりの機会という制約を明確にする
5. より広範なマーケティング、プレイヤーからのフィードバック、ビルド、パフォーマンスに関する作業が本当の課題である場合は、適切な担当先へつなぐ

必要に応じて、以下を確認してください。

• references/intake-packets-and-route-outs.md
• references/diagnostic-model.md
• references/event-hooks.md
• references/checklists.md

このスキルを使用する場合

• 重要な公開タイミングの前に、Steam の近日登場ページまたは公開中のストアページを確認する
• トラフィック、コンバージョン、根拠、タイミングを混同せずに、ウィッシュリストが伸び悩む問題を診断する
• デモを一般公開してよいか、または信頼を損なう可能性が高いかを判断する
• Steam Next Fest や類似の公開イベントが、実際の準備状況に合っているかを判断する
• 終盤の Steam ローンチに関する不安を、大規模なマーケティングの書き直しではなく、1 つのチェックリスト／ランブックパケットにまとめる
• Steam 向けのクリエイター対応／アウトリーチの準備状況を、適切な次のパケットを選ぶのに必要な範囲だけでトリアージする

このスキルを使用しない場合

• 主な作業が、ゲーム以外を含む広範なローンチ／GTM／ライフサイクル／顧客獲得である → marketing-automation
• 主な作業が、プレイヤー／デモのフィードバック、混乱、バグ、プレイテストのメモの優先順位付けである → game-demo-feedback-triage
• 主な作業が、ビルドの失敗、パッケージングの失敗、CI／エディターのログである → game-build-log-triage
• 主な作業が、ランタイムのプロファイリング、フレーム時間の診断、Steam Deck のパフォーマンス、プラットフォームのボトルネックである → game-performance-profiler
• 主な作業が、Steam 向けのローンチ／ストア作業ではなく、ゲームプロジェクト全体のマイルストーン調整である → bmad-gds

手順

ステップ 1：依頼を 1 つのパケットに分類する

アドバイスをする前に、最適なパケットを 1 つ選んでください。

パケット

• page-promise-audit — 主なリスクがページのコンバージョンにある場合：カプセル画像、スクリーンショット、トレーラー、短い説明文、タグ
• wishlist-signal-check — ユーザーがウィッシュリストの伸び悩みを訴えており、トラフィックの弱さとコンバージョンの弱さを切り分ける必要がある場合
• demo-readiness-gate — 現在の公開タイミングでデモがプラスになるか、マイナスになるかが重要な場合
• event-timing-workback — 準備状況とのトレードオフを踏まえて、Next Fest／ショーケース／タイミングを判断する必要がある場合
• launch-ops-runbook — ページはおおむね整っているものの、リリース時期、クリエイター対応の準備、レビュー／リリースの管理、担当者の割り当てが散在している場合

複数の懸念が混在している場合でも、主要なパケットを 1 つ選び、副次的な懸念を 1 つ挙げてください。

ステップ 2：信頼できる最小限の Steam パケットをまとめる

実際の判断を裏付ける最小限の根拠だけを集めてください。

• 現在の訴求ポイント：近日登場、ウィッシュリストの伸び悩み、デモの公開／更新、Next Fest、ローンチ時期、または不明
• ページの根拠：URL またはスクリーンショット、カプセル画像、最初のスクリーンショット、短い説明文、タグ
• 根拠の状況：トレーラーのリンク／冒頭のメモ、デモの状況、一般公開ビルドへの信頼度
• シグナルの状況：トラフィックが弱い、コンバージョンが弱い、どちらも不明、または不明
• タイミングの状況：フェスティバルの締め切り、ローンチ目標、デモのタイミング、レビュー／リリースの制約
• 運用の状況：クリエイター／プレス向け資料、キー／アウトリーチ、担当者の不明確さ、ローンチチェックリストの不足

根拠が乏しい場合は、確信度を低く保ち、最小限で安全なパケットを選んでください。

ステップ 3：主なボトルネックを特定する

既存の診断モデルを使いつつ、主なボトルネックは 1 つに絞ります。

主なボトルネック

• visibility-acquisition
• promise-clarity
• proof-demo-readiness
• timing-hook-fit
• launch-ops-readiness
• evidence-gap

よくある対応例：

• 「ウィッシュリスト登録が少なく、トラフィックも少ない」→ visibility-acquisition
• 「クリックする人はいるものの、ウィッシュリストに登録してくれない」→ promise-clarity
• 「ページは問題なさそうですが、デモの出来は不安です」→ proof-demo-readiness
• 「今すぐ Next Fest に参加すべきか、それとも待つべきか？」→ timing-hook-fit
• 「リリースが近いのに、資料やチェックリストが散らばっているように感じます」→ launch-ops-readiness
• 「根拠となる情報がほとんどありません」→ evidence-gap

ステップ 4：一度きりの Steam のルールを適用する

何かを提案する前に、見落としやすい制約を確認します。

• リリース前に一般公開するデモを用意するには、ベースゲームのページが「近日登場」としてすでに公開されている必要があります
• 初回の一般公開デモのリリース時には、ウィッシュリスト登録者やフォロワーへの通知機会が一度だけ、限られた期間設けられます
• Next Fest への参加には、公開済みのページ、イベント開始時点で一般プレイ可能なデモ、最新のストアアセットが必要です
• Steam の審査とリリースには、引き続き手動でのタイミング調整やリスクが伴います。すべてが自動で進むと考えてはいけません

提案内容によってこれらの機会を弱いパッケージに費やすことになる場合は、その点をはっきり伝えます。

ステップ 5：パケットに応じた介入策を選ぶ

パケットは 1 つ、介入策も 1 つに絞ります。

page-promise-audit

ページの内容がボトルネックと思われる場合に使用します。

注目する点：

• カプセル画像の視認性
• スクリーンショットの順序とゲームプレイの証拠
• トレーラーの冒頭
• 短い説明文の具体性
• タグの一貫性

次に作成するとよい成果物：

• page rewrite brief
• screenshot reorder brief
• trailer hook brief
• tag audit

wishlist-signal-check

チームが弱いウィッシュリストの結果に過剰適合している場合に使用します。

注目する点：

• トラフィックの少なさとコンバージョンの低さの違い
• ページの内容が、実際にオーディエンスに向けた訴求と合っているか
• デモや実証が不足している、または弱いか
• ウィッシュリストの不調の背景に、タイミングやイベントの問題が隠れていないか

次に作成するとよい成果物：

• wishlist signal memo
• page rewrite brief
• visibility push check
• demo readiness checklist

demo-readiness-gate

デモが一般公開に向けた実証となるかが論点の場合に使用します。

注目する点：

• デモが信頼感を高めるか
• 最初のセッションの品質が、現在のページでの訴求に見合っているか
• 通知やイベントの機会を早く使いすぎていないか
• よりよい選択肢が、磨き込み、延期、機会の絞り込み、または実行のどれか

次に作成するとよい成果物：

• demo readiness checklist
• proof-gap notes
• event timing memo

event-timing-workback

主な判断事項が、実際の準備状況で一般公開の機会に間に合うかどうかの場合に使用します。

注目する点：

• Next Fest やショーケースとの適合性
• ページ、トレーラー、タグ、デモの準備状況を一体として評価すること
• イベントを準備状況の判定基準として扱っているのか、それとも期待先行の認知獲得策として扱っているのか
• 期限までに必要な直近の作業と逆算スケジュール

次に作成するとよい成果物：

• Next Fest runbook
• event timing decision memo
• asset lock checklist

launch-ops-runbook

ページやデモの中核部分にはおおむね問題がないものの、リリースの実行準備がまとまっていない場合に使用します。

注目する点：

• 審査とリリースのタイミング
• クリエイターや報道関係者への準備、キーやアウトリーチ用パケットの整理
• 担当者の不在や不明確さ
• リリース当日のチェックリストと不測の事態への対応ポイント

次に作成するとよい成果物：

• launch checklist
• launch-day runbook
• creator/outreach prep packet

ステップ 6：スコープが広がる前に別の担当へ振り分ける

隣接する作業を取り込むのではなく、次の場合は別の担当へ振り分けます。

• Steam 向けのローンチ／ストア作業を超える、広範な集客／コンテンツ／ライフサイクル／効果測定の戦略が必要 → marketing-automation
• 根拠の大半がプレイテストのコメント、ユーザーの混乱、または一貫しないデモのフィードバック → game-demo-feedback-triage
• 問題が単一のビルドの破損、パッケージングの失敗、または CI／エディターのログ → game-build-log-triage
• 本当のボトルネックがランタイムのパフォーマンス、Steam Deck、フレームタイム、またはプラットフォームの制約 → game-performance-profiler
• 作業がより広範なマイルストーンの調整、マイルストーンのリスク、またはプロデューサー的な順序付け → bmad-gds

信頼できる最初の窓口は、次に取るべき行動を絞り込みます。隣接するあらゆるゲームマーケティング業務に対応すると主張するものではありません。

ステップ 7：Steam ローンチパケットを 1 つ返す

長大なエッセイではなく、簡潔なパケットを 1 つ返します。

# Steam Launch Packet

## Packet choice
- Primary packet: page-promise-audit | wishlist-signal-check | demo-readiness-gate | event-timing-workback | launch-ops-runbook
- Secondary concern: optional
- Current hook: ...
- Confidence: high | medium | low

## Evidence used
- Page / asset evidence: ...
- Demo / proof evidence: ...
- Signal context: ...
- Timing / ops context: ...
- Missing but important: ...

## Primary bottleneck
- Bucket: visibility-acquisition | promise-clarity | proof-demo-readiness | timing-hook-fit | launch-ops-readiness | evidence-gap
- Why it matters now: ...
- Evidence: ...

## Recommended intervention
- One intervention: ...
- Why this is the shortest credible move: ...

## Priority checks
1. ...
2. ...
3. ...

## Recommended next artifact
- Choose one: page rewrite brief | screenshot reorder brief | trailer hook brief | tag audit | wishlist signal memo | visibility push check | demo readiness checklist | event timing decision memo | Next Fest runbook | asset lock checklist | launch checklist | launch-day runbook | creator/outreach prep packet

## Route-outs
- Skill: ...
- Why: ...
- Packet to pass: ...

## What not to do yet
- 1-3 bullets that prevent folklore, wasted spend, or premature scope drift

ステップ 8：確定前に境界を確認する

次の点を確認します。

• ページ監査、デモ QA、アウトリーチ CRM、広範な GTM 戦略を混ぜずに、パケットを 1 つ選びましたか？
• ページの変更を提案する前に、トラフィックの弱さとコンバージョンの弱さを分けて考えましたか？
• デモや Next Fest を、一般的な露出機会として無償で使えるものではなく、準備状況を見極めるゲートとして扱いましたか？
• 該当する場合、単発の実施機会やレビューに関する制約を明示しましたか？
• このスキルの範囲を広げずに、フィードバック／ビルド／パフォーマンスの作業を別の担当へ振り分けましたか？

出力形式

必ず簡潔な Steam ローンチパケットを返します。

必須条件：

• 主となるパケットは 1 つ
• 主となるボトルネックは 1 つ
• 次の成果物は 1 つ
• 根拠が乏しい場合は不確実性を明示
• 実際の作業が別の担当に属する場合は振り分ける
• 汎用的なマーケティング論を長々と述べない

例

例 1：ある程度のトラフィックはあるが、ウィッシュリスト登録が少ない

入力

ソーシャル投稿から Steam ページへのクリックはありますが、ウィッシュリスト登録は依然として少ないです。カプセル画像、スクリーンショット、短い説明文、タグを確認してください。

望ましい回答の方向性

• パケット：wishlist-signal-check
• ボトルネック：promise-clarity の可能性が高い
• 次の成果物：page rewrite brief または screenshot reorder brief
• トラフィックだけが問題だと決めつけない

例 2：Next Fest への参加判断

入力

Next Fest に参加したいです。ページは公開済みで、トレーラーもまずまずですが、デモの仕上がりがまだ粗いのではないかと心配です。

望ましい回答の方向性

• パケット：event-timing-workback または demo-readiness-gate
• ボトルネック：proof-demo-readiness
• Next Fest は準備状況を見極めるゲートであると指摘する
• 次の成果物：demo readiness checklist または Next Fest runbook

例 3：ローンチチェックリストの依頼

入力

Steam ローンチ用のチェックリストをください。ページ、トレーラー、デモ、小規模なクリエイターリストがあります。

望ましい回答の方向性

• パケット：launch-ops-runbook
• ボトルネック：launch-ops-readiness
• 次の成果物：launch checklist または launch-day runbook
• ページのコンバージョンとクリエイター向け準備は、ローンチ運用の範囲内にとどめ、GTM 全体の見直しに広げない

ベストプラクティス

1. まずパケットを選ぶ — 最初の窓口で、すぐにタスクを絞り込む必要があります。
2. シグナルと俗説を切り分ける — ウィッシュリスト、デモ、Next Fest には、的外れな定型アドバイスがつきものです。
3. デモを公開される証拠として扱う — 単なる追加アセットではありません。
4. Steam のタイミングを制約の仕組みとして扱う — Coming Soon、デモの通知タイミング、レビュー／リリース、Next Fest はすべて重要です。
5. 長大なローンチ理論を並べるより、次の成果物を 1 つ提示します。
6. Steam に特化する — これはリポジトリにおけるゲームローンチ向けの例外であり、汎用的なマーケティング用ラッパーではありません。

参考資料

• Steamworks Documentation — Steam での露出
• Steamworks Documentation — Coming Soon
• Steamworks Documentation — デモ
• Steamworks Documentation — Steam Next Fest
• Steamworks Documentation — リリースプロセス