App Storeレビュー対策:評価を増やし、正しく返信する方法

要点: 評価の依頼はシステム標準のダイアログだけで行います(iOSはRequestReviewActionまたはAppStore.requestReview、AndroidはIn-App Review API)。タイミングは、ユーザーが何かを達成した直後です。初回起動時や、ボタンのタップから呼び出すのは避けてください。Appleのダイアログは年3回まで、Googleは非公開のクォータが適用され、どちらのストアもインセンティブの提供や事前の質問を禁止しています。返信は、低評価やバグ報告のレビューから優先し、短く具体的に書き、修正をリリースしたらその旨を伝えましょう。どちらのストアもレビュアーに通知が届き、レビュアーは評価を更新できます。

評価は、ストアページを初めて見た人が信頼するかどうかを左右します。Googleも、Playでは「評価、レビュー、ダウンロード数、その他の要素の組み合わせ」でアプリが順位付けされると明言しています。レビューを増やしたいと考えているチームは多いものの、ルールの境界線を正確に把握している人は多くありません。そのため、依頼が足りなかったり、AppleやGoogleの審査担当者にリジェクトされるような導線を作ってしまったりします。

このガイドでは、両ストアの最新ルール(2026年10月時点のAppleとGoogleのドキュメントで確認済み)、依頼のタイミング、返信の仕方、レビューをロードマップに活かす方法を解説します。

ルール(2026年10月時点)

App Store

API。 Appleは現在、SKStoreReviewControllerを非推奨としています(iOS 18以降)。SwiftUIではRequestReviewAction(環境値requestReviewを読み取って呼び出す)、UIKitではUIWindowSceneを渡したAppStore.requestReview(in:)を使います。どちらもiOS 16以降で利用できます。古いiOSもサポートしている場合は、従来の呼び出しを利用可否のチェックの内側に残してください。

上限。 そのデバイスでまだアプリを評価していないユーザーに対して、StoreKitがダイアログを表示するのは365日間で最大3回です。すでに評価やレビューを投稿している場合は、アプリの新バージョンであり、かつ前回のレビューから365日以上経過した場合にのみ表示されます。また、ユーザーはすべてのアプリでこのダイアログをオフにすることもできます。

呼び出しても何も起きないことがある。 このAPIはアラートを表示しない場合があるため、Appleはボタンのタップなどユーザー操作への応答として呼び出さないよう求めています。開発モードでは常にダイアログが表示されますが、TestFlightのビルドでは呼び出しは何の効果もありません。ベータ版で導線の良し悪しを判断しないでください。

常設リンクはOK。 Appleのドキュメントでは、設定画面にプロダクトページへの常設リンクを置き、URLにaction=write-reviewを付けてレビュー作成画面を直接開く方法が提案されています。「Streaklyを評価する」といった項目の置き場所として適切です。

App Reviewが取り締まる内容。 ガイドライン5.6.1は、提供されているAPIを使うことを求め、Appleは「独自のレビュー依頼を認めない」としています。ガイドライン3.2.2(x)は、機能やコンテンツの利用条件としてアプリの評価やレビューを強制してはならないと定めています。ガイドライン5.6.3(Discovery Fraud)はレビューの操作を禁じており、セクション3の冒頭でも、金銭を伴う、インセンティブ付き、フィルタリングされた、または偽のフィードバックがあるとApple Developer Programから除名される可能性があると警告しています。ここで重要なのは「フィルタリング」という言葉です。満足したユーザーをストアへ、不満なユーザーをメールフォームへ振り分ける導線は、まさにこれに当たります。

Google Play

API。 Play In-App Review APIは、アプリ内にレビューカードを表示します。Googleはユーザーごとに期間を区切ったクォータを設けています。具体的な値は実装の詳細で、予告なく変わる可能性があります。そのため、短期間(Googleの例では1か月未満)にlaunchReviewFlowを複数回呼び出しても、何も表示されないことがあります。

