App Store と Google Play のレビューへの返信方法

どちらのストアでも、開発者は本文のあるレビューに公開で返信できます。

Apple App Store

• App Store Connect： アプリを開き、評価とレビューのセクションに移動して、各レビューに返信します。適切なロールを持つチームメンバーが返信を作成できます。
• App Store Connect API： App Store Connect API はカスタマーレビューと開発者の返信を提供しており、ツールからレビューを一覧にしたり、プログラムで返信を投稿したりできます。API キーは Users and Access → Integrations で作成し、.p8 秘密鍵は1回しかダウンロードできません。

Google Play

• Play Console： アプリを開き、評価とレビューの下にあるレビューのセクションで、レビューを読んで返信します。
• Google Play Developer API： Reply to Reviews API で、レビューの一覧取得と返信ができます。注意点として、API が返すのはおおよそ直近1週間に作成または更新されたレビューだけで、しかも本文のあるものに限られます。それより古い履歴は、Play Console からエクスポートできる月次のレビューレポートにあります（Google Play レビュー履歴のガイドを参照）。

両方のストアで公開しているなら、コンソールが2つ、権限の設定が2つ、毎日確認する場所が2つということになります。この分断こそ、チームが返信を1つのツールにまとめる一番の理由です。

どちらのストアも、開発者の返信に関するルールを公開しています。社内の返信ガイドを書く前に原文を読んでください。以下の要約は出発点であり、代わりにはなりません。

Apple

Apple の Ratings, Reviews, and Responses のページでは、フィードバックに返信し、バグや機能のリクエストに対応し、返信を関連性のある丁寧なものにするよう開発者に勧めています。返信は公開され、Apple は公開後に返信を編集できると説明しています。

Google Play

レビューの表示と返信に関する Play Console ヘルプには、返信のルールが含まれています。おおまかに言えば、返信は話題から外れず、個人情報、宣伝、インセンティブ、不適切な表現を含めてはいけません。Google はルールを更新するので、正確な一覧は最新のページで確認してください。

両方のポリシーを守るための実践的なルール

• 公開の返信で個人情報（メールアドレス、電話番号、注文番号）を尋ねたり、繰り返したりしないでください。サポート窓口に案内しましょう。
• ユーザーにレビューを変えてもらうために、特典、割引、メリットを提供しないでください。
• 言い争わない、からかわない、そしてユーザー自身のレビューに書かれていること以上の情報を明かさないでください。
• 宣伝的な表現は避けましょう。特定のバージョンでの修正に触れるのは問題ありませんが、別の製品を宣伝するのは不適切です。

Google Play の上限は Reply to Reviews API のドキュメントに記載されています。両方のストアで同じ返信ライブラリを使うなら、各テンプレートを350文字以内に収まるように書きましょう。当社の返信テンプレートはこのルールを守っています。

日本語の返信についての補足：日本語は英語より少ない文字数で同じ内容を書けることが多いため、350文字の制限には比較的余裕があります。それでも、敬語を重ねると長くなりがちです。下書きではなく、最終版の文字数を数えましょう。

ほとんどの返信に使える信頼できる構成：

1. 具体的な問題に触れる。 ユーザーが書いた細部（「決済画面でアプリが固まる」）を繰り返し、誰かが読んだことを示します。
2. 役に立つことを伝える。 回避策、状況（「4.2で修正済み」）、または明確な次のステップ。
3. 詳しい情報が必要なら非公開の窓口を案内する： サポートのアドレスやアプリ内ヘルプなど。返信の中で個人情報を求めてはいけません。
4. ブランドに合うなら、個人またはチームとして署名する（「サポート担当 佐藤」）。

返信の質を下げるもの：

• 何十件ものレビューに同じ文面を貼り付けること。読む人は気づき、誰もレビューを読んでいないように見えます。
• 防御的になる、ユーザーのせいにする（「使い方が間違っているのでは」）、皮肉を言うこと。
• 予定のない機能に日付を約束するなど、守れない約束をすること。
• 具体的な中身のない決まり文句（「貴重なご意見ありがとうございます」）だけで終わること。

