LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリ内レビュー促進とAndroid・iOS公式APIの仕組み

アプリ内レビュー促進（In-App Review）とは、ユーザーがアプリを離れずにストア上の星評価とレビューを投稿できるよう、OS標準のダイアログをアプリ内で呼び出す仕組みを指します。Androidでは「Google Play In-App Review API」、iOSでは「SKStoreReviewController」または最新のSwift APIである「AppStore.requestReview」がこれに該当します。

この2つのAPIには共通する重要な特性があります。それは、呼び出しさえすればダイアログが常に表示されるわけではなく、実際に表示するかどうかの判断をOS・ストア側が握っている点です。Android Developersは、Google PlayがユーザーへのレビューダイアログをGoogle Play側の期間制限付きの上限（time-bound quota）で制御していると明記しています^*1。Appleも、SKStoreReviewControllerによるレビュー要求は1つのアプリにつき365日間で3回までという上限を公式ドキュメントで示しています^*2。

つまりアプリ内レビュー促進の実装とは、開発者が「いつAPIを呼ぶか」を設計する工程であり、「いつダイアログを表示するか」は最終的にOS側の裁量に委ねられる仕組みだと理解しておく必要があります。次のセクションから、Android・iOSそれぞれの制御仕様を具体的に見ていきます。

Google Playが課すtime-bound quotaと表示制御

Google Play In-App Review APIとは、Google Playが提供するライブラリを通じて、ユーザーがPlay Storeの1〜5つ星評価とコメントをアプリ内で送信できるようにする仕組みです。Android Developersの公式ガイドでは、アプリからAPIの呼び出し（launchReviewFlow）を行っても、Google Playが課す期間制限付きの上限に達している場合はダイアログが表示されないことがあると説明されています^*1。

具体的には、短期間（たとえば1か月未満）に何度もAPIを呼び出しても、その都度ダイアログが出るわけではないと公式ガイドに記載されています^*1。上限の具体的な回数や期間は実装の詳細であり、Google Playが予告なく変更できる仕様とされています^*1。この特性から、開発者側で表示頻度を細かく制御することはできません。

公式ガイドはさらに、レビュー促進を呼びかける専用のボタンやコールトゥアクションをアプリ内に置くべきではないと注意しています^*1。理由は、ユーザーがボタンを押してもquotaに達していればダイアログが表示されず、押しても何も起きないという体験になり、ユーザーの期待を裏切るためです^*1。ボタンでレビューを促したい場合は、In-App Review APIを使わずPlay Storeの該当ページへ直接リダイレクトする実装が推奨されています^*1。

Appleの年間3回上限とSKStoreReviewControllerの仕様

SKStoreReviewControllerとは、Appleが提供するAPIで、ユーザーがアプリを離れずにApp Store上のレーティングとレビューを送信できるようにする標準ダイアログを表示する仕組みです。Swiftの新しいAPIであるAppStore.requestReviewも同じダイアログを呼び出します。

Apple公式ドキュメントは、1つのアプリにつき365日間で3回までレビューを要求できると明記しています^*2。この上限もGoogle Playと同様にシステム側が管理しており、開発者がAPIを何度呼び出しても、上限に達した後はダイアログが表示されません^*2。表示されるかどうかの最終判断はシステムに委ねられており、呼び出しが常にダイアログ表示につながる仕様ではない点はAndroidと共通しています。

タイミングについて公式ドキュメントは、ユーザーがアクションやレベル、タスクを完了して満足度が高いと見込まれるタイミングで要求すること、そしてユーザーの操作中の活動を中断しないことを推奨事項として挙げています^*2。この推奨は次のセクションで扱うタイミング設計の土台になります。

成功体験の直後・課金直後を避ける——出すタイミング設計

アプリ内レビュー促進の実装で実務上の判断が分かれやすいのは、コードのAPI呼び出し自体ではなく「どの瞬間にAPIを呼ぶか」というタイミング設計です。表示機会が限られている以上、限られた機会をどの瞬間に使うかが評価の質を左右します。

Apple公式ドキュメントが示す基本原則は、ユーザーが何らかのアクション・レベル・タスクを完了し満足度が高いと見込まれる瞬間に要求することです^*2。具体的には、コンテンツの読み込みが完了した直後、目的の操作（検索・保存・共有など）が成功した直後といった、ユーザーが達成感を得ているタイミングが候補になります。

避けるべきタイミングとして実務で言われるのは、エラー発生直後・読み込み中・課金直後・初回起動直後です。課金直後は、レビューが購入への感謝や見返りと結びつく印象を与えやすく、後述する誘導の疑いを招く可能性があります。エラー発生直後は満足度が低い状態でレビューを求めることになり、低評価を誘発するリスクがあります。Apple公式ドキュメントも、ユーザーの活動を中断しないことを明確な条件としています^*2。

タイミング設計を内製で行うには、アプリ内のどの操作が「成功体験」に該当するかをイベント単位で定義し、その発生頻度・ユーザー属性を分析する工程が必要です。単純に「起動N回目」で呼び出す実装は表示機会を無駄にしやすく、成功体験に紐づけた条件分岐の設計には行動分析の知見が求められます。

ストア規約違反となる誘導・見返り提供のアンチパターン

アプリ内レビュー促進の実装では、ストア規約に違反するアンチパターンを避ける必要があります。違反すると審査リジェクトやアプリ削除の対象になり得るため、実装前に確認すべき領域です。