デザイン上のルール。 カードはそのまま表示します。サイズ変更、オーバーレイ、プログラムによる削除はしないでください。APIの前に「評価する」ボタンを置くのも避けましょう。クォータに達したユーザーには壊れた体験になってしまうためです。ボタンのタップはPlayストアへ遷移させてください。

事前の質問は禁止。 Googleははっきり述べています。アプリは評価ボタンやカードを表示する前、または表示中に、ユーザーへ質問してはいけません。「このアプリは気に入っていますか?」のような意見を尋ねる質問や、「このアプリに星5をつけますか」のような予測を尋ねる質問も含まれます。

インセンティブは禁止。 User Ratings, Reviews, and Installs policyは、評価、レビュー、インストール数の操作を禁止しています。違反例には、評価と引き換えに割引などのインセンティブを提供すること、リンク、クーポン、コードを含むレビューを促すことが挙げられています。

比較表

依頼のタイミング:起動時ではなく「成功体験」の直後

AppleのHuman Interface Guidelinesは、ユーザーがある程度アプリを使い込んでからのみ依頼すること、初回起動時やオンボーディング中、作業の途中では絶対に依頼しないこと、そして「依頼の間隔を少なくとも1〜2週間」あけることを求めています。Googleも、ユーザーが「有益なフィードバックを返せるほど十分にアプリやゲームを体験した」段階で依頼するよう述べています。これはタイマーではなく、条件ゲートとしてコードに落とし込みましょう。

架空のアプリで見る条件ゲートの例

習慣トラッカーの架空アプリ「Streakly」を例にします。次の条件がすべて満たされたときだけ、ダイアログを表示します。

1. ユーザーが7日連続の記録を達成し、お祝い画面を2秒以上表示している。
2. アプリを開いた日が5日以上ある。
3. このセッション中にクラッシュや同期失敗が起きていない。
4. このアプリバージョンでは、まだレビューを依頼していない。
5. 前回の依頼から14日以上経過している。

これらの条件はどれもユーザーに質問をしないため、両ストアのルールの範囲内に収まります。Apple公式のサンプルプロジェクトも同じ考え方です。ある処理を複数回完了するまで待ち、同じバンドルバージョンでは2度依頼せず、完了画面で数秒待ちます。

@Environment(\.requestReview) private var requestReview

func streakCompleted() {
    guard ReviewGate.shouldAsk(version: appVersion) else { return }
    ReviewGate.markAsked(version: appVersion)
    requestReview()
}

不満を持つユーザーからのフィードバックは、設定画面やヘルプに、全員に共通の常設「フィードバックを送る」項目を用意して受け付けましょう。これは、誰にシステムのダイアログを表示するかの判断に使ってはいけません。

評価の計算:星5がいくつ必要か

現在の平均がA(N件の評価)で、新しい評価の平均がRのとき、目標Tに到達するために必要な新規評価数xは次の式で求められます。

x = N × (T − A) / (R − T)

単純平均と仮定して、3.9を4.3に引き上げる場合:

1,000件の場合の検算:(1,000 × 3.9 + 572 × 5) ÷ 1,572 = 4.30。ここから2つのことが言えます。新規の評価がすべて星5になることはまずないので、現実的な数字は中央の列に近くなります。そして、件数よりもRとTの差のほうが重要です。星1のレビューを生む原因を直せばRが上がり、どんな依頼ダイアログの調整よりも早くxが減ります。

ストアごとの注意点が2つあります。Googleは、Playでユーザーに表示される評価は最近の評価に重みを置いていると述べているため、改善版では上の表よりも早く回復します。一方、Appleの総合評価は地域ごとなので、この計算は国別に行い、ダウンロード数の多い国から始めてください。

App Storeの総合評価をリセットする

Appleでは、新バージョンのリリース時に総合評価をリセットできます(AdminまたはApp Managerのロールが必要)。バージョンのページで「Reset rating when this version is released」を選択し、審査に提出する前に保存します。事前に知っておくべきこと:

• バージョン公開と同時に、すべての国に一斉に適用されます。
• リリース後は元に戻せません。
• 書かれたレビューはページに残ります。
• 新バージョンの評価が十分に集まるまで、プロダクトページには評価が最近リセットされたことが表示されます。

