リリースボタンを押した直後の数時間ほど、落ち着かない時間はありません。アップロードしたビルドがレビューを通り、ストアに「入手」ボタンが灯った瞬間から、しばらくのあいだ、自分のアプリはほとんど自分の手を離れます。世界のどこかで、見知らぬ誰かが、自分の作ったものを最初に開いています。その時間が、その後の半年から1年ぶんの評価とランキングを、思っているよりはるかに大きく左右します。
2014年から個人で iOS / Android アプリを作り続けてきて、累計のダウンロードはだいぶ前に5,000万を超えました。壁紙系・癒し系・引き寄せ系といったジャンルで、いまも複数のアプリを運用しています。新作のリリースは数えきれないほど経験してきましたが、毎回緊張するのは「最初の72時間」です。Rork のような生成型ツールで一気に組み上げたアプリだとなおさら、ここに何が起きるか分かっていないと、後追いで取り返すのが本当に難しくなります。
本記事は、Rork で作ったアプリをストアに出した直後の3日間で実際に起きること、そしてどの順番で何を見ればいいかを、運用者の視点でまとめたメモです。教科書的な総論ではなく、自分の手で何度も体験してきた具体的な順序として読んでいただけたらと思います。
最初の3時間 — まず「届いているか」を確かめる
リリース直後にいちばん最初に見るべきは、新機能でも収益でもなく、「アプリが届いているか」です。App Store Connect の販売およびトレンドに最初のダウンロード数が立つまでに、地域によって30分から数時間のラグがあります。この時間に、もし Crashlytics のリリース別ダッシュボードに最初のクラッシュレポートが乗っていたら、その瞬間にやるべきことは決まっています。
最初の3時間で重点的に見るのは、次の3点だけで十分です。
ひとつ、Crashlytics（または Sentry など）のクラッシュフリーユーザー率が 99% を割っていないか。ふたつ、App Store Connect / Google Play Console の「クラッシュ」セクションに ANR や強制終了の急増がないか。みっつ、AdMob のリクエストが「ほぼゼロ」になっていないか。
3つ目の AdMob は意外と見落としがちで、SDK の初期化に失敗していたり、AppOpen 広告のフリークエンシーキャップが厳しすぎたりすると、リクエスト数自体が立ち上がらないことがあります。私は過去に一度、本番ビルド側で AdMob のテスト ID をうっかり残してしまい、リリース直後に「広告は出ているのに収益が一切立たない」という状態を半日続けたことがあります。リリース当日にこういう設定ミスを見つけるなら、最初の3時間で気づくのが圧倒的に安全です。
6 時間目 — レビューの「初速」を観察する
ストアレビューは、出始めの数件が、その後数週間にわたる平均スコアの基準になります。とくに無料アプリの場合、最初の10件のレビューで平均が 3.0 を割ると、そこから 4.0 台に戻すのは想像以上に大変です。
リリースから6時間ほど経つと、海外のヘビーユーザーから「アプリ内のテキストが切れている」「ダークモードで文字が読めない」といった、視覚まわりの細かいフィードバックが届きはじめます。Rork の生成物はデフォルトでダークモードに対応していますが、私の経験では、リリース直後に最も指摘されるのはやはりここでした。とくに iPad や折りたたみ端末のような特殊なレイアウトでは、ボタンのラベルが2行に折り返されて読みにくくなる、というレポートが入りやすいです。
このタイミングで意識しているのは、星評価そのものよりも「コメント本文の質」です。星1がついていても、本文に「ここを直してほしい」という具体的な指摘があれば、それはむしろ宝物です。逆に星5でも「いいですね」だけのコメントは、改善の手がかりにはなりません。レビュー一覧を見るときは、ソートをまず「最新」にし、そのうえで「★1〜★3」だけをフィルタしてざっと読みます。ここで挙がった具体的な指摘を、当日のうちにメモにまとめておくと、翌日の優先順位がぐっと整います。
12 時間目 — 広告とリテンションの最初のグラフを読む
リリースから半日が経つと、AdMob のレポートに「Day 0 のクリック率」「Day 0 の eCPM」が乗りはじめます。ここで注意したいのは、最初の日の数字は良く出すぎることが多い、という点です。
これは経験則ですが、リリース初日は、新規ユーザーがアプリを試そうとして画面遷移を多くするため、インタースティシャル広告の表示回数が通常より増えやすい傾向があります。同じ理由で、AppOpen 広告の impression もふだんより1.3倍ほど多く見えます。この数字を「リリース後の通常値」だと思い込むと、3日後にがっかりすることになります。
私は新規アプリのリリース直後は、AdMob の eCPM をあえて「14日間移動平均」で見るようにしています。Day 0 や Day 1 単独の数値ではなく、安定するまで2週間待つ。これだけで、慌てて広告位置を変えたり、フリークエンシーキャップをいじったりする回数がぐっと減りました。
リテンションについても同じで、リリース当日の Day 1 リテンションは、純粋な新規ユーザーではなく、自分や知人がアプリを試した「ノイズ込み」の値になっています。Firebase Analytics の audience を「リリース初日に獲得」で切ってリテンション曲線を見るときは、最低でも3日分のデータが揃ってからにしています。
24 時間目 — クラッシュレポートの「集約」をかける
リリースから丸1日が経過すると、Crashlytics のクラッシュレポートが個別のスタックトレースから「グループ」に集約されはじめます。ここで初めて、「同じバグで100人がクラッシュしている」のか「100種類の小さなバグでそれぞれ1人ずつクラッシュしている」のかが見えてきます。
実際にやってみると、リリース直後のクラッシュは8割が「上位3グループ」に集中していることがほとんどです。逆に言えば、上位3グループだけを直せば、影響を受けるユーザーの大半を救えるということでもあります。私はこの時点で、上位3つのクラッシュについて再現手順を Rork のコード側で検証し、その日のうちにマイナーアップデートをビルドしておきます。アップロードと審査提出は翌朝にまわすとしても、ビルドだけはこのタイミングで用意しておくのが、自分の精神衛生にとっても良いと感じています。
ここで欲張って「あれもこれも」と直そうとすると、24時間という限られた時間で何も終わりません。リリース直後の修正は「クラッシュ3件と、明らかな表示崩れ1件」までと自分のなかでルールを決めています。
48 時間目 — レビュー返信の最初の波をさばく
48時間が経つと、App Store / Google Play のレビュー数は、よほど小さなアプリでない限り、両ストア合計で20〜50件ほど溜まってきます。ここで私が意識しているのは、「翌日まで貯めない」という一点だけです。
レビュー返信は、書きはじめると意外と時間がかかります。1件あたり3〜5分として、30件で90〜150分。これを2日分まとめて返信しようとすると、半日仕事になります。リリース直後の貴重な時間を、まとめ返信に溶かしてしまうのは本当にもったいありません。だから、12時間に1度の頻度で、まとめて20件ずつ返信していくのが私の運用パターンです。
Rork で作ったアプリのレビューは、独自実装のアプリよりも「機能の浅さ」を指摘されやすい傾向があります。「もう少し○○機能が欲しい」「他社アプリと比較して△△が足りない」といった内容です。これらに対して、その場で機能追加を約束する必要はありません。「フィードバックをありがとうございます。次のアップデートで検討します」という一文だけでも、返信があること自体がストアでの信頼感に直結します。
72 時間目 — ランキングの「定位置」を確認する
リリースから3日目に入ると、各カテゴリでの順位が、ある程度の幅で「定位置」を取りはじめます。私はこの3日目の順位を、その後1ヶ月の運用方針を決める基準にしています。
具体的には、3日目のカテゴリ順位が想定より上位なら、ASO（ストア最適化）の方向は合っていると判断し、しばらくは現状の構成を維持します。逆に想定より下位なら、その日のうちにスクリーンショットの順序とサブタイトルを差し替え、A/B テスト用に2案を準備します。判断を3日目に固定しておくことで、毎日順位を見て一喜一憂する時間を減らせます。
ここで気をつけているのは、「絶対順位」ではなく「日次の伸び」を見ることです。リリース直後はストア側のブースト枠（New & Noteworthy などの動的な扱い）が効いていることもあり、絶対順位は実力以上に出ていることがあります。3日目の絶対順位そのものではなく、「Day 3 の数字を Day 7 がどれくらい維持できるか」を見たほうが、長期的な判断には適しています。
私の72時間チェックリスト
最後に、私自身がリリースのたびに iCloud のメモに書き写しているチェックリストを置いておきます。Rork で作ったアプリでも、独自実装のアプリでも、共通して使っているものです。
- リリース0時間: ストアの「入手」ボタン点灯確認・最初のダウンロード地域メモ
- リリース3時間: クラッシュフリー率・ANR 急増・AdMob リクエスト立ち上がり
- リリース6時間: ★1〜★3 レビュー本文をフィルタして読み、当日対応リストへ
- リリース12時間: AdMob は14日移動平均で見る・Day 0 数値を信じすぎない
- リリース24時間: Crashlytics 上位3グループの再現確認・修正ビルド準備
- リリース48時間: レビュー返信20件ずつ・「次回検討します」を恐れない
- リリース72時間: カテゴリ定位置確認・ASO 変更は3日目以降に集中
このリストは、何かを増やすためのものではなく、「やらないことを決める」ためのものです。リリース直後はやれることが無限にあるように感じますが、本当に効くのはこの7項目だけだと、何度も経験するうちに確信するようになりました。
静かな初日を、設計の力で迎えるために
1997年、16歳ではじめてインターネットに触れたとき、自分が書いたコードが地球の裏側の誰かに届く感覚に、何度も胸を熱くしました。それから30年近くが経ち、いま自分が作ったアプリは、本当に地球の裏側の誰かのホーム画面に並んでいます。リリース直後の72時間は、その「届いている」という事実を、自分の体で確かめる時間なのだと、最近は思うようになりました。
Rork のような生成型のツールを使うと、アプリそのものを作ること自体は、以前よりずっと速くなりました。だからこそ、リリースから72時間という、長くなりすぎることのない時間のなかで何を見て何を見送るかという「設計」のほうに、自分の集中をまわせるようになったと感じています。慌てず、しかし手を抜かず、その日のうちに片付くことだけを片付ける。次にアプリを出すときの参考になれば嬉しいです。
最後までお読みいただき、ありがとうございました。