Rork で作るオンボーディングで初日の離脱を半分にする — データで直す設計ノート

Rork で作ったアプリを公開して、インストールは取れているのに翌日にはほとんどのユーザーが戻ってこない、という経験はありませんか。私は何度もあります。個人開発で広告を打たず、オーガニックのインストールがじわりと伸び始めたアプリで、初日の離脱率を計測してみたら 60 〜 70% というのは珍しくありません。残酷な数字ですが、裏を返せば、オンボーディングを 1 つ直すだけで戻ってこない半数を取り戻せる余地がある、ということでもあります。

Rork で作った小さめのアプリの初日離脱を、推測ではなくデータで減らしていくためのプロセスを実例とともに整理しました。大きな施策ではなく、計測 → 仮説 → 1 画面の調整 → 再計測、というサイクルをどう回すかが中心です。私の運用している仕組みをそのまま書きますので、明日から組み込めるところから抜き出して使ってください。

初日離脱を「1 つの数字」にしない

「初日離脱率」という 1 つの数字に逃げ込むと、何を直せば良いか分からなくなります。私はいったん、インストール後 24 時間を 4 段階に分解して、それぞれの脱落率と原因を別々に見ています。

段階 1: インストール完了 → 初回起動

意外にここで落ちる人がいます。特に iOS で TestFlight 経由 / ベータ配布の場合や、Android のサイドロードで配布している場合、インストールしたけど起動しないユーザーが一定数います。計測としては install → first_open の 1 時間以内の到達率を取ります。ここが 85% を下回るようなら、ストアページやダウンロード後の案内が弱い、と見なします。

段階 2: 初回起動 → オンボーディング完了

ここが最大の脱落ポイントです。アプリを一瞬開いて閉じられてしまう層で、「何のアプリか分からなかった」「インストール時と印象が違った」「すぐに何かを入力させられるのが嫌だった」など、理由は多岐にわたります。私はここを first_open → onboarding_complete で見ますが、同時に「オンボーディングの i 枚目で閉じたか」を画面単位で記録します。

段階 3: オンボーディング完了 → 最初の価値体験

ここが設計で最も悩むポイントです。「アプリで最初にユーザーが『お、これ良いな』と思う瞬間」を 1 つだけ定義します。写真アプリなら 1 枚加工して保存した瞬間、タスク管理アプリなら最初のタスクを 1 つ完了した瞬間。私はこれを aha_moment という単一イベントで計測しています。

段階 4: 最初の価値体験 → 翌日の再起動

最初の価値を体験したユーザーの、24 時間後の再起動率です。ここが高ければ、アプリの核は機能しています。低ければ、価値の大きさが足りていない、またはユーザーが翌日その価値を思い出す動機が弱い、という話になります。

この 4 段階を一度 Mixpanel や Amplitude、もしくは Firebase の Funnel で可視化すると、「どこで一番落ちているか」が露骨に見えます。私のアプリでは、段階 2（初回起動からオンボーディング完了まで）が明確に厚い壁になっていました。

Rork でオンボーディング画面を減らすという決断

オンボーディング画面が 5 枚あるアプリは、4 枚目までに半分以上が閉じます。これは自分のデータでも、他の個人開発者と共有した経験でも一貫しています。ところが、設計する側の心理としては「説明を足したい」という誘惑が強い。アプリの素晴らしさを伝えたいから、主要機能を紹介したいから、権限取得の意図を説明したいから、という気持ちで 1 枚、また 1 枚と画面を増やしてしまいます。

私の Rork アプリで実際にやった意思決定は、増やす方向ではなく、削ぎ落とす方向でした。オンボーディング画面を 5 枚から 2 枚に減らし、最初の 1 枚では「何のアプリか」だけを 1 文で伝え、2 枚目でメイン画面に入るための最小限の操作だけを案内します。権限取得も、必要になった瞬間まで遅延させる。結果、オンボーディング完了率が約 1.7 倍に上がりました。

このとき Rork の便利さが効きました。AI に「オンボーディングを 5 枚から 2 枚に削り、権限ダイアログはメイン画面で必要になった瞬間に出す形に変えて」と頼むと、画面遷移と権限リクエストの位置を連動させた形で書き直してくれます。ただし、AI が書いた初稿をそのまま使うのではなく、「どこで何を計測しているか」は自分で確認します。イベント名を変えられていたり、計測呼び出しが抜けていたりすると、施策の効果が測れなくなるからです。

1 枚目で伝えるべきは「機能」ではなく「状態」

1 枚目で何を伝えるかは、勝負どころです。機能を説明するのではなく、このアプリを使った後のユーザーの「状態」を 1 文で書きます。