Appleは、リセットは控えめに使うよう推奨しています。私たちの目安は、低評価の原因が新バージョンで解消される問題であり、かつ依頼ゲートによって数週間で意味のある件数を積み直せる場合にのみリセットする、というものです。

レビューへの返信方法

各ストアでできること

App Storeでは、Account Holder、Admin、Customer Supportのロールを持つユーザーが、App Store Connectの「Ratings and Reviews」から返信できます。表示される返信はレビュー1件につき1つで、反映までに最大24時間かかることがあり、後から編集や削除も可能です(編集した返信にはその旨が表示されます)。Appleの評価とレビューのページには、返信するとレビュアーに通知が届き、レビューを更新できること、どれだけ古いレビューにも返信できること、返信済みのレビューをユーザーが編集するとメールで通知を受け取れることも書かれています。

Google Playでは、「Reply to reviews」権限を持つ人なら誰でも、レビュー1件につき公開の返信を1つ投稿でき、いつでも編集できます。ユーザーにはプッシュ通知とメールが届き、評価やレビューを更新できます。Reply to Reviews APIで返信する場合は、返信はプレーンテキスト350文字までで、APIが返すのは直近1週間に作成または変更されたレビューのみ、通知が送られるのはレビューに対する最初の返信だけです。

両ストアが求めるトーンは共通で、簡潔で、丁寧で、具体的であること。個人情報、宣伝、スパムは入れません。Googleはさらに、返信はユーザーの問題に焦点を当て、より高い評価を求めないようにと述べています。

どのレビューから返信するか

Apple自身のアドバイスは、すべてに返信できない場合、最も低い評価と、現行バージョンの技術的な問題に触れたレビューを優先する、というものです。ここに、ストアのルールではなく推奨事項として目標を加えます。星1〜2のレビューには、ユーザーがまだアプリを入れているうちに、1営業日以内に返信する。それ以外は1週間以内に返信する、という目標です。

返信テンプレート

以下のテンプレートはいずれも350文字以内なので、両ストアで使えます。角括弧の部分は書き換えてください。Appleは、似たレビューへの返信でも定型文ではなく個別の返信を推奨しています。

星1、バグ報告

ご指摘ありがとうございます、[名前]さん。おっしゃるとおり、前回のアップデート以降、[デバイス/OS]で[機能]が動作しない状態になっていました。原因を特定し、修正はバージョン[x.y]で今週中に公開予定です。アップデート後も改善しない場合は、機種名を添えてsupport@[app].comまでご連絡ください。直接確認いたします。

星1、機能要望

ご指摘のとおりです、[名前]さん。Streaklyには現時点で[Xをする機能]がありません。今月最も要望の多い機能で、ロードマップに入っていますが、守れない日付はお約束しません。それまでは[回避策があれば記載]。実装時にはこちらに返信でお知らせします。

星2、価格への不満

率直なご意見ありがとうございます。無料プランでは[主要機能]をご利用いただけ、プレミアムでは[具体的な機能]が加わり、料金は[価格/期間]です。解約はアカウント設定からいつでも可能です。無料だと思われていた機能が有料になっていた場合は、support@[app].comまでどの部分かお知らせください。

星5、お礼

ありがとうございます、[名前]さん![N]日連続はなかなかできることではありません。Streaklyをさらに使いやすくするためのご要望が1つでもあれば、ぜひこちらにお寄せください。返信はすべて読んでいます。

他のアプリ宛て、またはストア自体に関するレビュー

ご投稿ありがとうございます。Streaklyには[言及された機能]がないため、別のアプリについてのレビューかもしれません。当アプリについてでしたら、状況をsupport@[app].comまでお知らせください。対応いたします。課金に関するお問い合わせは、[Appleサポート / Google Playヘルプ]が直接対応できます。

入れてはいけないもの:割引、コード、「評価を更新していただければ…」といった提案(インセンティブ)、確実でない日付付きの約束、レビュアーとの言い争い、ユーザーを特定できる情報。iOSの課金やダウンロードの問題については、Appleはユーザーを「Appleサポート」へ案内するよう求めています。

