Tabelog Japan Restaurant Market Stats — Budget & Score by Area

What does the restaurant market of this Japanese neighbourhood actually look like? One call per area answers it: how many restaurants Tabelog lists there, what people pay for dinner and for lunch, how the Tabelog scores are spread, which genres dominate and which stations they cluster around.

This Actor reads Tabelog (食べログ — Japan's largest restaurant review site, ~900,000 listed restaurants) and returns one compact market record per area, not a raw dump you have to aggregate yourself.

• dinnerBudgetBands / lunchBudgetBands — the real price structure of the area as Tabelog's own budget bands (～￥999 … ￥30,000～), ordered by price with a count each, plus the median band (an ordinal median — averaging two band labels would be meaningless) and yen statistics for the band bounds
• tabelogScore + scoredShare — min / p25 / median / p75 / max / average of the scores and the share of restaurants that actually carry one. Many Tabelog restaurants are unrated, and a score distribution that silently drops them is a lie
• reviewCount + reviewCountKnown — how much attention the area gets (a count only; see below), and how many of the sampled restaurants that statistic is actually computed on
• genreTop / stationTop / distanceMeters + distanceMetersKnown — the genre mix, the nearest-station mix, and how far restaurants sit from a station over the restaurants whose cassette states a distance
• Every statistic states its own denominator. scoredShare, reviewCountKnown and distanceMetersKnown sit next to the statistic they belong to, against sampledRestaurants — no number in the record is silently computed over "whatever happened to parse"
• Optionally every sampled restaurant, and optionally detail-page enrichment (address, postal code, phone, latitude/longitude, price range, cuisine, seats, opening hours, reservation policy, transport) for lead generation

Review text is never collected. No review bodies, no reviewer names, no reviewer page links, no review photos — this Actor returns business facts about restaurants only. Review counts (a number) are included.

No login, no API key, nothing stored between runs. HTTP only, no browser, 256 MB.

Input

Field	Example	Notes
areas	["tokyo/A1301/A130101"]	Area path <prefecture>/<large area>/<medium area>. A full https://tabelog.com/... URL works too and is normalised down to the area path. 1–10 areas per run — each area is a separate billable unit ($0.02 each) and its own set of requests 2 s apart, so keeping runs short is what keeps them inside the 300 s timeout. Split a bigger job into several runs
genre	"sushi"	Optional genre slug, used as a path segment: sushi, ramen, izakaya, yakitori, washoku, japanese, seafood, soba, unagi, okonomiyaki, monjya, yoshoku, … Empty = all genres
sort	"newest"	newest (新着順) / rating (点数の高い順) / standard. See the note below on why standard is not the default
pagesPerArea	3	20 restaurants per page, 1–10 pages. 3 pages = up to 60 restaurants
includeIndividualItems	false	Off by default. Enable to also get one record per sampled restaurant (+$0.002 each)
fetchDetails	false	Off by default. Enable to fetch detail pages and add address / phone / lat-lng / seats / hours (+$0.002 each)
maxDetails	10	How many detail pages per area (1–20). One extra request, 2 s apart, per restaurant

Finding an area code: open the area on Tabelog and copy the URL — https://tabelog.com/tokyo/A1301/A130101/rstLst/ is Ginza; A1304 Shinjuku, A1303 Shibuya, A1307 Roppongi, osaka/A2701/A270101 Umeda. Pasting the whole URL into areas works.

Output

One type: "area_summary" record per area:

{
  "type": "area_summary",
  "area": "tokyo/A1301/A130101",
  "areaUrl": "https://tabelog.com/tokyo/A1301/A130101/rstLst/?SrtT=nod",
  "genre": null,
  "sort": "newest",
  "totalRestaurantsFound": 2671,
  "sampledRestaurants": 60,
  "pagesFetched": 3,
  "tabelogScore": {"min": 3.0, "p25": 3.06, "median": 3.14, "p75": 3.3, "max": 3.62, "average": 3.19},
  "scoredShare": 0.6167,
  "reviewCount": {"min": 1, "p25": 4, "median": 12, "p75": 48, "max": 1204, "average": 61},
  "reviewCountKnown": 37,
  "dinnerBudgetBands": [{"band": "～￥999", "count": 2}, {"band": "￥6,000～￥7,999", "count": 14}, {"band": "￥15,000～￥19,999", "count": 9}],
  "dinnerBudgetMedianBand": "￥6,000～￥7,999",
  "dinnerBudgetP25Band": "￥4,000～￥4,999",
  "dinnerBudgetP75Band": "￥15,000～￥19,999",
  "dinnerBudgetLowerJpy": {"min": 6000, "p25": 6000, "median": 8000, "p75": 15000, "max": 30000, "average": 11200},
  "dinnerBudgetUpperJpy": {"min": 999, "p25": 7999, "median": 9999, "p75": 19999, "max": 29999, "average": 12480},
  "lunchBudgetBands": [{"band": "～￥999", "count": 11}, {"band": "￥1,000～￥1,999", "count": 20}],
  "lunchBudgetMedianBand": "￥1,000～￥1,999",
  "genreTop": [["寿司", 12], ["日本料理", 9], ["居酒屋", 7]],
  "stationTop": [["銀座一丁目駅", 21], ["東銀座駅", 14]],
  "distanceMeters": {"min": 32, "p25": 120, "median": 210, "p75": 380, "max": 1200, "average": 268},
  "distanceMetersKnown": 58,
  "detailsFetched": 0,
  "checkedAt": "2026-07-27T09:00:00+00:00",
  "sourceUrl": "https://tabelog.com/tokyo/A1301/A130101/rstLst/?SrtT=nod"
}

Reading the statistics — every one of them states its denominator. sampledRestaurants is the whole sample; the three fields next to it say how much of that sample each distribution actually covers, because Tabelog leaves these fields blank on many cassettes:

Field	Denominator for	Means
scoredShare	tabelogScore	Share (0–1) of the sampled restaurants that carry a Tabelog score at all — the rest render 「-」
reviewCountKnown	reviewCount	Count of sampled restaurants whose cassette states a review count
distanceMetersKnown	distanceMeters	Count of sampled restaurants whose cassette states a walking distance from a station

So reviewCount.median with reviewCountKnown: 37 and sampledRestaurants: 60 is the median over 37 restaurants, not 60. pagesFetched plays the same role for sampledRestaurants itself, and a run cut short by the time budget also carries truncatedForTimeLimit: true.

With includeIndividualItems: true, one type: "restaurant" record per sampled restaurant:

{
  "type": "restaurant",
  "area": "tokyo/A1301/A130101",
  "tabelogId": "13108000",
  "name": "おたる政寿司 銀座",
  "url": "https://tabelog.com/tokyo/A1301/A130101/13108000/",
  "score": 3.47,
  "reviewCount": 596,
  "station": "銀座一丁目駅",
  "distanceMeters": 62,
  "genres": ["寿司", "日本料理", "海鮮"],
  "dinnerBudgetBand": "￥15,000～￥19,999",
  "lunchBudgetBand": "￥4,000～￥4,999"
}

With fetchDetails: true, one type: "restaurant_detail" record for the first maxDetails restaurants — the same fields plus address, postalCode, addressRegion, addressLocality, streetAddress, telephone, latitude, longitude, priceRange, servesCuisine, seats, openingHours, reservationPolicy, transport.

Pricing — from $0.02 per area, no subscription

Event	Price	When
Area market summary (area-analyzed)	$0.02	Per area analyzed
Individual restaurant (restaurant-scraped)	$0.002	Only if you enable Include individual restaurants
Restaurant detail record (restaurant-detail-scraped)	$0.002	Only if you enable Fetch restaurant detail pages

Individual restaurant records and detail records are OFF by default, so a default run (1 area, 3 pages, summary only) costs a flat $0.02 and takes about 6 seconds. An area that returns zero restaurants is never charged — it fails the area instead, so you never pay for a typo in an area path or genre slug.

Notes & limits

• Review text is never collected. Review bodies, reviewer names, reviewer page links and review photos are never parsed, stored or emitted. Every field is read out of the one element that carries its own class token, so review text cannot leak into a record even by accident. Review counts (a number) are included
• sort: "standard" is Tabelog's own recommended order and is ad/PR weighted. That is why newest (新着順) is the default here — the same trap as SUUMO's おすすめ順. Use standard only if you deliberately want the promoted ordering, and read every statistic produced from it as "the promoted end of this market". Every record states the sort it was produced with
• The sample is a sample. totalRestaurantsFound is the whole area; sampledRestaurants is what the statistics are computed on (pagesPerArea × 20). Raise pagesPerArea for a more representative distribution
• Tabelog caps a result set at 100 pages / 2,000 restaurants — page 101 returns HTTP 400. Areas larger than that (Ginza alone has ~2,700) must be sliced with genre to be enumerated exhaustively
• scoredShare, reviewCountKnown and distanceMetersKnown matter. A large share of Tabelog restaurants have no score, no review count or no station distance at all. tabelogScore covers only the scored ones, reviewCount only the ones with a count and distanceMeters only the ones with a distance — and each of the three says exactly how many that was, against sampledRestaurants
• A list page is 20 cassettes, and some of them are ads. PR/ad cassettes carry no restaurant link, so a full page can yield 19 records. The page loop counts cassettes, not records, when it decides whether it has reached the end of the area — otherwise a single ad on page 1 would end the run one page in
• The hit count is live and drifts by a few between requests, so totalRestaurantsFound is a snapshot, not a stable key
• An unknown genre slug does not 404 on Tabelog — it returns a different page. The slug is passed through as given and an area that comes back with zero restaurants fails rather than returning a summary for the wrong query
• Read-only and throttled (1 request / 2.0 s). A run has a 95-second soft budget and areas is capped at 10, which is what keeps a worst case inside the Actor's 300-second timeout. Page 1 of every area always runs, so every area produces a record; the follow-up list pages and the detail-page enrichment are what get skipped once the budget is spent, and the affected summary keeps what it collected and carries truncatedForTimeLimit: true with a smaller pagesFetched
• If every area fails, the run fails — never a silent empty success
• No personal data. Restaurant business information only: name, address, phone, coordinates, seats, hours. No reviewers, no customers

Use cases

• B2B lead lists for the restaurant industry — POS, reservation SaaS, food wholesale, payments: pull an area, filter by budget band and genre, enrich the top N with address and phone
• Site selection & competitive density — how many sushi restaurants are within 300 m of this station, and at what price point
• Price positioning — what dinner budget band the neighbourhood actually sits in before you set your own menu prices
• Market monitoring — schedule the Actor per area and track the median band, the score distribution and the restaurant count over time
• Inbound-tourism and delivery planning — genre mix and budget mix per station area

---

日本語ガイド

食べログのエリア相場を、エリア1件につき1レコードで返す Actor です。

• 概要: エリア(<都道府県>/<大エリア>/<小エリア>、例 tokyo/A1301/A130101 = 銀座)を指定すると、そのエリアの掲載店舗数・夜/昼の予算帯分布・食べログ点数の分布・口コミ件数の分布・ジャンル構成・最寄駅構成・駅からの距離を1レコードで返します。予算帯は食べログの帯(～￥999〜￥30,000～)をそのまま安い順に並べ、中央値の帯(帯は順序尺度なので平均ではなく順位の中央値)と帯の上限/下限の円建て統計を併せて返します。
• 点数の扱い: 食べログは点数の付いていない店が多数あります。tabelogScore は点数のある店だけの分布で、scoredShare がその割合です(点数無しの店を黙って落とした分布は嘘になるため必ず併記します)。同様に reviewCount には reviewCountKnown、distanceMeters には distanceMetersKnown(いずれも「その統計に実際に寄与した店舗数」)を必ず併記します。分母は sampledRestaurants です。
• 使い方: areas にエリアパスを入れます。食べログの URL をそのまま貼っても構いません(自動で正規化します)。genre でジャンルを絞れます(sushi / ramen / izakaya など、URL のパスセグメントと同じスラッグ)。個別店舗のレコードが必要なときだけ includeIndividualItems、住所・電話・緯度経度・席数・営業時間まで必要なときだけ fetchDetails を ON にします。
• 料金: エリアサマリー1件 $0.02、個別店舗レコード $0.002/件、詳細レコード $0.002/件。個別レコードと詳細取得は既定 OFF なので既定実行は $0.02 固定です。0件のエリアには課金されません(そのエリアは失敗として扱います)。
• 並び順の注意: standard は食べログの「標準」= 予約・PR店舗優先の広告加重順です。SUUMO のおすすめ順と同型の罠のため既定にはせず、既定は新着順(newest = SrtT=nod) です。どの並び順で取得したかは全レコードの sort に必ず記録されます。
• 口コミ本文は一切取得しません。 口コミ本文・投稿者名・投稿者ページへのリンク・口コミ写真は、パースも保存も出力もしません。取得するのは店舗の事業所情報のみで、口コミは件数(数値)だけを扱います。
• 上限: 1ページ20件・最大100ページ(2,000件)が食べログ側の硬い上限です(101ページ目は HTTP 400)。銀座だけで約2,700件あるため、全件を数え上げたい場合は genre で分割してください。リクエスト間隔は 2.0 秒固定です。areas は1回の実行につき最大10件(1件ごとに課金・リクエストが増えるため)。実行時間の上限に達した場合は、以降のリストページ取得を打ち切り、取得済みの分でサマリーを返して truncatedForTimeLimit: true と実際の pagesFetched を記録します(各エリアの1ページ目は必ず取得します)。

---

中文指南

日本最大的餐厅点评网站「食べログ(Tabelog)」的商圈行情，一次调用返回一条汇总记录。

• 功能: 指定商圈(<都道府県>/<大区>/<小区>，例如 tokyo/A1301/A130101 = 银座)，即可获得该商圈的餐厅总数、晚餐/午餐预算区间分布、Tabelog 评分分布、点评数量分布、菜系构成、最近车站构成与步行距离。预算区间按食べログ原始档位(～￥999 至 ￥30,000～)由低到高排列，并给出中位数档位(档位是序数，因此取排名中位数而非平均值)与档位上下限的日元统计。
• 评分说明: 食べログ上有大量餐厅没有评分。tabelogScore 仅统计有评分的餐厅，scoredShare 表示其占比 —— 悄悄丢弃无评分餐厅的分布是不诚实的。同理，reviewCount 配 reviewCountKnown、distanceMeters 配 distanceMetersKnown(均为实际参与该统计的餐厅数量)，分母为 sampledRestaurants，让每项统计都有明确的覆盖范围。
• 用法: 在 areas 中填入商圈路径，直接粘贴完整的食べログ网址也可以(会自动规范化)。用 genre 限定菜系(sushi / ramen / izakaya 等，与网址中的路径段一致)。需要单店记录时开启 includeIndividualItems；需要地址、电话、经纬度、座位数、营业时间时开启 fetchDetails。
• 价格: 商圈汇总每条 $0.02，单店记录每条 $0.002，详情记录每条 $0.002。单店记录与详情抓取默认关闭，因此默认运行固定为 $0.02。零结果的商圈不收费(该商圈会被判定为失败)。
• 排序提醒: standard 是食べログ自家的「标准」排序，带广告/推广加权，因此本 Actor 默认使用最新开业顺序(newest = SrtT=nod)。每条记录都会记录实际使用的 sort。
• 绝不采集点评正文。 点评正文、点评人昵称、点评人主页链接与点评照片一律不解析、不存储、不输出，只采集餐厅的经营信息；点评仅使用数量(数字)。
• 上限: 每页 20 家，**最多 100 页(2,000 家)**为网站硬上限(第 101 页返回 HTTP 400)。仅银座就约有 2,700 家，需要穷举时请用 genre 拆分。请求间隔固定 2.0 秒。每次运行最多 10 个 areas(每个商圈单独计费、单独发起请求)。达到运行时间预算后将停止抓取后续列表页，用已获取的数据生成汇总并标记 truncatedForTimeLimit: true(pagesFetched 如实记录)；每个商圈的第 1 页始终会抓取。