飲食サービスのデータ収集について

みなさんこんちゃ☕
よく小走りしている小林です。

今回は 「食べログ等飲食サービスのデータ収集」 について、
先月やったことを記事にまとめてみます💻
技術寄りですが、きっかけはめちゃくちゃ身近な話です。

はじめに

先月、親戚からこんな相談を受けました。

飲食店を開業したいんだけど、
どの駅らへんで、どんなジャンルの店を出すのが良いと思う？

おお…急に経営判断…！🙄
とはいえ、せっかくなら 勘ではなくデータで考えよう と思い、

各飲食サービスのデータ収集
駅ごとの店舗数・ジャンル分布の可視化
レビュー傾向の分析

を行い、簡単なプレゼン資料を作ってあげました。

この記事では、そのときに行った
飲食サービスのデータ収集〜分析 について書いていきます。

データ収集に関する法的な注意事項

まず一番大事な話⚠️

飲食サービスのデータを収集する際は、
必ず利用規約や法律を確認する必要があります。

特に意識したポイントは以下です。

利用規約でスクレイピングが禁止されていないか
公式APIが提供されていないか
取得データの利用目的（公開・商用利用など）
サーバーに過度な負荷をかけないこと

今回は、

個人利用
調査・検討目的
取得頻度は低く、最小限

という前提で「全てやってみた結果」を伝えるものでないものになります。
つまり、やるならこんな感じかなぁ程度です。

※ 商用利用や成果物の公開を前提とする場合は、本当に慎重になったほうがいいです（重要）。

対象としたプラットフォームと考えられる手段

今回、対象とした飲食サービスは以下です。

食べログ
Google マップ
ぐるなび
Hotpepper
HAMONI
AutoReserve
Retty

と、検索で出てきたあらゆるプラットフォームになります🔎
でそれぞれで考えられるデータ取得手段は、

① 公式API

提供されていれば最優先
安全・安定・合法

② スクレイピング

利用規約の確認が必須
実装は楽だがリスクあり
サイト構造変更に弱い

③ 手動＋加工

件数が少ない場合は現実的
精度は高いが時間がかかる

が考えられます。

プラットフォーム別概要

食べログ

公式APIの有無
- ❌ 現在、一般向けの公式APIは提供されていない
- 過去に法人向けAPIが存在したが、現在は利用ハードルが非常に高い
スクレイピングについての利用規約
- ❌ 利用規約上、スクレイピングや自動取得は禁止
- クローリング・自動収集・転載は禁止利用が明記されている
所感
- 情報量・信頼性は非常に高い
- ただし技術的にも法的にも扱いづらく、本気で使うなら正規契約前提という印象

Google マップ

公式APIの有無
- ✅ Google Places API が提供されている
- 店舗情報・レビュー・評価などが取得可能
- ただし 無料枠は制限あり & クレジットカード登録必須
スクレイピングについての利用規約
- ❌ 明確に禁止
- HTML解析や自動取得はNG
所感
- APIがある分、最もクリーンで安心
- コストと制限をどう許容するかがポイント
- 商用・研究どちらでも現実的な選択肢

ぐるなび

公式APIの有無
- ✅ 公式APIあり（ぐるなびWebサービス）
- 店舗情報・ジャンル・位置情報などが取得可能
スクレイピングについての利用規約
- ❌ 原則禁止
- APIの利用が前提
所感
- APIが整備されていて扱いやすい
- 情報の網羅性はやや弱いが、分析用途には十分
- 学習用・検証用としてかなり優秀

Hotpepper

公式APIの有無
- ✅ リクルートが提供する HotPepper Gourmet API が存在
- 店舗情報・エリア・ジャンル取得が可能
スクレイピングについての利用規約
- ❌ 禁止
- API利用が前提
所感
- APIが使いやすく、ドキュメントも比較的親切
- 居酒屋・飲み会系の情報が強い
- 学生の分析題材としてはかなり良い

HAMONI

公式APIの有無
- ❌ 公開APIは存在しない
スクレイピングについての利用規約
- ❌ 明確な記載は少ないが、利用規約的にリスク有りと判断
所感
- 高価格帯・グルメ層向けの情報が特徴的
- データとしては面白いが、取得・利用はかなり慎重になる必要あり

AutoReserve

公式APIの有無
- ❌ 一般向けAPIはなし
スクレイピングについての利用規約
- ❌ スクレイピングや自動取得は禁止
所感
- 店舗データは多いが、トラブル事例も多く取り扱い注意
- 分析用途としては避けた方が無難

Retty

公式APIの有無
- ❌ 現在、一般公開APIはなし
スクレイピングについての利用規約
- ❌ 原則禁止
- 無断取得・転載は禁止利用は禁止されている
所感
- 実名制レビューという独自性が強い
- データとしての価値は高いが、取得方法が限られるのがネック

といった感じで、どれも使用は厳しいなという結論でした。
ただ、チャッピーさんに聞いたところ

実務的な安全策（おすすめ）

まず利用規約を読む
robots.txtを確認
User-Agentを明示
リクエスト間隔を空ける（数秒〜）
可能なら公式APIを使う

スクレイピングが「OK」になりやすいケース

利用規約で明確に禁止されていない

公開情報のみを取得している
（ログイン必須ページ、会員限定、購入後コンテンツはNGになりやすい）
アクセス頻度が低い
（サーバーに負荷をかけない。秒間何十リクエストとかはアウト）
個人情報を扱わない
研究・個人利用・検証目的で、商用でない

とのことでしたので、ちょこっと自分の調査用にする程度なら、
自己責任でといった形なのでしょうか？🤔

無論、この記事はそのような行為を助長するものでないことご了承ください(- -)

分析したかったデータについて

今回、特に重視したデータは以下の3点です。

① 住所（立地）

駅からの距離
エリアごとの店舗密度
駅単位でのジャンル分布

→ 競合が多すぎないかを見るため。

② レビュー

レビュー数
評価の平均
コメントの傾向（簡易的なテキスト分析）

→ 人気ジャンルや不満点の把握。

③ カテゴリー（ジャンル）

ラーメン、居酒屋、カフェなど
駅ごとのジャンルの偏り

→ 「この駅、○○多すぎ問題」を可視化。

開発環境の比較

今回、少し悩んだのが開発環境です。

Python

スクレイピング・分析が楽
pandas / matplotlib が強い
学習コストはやや高め

JavaScript（Node.js）

非同期処理が得意
Web系と相性が良い
データ分析はやや面倒

結論としては、

Python一択でした。

データ取得
CSV化
グラフ作成

までが非常にスムーズで、
「分析してる感」があって楽しかったです😎

開発

これチャッピーさんですぐできます🙄

というより、作ってて思ったのですが情報収集するうんぬんより

全てをチャッピーに聞いた方が早かったのではと思うレベルでした；＿；ｗ

おおまかな結果

ざっくりとした結果ですが、

駅によってジャンルの偏りがかなり大きい
競合が多い駅ほどレビュー平均点が低め
少し外れた駅に高評価店が集中しているケースもあった

親戚には、

この駅は○○系が多すぎるから、
逆に△△系はチャンスありそう

といった形で説明しました。

「データで見ると納得感あるね〜」
と言ってもらえて、正直うれしかったです☕✨

また面白いテーマがあれば、
どんどん記事にしていこうと思います💻

ここまで読んでいただきありがとうございました！
どうぞどうもよろしくです😎