修正後にフォローアップする

リリースでレビュアーが不満を述べていた点を修正したときは、リリースノートでそれを伝え、該当するレビューに返信することをAppleは推奨しています。レビュアーに通知が届き、レビューを更新できるため、星を取り戻す最も誠実な方法です。Google Playでは、既存の返信を編集しても新たな通知は送られないため、修正はリリースノートでも告知しましょう。

返信しないほうがいい場合:報告する

レビューに不快な内容、スパム、ストア規約に違反する内容が含まれている場合は、返信せずApp Store Connectの「Report a Concern」を使います(ユーザーには通知されません)。Google Playでは、Play Consoleのレビューから報告します。誹謗中傷に公開の場で応じてはいけません。

レビューをロードマップに変える

返信で改善できるのは、ユーザー1人との関係です。より大きな成果は、レビューを集計して読むことで得られます。

1. すべてのレビューにタグを付ける。 短く固定したリストから、主なトピックを1つ選びます。バグ、パフォーマンス、料金、機能不足、UXの分かりにくさ、同期/データ、称賛など。タグは10個未満にしないと、誰も一貫して使いません。
2. バージョン別・国別に毎週集計する。 リリース後に急増したトピックは、リグレッションです。ゆっくり増えるトピックは、ロードマップの候補です。
3. 件数ではなくダメージの大きさで順位付けする。 星1の言及は星3より重く見ます。星1の「同期でデータが消えた」が10件あれば、星3の「ダークモードがほしい」の40件より優先されます。
4. 言い換えずに引用する。 各チケットに実際のレビューの引用を2〜3件入れましょう。エンジニアは、情景が思い浮かぶものを直します。
5. 競合の星1レビューを読む。 競合アプリに共通して繰り返される不満のテーマは、より良いプロダクトが埋められる隙間です。
6. リリースノートと返信でフォローアップする。 そのうえで、そのトピックの割合が下がるかを見ます。

Appleは現在、米国とそのほか8つの英語圏ストアフロントのプロダクトページで、LLMが生成したレビューの要約も表示しています。レビュアーが最も多く繰り返した内容が、ユーザーが最初に読む内容になります。繰り返される不満は、返信するだけでなく根本から直すべき理由がここにもあります。

よくある間違い

• レビューAPIに「評価する」ボタンを直結する。 クォータを使い切ると何も表示されません。代わりにストアページへリンクしてください。
• ダイアログの前に「Streaklyを楽しんでいますか? はい / いいえ」と尋ねる。 Google Playでは禁止、iOSでは独自のレビュー依頼として扱われます。
• アップデート後の起動時に依頼する。 初回起動でなくても、アプリの起動直後に依頼するのは避けるようAppleは助言しています。
• サポートに問い合わせて満足したユーザーにだけ依頼する。 これはフィルタリングであり、Appleは操作行為として名指ししています。
• コピペの返信。 50件のレビューに同じ文面が並ぶとボットに見え、誰の役にも立ちません。
• 悪い1週間を隠すために評価をリセットする。 全地域のカウントが消える一方、書かれたレビューは消えません。
• 国別の差を無視する。 翻訳バグが原因で、米国で4.6でもドイツでは3.8ということが起こりえます。

Searviaでできること

Searviaのレビューツールは、最新のレビューをトピックごとにまとめ、それぞれに次のアクションを提示します。レビュアーの言語で返信案を作成し、編集・承認したうえで、App Store ConnectまたはGoogle Playを連携すれば公式API経由で公開します(オプションのレビューエージェントは、レビューの下書き、タグ付け、フラグ付けを自動で行え、承認なしで公開するのはオンにした場合のみです)。評価トラッキングは国別の評価を追跡し、7日以内に国の評価が0.1以上下がった日の朝にアラートを送ります。クレームマップは、あらゆるアプリの星1〜2のレビューを、実際の引用付きでテーマに整理します。全体の流れはアプリレビュー分析でご覧ください。