"この時点で評価がどうして急落したのか?"
四半期ごとのグローバル顧客体験（CX）レビュー会議を思い出します。スライドにはある海外主要都市の支店の評価が4.4から3.6に急落しています。その場で初めて気づきました。レビューを見ると、「予約したが2時間待ち」「担当者が約束を守らない」といった不満が2か月前から集中しており、オーナーの返信は一つもついていませんでした。その支店はすでに都市検索のトップから外れ、元に戻すのに半年かかります。
世界中に数十か国に支店を持つブランドで繰り返される光景です。支店が数百〜数千もあるため、評判は支店ごとに異なるからです。
- 支店を一つずつ人が毎日Googleマップで評価を確認することは不可能です。結局、特定の支店の急落シグナルが「平均は良好」という四半期の要約の一文に飲み込まれます。
- 低い評価のレビューにマネージャーが数か月間返信をしなくても、「どの支店がどれだけ放置されているか」を数える方法そのものがありません。
- 向かいの競合ブランドは否定的なレビューごとに1日以内に返信して顧客を取り戻しますが、私たちがどこで対応が遅れているかの地図はありません。
- 評価という単一の数字だけが正常であれば、その4.2点の中で待ち時間が悪化しても施設が老朽化してもシグナルが届きません。
支店を一つずつクリックしても、崩れる支店を崩れる最中に捉えることはできません。
Googleマップのレビューと対応を自社・競合の基準で収集する
ハッシュスクレイパーを使用すると、自社の支店だけでなく主要競合ブランドの支店までGoogleマップのレビューを同じ項目で収集できます。支店ごとの評価・レビュー数・評価の分布だけでなく、各レビューに支店側が返信をしたかどうかも追跡します。
実際のクローリングデータ例 - 自社支店のレビュー（未対応）
{
"Brand": "자사",
"Store": "○○ 매장 (도시 A)",
"Country": "Brazil",
"Store Rating": 3.6,
"Review Count": 412,
"Review": {
"Reviewer": "M. S.",
"Rating": 2,
"Date": "2026-06-20",
"Body": "예약했는데 두 시간을 기다렸습니다 ...",
"Owner Reply": { "Replied": "N", "Date": null, "Text": null }
},
"Collected At": "2026-07-08"
}
実際のクローリングデータ例 - 競合ブランドの支店のレビュー（対応完了）
{
"Brand": "경쟁 브랜드",
"Store": "△△ 매장 (도시 A)",
"Country": "Brazil",
"Store Rating": 4.2,
"Review": {
"Rating": 2,
"Date": "2026-06-19",
"Body": "대기 시간이 길었어요",
"Owner Reply": {
"Replied": "Y",
"Date": "2026-06-20",
"Text": "불편을 드려 죄송합니다. 예약 응대 절차를 개선하고 있습니다 ..."
}
}
}
これらのデータを並べると、同じ都市・同じタイプの不満に対して、一方は1日で返信し、もう一方は沈黙しているという事実が明らかになります。返信の有無がレビューごとに構造化されているため、支店ごとの対応率と「低評価で返信がない」レビューを指標として抽出できます。
用例：グローバルブランドの多国籍支店の評判管理
世界中に数十か国に支店を持つあるグローバルブランドは、各国に散らばった支店のレビューと競合ブランドの評判を同じ基準で見る必要がありました。数百の支店、数十の言語があり、どの支店が低い評価を受けているか、マネージャーがレビューに返信したかさえ一目でわかりませんでした。
クローリング設定
- 対象：自社支店 + 主要競合ブランドの支店、数十か国
- 収集項目：支店ごとの評価・レビュー数・評価の分布、個々のレビュー（評価・本文・投稿日）、オーナーの返信の有無・内容
- 分析：レビュー本文を属性（対応・待ち時間・施設・清潔・相談品質など）ごとに分類・感情分析
- クローリング周期：定期収集
クローリングデータで分析可能な項目
| 分析項目 | 活用方法 |
|---|---|
| 支店ごとの評価推移 | 特定支店の評価がいつからどれだけ急落したかを時系列で確認 |
| レビュー対応率 | 支店ごとの「返信したレビュー / 全体のレビュー」と低評価未対応件数 |
| 自社 vs 競合 | 都市・市場単位で評価・対応率の差異を比較 |
| 属性ごとのVOC | 対応・待ち時間・施設・清潔など項目ごとに不満を分類 |
| 国別比較 | 評価インフレを補正した市場単位評判ランキング |
量的成果
| 項目 | 内容 |
|---|---|
| 収集国 | 数十か国 |
| 対象ブランド | 自社 + 主要競合ブランド |
| 収集・分析 | 支店ごとの評価・レビュー・評価の分布 + オーナーの返信の有無・内容 |
| 収集周期 | 定期 |
散在していた支店評判が一つの表にまとまると、四半期報告を待たずして崩れる支店をその週に突くことができました。
- 急落支店 — '過去30日の評価急落上位支店'ビューで絞り、急落に貢献したレビュー本文まで直接開いて原因を特定します。
- 放置支店 — '評価低いが返信0%'の支店を自動的に選び、'よくやっているだろう'ではなく名前で指摘します。
- 競合差 — "この市場は競合社対応率85%だが、私たちは40%"のように都市・市場単位の差を地図上に描き、どの市場から手をつけるかを決定します。
同じデータでも役割によって異なる答えを得る
同じ統合データセットを使っても、部署ごとに投げかけられる質問は異なります。これまで「勘」や「自己報告」で答えられていたものです。
| 役割 | 投げかける質問 | データが与える答え |
|---|---|---|
| 本社CX全般 | どの市場・支店に問題があるか | 急落支店・未対応支店を自動選別 |
| 地域法人運営 | 四半期報告前に急落を事前に捉えるには | 週間評価急落上位支店ビュー |
| 支店マネージャー | 今すぐ返答すべきレビューは | 低評価・未対応・経過日基準アラート |
| 競合情報 | 競合社より優れているか悪いか | 同じ軸の評価・対応率差 |
| マーケティング（ローカルSEO） | 地図露出・コンバージョンはどこから来るか | 支店ごとの対応率・評価指標化 |
| CS・品質 | どの不満が構造的に感じられるか | 属性・頻度ベースのランキング |
特に本社視点では予算配分が特に残念でした。ある地域法人が「当社市場は元々顧客が厳しいため評価が低い」と人員を要求する際、それは理にかなっているが反論も認める根拠がありませんでした。
全支店を同じ周期・同じ項目で収集すると、「この市場は顧客が厳しくない、待ち時間不満が全支店平均の2倍」といった原因を数値で隠すことができます。予算は声の大きい法人ではなく、本当に問題のある市場に向かいます。
評価を一つでまとめていたレビューを属性に分解する
評価という単一の数字だけを見ると、見た目は良さそうな支店の中で、どの属性が静かに崩れているかは見えません。ハッシュスクレイパーはAIを活用してレビュー本文を分析可能な形式で整理します。
- 属性分類・感情分析: 対応・待ち時間・施設・清潔・相談品質などが言及された項目ごとに文をまとめ、肯定的・否定的を判別
- 多言語処理: 複数の言語のレビューを翻訳・分類し、標本が英語圏に偏らず国別の問題を網羅的に集計
- 対応品質チェック: 返信の有無だけでなく、返信内容まで収集し、形式的コピペで対応する支店を選り分ける
おかげで同じ4.2点の中でも「待ち時間不満が最近増えている」「この市場は施設不満が異様に高い」といった属性単位の診断が出ます。声の大きいレビュー一件ではなく、数百件にわたる繰り返される不満を頻度順に改善優先順位に上げることができます。
rawデータをレポート・ダッシュボードに
収集されたデータはraw dataとして提供されます。ただし、このデータを実際に活用するには、結局誰かが再び加工してレポートやダッシュボードを作成する必要があります。国ごとに担当者が手作業で評価を整理し、異なる形式のエクセルをアップロードすれば、本社は集計に数日を費やし、国々間の比較は基準が合わずに諦めることになります。
ハッシュスクレイパーはこの最後の段階まで共に構築できます。国ごとの評価・対応率、急落支店、属性ごとの不満推移を1つの画面にまとめた視覚化ダッシュボードや定期レポートで提供すれば、実務者は支店を一つずつ開いて見なくても状況を読み取れます。raw dataが必要な場合は、エクセル・メール・API・DB連携でそのまま受け取り、自社システムに組み込むことも可能です。
- レビュー・VOC分析ソリューション: Review & VOC Data
なぜ社内で直接行うのが難しいのか
数十か国の支店のGoogleマップ評判を社内で直接管理しようとしたチームが共通して直面する壁があります。
Googleマップには「未返答のレビューのみを表示」や「何日間放置されているか」、「先週に比べてどれだけ急落したか」などの管理ビューがありません。支店が複数ある場合は各ページを一つずつ開いて目で数えなければならず、競合ブランドの支店まで同じ基準で集めるのは数十か国規模で手作業で処理できません。
さらにウェブデータ収集特有の運用負担が加わります。
- 保守の手間: 地図・レビュー画面構造は頻繁に変わり、そのたびに収集が静かに停止します。対象が数十か国・数百の支店であれば、この対応は常時業務になります。
- 絶え間ないモニタリング: どの国で収集が0件になったり半分だけ入ってきたりしても気づく人がいなければデータに穴が開きます。失敗・欠落を検知して再収集する体制が必要です。
- 収集インフラ構築と管理: 多国籍大量収集には流動IP・プロキシ、ブラウザ自動化、スケジューラ、大容量ストレージが一緒に回る必要があります。これを立てて維持するのに専任人員とコストがかかります。
ハッシュスクレイパーはこの負担を一括して引き受けます。多国籍支店データを同じスキーマで定期�
