Rork で作ったアプリを『削除されない』ものにする — 個人開発のための継続率設計
私は 2014 年から個人でアプリを作ってきました。Rork に出会う前から、AdMob で月 100 万円を超える収益が出るアプリも、リリース当日にダウンロードが伸びたあと一週間で消えていったアプリも、両方経験しています。両者の差は機能の数でも、デザインの綺麗さでもありませんでした。差は「削除されないようにする設計を、リリース前にやったかどうか」だけでした。
Rork はアプリを素早く立ち上げられるツールなので、ついリリース後の運用設計を後回しにしがちです。しかし削除されるアプリは、リリースから 3 日以内、長くても 1 週間以内に削除されます。この期間に何が起きているかを設計しないと、Rork の生産性で量産したアプリが、量産したまま消えていきます。
ストアの星評価ではなく「削除タイミング」を見る
多くのアプリ運営の解説では、星評価やクラッシュ率を主要な KPI に挙げます。これは間違いではないですが、個人開発者にとって最も大事な KPI は「ユーザーがいつ削除したか」です。星評価は削除しないユーザーが付けるもので、削除する人は静かに去ります。星評価が高いのに DAU が伸びない場合、削除タイミングを見ていない可能性が高いです。
私はリリース後の最初の一ヶ月、毎日「インストール後 N 日で削除されたユーザーの割合」を Firebase などの分析ツールから抽出しています。具体的には次の三つの数字を毎朝チェックします。
D0 削除率 — インストール当日に消された割合（理想は 5% 未満）
D1 削除率 — 翌日までに消された割合（理想は 15% 未満）
D7 削除率 — 一週間以内に消された割合（理想は 40% 未満）
業界の標準値はもっと厳しいですが、個人開発で広告予算を使わない場合の現実的な閾値です。これより悪い場合、機能ではなく初週の設計に問題がある可能性が高いです。
D0: 起動 60 秒以内に「これは私のためのアプリだ」を渡す
D0（インストール当日）に削除されるアプリには、共通のパターンがあります。起動直後にユーザーが「これは私のために作られたアプリだ」と感じるエピソードが用意されていないのです。Rork で作るアプリはコンセプトが先鋭化していることが多いので、本来この設計は得意分野なのですが、ついつい「機能の説明」を最初に置いてしまい、ユーザーが冷めます。
私が D0 で気をつけているのは、起動から 60 秒以内に次の三つを終えることです。
1. 「あなたのことを知りたい」を伝える質問を1問だけする
2. その答えに応じてホーム画面の見え方を実際に変える
3. 「これがあなた専用の状態です」と明示する
質問を1問に絞るのが鍵です。質問が多いと、ユーザーは「面倒なアプリ」と判断して 30 秒で削除します。1問だけ、しかもその答えがホーム画面に即座に反映されることが大事です。たとえば「壁紙アプリなら好きな雰囲気を1つだけ選ばせ、その雰囲気のコレクションだけ最初に見せる」が分かりやすい例です。
Rork のテンプレ的なオンボーディングをそのまま使うと、複数ステップのフォームになりがちです。これは D0 削除率を悪化させる元凶です。私は Rork のオンボーディングを必ず1問に削ります。
D1: 起動から 24 時間後に「思い出される理由」を仕込む
D1（インストール翌日）に削除されるユーザーは、「使う理由を見つけられなかった」人です。一日経ってもう一度アプリを開く動機が、明示的に作られていない場合に発生します。
ここで多くの個人開発者が手を伸ばすのが「プッシュ通知」ですが、私の経験では D1 段階でのプッシュ通知は逆効果です。インストール翌日に通知が来ると、「うっとうしい」と感じて即削除する人がいます。代わりに、アプリ自体に「翌日になったら別の表情を見せる」仕掛けを入れます。
具体例を一つ挙げます。私のとあるアプリでは、初日の夜にだけ表示される画面と、翌日の朝にだけ表示される画面を別物にしてあります。ユーザーは翌朝アプリを開いたとき、「あ、昨日とは違う」と気づきます。気づきは記憶を強化し、削除のスイッチを押す指を止めます。
// アプリ起動時に「経過日数」と「時間帯」で見せ方を切り替える
function getMorningSurfaceForDay1(installedAt: Date, now: Date) {
const hours = (now.getTime() - installedAt.getTime()) / 36e5;
if (hours >= 12 && hours <= 36 && now.getHours() < 12) {
return "morning_after_first_day";
}
if (hours < 12) {
return "first_evening";
}
return "regular_home";
}この単純なロジックが入っているだけで、アプリは「時間と一緒に育つ」感じを出せます。プッシュ通知に頼らずに、再訪したときの体験そのもので継続を促すのが、私の好む設計です。
D3: 「使い込んだ感」を可視化する
D3（インストール3日目）の削除は、「もう新鮮味がない」と感じたユーザーが落ちるタイミングです。ここで効くのは「使い込んだ感」を見せる工夫です。
私が好むのは、ユーザーが起動するたびにじわじわ蓄積される小さな履歴の可視化です。たとえば壁紙アプリなら「これまで保存した壁紙の枚数」を、瞑想アプリなら「これまで瞑想した分数」を、シンプルに表示するだけで構いません。重要なのは、その数字が「自分の積み重ね」だと感じられることです。
// ユーザーの累積アクションを軽い演出で見せるパターン
function buildStreakBadge(actionCount: number) {
if (actionCount === 0) return null;
if (actionCount < 10) return { label: `${actionCount}回 はじめての旅`, tone: "soft" };
if (actionCount < 50) return { label: `${actionCount}回 続けています`, tone: "warm" };
return { label: `${actionCount}回 積み上げています`, tone: "deep" };
}ここで気をつけるのは、ゲーミフィケーション的な煽りにしないことです。「あと N 回でレベルアップ！」のような強いインセンティブは、Rork で作るような個人開発のアプリの世界観と相性が悪いことが多いです。淡く、控えめに、ユーザーの行動が積み重なっていることを伝えるだけで十分です。
D7: 「ここから本領発揮」フェーズを明示する
D7（一週間後）まで残ったユーザーは、削除候補ではなく「本当のユーザー」になりかけています。ここで多くのアプリは何もせず、ただ機能を提供し続けます。私はこの時点で「ここから本領発揮」というフェーズを明示することを推奨します。
具体的には、一週間使ったユーザーにだけ表示される機能や設定項目を作ります。これは「上級者向け」というラベルではなく、「あなたはもう新規ユーザーではないので、この機能を使えます」というアンロックの体験です。
function getUnlockedFeatures(daysSinceInstall: number) {
const features = ["basic"];
if (daysSinceInstall >= 1) features.push("personal");
if (daysSinceInstall >= 3) features.push("history");
if (daysSinceInstall >= 7) features.push("advanced_filters");
if (daysSinceInstall >= 30) features.push("custom_themes");
return features;
}機能を後出しにする最大のメリットは、初週の認知負荷を下げることと、長く使うほど「アプリが応えてくれる感」が出ることです。Rork で作るアプリは機能数が控えめになりがちなので、最初から全部出さず、時間で段階的に開く設計と相性がいいです。
削除直前のサインを拾う
ユーザーが削除する前には、必ず「削除を考え始めるサイン」が出ます。代表的なものは次の三つです。
第一に、起動頻度の急激な低下です。たとえば「過去 7 日のうち 5 日起動していたユーザーが、突然 2 日続けて起動しなくなる」。これは離脱の前兆です。
第二に、設定画面への滞在時間の増加です。「通知を切る」「データを消す」といった操作を探しているサインで、削除直前によく見られます。
第三に、アプリ内のヘルプやお問い合わせを開く回数の増加です。困っていることがあるのに解決できていないサインです。
これらを Firebase のイベントとして拾い、特定の閾値を超えたユーザーにだけ「アプリ内のお礼メッセージ」を出すと、削除率が下がるケースを見たことがあります。ただし通知は出してはいけません。アプリを開いている瞬間に、控えめに気持ちを伝えるだけです。
「削除されたユーザー」を呼び戻そうとしない
最後に、これは個人開発者として大事にしている考え方です。削除されたユーザーをメールやリターゲティング広告で呼び戻すのは、個人開発の場合は労力に見合いません。
理由は二つあります。第一に、削除したユーザーは「自分には合わなかった」と判断した人で、その判断は基本的に正しい。第二に、呼び戻しのコストは、新しいユーザーに来てもらうためのオーガニック改善に投じたほうが、長期的に効きます。
削除を真剣に減らす運用とは、削除した人を追わないことと表裏一体です。今いるユーザーが削除しないように体験を磨くこと、それが個人開発の継続率設計の中心です。
次の最小の一歩
明日、自分のアプリを一度アンインストールして、もう一度ストアからインストールしてみてください。最初の 60 秒、最初の翌朝、3 日目の朝で、それぞれアプリは何を見せてきますか。「これは私のためのアプリだ」を 60 秒以内に感じられたか、翌朝に違いを感じたか、3 日目に積み重ねを感じたか。感じなかったポイントが、削除されている原因のすぐ近くにあります。