レビュー分析とは？大量のレビューを読み解く実践ガイド

ただ、多くのチームは「数える」工程を飛ばします。20件ほど読んで、自分がもともと作りたかったものを裏付ける一件を見つけ、それをリサーチと呼ぶ。

レビュー分析とは

レビュー分析は、バラバラな顧客の声（アプリストアのレビュー、G2、Amazon、Trustpilot、レビューのような文面のサポートチケット）を、分類済みで数えられるデータに変えるための手順です。

もう少し詳しく言うと、同時に2つの仕事をしています。1つ目は分類。この人は何について話しているのか。オンボーディング、価格、同期の不具合、足りないエクスポート機能。2つ目は感情の向き。喜んでいるのか、怒っているのか、それとも諦めているのか。「オフラインモードがあればなあ」で終わる5つ星レビューは、機能リクエストを含んだ好意的なレビューです。星の数だけ追っていると、この情報は丸ごと消えます。

なぜ重要か。レビューは、誘導的な質問を投げなくても人が自発的に情報を出してくれる唯一のチャネルだからです。アンケートが表示されたからレビューを書く人はいません。腹が立った、あるいは感動した — , そのどちらかが3分を使わせるほど強かったから書く。この偏りこそが価値です。偏っていると意識している限りは。

レビュー分析を進める方法（ステップ別）

先に問いを決める。 「オフラインモードを作るべきか？」と「新規ユーザーが最初の1週間で離脱する理由は？」では、必要なレビューの範囲が違います。エクスポートする前に、問いをシートの一番上に書く。
生のレビューを書き出す。 Google Play Consoleでは開発者がレビューをCSVでダウンロードでき、アプリのバージョンで絞り込めます。評価の算出や表示のしくみはGoogleの評価とレビューに関するドキュメントに。Apple側はApp Store Connectでのカスタマーレビュー管理に説明があります。
整えるだけ。磨かない。 空のレビューと明らかなスパムは除く。誤字や罵り言葉はそのまま残す。あれもシグナルです。
タグはロードマップからではなく、データから作る。 最初の50件を読み、出てきたトピックを片っ端から書き出す。次の20件で新しいタグが出なくなったら、そこで打ち止め。
全件にタグを付ける。 1件のレビューにタグが3つ付くこともある。それでいい。
数えて並べる。 タグごとにまとめ、さらに各タグの中を感情で分ける。
外れ値は手で読む。 言及が2件しかないタグが、返金の傾向を説明していることもあります。
発見は「数字入りの一文」で書く。 「同期の失敗が400件中34件、うち31件は星1つか2つ」。これが「ユーザーは同期にイライラしている」より強い。

実際の作業の流れ

たとえば習慣トラッカーのアプリを見ているとします。直近3バージョン分のレビューを書き出す。出てきたタグは、連続記録リセットのバグ、ウィジェット、課金画面の出るタイミング、ダークモード、Apple Healthとの同期、他アプリからのインポート — , こんな感じになるでしょう。

次にバージョン別に分けます。「連続記録リセットのバグ」が4.2に集中していて4.3では消えているなら、それはもう直ったバグ。議論を続ける必要はありません。一方「課金画面のタイミング」が全バージョンに顔を出すなら、バグではなく設計上の判断です。しかもレビューを書くほど製品を気に入ってくれた人の好意を、その判断が削っている。

大量のレビューに感情スコアを付けるなら、Google Cloud Natural Language APIのドキュメントに返ってくる値の説明があります。-1から1のスコアと、方向に関係なく感情の強さを表すmagnitude。知っておくと役立つ挙動が一つ。3つ褒めて1つ酷評している長いレビューは、スコアがほぼゼロになります。だから感情スコアだけではタグ体系として使い物にならない。トピックが必要なんです。

レビュー群を信用する前にもう一つ確認したいこと。それが本物かどうかです。FTCの消費者レビュー・推奨に関する規則が存在するのは、偽レビューが現実の問題だから。似た言い回しで具体性がない5つ星が固まって並んでいたら、疑ってかかるべきです。

手作業と自動化、レビュー分析の比較