テンプレートは良い出発点です。少なくとも最初の1文と具体的な細部は、必ず個別に書き換えましょう。

日本語では、丁寧語（です・ます）を基本にし、必要以上に硬い敬語は避けるとバランスが取れます。カジュアルなブランドでも、不満を持つユーザーへの返信は丁寧にしておくのが安全です。

すべてのレビューにその日のうちに返信できるチームはほとんどありません。簡単な順番を決めておけば、最も重要なものを見落とさずに済みます：

1. 再現可能な問題を説明している星1と星2のレビュー（クラッシュ、ログインの失敗、決済の問題）。修正後に評価が変わる可能性が最も高く、バグの発見にもつながります。
2. お金に関するレビュー： 請求、サブスクリプション、返金。正しい返金手続きにすばやく案内しましょう。
3. 最新バージョンについての最近のレビュー。 現在のビルドを反映しており、最も目に付きます。
4. 提案を含む星3と星4のレビュー。 短いお礼とアイデアの状況を伝えると好感につながります。
5. 星5のレビュー。 時間があるときに返信する価値があります。短く具体的なお礼で十分です。

返信に値しないレビューもあります。スパム、誹謗中傷、明らかに別のアプリについてのレビューです。返信する代わりに、ストアのツールで不正な投稿を報告しましょう。

返信は1回きりのものではありません。どちらのストアでも既存の返信を編集でき、投稿者もあとからレビューを変更できます。Apple は、返信するとユーザーに通知され、レビューを更新できると説明しています。Google Play もヘルプ記事で同様の仕組みを説明しています。通知の正確な仕組みはストアによって異なり、変わる可能性があります。

だからこそ、フォローアップの返信は最も効果的な取り組みの1つです：

• 誰かがバグを報告したら、確認したことを返信し、社内で問題を記録します。
• 修正がリリースされたら返信を編集または更新します：「バージョン4.3で修正しました。ご報告ありがとうございました。」
• ユーザーが戻ってきてレビューを更新することがあります。更新されなくても、これから読む人には未解決の不満ではなく解決済みの問題が見えます。

そのためには、どのレビューがどのバグに対応しているかを把握する必要があります。バグ報告を課題管理ツールに送ると役立ちます。アプリレビューを Linear の issue にする方法をご覧ください。

2つの数字で、返信のプロセスが健全かどうかがわかります：

• 返信率： 一定期間に開発者の返信を受けたレビュー（または本文のあるレビュー）の割合。全体と、星1〜2のレビューに分けて測りましょう。
• 平均返信時間： レビューの投稿から返信までの時間。遅れて対応した古いレビューがいくつかあると平均が歪むため、中央値も役立ちます。

チームに合った目標を決めましょう。たとえば「本文のある星1〜2のレビューには2営業日以内に必ず返信する」とし、毎週確認します。リリースのたびに傾向を見てください。準備していないと、レビューの急増で返信時間が延びがちです。

Review Expert は App Store と Google Play のレビューを1か所に集め、チームがコンソールを切り替えずに返信できるようにします：

• Apps & Businesses で、App Store Connect API キーと Google Play のサービスアカウントを使ってアプリを接続します。まず履歴が同期され、その後は約5分ごとにレビューが届きます。
• レビュー一覧を星、プラットフォーム、日付で絞り込み、優先順位に沿って対応します。
• Review Expert で返信を書くと、公式 API でストアに投稿されます。既存の返信も同じ方法で更新できます。チームのすべてのロール（オーナー、管理者、レビュアー）が返信できます。
• ダッシュボードには、評価の推移と並べて返信率と平均返信時間が表示され、追いつけているかがわかります。

AI による返信の下書きと自動返信ルール（承認ステップは任意）も利用できます。詳しくはレビューへの返信とダッシュボードをご覧ください。