競合レビュー分析とは？実践ガイド

競合レビュー分析とは

競合製品に対してユーザー自身が書いたレビューを体系的に読み込み、機能の穴、繰り返される不満、満たされていないニーズを取り出す。それが競合レビュー分析です。

ただ、定義より中身のほうが大事です。「競合のレビューを見ました」と言う人の多くは、App Storeのページを10分ほど眺めて、なんとなくの雰囲気を持ち帰っただけ。それは分析ではありません。分析とは、300件のレビューを集め、1件ずつテーマ（オンボーディング、価格、同期の不具合、エクスポート）でタグ付けし、各テーマの出現回数を数え、「一度だけ落ちた」と「データを書き出す手段がなく、11人が同じことを書いている」を切り分けることです。

なぜそこまでやるのか。レビューは、司会役に促されることなくユーザーが自分から不満を差し出してくれる、唯一の調査チャネルだからです。礼儀のために1つ星を付ける人はいません。アンケートの回答者は言葉を濁す。インタビュー対象者は親切に振る舞おうとする。でも、同期バグで3時間分の作業を失った人は、思ったことをそのまま書きます。

しかも人気製品のネガティブレビューは、ホワイトボードの前で捻り出すアイデアよりずっと筋のいい着想源になります。イライラしながらもお金を払い続けている人がすでにいる。つまり、失敗のしかたまで記録済みの、検証されたニーズです。

競合レビュー分析を実践する方法

1. 競合は3〜6社に絞る（20社は多すぎ）。 市場リーダー、勢いのある挑戦者、そして代替手段として使われている隣接ツールを1つずつ入れます。習慣トラッカーを作るなら、隣接ツールはNotionや紙の日記アプリかもしれません。
2. どこから集めるか決める。 モバイルならApp StoreとGoogle Play。B2BソフトならG2、Capterra、Trustpilot。生々しい声はRedditや製品公式のコミュニティフォーラム。拡張機能ならChrome Web Storeのレビューも。
3. レビューをスプレッドシートに集める。 列は、出典、日付、星の数、バージョン、レビュー本文、自分が付けたテーマタグ、深刻度メモ。100件くらいなら手作業のコピペでいけます。それを超えるならツールを使いましょう。
4. タグの一覧を作る前に、まず30件読む。 ここを飛ばす人が多いです。あらかじめ決めた箱にレビューを押し込むのではなく、カテゴリーを本文から立ち上げてください。
5. 全件タグ付けして、数える。 1件のレビューにタグが3つ付いても構いません。欲しいのは頻度表です。
6. 「自分で直せるか」で不満を分ける。 「高い」はポジショニングの話。「CSVエクスポートがない」は1週間で出せる機能の話。まったく別の山です。
7. 開発元の返信も見る。 同じ要望に対して2年間「ロードマップに入っています」と返し続けているなら、それは作らないと決めた要望。だからこそ、あなたの取り分になります。
8. 具体的な機会仮説を3つ書く。 「オンボーディング改善」ではダメ。たとえば「Androidの新規ユーザーがカレンダー権限の画面で離脱している。言及は14件。スキップして後で説明するフローを作る」くらいの粒度で。

---

実例で見るワークフロー

メモアプリを例にしてみます。主要なアプリのGoogle Playページを開き、星1つと2つのレビューだけに絞って、新しい順に並べる。Google Playは評価だけでなくアプリのバージョンでも絞り込めます。ここが意外と侮れないところで、特定のリリース以降に不満が急増したのかどうかが見えてきます。

出てくるテーマは、そのアプリ固有のものではなくカテゴリ全体で繰り返されています。同期の競合。既存ユーザーにも適用されたサブスク値上げ。画像内のテキストを見つけられない検索。ペイウォールのあるサイトで動かないWebクリッパー。

面白いのはこの次です。見つけたテーマを、規模の小さい競合と突き合わせてみる。トップシェアのアプリに同期の不満が40件あって、挑戦者側にゼロなら、解決しているのか、そもそもユーザーがいないのか。結論を出す前にレビューの総数を確認しましょう。（これは本当によくある間違いなので、むしろ手順ゼロにしたいくらいです。）

B2BならG2のレビューページが便利です。「気に入らない点は?」が独立した項目になっているので、ひとかたまりの文章から感情を切り分ける手間が省けます。Capterraもpros/consの欄で同じことをしています。何が表示され何がフィルタされるのか知りたければ、Appleが評価とレビューの仕組みを公開しています。