手法	向いている場面	見落とすもの	手間
スプレッドシートで手作業タグ付け	数百件以下、新製品の初回分析	規模に耐えない。200件を過ぎると集中力が落ちる	1件あたりは重いが、準備は軽い
キーワードと頻度のカウント（TF-IDF、ワードクラウド）	想定していなかった語彙の発見	皮肉、否定表現、丁寧に書かれた機能要望	軽い。ただしクリーニング規則が必要（scikit-learnの特徴抽出）
感情分析APIでスコア化	時系列やバージョン間のムードの推移	肝心のトピック。賛否混在のレビューは平均されて消える	一度組めば軽い
固定タグリストを渡してLLMにタグ付けさせる	数千件、毎月の定期実行	モデルに自由にカテゴリを作らせるとブレる	準備は中程度、運用は軽い

おすすめは、最初の100件を自分の手でタグ付けし、そこで作ったタグリストで自動化すること。生のレビューを読まないまま自動化すると、見た目は整っているのに何も意味しないカテゴリができあがります。

星の数に騙される理由

平均4.0という数字は、何を直すべきかをほとんど教えてくれません。同じ平均でも、幅広く「まあ満足」なアプリと、熱心なファン層に加えて課金バグに激怒している少数派を抱えたアプリがあり得る。

まず1つ星と3つ星を読んでください。1つ星は何が壊れているかを名指しします。3つ星が語るのはトレードオフ。そしてプロダクトの判断が必要になるのは、まさにそのトレードオフの部分です。

よくある失敗

レビューの件数を数えて、「問題を抱えた人」の数を数えていない。同じ週に同じクラッシュについて届いた10件は、1件の障害です。

競合のレビューを見ていない。自社のレビューが教えてくれるのは、ユーザーが何を我慢してくれているか。競合のレビューが教えてくれるのは、人が何を理由に乗り換えるか。競合を3つ選び、レビューを集め、同じタグリストで分類しましょう。

もう一つ、これも本当によくある。機能要望を指示書として扱ってしまうこと。CSV書き出しが欲しいと言う人は、本当にCSVが欲しいのかもしれないし、データを別のどこかに置きたいだけかもしれない。要望は症状です。その前後の文章を読んでください。

重要なポイント

レビュー分析とは、レビューにトピックと感情のタグを付けて数えること。数件読んで印象を語るのは分析ではありません。
自動化の前に、まずレビュー本文からタグの一覧を作る。
トピックタグのない感情スコアはほぼ役に立ちません。良い点と悪い点が混ざったレビューは、平均すると「ニュートラル」になってしまうからです。
バージョン・日付・プラットフォームで区切る。やらないと、すでに直したバグについて議論することになります。
競合のレビューには、自社のレビューでは絶対に見えない「乗り換えのきっかけ」が出てきます。

まずは製品ひとつ、問いひとつから。レビューを200件エクスポートして、午後いっぱい手作業でタグを付けてみてください。ユーザーが実際に書いた内容にぶつけたあと、自分のロードマップが生き残るかどうかが分かります。午後を潰す前にタグ付け結果のイメージだけ見ておきたいなら、無料のアプリレビュー分析ツールにアプリを通して、どの不満が固まって出てくるかを眺めてみるのが早いです。

よくある質問

Q: レビュー分析が意味を持つには、何件くらい必要ですか？

A: 新しいレビューを読んでも新しいトピックが出てこなくなる件数、が目安です。小さなアプリなら100件、使い道の多いカテゴリー上位アプリなら数百件。見るべきはタグが出尽くしたかどうかで、決まった件数ではありません。

Q: ChatGPTなどのLLMに分析させてもいい？

A: カテゴリー一覧を固定で渡し、構造化された形式で出力させれば、タグ付けはかなり安定します。ただしカテゴリーを自由に考えさせると毎回ラベルが変わり、前月との比較ができなくなります。

Q: レビュー分析と感情分析の違いは？

A: 感情分析はテキストがポジティブかネガティブかを測るもの。レビュー分析はそれに加えて、トピック分類、バージョンや日付での切り分け、そして意見を優先順位に変えるための集計まで含みます。

Q: 自社アプリでない場合、レビューはどこから取れますか？

A: アプリストアの公開ページ、G2、Capterra、Trustpilot、Redditのスレッド、Amazonの商品ページ。どこにでもレビューは出ています。スクレイピング前に各プラットフォームの規約を確認し、公式のAPIやエクスポート機能があるならそちらを優先してください。

Q: どのくらいの頻度でやり直すべき？

A: 毎月リリースする製品なら、リリースサイクルごとに1回。実施のたびにタグ一覧は変えないこと。そうすれば、その不満カテゴリーが減っているのか増えているのかが見えます。