本記事では、食べログから店舗情報を自動で集めるためのPython（ まず最も多い疑問——「規約上、本当にダメなのか」——を整理します。結論から言えば、食べログ利用規約には「スクレイピング」という単語そのものは登場しません。ただし、SUUMOなど他社の規約と違い、「複写、若しくはその他の方法により再生、複製、送付、譲渡、頒布、配布、転売」を明示的に禁止する条項（第9条）があり、スクレイピングで取得したデータの保存・利用は規約に正面から触れやすい構造です。明示禁止文言ではない部分も、より広く包括的な条項で実質的に縛られているため、3つの条項を組み合わせて読み解くことになります。 食べログを運営する株式会社カカクコムの利用規約（requests + BeautifulSoup）を使った最小実装のコード例から、つまずきやすいエラーの対処、押さえておきたい利用規約・著作権法・偽計業務妨害などの法的論点、そして用途に応じて使い分けたいホットペッパーグルメサーチAPI・Google Places APIなどの代替候補まで、実装者目線で網羅的に整理します。コードを書いて動かしたい人と、業務導入前に押さえるべきポイントを把握したい人の両方に向けた構成です。
食べログのスクレイピングは規約違反なのか？
利用規約に「スクレイピング」の明示禁止条項はあるか
tabelog.com/help/rules/）を確認しても、「スクレイピング」「クローラー」「ロボット」といった単語による明示的な禁止条項は見当たりません。ただし「複製」「再生」「複写」「転売」といった行為レベルの禁止文言は第8条・第9条で明確に列挙されており、SUUMOの「スクレイピングという単語自体がない」ケースよりも、規約上の評価は厳しい部類に入ります。
スクレイピングを規約上どう評価するかは、以下3つの条項を組み合わせて読み解くことになります。 食べログ規約のポイント：他のグルメサイトと比べて「複製」「再生」を明示禁止している点と、口コミ利用に対する1件1万円の利益請求権が組み込まれている点が特徴的です。「スクレイピング」という単語の有無ではなく、取得方法（自動化の度合い）・取得規模（負荷）・取得目的（個人学習か商業利用か）の3軸でバランスを取るのが実務上の判断基準ですが、口コミデータの取得・利用は他項目より一段厳しめに評価すべきです。 「規約違反 ＝直ちに刑事罰」ではありません。規約は契約の一種であり、違反があっても多くの場合まずは民事的な対応（アカウント停止、IP遮断、警告書送付）に留まります。ただし、規約違反は法的紛争になった際の不利な事実として効いてきます。さらに、取得方法や規模が大きくなると、規約違反とは別レイヤーで以下のリスクが現実化します。 これらの法的論点は記事末尾の「法務で押さえる4つの論点」で詳しく扱います。ここで押さえておきたいのは、規約・民事・刑事の3層にはそれぞれ別の閾値があるということ。アクセス頻度・取得規模・利用目的をそれぞれ適切に抑えれば、各層のリスクは実務上コントロール可能な範囲に収まります。 規約論と並んで、実装者がぶつかるのが「そもそも技術的に取れない」という壁です。食べログはUA・IPレピュテーション・アクセスパターン・Cookieなど複数シグナルを組み合わせたbot検知を行っていると考えられ、軽い気持ちで書いたスクリプトはどこかで止まることが多いと報告されています。判定は実行環境や時期で変動しますが、報告されている挙動と、過剰な検知を避けるための原則を整理します。 スクレイピング解説記事でしばしば言及されるのが、「 一方で、本記事執筆時の特定環境からの検証では、 結論：「UAをChromeに偽装すれば必ず通る」も「デフォルトUAなら必ず弾かれる」も、どちらも単純化しすぎです。食べログのbot検知はIP・パターン・Cookie・UAなど複数シグナルの組み合わせで判定される構造のため、1回のアクセス結果はサンプルでしかなく、サイト全体の挙動を代表しません。継続的にアクセスするほど検知精度が上がる傾向もあるため、「最初の数リクエストは通ったが、しばらくして403/429が返り始める」というパターンも珍しくありません。 店舗一覧ページ アンチボット対策に引っかかると、一般的に段階的に強い制限がかかると言われています。 共有IP（VPN・モバイル回線・データセンターIP）で遮断されると、同じIPを使う他の利用者にも影響が出ます。「自分だけの問題」では済まないため、業務で動かす場合は遮断時の影響範囲まで設計に含めるべきです。なお、プロキシ（IPローテーション）でこの遮断を回避する設計案もありますが、検知回避の意図と評価されるリスクがあるため、後段の「プロキシの利用判断」で詳しく扱います。 実装に入る前に、食べログのページ構造と、技術的に取得できるデータ項目を整理します。店舗一覧ページを例に、URLパラメータ・店舗カードの粒度・60ページ上限などを把握しておくと、後段のコード例が理解しやすくなります。 食べログの主要ページは、おおむね以下のURL構造を取ります。 一覧URLには都道府県名・エリアコード（ 食べログの店舗一覧は、URLパスの末尾に 1,200件を超える結果を取得したい場合は、検索条件を絞ってからスクレイピングする必要があります。エリア・ジャンル・予算・営業時間など条件を細かく分けて、結果が1,200件以内に収まる単位でループを回すのが現実的なアプローチです。 店舗の一覧ページ・詳細ページから（技術的に）取得できる主なデータ項目を整理します。実装の難易度は項目によって差があり、特に「口コミ本文」「写真URL」「予約状況」は別ページへの遷移や追加リクエストが必要になることが多いです。 口コミと写真は別レイヤー：店名・住所・点数といった事実情報と異なり、口コミ本文と店舗写真は投稿者・店舗の創作的表現・著作物です。取得・保存・利用の各段階で著作権法・規約第6条(1)③（口コミ利用に対する1件1万円の利益請求権）が直接効いてきます。「取得は技術的に可能」と「利用が法的に安全」は別物として扱ってください。 食べログの一覧ページは、現時点では主要部分がサーバーサイドレンダリング（SSR）されており、HTTPで取得したHTMLに店舗カードが既に埋め込まれています。つまり ページ構造は食べログ運営側の都合で変わることがあります。「今このセレクタで動く」と「半年後も動く」は別問題なので、スクレイピングをビジネスロジックに組み込む場合は、セレクタの抽象化・異常検知・通知設計をあらかじめ仕込んでおくと運用が安定します。逆に言えば、ここを設計段階で押さえておけば、構造変更があっても短時間で復旧できる体制が組めます。 ここからは、Pythonの セレクタの鮮度に関する注意：以下のコード例で使用しているクラス名（ 利用目的に関する注意：このコードは技術解説目的の最小例です。実運用ではsleep間隔・User-Agentの設定・並列度の制御など、後述する技術的・法務的な配慮を踏まえて設計してください。大量取得が必要なユースケースでは、用途によってはホットペッパーグルメサーチAPIやGoogle Places APIなどの公式APIの方が運用コストが軽い場合もあるので、後段の代替手段セクションも合わせて検討すると判断材料が増えます。 使用するライブラリは 実質禁止に効く3つの条項
規約違反と法的リスクの関係
食べログのアンチボット対策——何が検知され得るのか
User-Agentと403ブロックの関係
python-requests やcurl のデフォルトUser-Agent（UA）でアクセスすると HTTP 403 Forbiddenが返る」という挙動です。食べログについても、複数の実装記事や検証ブログで「デフォルトUAだと弾かれた」というレポートが上がっています。これは技術的には十分にあり得る挙動で、対策として「ブラウザ相当のUAを指定する」というアドバイスがセットで紹介されることが多いです。curl/8.7 のデフォルトUAでも一覧ページに200が返るケースが観測されました。つまり、UAによる403ブロックは「常に発動する固定的なルール」ではなく、実行環境（IPアドレスのレピュテーション、データセンターIPか家庭用IPか、時間帯、直前のアクセス頻度、Cookieの保持状況、A/Bテストのバリアント等）によって動的に判定されると考えるのが妥当です。robots.txtから読み取れる運営側の意思
https://tabelog.com/robots.txtを読むと、運営側がbotにどう振る舞ってほしいかが垣間見えます。要点は3つです。
Crawl-delay: 5〜10を明示。Bingbot・Baiduspider・grapeshot・YouBotは5秒、BaiduMobaider・BaiduImagespider・Leikibot・Sogouは10秒。検索エンジンbotにすら5〜10秒間隔を要求するのは、運営側の「ボットに期待する間隔」のシグナルGPTBot: Disallow: /。OpenAIのAI学習用クローラーはサイト全体を完全禁止。これはSUUMOがGoogle-Extended（GoogleのAI学習クローラー）を全許可しているのと正反対で、食べログ運営側の「データの再利用・学習素材化を歓迎しない」明確な意思表示/yoyaku/tabelog_booking/、/rvwr/*/visitdtl/、/ad_mobile/等）。アクセスが想定されていないパスへの巡回は明確にNG/{都道府県}/{エリアコード}/rstLst/自体はrobots.txtでDisallowされていないため、「クロール自体は技術的に許可されている」と解釈する向きもあります。しかし利用規約が上位ルールであり、robots.txtで許されていても規約で禁じられていれば違反になる点は変わりません。GPTBotを名指しで全禁止している運営姿勢を踏まえると、自動取得全般に対する姿勢は厳しい部類と読み取れます。検知された後に起きること
食べログから取得できるデータと、ページ構造の基礎
一覧ページと詳細ページの構造
/{都道府県}/{エリアコード}/rstLst/{ジャンルコード?}/{ページ番号}/?{クエリパラメータ}/{都道府県}/A{大エリア4桁}/A{小エリア6桁}/{店舗ID8桁}/（例: /tokyo/A1304/A130403/13049970/）dtlrvwlst/dtlrvwlst/B{口コミID}/A1304= 新宿エリア等）・ジャンルコード（RC0102 = 焼肉等）・並び替えパラメータなど構造化されたパスとクエリが入ります。実装者目線では便利ですが、これは同時に「予測可能なクロールパターン」を作ってしまうため、運営側のパターンマッチング検知に引っかかりやすい側面もあります。ページネーションと60ページ上限
/{ページ番号}/ を付けてページネーションする構造です（例: .../rstLst/RC0102/2/）。1ページあたり20件表示、UI上で並び順や絞り込み条件を変更できますが、ページ番号は60が上限です。本記事執筆時の実機検証では、60ページ目はHTTP 200で正常に表示される一方、61ページ目はHTTP 400が返されました。つまり1検索条件あたり最大1,200件（20件 × 60ページ）までしか取得できない設計です。取得できる主なデータ項目
カテゴリ
項目例
取得難易度
店舗基本情報
店舗名、住所、最寄駅、ジャンル、電話番号
低（一覧から取得可）
評価・スコア
総合点（3.5等）、夜の評価、昼の評価、口コミ件数
低
予算・営業情報
昼予算、夜予算、営業時間、定休日、座席数
中（詳細ページが必要なものあり）
設備・条件
個室の有無、禁煙、ペット可、貸切可
中（詳細ページが必要）
口コミ本文
口コミ全文、投稿者ID、投稿日時、点数内訳
高（口コミ一覧→個別ページの遷移が必要、著作権リスク高）
写真・地図
店舗写真URL、メニュー写真、地図座標
高（遅延読み込みやJS依存あり、著作権リスク）
静的レンダリングと動的レンダリングの違い
requests + BeautifulSoup級の素朴な構成でも一覧データ自体はパース可能、という前提です。ただし以下の点に注意してください。
list-rst__rst-name-target、c-rating__valのように__でネストを表現。比較的安定したクラス命名だが、年単位でリニューアルが入ると変更されるPythonで食べログをスクレイピングする最小実装
requests とBeautifulSoupを使って、食べログの店舗一覧から店舗情報を取得する最小限の実装例を示します。list-rst、list-rst__rst-name-target、c-rating__val等）は、2026年5月時点でChrome開発者ツールおよび実機HTTPレスポンスで確認したものです。食べログのDOM構造はA/Bテスト・定期改修・運営側の対策強化などにより、予告なく変更されます。本記事公開後しばらく経ってからコードを動かす場合は、必ずChrome開発者ツールで最新のクラス名を確認してから実行してください。コピペでそのまま動く保証はありません。必要なライブラリと環境準備
requests（HTTPクライアント）とbeautifulsoup4（HTMLパーサ）の2つだけです。Python 3.10以降を前提にしています。
pip install requests beautifulsoup41ページ分の店舗カードを取得するコード
食べログの店舗一覧ページは、各店舗がdiv.list-rst（店舗カード単位）でフラットに並ぶ構造です。SUUMOのように「建物の中に複数部屋」というネスト構造はないため、1カード＝1店舗として素直にパースできます。
import time
import random
import requests
from bs4 import BeautifulSoup
URL = (
"https://tabelog.com/tokyo/A1304/rstLst/RC0102/"
"?SrtT=rt&Srt=D&sort_mode=1"
)
HEADERS = {
# 食べログはデフォルトのpython-requests UAでアクセスすると環境によっては
# HTTP 403が返ることが報告されている。ブラウザ相当のUAを明示しておくと
# 弾かれにくい。学術用途等で正体を表明する場合は、連絡先を含むカスタムUA
# （例: YourOrgBot/1.0 (+https://example.com/contact)）も検討する
"User-Agent": (
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/124.0.0.0 Safari/537.36"
),
}
def fetch_listing(url: str) -> BeautifulSoup:
resp = requests.get(url, headers=HEADERS, timeout=30)
resp.raise_for_status()
return BeautifulSoup(resp.content, "html.parser")
def parse_shop(card) -> dict:
"""店舗カード単位の情報（店名・URL・点数・エリアジャンル）を抽出する"""
name_link = card.select_one("a.list-rst__rst-name-target")
rating_val = card.select_one(
".list-rst__rating-total .c-rating__val"
)
dinner_val = card.select_one(
".c-rating-v3__time--dinner .c-rating-v3__val"
)
lunch_val = card.select_one(
".c-rating-v3__time--lunch .c-rating-v3__val"
)
area_genre = card.select_one(".list-rst__area-genre")
comment = card.select_one(".cpy-comment-text")
return {
"name": name_link.get_text(strip=True) if name_link else "",
"url": name_link["href"] if name_link else "",
"rating_total": rating_val.get_text(strip=True) if rating_val else "",
"rating_dinner": dinner_val.get_text(strip=True) if dinner_val else "",
"rating_lunch": lunch_val.get_text(strip=True) if lunch_val else "",
"area_genre": area_genre.get_text(" ", strip=True) if area_genre else "",
"comment": comment.get_text(strip=True) if comment else "",
}
def main():
soup = fetch_listing(URL)
cards = soup.select("div.list-rst")
print(f"取得件数: {len(cards)}")
for card in cards:
shop = parse_shop(card)
print(shop)
if __name__ == "__main__":
main()このコードを実行すると、1ページ目に表示されている店舗ごとに、店名・詳細URL・総合点・夜と昼の点数・エリアジャンル・コメントをフラットなdictとして出力します。CSV保存や分析に流す場合は、このdictをpandas.DataFrame や csv.DictWriter に渡すだけです。
ページネーションを回す
食べログの店舗一覧は、URLパスの末尾に /{ページ番号}/ を付けるとそのページに遷移します（例: .../rstLst/RC0102/2/）。前述のとおり60ページが上限です。総ページ数はページネーション要素から取得できますが、61以降を要求するとHTTP 400が返るため、ループ側で60を上限として固定するのが安全です。
from urllib.parse import urlparse, urlunparse
MAX_PAGE = 60 # 食べログは61ページ以降を要求するとHTTP 400が返る
def with_page(url: str, page: int) -> str:
"""rstLst のURLにページ番号を埋め込む。
例: .../rstLst/RC0102/ → .../rstLst/RC0102/3/
既にページ番号付きの場合は差し替える
"""
parts = list(urlparse(url))
path = parts[2].rstrip("/")
segments = path.split("/")
# 末尾セグメントがすでに数字ならページ番号として差し替え
if segments[-1].isdigit():
segments[-1] = str(page)
else:
segments.append(str(page))
parts[2] = "/".join(segments) + "/"
return urlunparse(parts)
def has_next(soup: BeautifulSoup, current_page: int) -> bool:
"""次ページが存在するか判定する。
60ページ上限と「次へ」リンクの両方をチェック"""
if current_page >= MAX_PAGE:
return False
# ページネーション末尾の「次の20件」リンクの有無を確認
next_link = soup.select_one('a[rel="next"]')
return next_link is not None
def crawl_all_pages(base_url: str, max_pages: int = MAX_PAGE):
"""最大 max_pages ページまで巡回する。本番では十分なsleepを入れる"""
for page in range(1, max_pages + 1):
url = with_page(base_url, page)
soup = fetch_listing(url)
yield page, soup
if not has_next(soup, page):
print(f"page={page} で終端に到達。終了。")
break
# 食べログのrobots.txtはbingbot等にCrawl-delay: 5〜10を要求している
# 公開ページ向けの明示シグナルではないが、運営側の期待値として参考にする
time.sleep(random.uniform(10, 20))CSVに保存する
取得したdict列を、標準ライブラリのcsv.DictWriter に流すだけで保存できます。Excelで開く前提ならencoding="utf-8-sig"（BOM付きUTF-8）にしておくと文字化けしません。
import csv
FIELDS = [
"name", "url",
"rating_total", "rating_dinner", "rating_lunch",
"area_genre", "comment",
]
def save_csv(rows: list[dict], path: str = "tabelog.csv") -> None:
with open(path, "w", newline="", encoding="utf-8-sig") as f:
writer = csv.DictWriter(f, fieldnames=FIELDS)
writer.writeheader()
for row in rows:
writer.writerow(row)動かない時のチェックリスト
最小実装でつまずいた場合、次の順序で原因を切り分けます。
- HTTPステータスコードを確認：
resp.status_codeが 200以外なら、まずそこを潰す。403ならUser-Agent・IP・Cookieの組み合わせを疑う、429ならリクエスト頻度を下げる、400ならURLパラメータやページ番号（60超え）を疑う - HTMLが想定通り返っているか確認：
print(resp.text[:2000])でHTMLの冒頭を見る。エラーページや空ページが返っていればアクセス側の問題 - セレクタが現行構造と一致しているか確認：Chromeの開発者ツールで実際のクラス名を確認し、コード内のセレクタと突き合わせる。食べログはA/Bテストや定期改修でクラス名が変わる可能性がある
- カードは取れるが空文字になる場合：セレクタは合っているが、子要素がさらに深くネストしている可能性。
card.prettify()で整形出力して構造を再確認する
スクレイピング時の技術的な注意点
仮に食べログへスクレイピングを実施する場合（個人の学習用途等）、最低限押さえておくべき技術的な配慮事項を整理します。これらは「適法にする」ためのものではなく、「最低限のマナーラインを越えないため」のチェックリストです。
リクエスト間隔（sleep）の設計
食べログのrobots.txtはBingbot・Baiduspider等に対してCrawl-delay: 5（5秒間隔）を、画像クローラー等に対してはCrawl-delay: 10（10秒間隔）を明示しています。検索エンジンbotにすら5〜10秒を要求しているため、これを参考値として、人間がブラウザで操作するペースを大きく超えない間隔（最低でも数秒、安全側なら10〜30秒）を取るのが現実的です。固定値だとパターン検知されやすいため、ランダムな揺らぎを加えるのも定石です。
import time
import random
# 例: 10〜20秒のランダムなインターバル
time.sleep(random.uniform(10, 20))User-Agentと正体表明
python-requests/2.x やcurl/8.xのデフォルトUAは、過去の検証記事で403ブロックの対象となるケースが報告されています（本記事執筆時の検証では通る環境もありましたが、保証はありません）。少なくともブラウザ相当のUAを指定しておく方が、IP・アクセスパターン等の他の要因で弾かれる確率を下げられます。ただし「ブラウザに偽装する」ことは検知回避に近い設計であり、紛争時の説明責任が重くなります。学術研究や許諾調整中の調査であれば、連絡先を含むカスタムUA（例:YourOrgBot/1.0 (+https://example.com/contact)）で正体を明らかにする方が誠実です。
robots.txtとCrawl-delayの遵守
robots.txtは法的拘束力を持つものではありませんが、これを無視するとサーバー負荷面でも紛争時の説明面でも不利になります。食べログはGPTBotをDisallow: /で完全禁止しており、運営側が「データの再利用・学習素材化を歓迎しない」明確なシグナルを出している点も踏まえる必要があります。Pythonであればurllib.robotparser、Node.jsであればrobots-parser 等のライブラリで、自動的にチェックする設計が安全です。
取得頻度と並列度
sleep間隔と同等に重要なのが、同時並列リクエスト数です。10並列で1秒sleepすれば、サーバーから見れば0.1秒間隔と同じです。食べログのような大規模サイトでも、特定IPからの同時並列は明確な異常パターンとして検知されます。並列度は1〜2に抑え、必要なら複数日に分けて取得する設計が現実的です。
プロキシの利用判断
IP単位の遮断対策として、プロキシ（IPローテーション）を使う設計案が一般的に存在します。Bright Data、Decodo、Octoparseなどの商用プロキシサービスは数百万〜数千万単位の住居用IPを提供しており、検知される前にIPを切り替えながらアクセスする運用が可能です。一見すると「これで永久に取れる」と見えますが、技術的・法的に注意点があります。
まずプロキシは「検知回避を目的とした技術」と評価される側面があります。食べログのように利用規約で複製・再生を明示禁止しているサイトに対して、プロキシでIPローテーションして突破する設計は、紛争時に「故意の検知回避」と評価されやすく、説明責任が重くなります。著作権法30条の4の「権利者の利益を不当に害する場合」に該当する余地も大きくなります。
プロキシが有効な典型シーンは、許諾済みのアクセス（運営側と契約・了承を得ている場合）で実IPだけでは取得帯域が足りないケース、地理的制約のあるサイトに正規ルートでアクセスする場合（海外IPが必要等）、自社所有サイトの監視を多地点から行うケースなどです。一方、「規約上グレーなサイトを物量で押し切る」目的でプロキシを導入すると、紛争時の説明責任が重くなる方向に作用するため、設計の前にユースケースとリスクの整合を取っておくのが安全です。
各プロキシサービスの料金体系・対応国・実装方式の違いは、別記事で詳しく整理しています。
マナーの本質：ボット対策は「攻撃的なボット」だけでなく、「マナーを知らない初心者の善意のボット」も一緒に弾くように設計されています。意図がなくても挙動が悪ければ、結果は変わりません。プロキシで物量的に押し切る前に、対象サイトが本当にスクレイピング向きの取得経路なのかを再評価する方が、結果的に早道になることが多いです。
よくあるエラーと原因
実装中に遭遇するエラーは、原因がアンチボット対策由来か、ページ構造変更由来かで対処方針が大きく変わります。代表的な4ケースを整理します。
HTTP 403 Forbidden
よくある原因の一つが、User-Agentが python-requests/2.x やcurl/8.x のデフォルト値のままであるケースです。ブラウザ相当のUAを設定することで解消することが多いです。ただし食べログのbot検知はUA単独ではなく、IPアドレス・直前のアクセスパターン・Cookieなど複数シグナルの組み合わせで動的に判定される構造のため、UAを変えても403が返る場合は、IP単位でブロックされている、Refererや特定のCookieが要求されている、短時間にアクセスを集中させすぎたなど他の要因を疑う必要があります。同じUAでも、別のIPからは通る・1日空けたら通るというケースは珍しくありません。
HTTP 429 Too Many Requests
短時間に大量リクエストを送った場合に返されるレートリミットエラーです。同一IPからのリクエスト頻度を下げる以外に根本対処はありません。Retry-Afterヘッダーが付いている場合は、その秒数だけ待ってから再開してください。429が頻発する状態で押し切ると、IP単位の長期遮断に格上げされるリスクがあります。
HTTP 400 / 空レスポンス
食べログ特有の400トリガーとして、61ページ以降を要求した場合があります（実機検証で確認）。1検索条件あたりの上限が60ページ（最大1,200件）に設定されているため、ループ側で60を上限として固定するのが安全です。それ以外の400要因としては、URLのクエリパラメータが不完全、Cookieが未送信、必須ヘッダーが欠落しているなどが考えられます。ブラウザの開発者ツールで実際のリクエストを観察し、ヘッダー・Cookie・パラメータの差分を埋めるのが基本対処です。
HTMLが想定と違う・データが取れない
レスポンスは200で返るのに、目的の店舗カードが空になっているケース。これはアンチボット対策由来ではなく、ページ構造の変更がほぼ全ての原因です。食べログはA/Bテストや定期改修でDOM構造・クラス名が変わることがあり、過去にハードコードしたCSSセレクタは早晩動かなくなります。list-rst__rst-name-targetのようなBEM風クラス名は比較的安定していますが、年単位のリニューアルで一括変更されるパターンもあります。複数のフォールバックセレクタを持たせる・XPathで属性ベース検索するなどの設計が必要です。
用途別に検討したい代替・併用データソース
ここまで実装と運用の設計を見てきましたが、すべてのユースケースで食べログのスクレイピングが最適とは限りません。特に定番店舗の網羅取得・統計的なエリア分析・予約導線まで含む業務といった用途は、公式APIや他社サービスの方が安定的かつ低コストでまかなえることがあります。スクレイピングと代替データソースは「どちらかを選ぶ」関係ではなく、用途に応じて使い分け・併用するのが現実的です。
ホットペッパーグルメサーチAPI（最有力の公式ルート）
リクルートが提供する「リクルートWebサービス」の一機能で、個人開発でも無料で使えるAPIキー発行制のサービスです。グルメ系の公式APIとしては最も導入ハードルが低く、商用利用も規約の範囲内で可能です。
- 取得項目：店舗ID・店舗名・住所・電話番号・営業時間・定休日・ジャンル・予算・収容人数・設備情報（個室・WiFi・禁煙席・駐車場等）・写真URL・店舗URL・クーポン情報
- 利用条件：APIキー発行（無料登録）・利用規約への同意
- 制限：1日あたりリクエスト数の上限あり・取得項目はホットペッパー掲載店舗に限定
注意点として、食べログのような「全国網羅の点数ランキング」は対象外です。ホットペッパー掲載店のみ（自社で広告契約のある店舗中心）になります。「予約導線まで含む業務」「自社サービスでクーポン提示まで行う」用途であれば、食べログから無理に取るよりも遥かに安定したデータが揃います。
Google Places API（世界標準の店舗情報ルート）
Googleマップ上の店舗データにAPI経由でアクセスできるサービスです。Googleアカウントとクレジットカード登録が必要で、利用量に応じた従量課金です（毎月一定額の無料枠あり）。
- 取得項目：店舗名・住所・電話番号・営業時間・Googleレビュー本文と点数・価格帯（$〜$$$$）・店舗写真・地図座標
- 強み：Googleマップ自体が一次ソースのため、ほぼすべての実在飲食店をカバー
- 料金：Text Search・Place Details等の機能別にリクエスト単価が設定（毎月の無料枠あり）
e-Stat（マクロ統計用途）
個別店舗データではなく、飲食店業全体の店舗数・売上規模・地域分布などのマクロ統計が必要な場合は、e-Stat（政府統計の総合窓口）に経済センサスやサービス業基本調査のデータが集まっています。物件単位ではなく地域単位の集計データですが、飲食店マーケット規模調査や政策研究の用途では十分です。
取得ルート比較表
| 手段 | 合法性・規約 | データの安定性 | コスト | 向く用途 |
|---|---|---|---|---|
| 食べログをスクレイピング | 規約上リスク高（複製・口コミ利用の明示禁止） | 低（仕様変更・遮断リスク） | 無料（保守コスト大） | 個人の短期検証（非推奨） |
| ホットペッパーグルメサーチAPI | 規約同意・APIキー登録 | 高（公式提供） | 無料 | 個人開発・クーポン連携・予約導線 |
| Google Places API | 規約同意・課金 | 高（Googleが一次ソース） | 従量課金（無料枠あり） | 網羅性重視・世界対応・地図連携 |
| e-Stat（経済センサス等） | 公的統計、利用自由 | 高（5年周期更新） | 無料 | 飲食市場規模調査、政策研究 |
| カカクコムへの個別許諾交渉 | 契約に基づき条件明確化 | 高（契約次第） | 交渉次第 | 商用・再配布・長期運用 |
使い分けの目安：用途が「店舗網羅・予約導線・クーポン連携」など正規ルートで完結できる業務であれば、ホットペッパーグルメサーチAPI＋Google Places APIで大部分のニーズが満たせます。一方で「食べログ独自の点数や口コミ動向の分析」が要件に入る場合は、食べログからの取得が技術的に最短ルートになりますが、本記事の規約パートで触れたとおり複製・口コミ利用に対する罰則条項（第6条(1)③の1件1万円請求権）が直接効くため、利用態様の設計には特に慎重さが求められます。
食べログ含むグルメ・店舗データのスクレイピング、実装まで進めませんか？
Wilicoでは、グルメ・EC・不動産など多様な領域でスクレイピング案件の要件整理・実装・運用監視・法務確認まで一貫してご支援しています。アンチボット対策の設計、構造変更時の保守、ホットペッパーAPIやGoogle Places APIなど複数データソースの統合まで、自社内で抱え込まずに進めたい部分だけ切り出してお任せいただけます。
法務で押さえる4つの論点
スクレイピングの法的論点は、ひとつの法律だけで片付かないのが厄介な点です。食べログを対象とする場合に特に重要となる4つの論点を、根拠条文と判例とセットで整理します。
著作権法とデータベース保護（30条の4を含む）
日本の著作権法では、「情報の選択又は体系的な構成によって創作性を有するデータベース」はデータベースの著作物として保護されます（著作権法12条の2）。食べログの店舗データベースは、独自の項目設計（店舗名・点数・口コミ件数・予算・営業時間・ジャンル等の組み合わせ）と検索体系を持つため、データベースの著作物として保護される可能性があります。
食べログ特有の論点として、口コミ本文は投稿者の創作的表現として通常の著作物に該当し、投稿時に食べログ側が複製・公衆送信・翻訳・翻案等の利用許諾を受けています（規約第6条(4)③）。つまり、口コミを丸ごとスクレイピングして別サイトで表示する・社内ナレッジとして長期保存するといった行為は、投稿者の著作権と食べログの利用権限の両方に直接抵触する可能性があります。さらに規約第6条(1)③の「口コミを利用して利益を得た場合、1件1万円を請求できる」条項が、契約レイヤーから罰則として効いてきます。
一方で、2018年改正で導入された著作権法30条の4は、「著作物に表現された思想又は感情の享受を目的としない利用」（情報解析等）について、権利者の許諾なく利用できると定めています。点数推移の分析、ジャンルごとの相場分析、機械学習用の特徴量抽出といった情報解析目的の利用は、原則としてこの条項でカバーされます。ただし条文には「著作権者の利益を不当に害する場合」は適用外という但し書きがあり、食べログの代替サービスを作るような市場代替性のある利用は対象外と解されています。つまり、「自社の意思決定に使う情報解析」と「食べログと競合する公開サービスの構築」は別物として整理しておくと、本条項の恩恵を活かしやすくなります。
偽計業務妨害（刑法233条）と岡崎事件の教訓
偽計業務妨害は「虚偽の風説を流布し、又は偽計を用いて、人の信用を毀損し、又はその業務を妨害した者は、三年以下の懲役又は五十万円以下の罰金に処する」と定めています。スクレイピング文脈で必ず参照されるのが、岡崎市立中央図書館事件（2010年）です。
- 図書館の新着図書情報を取得するため、約1秒に1回というペースでクローラーを走らせた
- サーバー側のバグでアクセス障害が発生
- 偽計業務妨害容疑で逮捕、20日間勾留、最終的に起訴猶予
この事例から実務で学べるのは、攻撃意図の有無や「常識的な」アクセス間隔の設定だけでは刑事リスクを完全に排除できない、という点です。逆に言えば、アクセス頻度・サーバー応答時間の監視・障害発生時の即座な停止・運営側との対話チャネルの確保を設計に組み込めば、同種のリスクは大きく抑えられます。「相手のサーバー状態を観察しながら設計する」のがスクレイピング実装の基本作法、と捉えるのが現実的です。食べログは大規模サイトで一定の負荷耐性はありますが、それは「攻撃的なアクセスを許容する」という意味ではありません。
個人情報保護法（口コミ投稿者・個人経営店の情報が含まれる場合）
食べログから取得できる情報のうち、口コミ投稿者のニックネーム・プロフィール画像・投稿履歴、および個人経営店の店主氏名・個人携帯番号は、個人情報保護法における「個人情報」または「個人関連情報」に該当する余地があります。これらの取得・利用・第三者提供に法的規律がかかります。
- 個人情報の取得時には、利用目的を本人に通知または公表する必要がある（個情法17条・21条）
- 取得した個人情報を本来の目的を超えて利用する場合、本人の同意が必要
- 第三者提供（再配布・販売等）には別途同意が必要
スクレイピングで口コミ本文と投稿者ニックネーム・プロフィールをセットで取得し、社内データベースに保存すると、これらの規律を満たさないまま個人情報・個人関連情報を保有することになります。点数や店舗の事実情報だけと違って、口コミ系は個人情報リスクが直撃する領域なので、利用目的とデータ保持期間を文書化したうえで設計するのが現実的です。
不正競争防止法（限定提供データ）
2019年改正で導入された限定提供データ制度（不正競争防止法2条7項）は、特定の者に提供される業務上のデータを保護対象としています。要件は3つです。
- 限定提供性：業として特定の者に提供する情報
- 相当蓄積性：電磁的方法で相当量蓄積されている
- 電磁的管理性：ID/パスワード等で管理されている
重要なのは、不正競争防止法2条7項の括弧書きに「無償で公衆に利用可能となっている情報」を除外する規定があることです。食べログの一般公開ページは無料・無認証でアクセスできるため、通常は限定提供データには該当しません。会員限定・ログイン裏側のデータ（食べログプレミアム会員限定情報・店舗管理画面の情報等）にアクセスする場合は話が変わります。
「robots.txtでDisallowされていない＝合法」「規約に書いていない＝自由」という単純図式ではありません。規約（契約）・著作権（著作物性とデータベース保護）・刑事（業務妨害）・個情法・不競法を、利用態様ごとに別個に検討する必要があります。特に食べログは口コミ利用に対する1件1万円の請求権が規約に明文化されている点で、契約レイヤーの罰則が他社より重い設計になっています。 個人学習・少量取得は、運用上のサーバー負荷の面で実務上問題視されにくいゾーンです。ただし食べログの場合、規約第9条で「複製・再生」が明示禁止されており、「個人利用なら何をしても良い」とは言いにくい構造です。サーバーへの負荷をかけない設計（sleepを十分に取る、並列度を上げない、深夜帯を避ける）と、取得データを再配布・公開しない・口コミは保存しないといった運用を組み合わせることが前提になります。再現可能なスクリプトとして組む場合は、本記事の技術的な注意点セクションで触れた配慮事項を入れておくと安心です。 ヘッドレスブラウザで人間の操作を模倣しても、規約上の「複製・再生」「営利目的のアクセス」に該当する余地は変わりません。むしろ、検知回避に近い設計は紛争時の説明責任が重くなります。技術的にバレないことと、適法であることは別の話です。 コンシューマ向けの公式APIは公開されていません。2023年5月にChatGPTプラグイン向けに「お店検索API」が用意されましたが、これはChatGPT専用で一般非公開です。カカクコムの法人向けサービス（食べログ広告等）は契約ベースで個人開発者が利用できるものではありません。個人開発者がグルメデータを正規に取得したい場合は、ホットペッパーグルメサーチAPI（リクルート）またはGoogle Places APIが現実的な選択肢です。 まずUser-Agentの設定を確認してください。curlやpython-requestsの標準UAでHTTP 403が返るケースは過去にも複数報告されています。UAがブラウザ相当でも動かない場合、IPアドレスがレピュテーション悪化で弾かれている可能性、ページがJavaScriptレンダリングに変わった可能性、HTML構造（クラス名・DOM）が変わった可能性、Cookieやセッション処理が必要になった可能性などが考えられます。サイト側の検知ロジックは段階的に強化されるため、過去動いた事実は将来の動作保証になりません。 「外部公開しなければ完全に問題ない」と言い切るのは難しいですが、社内分析用途は著作権法30条の4（情報解析の権利制限）の適用余地がある領域です。点数推移の分析、エリアごとの平均点・ジャンル分布の集計、機械学習用の特徴量抽出などは、原則としてこの条項の射程に入ります。一方で、食べログと競合する公開サービスを作るような市場代替性のある利用は適用外です。また、口コミ本文の社内保存・社内検索は、規約第6条(1)③（口コミ利用に対する利益請求権）が直接効く領域なので、点数や店舗の事実情報と分けて、保存対象から外す設計が安全です。社内利用であっても、規約第6条(1)①（営利目的利用）との関係で、取得規模・頻度・利用態様を文書化しておくと紛争時の説明がしやすくなります。 「これなら安全」という公式の閾値はありません。食べログのrobots.txtはBingbot等にCrawl-delay:5（5秒間隔）、画像クローラー等にCrawl-delay:10（10秒間隔）を明示しています。これが運営側がbotに期待する間隔のシグナルと読めます。スクレイピングを実施する場合は最低でも数秒〜数十秒のインターバルを取り、ランダムな揺らぎを加え、深夜帯を避けるなどの配慮が現実的です。ただし間隔を空ければ適法というわけではない点に注意してください。 本記事は一般的な技術・法務観点の整理であり、個別案件の適法性や契約解釈の最終判断ではありません。商用利用・大規模収集・再配布が絡む場合は、必ず利用規約の原文確認と、必要に応じて弁護士への相談を行ってください。記載の食べログの仕様・規約・アンチボット動作・HTMLクラス名等の情報は、いずれも2026年5月時点で確認したものです。食べログのDOM構造・規約条項・robots.txt・アンチボット挙動は、運営側の都合により予告なく変更される可能性があるため、本記事公開後に時間が経過してから参照する場合は、必ず最新情報を一次ソース（公式サイト・実機）で再確認してください。よくある質問
個人利用・少量なら問題ない？
SeleniumやPlaywrightなどブラウザ自動化なら大丈夫？
食べログに公式APIや、データ提供サービスはある？
過去に動いていたスクレイピングコードが急に動かなくなった
取得した店舗データを社内分析だけに使うのは合法？
sleepは何秒に設定すべき？
まとめ
免責事項・情報の鮮度について
