作品ローンチ・運営プレイブック

作品(Works)をベータから正式公開へ進めるときのチェックリストだよ。ライセンス確認、分配設定、フィードバック回収、サポート導線までを一気通貫で見直せるようにまとめた。

1. ベータ開始前にそろえるもの

• 目的と成功条件: 「初回プレイ30件」「完走率60%」「支援ボタンのクリック10件」など具体的に。数字があると改善しやすい。
• 対象ユーザーの想定: 初心者向けか、配信者向けか、特定ジャンルのファン向けかを決め、説明文に明記する。
• ライセンス/権利確認: `./licenses-and-rights.md` に沿って、権利者名とライセンスを設定。外部素材がある場合は出典URLもメモ。
• バージョンラベル: `v0.1-beta` のようにタグを付け、更新履歴を短く残す。プレイヤーが安心して試せる。

2. ベータ期間の運用

• 短いフィードバックループ: 週1回はログとアンケートを確認し、「想定プレイ時間」「詰まりポイント」「推しシーン」を記録する。
• クラッシュ・バグ報告導線: `/support/report` へのリンクを作品ページに置く。入力例も簡単に書いておくと報告率が上がる。
• 限定公開の使い分け: 内輪テストは限定公開で、フィードバックが集まったら公開に切り替える。切り替え時は告知文を残す。

3. 正式公開前の最終チェック

• チュートリアルの長さ: 5〜10分で終わるか？ 初回離脱が多いなら短縮する。
• ライブカード適合度: 主要キャラで最低1回は旅を実施し、口調崩れや禁則違反がないか確認（`./live-card-writing.md`）。
• ライセンス表記: KFL / CC / カスタムが一貫しているか。説明欄にクレジットを追記したか。
• 支援・購入導線: 支援ボタンやレプリカ配布を設定するなら、価格や特典説明を明記。`./creator-support-design.md` を参照。
• メタデータ: カバー画像、タグ、作品説明を最新に。公開範囲と配信可否の説明も添える。

4. 公開後の運営サイクル

• 週次レポート: プレイ数、完走率、支援額、よく読まれたログをまとめる。数字が落ちた箇所を次の改善に回す。
• イベント/アップデート計画: 「週1回の小アップデート」「月1回の大型イベント」など予定を決め、SNSとヘルプで予告する。
• UGC の活用: リプレイや配信クリップを `./replay-curation.md` の手順で記事化し、作品ページからリンクする。
• トラブル対応: 権利申立てや不具合が出たら迅速に非公開 → 修正 → 再公開。変更点を必ずリリースノート形式で共有する。

5. 長期運営のヒント

• 季節/テーマ更新: カラーやBGMを季節に合わせて差し替えるだけでも復帰率が上がる。
• 派生作品の扱い: 他クリエイターのライブカードを公式派生として迎えるときは、ライセンスと分配比率を事前に合意しておく。
• データで見る: 初動より「2週目の継続率」「完走後の支援率」を追うと改善ポイントが見つかりやすい。

ローンチはゴールではなくスタート。小さなサイクルで改善しながら、プレイヤーとの対話を続ければ作品の寿命は大きく伸びるよ。