口コミを読むとき、星の数を比べ、低評価のコメントから「競合の弱点」をまとめたくなります。しかし、高評価にも機能要望があり、問題の記述があっても再現できる不具合とは限りません。
実務で使いやすいのは、場面・ユーザーの記述・テーマ・根拠・次の検証を分けた一覧です。Todoist、TickTick、Microsoft To Doの公開レビューを例に、少数のデータを製品調査の論点へ整理します。アプリのおすすめランキングや満足度調査ではありません。
取得上限と、実際の取得件数は別
2026年10月4日にApifyのGoogle Playレビューツールで取得しました。対象は三つのアプリID、国パラメータは US、言語は en、並び順は NEWEST。各アプリの上限を30件に設定し、日付の下限は指定していません。
使用したアカウントでは1回につき最大10件という制限が示され、結果は各10件、合計 30件の本文付きレビューでした。「アプリID＋レビューID」の組み合わせも30種類です。上限の30件を三つ足して90件取得したとは説明しません。
| アプリと公開ページ | 有効件数 | 返された投稿日範囲（UTC） | バージョンが非空 |
|---|---|---|---|
| Todoist | 10 | 2026-10-01〜2026-10-02 | 9 / 10 |
| TickTick | 10 | 2026-10-01〜2026-10-03 | 7 / 10 |
| Microsoft To Do | 10 | 2026-09-29〜2026-10-03 | 10 / 10 |
並び順に最新を指定したことは、「取得日までの世界で最新の10件」を独立に確認したこととは違います。国・言語も取得条件であり、投稿者の国籍、居住地、母語を証明しません。米国や日本の利用者を代表する調査ではありません。
三つのアプリで投稿日範囲が異なるため、「この数日でどのアプリに問題が多いか」は比較しません。4件はバージョンが空欄でした。本文、星評価、日付、レビューIDは全件非空ですが、項目が埋まっていることは内容の真実性や問題の再現を保証しません。端末、利用環境、表示の完全性も一件ずつ確認したわけではありません。
最初に試したApp Storeのツールは、結果なしを示すレコードのみを返したため、分析から除外しました。これを「iOSのレビューが存在しない」とは解釈しません。実行の成功表示だけでなく、本文と有効件数の確認が必要です。
ストア評価、各レビューの星、本文を分ける
Googleの評価・レビュー説明では、表示評価がより最近の評価を重視することや、利用者が評価を更新できることが説明されています。取得した10件の星の単純平均を、Google Playのストア評価として扱うことはできません。
Appleの説明では、国・地域ごとの集計評価や、新バージョン公開時の評価リセットが案内されています。ストアごとに仕組みが異なるため、一つの「全ストア平均評価」にまとめません。
自社アプリの管理画面で利用できる分析機能も、競合の公開ページから取得できる項目とは別です。本例は公開レビューのみを扱い、収益、ダウンロード数、継続率、非公開の利用者データは含みません。
本文から論点を抽出する：三つの要約
以下は取得本文を短く言い換えたものです。原文引用でも、確認済みの不具合報告でもありません。
| 例 | コメントの手掛かり | テーマ案 | 次の確認 |
|---|---|---|---|
| Todoist、星3、10月2日 | デザインと速さを評価しつつ、繰り返しサブタスクの再表示時に順序が変わることを指摘 | 繰り返し、順序保持、肯定と問題の混在 | 該当バージョンで完了順序を変えてテストし、現在の動作を確認 |
| TickTick、星3、10月2日 | 7日表示の選択を保持してほしいという要望と、カレンダー入口・有料範囲への期待 | 表示設定、課金範囲 | 設定保持と現在のプランを別々に確認し、一括して不具合と呼ばない |
| Microsoft To Do、星5、10月2日 | 全体として評価しつつ、当日だけでなくすべてのタスクを見たいと要望 | タスク表示、機能要望、混合した感想 | 既存の一覧入口を調べ、機能がないのか見つけにくいのかを区別 |
星1〜2だけを残すと、三つ目のような要望を見落とします。星5でも、改善の要望がないとは限りません。 一方、具体的な場面がない短い称賛は「一般的な感想・情報不足」とし、テーマを推測で埋めません。
一件に複数のタグを付けられます。別のMicrosoft To Doのコメントは、メモ編集時のキーボードによる遮蔽と、タスクのステップに日付を設定したいという要望を含んでいました。「操作上の問題」と「機能要望」を分けますが、二人の利用者の声として数えてはいけません。
取得した元データと、分析者の判断を別の列に
ストア、アプリID、国・言語パラメータ、並び順、取得日時、レビューID、投稿日、星、本文、取得できたバージョン、出典を保存します。場面、テーマ、反応の種類、情報の十分さ、未確認事項は別列にします。
重複確認は「ストア＋アプリID＋レビューID」を出発点にします。定期観測では、同じレビューの本文が更新されることもあるため、スナップショット日時と変更を残します。コメントの更新は、必ずしも新しい利用者の追加ではありません。
空欄のバージョンを現在のバージョンで埋めません。同じバージョンというだけで、ある更新が原因だとも判断しません。端末が不明なら、特定の機種で問題が広く起きていると説明しません。
テーマは、たとえば「表示・ナビゲーション」「タスクの挙動」「課金・価値」と定義できます。これは分類の案で、本例で全30件の分類集計を完了したという意味ではありません。少量を人が確認し、曖昧な表現の扱いを揃えてから広げます。
テーマ比率を出すなら、分母を「本文があり分析に採用したN件」と記載し、除外理由も残します。複数タグなら合計が100%を超えることがあります。その比率は取得した口コミの特徴であり、全利用者の苦情率ではありません。本例ではテーマ比率、アプリ順位、問題発生率を公表しません。
次の製品調査につなげる
操作手順が明確なら再現テストを行い、課金や機能の境界に関する記述なら現行仕様を確認します。好みや要望なら、利用者への聞き取りや使いやすさのテストで補います。投稿件数だけでなく、影響、場面、自社の根拠を合わせて判断します。
この30件で示せるのは、星と本文の分離、欠損の扱い、記述から検証へつなぐ方法です。開発優先順位の確定には不十分です。アプリ間を比較するなら、共通の期間と追加取得のルールを改めて決めます。古いレビューを足して件数だけ揃えても、同条件の比較にはなりません。
今回の出力には、投稿者名、アバター、個人プロフィールURLを残していません。公開するのは集計値と短い言い換えだけで、レビュー全文のファイルは公開しません。公開されていることと、全文をそのまま再公開してよいことは別です。
レビューを調査用の表に整理したい場合は、対象アプリ・ストア・市場・言語と、判断したいことを商品・競合調査の窓口へお知らせください。小規模に取得できることを確認し、口コミの整理と製品の実測を分けて進めます。