Appleの App Review Guidelinesは、アプリの機能・コンテンツへのアクセスや利用を条件として、ユーザーにレビュー投稿やアプリ評価、他アプリのダウンロードなどのストア関連行動を強制してはならないと規定しています^*3。レビュー投稿の見返りとして特典や機能のロック解除を提供する実装は、この規定に抵触します。

Android Developersの公式ガイドも、レビューボタンやカードを表示する前後にユーザーへ「このアプリは好きですか」といった意見を尋ねる質問や、「5つ星をつけますか」といった予測的な質問をしてはならないと明記しています^*1。事前に好意的な回答をしたユーザーだけにレビューダイアログを出す、いわゆる「ゲーティング」実装は、この規定に違反する典型パターンです。

具体的なアンチパターンとして次が挙げられます。第一に、レビュー投稿を条件に有料機能を解放する実装です。第二に、レビュー表示前に満足度アンケートを挟み、好意的な回答者にのみダイアログを出す分岐です。第三に、標準ダイアログの外観を改変したり、独自のポップアップで先行同意を取ったりする実装です。いずれも、OS標準のAPIが前提とする「公平にすべてのユーザーへ提示する」という設計思想に反します。

レビュー促進とアプリ計測の関係

アプリ内レビュー促進の実装では、API呼び出し自体の成否とユーザーの評価行動を分けて計測する設計が欠かせません。Android・iOSいずれのAPIも、ユーザーが実際にどの評価（星の数）を選んだか、レビュー本文を書いたかどうかをアプリ側に返しません。これはユーザーの匿名性を保つための仕様であり、開発者はストアの管理画面で公開後の評価分布を確認する形になります。

アプリ側で計測できるのは、API呼び出しを行ったタイミング・呼び出し時のユーザー属性・呼び出し後の継続利用状況までです。したがって計測設計では、「呼び出し実行ログ」と「呼び出し後のストア評価平均の推移」を別々のイベントとして記録し、時間差を踏まえて相関を確認する必要があります。呼び出し当日にストア評価が急変することは通常なく、審査反映や複数ユーザーの投稿が積算されるまで一定の遅れが生じます。

計測基盤を内製で構築するには、アプリ内イベント計測SDKの導入・呼び出しタイミングのイベント定義・ストア評価データの定期取得という複数の工程を横断する必要があります。呼び出し条件を変更した際の効果検証（A/Bテストに準じた比較）まで見据える場合、計測設計の初期段階から専門知識を持つ担当者が関与することが望まれます。

外注時の委託範囲と発注準備

アプリ内レビュー促進の実装を外注する場合、委託範囲を工程単位で切り分けて整理する必要があります。API組み込みだけを依頼する形と、タイミング設計から計測基盤まで含めて依頼する形では、必要な準備も進め方も異なります。

内製でこの領域を完結させる場合、Android・iOSそれぞれのAPI実装、ストア規約に抵触しないタイミング設計、呼び出しログの計測基盤という3つの領域を、アプリ本体の開発と並行して担う必要があります。特にタイミング設計は、規約知識と行動分析の両方が求められる領域で、実装チームが本来の開発と兼務するには負荷が大きくなりやすい部分です。

外注で任せられる範囲は主に3つに分けられます。1つ目はAPI組み込みそのものの実装で、AndroidのIn-App Review APIとiOSのSKStoreReviewController・AppStore.requestReviewを両OSで実装する作業です。2つ目は呼び出しタイミングの設計支援で、アプリ内のどのイベントを「成功体験」と定義し、どの条件で呼び出すかを整理する作業です。3つ目は呼び出しログと評価推移の計測基盤の構築です。

発注前に準備すべき情報は次の3点です。第一に、アプリ内の主要な操作フロー（どの画面でどんな操作が完了するか）を示す資料です。第二に、既存の計測基盤（分析SDKの導入状況）です。第三に、現在のストア評価・レビュー内容の傾向です。これらが整理されていないと、委託先がタイミング設計の前提を推測で補うことになり、提案の精度が下がるリスクがあります。

LASSICのアプリ内レビュー促進実装支援

LASSICは元請として、アプリのリリース後の保守・運用まで見据えた実装支援を提供します。API組み込みだけでなく、タイミング設計と計測基盤の構築までを一体で相談できる体制を整えています。

まとめ：アプリ内レビュー促進実装の3つの判断軸

本稿では、アプリ内レビュー促進の実装を外注でどのように進められるかを整理しました。要点を3つに集約すると、第一にAndroid・iOSいずれもOS側が表示頻度に上限を設けており、開発者は呼び出しのタイミングを設計できても表示の保証はできないこと、第二に成功体験の直後を狙い課金直後やエラー直後を避けるタイミング設計と、見返り提供・誘導的な質問を避ける規約順守が両立して必要であること、第三に外注する場合はAPI実装・タイミング設計・計測基盤という3つの領域で委託範囲を切り分け、発注側が操作フローと既存の計測状況を事前に整理することです。

アプリ内レビュー促進は、コード量としては小さい実装でありながら、ストア規約の理解とタイミング設計の精度が成果を左右する領域です。社内に規約知識や行動分析の経験を持つ担当者が少ない場合は、外部の専門知見を取り入れることで実装の精度を補強する選択肢があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Android Developers「In-app review API overview」https://developer.android.com/guide/playcore/in-app-review
2. *2　出典：Apple Developer Documentation「Requesting App Store reviews」https://developer.apple.com/documentation/storekit/requesting-app-store-reviews
3. *3　出典：Apple「App Review Guidelines」セクション3.2.2https://developer.apple.com/app-store/review/guidelines/

Tweet