個人開発でアプリを出していると、ダウンロードは伸びているのにレビュー数が二桁から動かない、という時期があります。私も壁紙アプリで長くこれに悩みました。よくある対処は「レビューしてください」の文面を練ることですが、実際に効いたのは文面ではなく、依頼を出す瞬間を変えることでした。
Rork が生成する Expo アプリでも、評価を求める仕組みは数行で入ります。問題はその数行を「いつ呼ぶか」です。iOS のネイティブ評価プロンプトは表示回数に厳しい上限があり、雑に出すと貴重な機会を無駄打ちします。レビュー数を伸ばすためのタイミング設計を、私自身が壁紙アプリで試した結果と ASO への効き方を交えて整理します。
なぜレビュー数が ASO に効くのか
App Store の検索結果やプロダクトページで、ユーザーがインストールを決める材料は限られています。スクリーンショットと、星評価と、件数です。
ここで見落とされがちなのが「件数」の役割です。星4.8でも件数が5件なら、ユーザーは「たまたま身内が付けただけかもしれない」と疑います。同じ4.8でも件数が500件あれば、それは信頼の証拠に変わります。つまりレビューは、星の高さと件数の両輪で初めてコンバージョンに効きます。星を上げる努力と、件数を増やす努力は別物だと分けて考えるのが出発点です。
そして件数は、検索順位そのものにも間接的に影響します。インストール後のコンバージョンと継続率が上がれば、ASO 上のシグナルが改善し、同じキーワードでの露出が伸びる——この循環の入口がレビュー件数です。
やってはいけない3つのタイミング
まず、評価を求めてはいけない瞬間を潰します。
- アプリ起動直後。まだ価値を感じていないユーザーに頼んでも、低評価か無視のどちらかです。
- クラッシュやエラーの直後。最悪のタイミングで、星1を量産します。
- 課金を断られた直後や、広告を見せた直後。気分が下がっている瞬間に頼むと逆効果です。
私が最初にやってしまったのは1番でした。起動時にプロンプトを出していた頃は、平均評価がじわじわ下がっていきました。タイミングを変えただけで、同じアプリの平均が回復したのが、この設計を真剣に考えるきっかけです。
「嬉しさの瞬間」を定義する
評価を求めるべきは、ユーザーがそのアプリで何か良い体験をした直後です。壁紙アプリなら「気に入った壁紙を保存した」「お気に入りに3枚追加した」瞬間。タスク系なら「タスクを完了した」瞬間です。
ポイントは、その瞬間が「ユーザー自身の達成」であることです。アプリが何かを押し付けた直後ではなく、ユーザーが満足を感じた直後を狙います。さらに、初回利用ではなく数回使ってアプリを気に入った頃合いを重ねると、評価の質が上がります。私の場合は「3セッション以上、かつお気に入り保存を2回以上した直後」を条件にしています。
expo-store-review の実装と頻度制限
実装は expo-store-review を使います。ネイティブのプロンプトは iOS の制約で年に3回までしか表示されないため、isAvailableAsync と独自の条件判定を必ず噛ませます。
import * as StoreReview from "expo-store-review";
async function maybeAskForReview() {
// 自前の条件: 価値を感じたユーザーだけに絞る
const sessions = await getSessionCount();
const favorites = await getFavoriteCount();
const alreadyAsked = await getReviewAskedThisVersion();
if (sessions < 3 || favorites < 2 || alreadyAsked) return;
if (await StoreReview.hasAction()) {
await StoreReview.requestReview();
await markReviewAskedThisVersion(); // バージョンごとに一度だけ
}
}
iOS の年3回制限は開発者からは制御できないため、システムがプロンプトを実際に出すかは分かりません。だからこそ「出してもいい条件を満たすユーザー」を絞り込み、限られた表示枠を最も評価してくれそうな層に当てるのが重要です。雑に毎回呼ぶと、表示されないまま年間の枠を消費します。
満足度チェックを挟む設計と Apple の線引き
「アプリは気に入っていますか？」と先に尋ね、はいの人だけネイティブプロンプトに進め、いいえの人はフィードバックフォームへ誘導する——この事前チェックは広く使われています。
ただし線引きが重要です。Apple が禁じているのは、星評価を入力させる自作のダイアログや、ネイティブプロンプトの代替となるカスタム UI です。一方、フィードバックの入口として満足度を尋ねること自体は許容範囲です。私は「満足度を尋ねる→満足な人だけ requestReview を呼ぶ→不満な人は問い合わせへ」という形にしています。これにより低評価が公開レビューに流れる前に、改善要望として受け取れます。
ここで絶対にやってはいけないのは、不満な人を評価から完全に締め出す露骨な設計です。誘導が露骨だと審査で指摘されますし、何より誠実ではありません。満足度チェックはあくまで「適切な出口へ案内する」ためのものだと考えています。
効果の測り方
施策の効果は、レビュー件数の増加ペースと平均評価の推移を、変更の前後で比べて見ます。タイミングを変えた週から、1日あたりの新規レビュー件数がどう変わったかを記録すると、効果がはっきり出ます。
私の壁紙アプリでは、起動時プロンプトから「嬉しさの瞬間」へ移しただけで、平均評価が0.3ほど回復し、月あたりの新規レビュー件数も明確に増えました。文面を何度書き直しても動かなかった数字が、タイミング設計だけで動いたのは、いま振り返っても象徴的でした。
レビューは買えませんが、出す瞬間は設計できます。同じようにレビュー数で伸び悩んでいる方の参考になれば幸いです。