レビュー導線を出したのに何も表示されない — Play In-App Review の数量制限と「表示保証なし」前提の設計

requestReviewFlow と launchReviewFlow を分けて持つ

実装の骨格は、ReviewInfo を「先に温めておく」設計にすると安定します。requestReviewFlow でネットワークを伴う準備を済ませて ReviewInfo を取得し、満足の瞬間が来たら launchReviewFlow を即座に呼ぶ。こうすると、肝心のタイミングで待たせずに済みます。

ただし ReviewInfo には寿命があり、長時間放置すると無効になります。取得しっぱなしで何分も抱えると、いざ使うときに失敗する。だから「画面に入ったタイミングで温め、その画面の中で使い切る」くらいの近さで運用するのが現実的です。

import com.google.android.play.core.review.ReviewInfo
import com.google.android.play.core.review.ReviewManagerFactory
import com.google.android.play.core.review.ReviewManager
 
class InAppReviewLauncher(context: Context) {
    private val manager: ReviewManager = ReviewManagerFactory.create(context)
    private var warmInfo: ReviewInfo? = null
 
    /** 満足の瞬間が来そうな画面に入ったら早めに呼んで温めておく */
    fun warmUp() {
        manager.requestReviewFlow()
            .addOnCompleteListener { task ->
                warmInfo = if (task.isSuccessful) task.result else null
                // 失敗してもクラッシュさせない。次の機会に再度温める
            }
    }
 
    /**
     * 実際に出したい瞬間に呼ぶ。
     * 戻り値で「出せたか」を返さないのが重要 — 呼び出し側も結果に依存しない。
     */
    fun launchIfReady(activity: Activity, onFlowFinished: () -> Unit) {
        val info = warmInfo
        if (info == null) {
            // 温まっていなければ何もしない。UX を止めない
            onFlowFinished()
            return
        }
        warmInfo = null // 使い捨て。ReviewInfo は再利用しない
        manager.launchReviewFlow(activity, info)
            .addOnCompleteListener {
                // 表示有無は問わない。次の遷移を再開するためだけのフック
                onFlowFinished()
            }
    }
}

ポイントは launchIfReady が成否を返さないことです。呼び出し側に「出せたか」を握らせると、必ずそこに分岐を書きたくなり、表示保証のない API の上に脆い前提を積み上げてしまいます。出せなかったときも onFlowFinished() を必ず呼んで、アプリの流れだけは止めないようにします。

いつ出すか — 満足のピークを engagement で捉える

In-App Review がうまく回るかどうかは、コードよりも「いつ呼ぶか」で決まります。Google も、ユーザーが価値を感じた直後に出すことを推奨しています。逆に、起動直後・課金直後・エラー直後のような「お願いごとが透けて見える瞬間」に出すと、低評価を引き寄せるか、無視されて quota だけを消費します。

私の壁紙・癒し系アプリでは、満足のシグナルを次のように定義しています。ある程度の枚数をお気に入りに保存した、一定時間以上アプリ内で穏やかに過ごした、複数セッションにわたって戻ってきてくれた——こうした「自分から繰り返している」状態が重なったときだけ、レビュー導線の候補にします。

/** 発火の可否だけを判定する純粋なポリシー。副作用を持たせない */
class ReviewTriggerPolicy(
    private val store: ReviewPrefs,
    private val clock: () -> Long = { System.currentTimeMillis() }
) {
    companion object {
        private const val MIN_DAYS_BETWEEN = 60L * 24 * 60 * 60 * 1000 // 60日
        private const val MIN_FAVORITES = 8
        private const val MIN_CALM_SECONDS = 90
    }
 
    fun shouldOfferReview(signals: EngagementSignals): Boolean {
        val now = clock()
        val sinceLast = now - store.lastOfferedAt
        if (sinceLast < MIN_DAYS_BETWEEN) return false          // 自前のクールダウン
        if (signals.favoritesCount < MIN_FAVORITES) return false // 満足のシグナル
        if (signals.calmSessionSeconds < MIN_CALM_SECONDS) return false
        if (signals.lastActionWasError) return false             // 直後の不満を避ける
        return true
    }
 
    /** 実際に発火した瞬間にだけ記録する（表示されたかは問わない） */
    fun markOffered() {
        store.lastOfferedAt = clock()
    }
}

markOffered() を呼ぶのは、launchReviewFlow を実際に試みた瞬間です。ここでも「表示されたか」は問いません。試みた事実をクールダウンの起点にすることで、quota に当たって無音だった場合でも、すぐに再発火して読者をうんざりさせる事故を防げます。60日という間隔は私のアプリでの落ち着きどころで、アプリの利用頻度によって調整する前提の値です。

広告・ペイウォールと衝突させない

満足のピークで出す、という方針は、もう一つの設計と必ずぶつかります。同じ「いい瞬間」に、AdMob のリワード広告の報酬付与やインタースティシャル、メンバーシップの案内も出したくなるからです。これらが重なって連続表示されると、ユーザーから見れば「お願いの連打」にしかなりません。

私はこの調停を、各ダイアログが勝手に出るのを禁じて、中央のコーディネーターに発火権を集約することで解いています。レビュー導線も例外ではなく、コーディネーターに「出したい」と申告し、そのフレームで他に何も出ていないときだけ許可をもらう形にしています。この考え方そのものは モーダル表示をコーディネーターで一元管理する設計 に詳しくまとめています。

// コーディネーター側に「レビューを出したい」候補として渡す
fun maybeOfferReview(activity: Activity, signals: EngagementSignals) {
    if (!policy.shouldOfferReview(signals)) return
    modalCoordinator.request(ModalRequest.Review(priority = 20) {
        policy.markOffered()
        reviewLauncher.launchIfReady(activity) {
            modalCoordinator.onModalFinished()
        }
    })
}

優先度を持たせて、課金や戻るボタンの広告ゲートと並べて調停するのがコツです。戻るボタン側のインタースティシャル制御と優先度がぶつかる場合の整理は、戻るボタンの広告ゲートをネストせず平らなガードで組む設計 と同じ考え方で揃えられます。レビュー導線は「邪魔をしてまで出すものではない」と割り切り、衝突したら譲るのが、長い目で見ると評価を守ります。

テストで「動かない」と勘違いしないために

最後の罠が、テスト環境での無音化です。In-App Review は、ローカルの debug ビルドや、まだ Play からインストールされていないアプリでは、実際のダイアログを出しません。launchReviewFlow は成功で返るのに、画面には何も出ない——私が最初に陥ったのは、まさにこの状態でした。

実際の表示を確認するには、Play の内部テスト（Internal testing）または内部アプリ共有（Internal app sharing）経由でインストールしたビルドで試す必要があります。それでも quota の影響は残るため、確認は「出る／出ないの二値」ではなく「条件を満たしたうえで、表示されることもされないこともある」という前提で受け止めるのが正しい読み方です。

この表をチームやドキュメントに一枚貼っておくだけで、「実装したのに出ない」という問い合わせの大半は未然に消えます。私はこの確認手順を本番運用に乗せる前に必ず一度通すことを推奨します。実際、私はこの一覧を Antigravity に投げて、自分のアプリの BuildConfig と配布フローに合わせた確認手順へ展開してもらいました。エージェントに「In-App Review は表示保証がなく、debug では無音、内部テスト経由でのみ確認できる」という制約を最初に渡しておくと、テスト手順の生成が一気に的確になります。

ポリシー違反の「事前フィルタ」と、許される設計の境界

In-App Review を扱うときに必ず確認しておきたいのが、満足度で出し分けてはいけない、という線引きです。「このアプリは気に入りましたか？」と先に聞いて、はい の人だけにレビュー導線を出し、いいえ の人は問い合わせフォームへ流す——この「ハッピーパスだけを誘導する事前フィルタ」は Google のポリシーで禁じられています。

一方で、行動シグナルでタイミングを選ぶこと自体は禁止されていません。前述のポリシーは「お気に入りを8件保存した」「穏やかに90秒以上過ごした」といった engagement を見ているだけで、ユーザーの評価そのもので分岐しているわけではありません。境界はシンプルで、満足度を問う UI を挟んで出し分けるのが NG、満足していそうな行動の瞬間を選んで全員に等しく出すのが OK です。この一線を踏み越えないことが、結果的にアカウントとアプリを守ります。

次の一手

In-App Review を初めて入れるなら、まず launchReviewFlow の完了コールバックから「レビュー済みフラグの永続化」を外すところから始めてみてください。私が半日溶かした沈黙の正体はそこにありました。表示保証のない API だと前提を置き換えるだけで、コールバック・quota・テストの3つの謎が一度に解けます。発火ポリシーと衝突調停は、そのうえで少しずつ自分のアプリのリズムに合わせていけば十分です。