❌「多機能タスク管理で生産性アップ」
✅「ベッドに入る前に、明日の最初の 1 つが決まっている状態をつくります」

機能の列挙は魅力的に見えても、ユーザーにとっては「自分がどう変わるか」の情報量がありません。状態を書くと、自分ごととして読み取れるので、スクロールや次へを押す動機がわずかに高まります。私の場合、この 1 文を書き変えただけで、1 枚目 → 2 枚目の遷移率が 8 ポイント改善した事例があります。

Rork に頼むときは、プロンプトに「機能ではなく状態を書いてほしい」と明示します。AI は機能列挙に流れやすいので、この指示を入れないと、どうしても「〇〇ができる、〇〇ができる」という書き方が出てきます。

権限リクエストを「理由 + 直前」の形にする

オンボーディング 2 枚目や 3 枚目に位置情報・通知・写真ライブラリ・カメラの権限ダイアログを並べている設計をよく見ます。私も昔やっていました。しかし、ユーザーはまだアプリの価値を受け取っていない段階で権限を求められると、反射的に「許可しない」を選びます。許可されなかった権限は後から取り直しにくく、アプリの主要動線が壊れます。

運用している私のルールは「権限は、使う直前に、理由をその場で 1 文添えて、聞く」です。例えば通知許可なら、「通知を有効にしますか」ではなく「明日の朝 7 時にタスクを思い出させたい場合に、通知を許可してください」と、その機能を選んだ直後に聞きます。Rork では、権限ダイアログを出す前にローカルで「説明シート」を差し込む実装が書きやすく、AI にそのように依頼できます。

この設計で、私のアプリでは通知許可率がオンボーディング直撃型に比べて約 2.2 倍に上がりました。権限は早く取るより、深く取るほうが長期の運用で効いてきます。

最小限の計測イベント設計

施策を打つ前に、次のイベントは必ず計測している状態にしておきます。Rork に渡すプロンプトにも、この計測を前提に書かせます。

first_open（アプリ起動時、既存セッションを除外）
onboarding_screen_view（枚数をプロパティで付与）
onboarding_skip（スキップボタンを押した瞬間）
onboarding_complete
permission_requested（種別と枚目をプロパティで）
permission_granted / permission_denied
aha_moment（アプリごとに定義した最初の価値体験）
session_end（バックグラウンド遷移時）

この最小セットがあると、段階別の離脱を分解でき、仮説を特定の画面・特定の操作に絞り込めます。Rork に実装を頼むときは、「このイベント名・このプロパティで計測呼び出しを入れてほしい」と明示してください。AI は計測コードを省略しがちなので、書面で指示しておくと実装の抜けが減ります。

週次レビューで 1 画面だけ変える

もう 1 つ、運用で効いたのが「週に 1 画面だけ変える」というルールです。一度にたくさん直すと、効果の切り分けができません。効果があったかどうかの判定ができないと、次の週に何をすれば良いか分からなくなります。

私のレビューのリズムは、月曜の朝に前週のファネルを見て、「一番厚い壁」に照準を合わせます。その週は、その壁の前後だけを触ります。1 週間後に再度ファネルを見て、数値の動きが大きければ原因はそこ、動かなければ仮説を変えます。Rork では設計変更が早く反映できるので、1 週間でも試行を 2 〜 3 回回せます。

「落ちる理由」をユーザーに聞く仕組みを用意する

定量データで壁の位置は分かりますが、理由までは分かりません。私は、オンボーディングを途中で離脱したユーザーに対して、次回起動時に 1 問だけアンケートを出しています。「前回、最後まで見ずに閉じた理由に近いものはどれですか」という形で、選択肢は 4 つ + 自由記述。回答率は低いですが、数十件たまると傾向が見えてきます。Rork でアンケート画面を作るのはプロンプト 1 つで数分ですので、ここは迷わず組み込む価値があります。

明日やること

この記事を読んでから Rork のアプリで最初にやるべきことは、おそらく次の 3 つです。

4 段階のファネルを計測環境に仕込む（イベントがない箇所にだけ追加する）
今のオンボーディングを 1 枚減らしてみて、翌週のファネルで確認する
権限リクエストを「使う直前 + 理由 1 文」に移す

どれも 1 日以内に動かせる作業です。大きな施策を構想するより、計測 → 1 画面 → 再計測のサイクルを始めてしまうほうが、2 週間で数字が動きます。個人開発では、動いた数字が次の意思決定を支えてくれますので、最初の 1 回転を早く回すことを優先してみてください。