ひとつだけ真剣に受け止めるべき注意点。レビューは極端に偏ります。人が書くのは、感激したときか激怒したときだけ。「まあ普通に使えてる」という静かな中間層は表に出てきません。だから件数は、ユーザー全体の傾向ではなく不満の強さを示すシグナルとして扱ってください。

どこを見るか：情報源の比較

情報源	向いている用途	注意点
App Store / Google Play	コンシューマー向けモバイル、バージョン紐付きの不具合	レビュー誘導ポップアップで高評価が水増しされる
G2 / Capterra	B2B SaaS、構造化されたpros/cons	ベンダー主導のレビュー。ギフトカード提供の開示を確認
Trustpilot	課金、返金、サポート品質	企業側がレビューを依頼でき、構成比が動く
Reddit / フォーラム	回避策、忖度なしの機能比較	構造がなく集計しにくい。サンプルも少ない
Chrome Web Store	拡張機能、ブラウザ固有の不具合	ニッチなツールはレビュー数が少ない

見つけた内容をどう使うか

各テーマを3つの箱に振り分けます。必須条件は、カテゴリ全体であまりに多く挙がっていて、自分の製品では絶対に起こしてはいけないもの（データ消失、同期の破綻）。差別化要因は、既存プレイヤーが断り続けているリクエスト。ノイズは、特定ユーザーの特殊事情に紐づいたもの全部です。

具体的なおすすめ：差別化要因のリストは2項目までに絞ること。11個のギャップを見つけて全部埋めようとしたチームは、批判していた既存製品より出来の悪いものを出荷します。

それから、レビューの原文はそのまま残しておきましょう。ランディングページの文章を書くとき、ユーザーが実際に打ち込んだ言い回しは、コピーライターがひねり出した表現に勝ちます。Nielsen Norman Groupのユーザーの言葉に関する記事が、私よりうまく説明してくれています。

重要なポイント

• 競合レビュー分析とは、不満にタグを付けて数えること。星の数をざっと眺めて雰囲気をつかむ作業ではありません。
• カテゴリを決める前に、まず30件読む。そうしないと「自分が予想していたもの」しか見つかりません。
• 低評価とアプリバージョンで絞り込むと、特定のリリースに紐づいた不満の塊が見えてきます。
• 「ロードマップに入っています」という開発者返信が何年も続いている機能は、その競合が作らない機能です。
• ポジショニングへの不満と機能の穴は分けて扱う。実際に手を動かして解決できるのは後者だけです。

今日の午後、競合を2社選んで、評価の低いレビュー100件をスプレッドシートに落としてタグ付けしてみてください。夕食までには、本物の課題リストが手元にあるはずです。スプレッドシートは面倒、という人は無料のアプリレビュー分析ツールに競合のアプリを通してみてください。すでに書かれたレビューの中から、どんな機会が出てくるか見えてきます。

よくある質問

Q: 競合レビューは何件くらい分析すればいいですか？

A: 競合1社あたり100件から。1〜2星に重心を置いてください。60件あたりで新しいテーマが出てこなくなったら、そこで飽和したサインなので止めてOKです。150件でもまだ新鮮な不満が出てくるなら、続けましょう。

Q: 競合レビューのスクレイピングは合法ですか？

A: 公開レビューデータはグレーな領域です。データが見えていても、プラットフォームの利用規約が自動収集を制限しているケースは少なくありません。手作業で読むぶんには問題なし。自動化するなら、規約を確認した上で公式APIか、コンプライアンス対応済みのツールを検討してください。

Q: 高評価レビューも読むべき？

A: 読むべきですが、目的が違います。高評価レビューからわかるのは「削ってはいけない機能」と「ユーザーが価値を語るときに使う言葉」。何を作るかを教えてくれるのは低評価レビューです。

Q: SWOT分析とはどう違うんですか？

A: SWOTは自分の判断で埋めていくフレームワーク。競合レビュー分析は、実際のユーザーの文章から証拠を積み上げるボトムアップの作業です。SWOTを置き換えるというより、SWOTの材料になることが多いですね。

Q: どのくらいの頻度でやり直せばいい？

A: 多くのプロダクトなら四半期ごとで十分。加えて、競合が大きなリリースを出したタイミングでチェックを。リデザインや価格改定の直後は、不満のテーマが一気に変わります。