アプリをリリースしてからが本当のスタート
私は個人開発でアプリをリリースし続けて 12 年になります。Rork が登場してからは、リリースまでの工数が劇的に短くなり、これまで諦めていたアイデアも形にできるようになりました。一方で、リリースしてからの 90 日間が、これまで以上に重要だと感じるようになっています。
アプリの本当の価値は、リリース後に決まります。クラッシュ、レビュー、広告収益、機能追加、課金導線、ユーザー定着率。どれも 1 つ間違えると、せっかく作ったアプリが伸びきれずに終わります。Rork で開発したアプリも例外ではなく、むしろ生成 AI で素早く作れるからこそ、運用フェーズの判断が品質を左右します。
ここではRork でリリースしたアプリの最初の 90 日間に直面する 8 つの分岐について、私自身の運用経験をベースに書きました。読者の皆さんが、リリース直後の意思決定で迷わないことを願っています。
分岐 1 — クラッシュレポートにどこまで反応するか
リリース直後の数日間は、クラッシュレポートが大量に届きます。OS のバージョン違い、特定の端末でのレンダリング不具合、ネットワーク異常時の挙動など、開発時には想定できなかったケースが次々と表面化します。
ここで重要なのは、全てのクラッシュに同じ優先度で対応しないことです。私が今使っている分類は次の通りです。
- 即修正対応：起動時クラッシュ、課金フロー中のクラッシュ、レビューに直結する操作でのクラッシュ
- 次のリリースで対応：特定機能でのクラッシュで、頻度が低く回避策があるもの
- 観察のみ：1 端末・1 OS でのみ発生し、再現できないもの
即修正対応は、最大でも 48 時間以内にホットフィックスを出します。Rork の場合、再ビルド・再申請が比較的早いので、Apple のレビューが空いている時間帯を狙えば、48 時間以内のリリースは十分現実的です。
逆に、観察のみと判断したクラッシュに時間をかけてしまうと、次の機能追加が遅れて、ユーザーが離れます。優先度を間違えないことが、リリース直後の運用効率を決めます。
分岐 2 — App Store のレビュー返信をいつ始めるか
アプリストアのレビュー返信は、書き始めると時間が消えます。1 件 5 分かけても、1 日 50 件返信すれば 4 時間が消える計算です。
私の判断基準は、最初の 14 日間はレビュー返信を控えるです。理由は、初期レビューの傾向はユーザー層が固まる前のものなので、返信内容が後で陳腐化するからです。代わりに、レビューの内容を全て記録して、次の改善計画の材料にします。
15 日目以降は、次のルールで返信します。
- 星 1〜2 の批判的なレビュー：必ず返信。改善予定があれば具体的に書く
- 星 3 のレビュー：機能リクエストなど建設的なものに限り返信
- 星 4〜5 のレビュー：機能リクエストや具体的な感想があれば返信、感謝のみは返信不要
この線引きを設けないと、レビュー返信に追われて開発時間が削られます。返信は機能改善より優先度が低いという前提を、自分の中ではっきりさせておくのが大切です。
分岐 3 — AdMob の収益が見え始めた時、戦略を変えるか
リリースから 30 日ほど経つと、AdMob の収益データが安定してきます。1 日あたり数百円なのか、数千円なのか、数万円なのかで、その後の開発戦略が変わります。
私が経験的に使っている分岐は次の通りです。
- 1 日 1,000 円未満：マネタイズより使い勝手の改善を優先。広告枠の追加は控える
- 1 日 1,000〜10,000 円：広告枠の最適化と、新規ユーザー獲得施策を並行
- 1 日 10,000 円以上：広告枠を 1〜2 箇所追加し、コア機能の拡張に投資
数字の絶対値は人によりますが、収益のレンジによって取るべきアクションが違うという考え方は、応用が効くと思います。リリース直後の数字に一喜一憂せず、30 日のレンジで判断するのが私のスタイルです。
ちなみに、1 日 1,000 円未満のアプリでも、シリーズで 5 本運用すれば 1 日 5,000 円になります。1 本のヒットを狙うより、コンスタントに動くアプリを複数持つ方が、個人開発者には現実的です。
分岐 4 — 機能追加と既存機能の改善、どちらを優先するか
リリース直後は「次に何を追加するか」を考えがちですが、これが落とし穴になります。既存機能の改善が、機能追加より早く収益に結びつくケースが多いからです。
私の判断軸は、機能ごとの 継続率の差分を見ることです。Firebase Analytics などで、機能 A を使ったユーザーと使っていないユーザーの 7 日後継続率を比較し、差が大きい機能を優先的に磨きます。
例えば、ある壁紙アプリで「お気に入り機能」を使ったユーザーの 7 日後継続率が 65%、使っていないユーザーが 28% だった場合、新機能を追加するより、お気に入り機能をより使いやすくする方が、全体の継続率を引き上げます。
機能追加は華やかに見えますが、実は 既に使われている機能を磨く方が、ROI が高いことが多いです。リリース直後の 90 日間は、特に既存機能の磨き込みに時間を使う価値があります。
分岐 5 — 課金導線をいつ・どう実装するか
無料アプリに後から課金を追加するか、最初からフリーミアムにするかは、リリース前から悩むポイントです。Rork で開発したアプリの場合、私は次のパターンを使い分けています。
最初から課金を入れるべきパターン：
- ユーティリティ系で、月 1〜2 回しか使わない用途
- ヘビーユーザーが少数で、ライト層が多い構造
- コンテンツの追加が継続的に必要なアプリ
リリース後に課金を追加するパターン：
- 当初の利用想定が読みづらく、ユーザー行動を見てから判断したいアプリ
- 広告と課金を併用する設計で、まず広告の効果を測りたい場合
私の経験では、リリース後に課金を追加する場合、最初の課金実装はできるだけシンプルにするのが鉄則です。複雑なプラン構成や年額/月額の使い分けは、データが集まってから検討すれば良く、最初は「広告を消す」「機能を全解放する」など 1 つの価値提案に絞ります。
分岐 6 — A/B テストをいつから始めるか
リリース直後から A/B テストを始めたくなる方も多いと思いますが、ユーザー数が少ない時期の A/B テストは判断に使えません。1 日 100 人しかインストールしていないアプリで、ボタンの色を変えて 5% の差が出たとしても、それが偶然か実力かは分かりません。
私が A/B テストを意味あるものとして使い始めるのは、1 日のアクティブユーザー数が 1,000 人を超えてからです。それまでは、A/B テストではなく、自分の感覚と数名のヒアリングで判断します。
リリース直後にやるべきは、A/B テストではなく「仮説の整理」です。次に何を変えるべきか、なぜそれを変えると効果が出ると思うのか、を文章として書き出しておくこと。これをやっておけば、ユーザー数が増えた時に、すぐに有意義な A/B テストを設計できます。
分岐 7 — ストア表示の最適化（ASO）にどこまで時間を使うか
App Store / Google Play のスクリーンショット、アイコン、説明文の最適化（ASO）は、効果が大きい一方で、無限に時間を吸い取られる作業です。
私の判断基準は、最初の 30 日は完璧を目指さないです。リリース直前に作った素材で 30 日運用し、その間にコンバージョン率（インプレッション → ダウンロード）のデータを集めます。30 日後に、次の優先順位で素材を更新します。
- アイコン（最も影響が大きく、最も判断を間違えやすい）
- 1 枚目のスクリーンショット
- アプリ名とサブタイトル
- 残りのスクリーンショット
- 説明文の本文
特に アイコンは 1 ヶ月間隔で 2〜3 回試行錯誤する価値があります。同じアプリでアイコンを変えただけで、ダウンロード数が 30〜50% 変わることは珍しくありません。
分岐 8 — 次のアプリに着手するか、このアプリに集中するか
90 日経つと、次のアプリのアイデアが浮かんできます。Rork で素早く作れるからこそ、新しいアイデアを試したくなります。しかし、1 本のアプリの成長を放棄して新しいアプリに移ると、両方が中途半端になることが多いです。
私が今使っている判断基準は、現アプリが次の条件を満たしているかどうかです。
- 7 日後継続率が 30% を超えている
- 1 日のダウンロード数が安定している（増減 ±20% 以内）
- 重大なクラッシュが解消されている
- 課金または広告の収益動線が確立している
これらを満たしていれば、現アプリに月 8 時間程度のメンテナンス時間を確保しながら、次のアプリ開発に時間を分配できます。満たしていない場合は、次のアプリに着手する前に、現アプリを軌道に乗せることを優先します。
複数アプリ運用の鉄則は、「手放せる状態を作ってから次に進む」ことだと思っています。手放せない状態のアプリを増やしても、運用負荷だけが積み上がります。
90 日後、自分のアプリを客観視できるかが分岐点
ここまで紹介してきた 8 つの分岐は、どれもリリース直後の判断としては地味なものです。派手な機能追加でも、大胆なピボットでもありません。しかし、90 日後に自分のアプリを客観視できる状態に持っていけるかが、その後の 1 年の運用を決めます。
90 日経った時点で、
- アプリの強みと弱みを自分の言葉で 3 つずつ言える
- 次の 30 日でやるべきことが優先度付きで 5 個リストアップできる
- 自分が手を入れなくても、最低限の運用が回る状態になっている
この 3 つが揃っていれば、その後の運用は飛躍的に楽になります。逆に、90 日経っても自分のアプリの全体像が見えていない場合、それはまだリリース直後の混乱を抜け出せていない証拠です。
Rork は素早く作れるツールですが、リリース後の運用は、開発と同じくらい時間がかかります。作る時間と同じくらい、運用設計の時間を確保することが、個人開発で長く続けるための一番の秘訣だと、12 年運用してきた今、強く思っています。
明日のあなたのアプリ運用に、この記事のどこか 1 つでも役立つ判断軸が残れば嬉しいです。