Tony Wang5 分で読めますUber Eatsのレストラン・メニューデータをスクレイピングする方法(2026年版・API & Python)
2026年にUber Eatsのレストラン検索、メニュー、レビューをスクレイピング — DIY、ノーコード、または認証情報不要の公開データを扱う構造化APIで。法的な基本事項も解説します。
2026年にUber Eatsのレストラン・メニューデータをスクレイピングする最速の方法は、Uber Eatsの内部APIを自力でリバースエンジニアリングする代わりに、正規化されたJSONを返す構造化APIを呼び出すことです。このJSONにはレストラン検索、位置情報の閲覧フィード、ストアメニュー全体、そしてレビューのスナップショットが含まれます。本ガイドでは、3つのアプローチすべてについて、それぞれが何を返し、どこで破綻し、そして法的な基本事項がどうなっているのかを解説します。
なぜUber Eatsをスクレイピングするのか?
Uber Eatsは世界最大級のフードデリバリーマーケットプレイスの1つであり、次のような用途に役立ちます。
- レストラン・メニューインテリジェンス — 市場全体にわたるメニュー項目、価格、在庫状況を追跡します。
- デリバリー市場リサーチ — エリアごとの料理ジャンルのカバレッジとレストラン密度を、DoorDashとあわせてデリバリー市場全体を把握します。
- レビュー・評判モニタリング — レストランの評価とレビューのセンチメントの推移を追跡します。
- 競合価格分析 — 近隣のストア間で同じ料理ジャンルの価格を比較します。
Uber Eatsのスクレイピングは合法か?
選択肢 1: Python での DIY(そしてなぜ破綻するのか)
Uber Eatsは内部APIからレストラン検索とストアページをレンダリングしているため、DIYスクレイパーは実質的にそのフローをリバースエンジニアリングすることになります。
import requests
# Uber Eats' consumer site calls an internal API, not a documented public endpoint
resp = requests.get("https://www.ubereats.com/feed?pl=...")
デモでは動きますが、その後すぐに破綻します。
- 公式の公開APIがない。 Uber Eatsはサードパーティによる検索、メニュー、レビューアクセス向けのデベロッパーAPIを公開していないため、ドキュメント化されたエンドポイントもキーもありません。コンシューマーアプリのプライベートな呼び出しを再現することになります。
- UUIDで指定されるストア。 ストアは人が読める形のidではなくUUIDで識別されるため、どのワークフローでもメニューやレビューを取得する前に、まず検索またはフィードでそれを解決する必要があります。
- 位置情報でゲートされたレスポンス。 フィードと検索結果は配達座標に紐づいているため、スクレイパーは1つのキャッシュされたレスポンスではなく、リクエストごとに実際の緯度/経度を必要とします。
- 移り変わる内部スキーマ。 プライベートなアプリバックエンドのレスポンス形式は予告なく変更され、再現したクエリを破綻させます。
選択肢 2: ノーコードツール
マーケットプレイスの「Uber Eatsスクレイパー」アクターはCSV/JSONをエクスポートし、単発の取得には適していますが、スケジュール実行するパイプラインでは扱いづらく、同じ内部APIの脆さを引き継ぎます。
選択肢 3: 構造化された Uber Eats API
繰り返し行うワークフローには、Uber Eatsスクレイピング APIが、認証情報不要の公開データとして正規化されたJSONを返します — Uber Eatsからのログイン、キー、Cookieは一切不要です。ある位置情報の近くのレストランを検索するには次のようにします。
curl "https://api.crawlora.net/api/v1/ubereats/search?query=pizza&latitude=37.7749&longitude=-122.4194" \
-H "x-api-key: $CRAWLORA_API_KEY"
続いて、ストアのUUIDを解決し、Pythonでメニューとレビューのスナップショットを取得します。
import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/ubereats"
results = requests.get(f"{base}/search", headers=h,
params={"query": "pizza", "latitude": 37.7749, "longitude": -122.4194}).json()["data"]["restaurants"]
store_uuid = results[0]["storeUuid"]
store = requests.get(f"{base}/store/{store_uuid}", headers=h).json()["data"]
menu = requests.get(f"{base}/store/{store_uuid}/menu", headers=h).json()["data"]["sections"]
reviews = requests.get(f"{base}/store/{store_uuid}/reviews", headers=h).json()["data"]["reviews"]
検索レスポンスは、そのまま保存できる正規化されたJSONです(実際のフィールド)。
{
"code": 200,
"msg": "OK",
"data": {
"restaurants": [
{ "storeUuid": "259fe6e9-9e3a-429d-ae24-be5eda54ba64", "name": "Udupi Palace", "slug": "udupi-palace-mission", "rating": 4.5, "reviewCount": 2000, "deliveryEtaText": "20-30 min", "cuisineTags": ["Indian"], "currencyCode": "USD" }
]
}
}
ストア詳細は、住所、電話番号、営業時間の要約、価格帯を含む完全なプロフィールを返し、メニューは項目ごとの価格を保持します(実際のフィールド、セントではなくドル単位)。
{ "storeUuid": "259fe6e9-...", "storeTitle": "Udupi Palace", "sections": [{ "title": "Appetizers", "items": [{ "title": "Samosa", "description": "Crispy pastry with spiced potato filling", "price": 6.99, "isSoldOut": false }] }] }
レビューはスナップショットとして返ってきます — 完全にページネーションされた履歴ではなく、総合評価と最近書かれたレビューのサンプルです。
{ "storeUuid": "259fe6e9-...", "rating": 4.5, "reviewCount": 2000, "reviews": [{ "eaterName": "Jamie L.", "text": "Great food, quick delivery.", "formattedDate": "01/01/26" }] }
キーワード検索の代わりに一般的な位置情報フィードを閲覧するには、/ubereats/search の query パラメータを省略するか(あるいは /ubereats/feed を使うか)してください。レストランごとに1行を保存し、スケジュールに沿って再取得してください。
収集できるもの
公開されたフィールド: レストラン検索結果と位置情報フィード(storeUuid、name、url、rating、review count、delivery ETA、cuisine tags、sponsoredフラグ、currency)、ストアプロフィール(住所、電話番号、評価、価格帯、営業時間の要約、営業中/注文可否ステータス)、メニュー全体(sections、items、description、price、sold-outステータス)、そしてレビューのスナップショット(総合評価、件数、サンプルのレビュー本文)。
制約とよくある課題
- 任意のレストランデータを取得できる公式APIがない。 サードパーティによる検索、メニュー、レビューへのアクセスは、Uber Eatsの内部アプリバックエンドをスクレイピングすることを意味します。構造化APIなら1つのキーの裏でこれを処理します。
- レビューは完全なフィードではなくスナップショットです。 レビューのエンドポイントは、ストアページが表示するのと同じサンプルを返すもので、これまでに投稿されたすべてのレビューではありません — レビューを網羅的に把握するには、一度きりのエクスポートではなく、繰り返し取得するものとして扱ってください。
- すべてが位置情報に紐づいています。 メニュー、価格、在庫状況は配達座標によって変化します — リクエストごとに実際の位置情報を渡してください。
- レビューは個人データ。 レビュアー名とレビュー本文はGDPR/CCPAのもとで個人データです。適法な根拠のもと、公開された事実に基づくフィールドを収集してください。
どのような場面で使われるか
- レストラン・メニューインテリジェンス — デリバリー市場全体にわたる価格と品揃えを追跡します。Eコマースプロダクトインテリジェンスのユースケースを参照してください。
- レビュー・評判モニタリング — レストランの評価とセンチメントの推移を追跡します。レビュー・評判モニタリングのユースケースを参照してください。
- デリバリー市場リサーチ — エリアごとの料理ジャンルの密度とレストランのカバレッジを、DoorDashとあわせてデリバリー市場全体を把握します。
出典
収集を始める
まずは無料で試す: 任意の公開URLを無料ウェブスクレイパーで実行するか、アンチボットチェッカーでサイトがボットをブロックするかどうかを確認できます。サインアップは不要です。
Playgroundで検索エンドポイントをテストし、APIドキュメントでスキーマを確認し、料金を確認してください。あわせて、デリバリー市場の反対側についてはDoorDashをスクレイピングする方法、ローカルビジネスの評価についてはYelpをスクレイピングする方法、このデータが実際にどう流れるかについてはモバイルアプリAPIの仕組み、そしてウェブスクレイピングは合法かもあわせて参照してください。
本記事はhow-to-scrapeガイドシリーズの一部です — 私たちが扱うすべてのプラットフォームを、1つのインデックスにまとめています。
よくある質問
Uber Eatsには公式APIがありますか?
サードパーティによる検索、メニュー、レビューアクセス向けの公開デベロッパーAPIはありません。Uber Eatsのレストランデータを収集するには、その内部APIをスクレイピングする必要があります。構造化APIなら1つのキーの裏でこれを処理し、ログイン不要の認証情報不要な公開データを返します。
Uber Eatsのストアはどうやって指定しますか?
ストアは数値のidではなくUUID(storeUuid)で指定され、/ubereats/search または /ubereats/feed が返します。まずそれを解決してから、ストア、メニュー、レビューの各エンドポイントで使用してください。
検索キーワードなしで閲覧するにはどうすればよいですか?
キーワード検索の代わりにある位置情報の一般的なレストランフィードを閲覧するには、/ubereats/search の query パラメータを省略するか、/ubereats/feed を直接呼び出してください。
Uber Eatsのどのようなデータを収集できますか?
公開されたフィールドです: レストラン検索結果と位置情報フィード(評価、レビュー数、配達予定時間、料理タグ、通貨)、ストアプロフィール(住所、電話番号、価格帯、営業時間、ステータス)、メニュー全体(セクション、項目、価格、売り切れステータス)、そしてレビューのスナップショット(総合評価、件数、サンプルのレビュー本文)。
レビューのエンドポイントは完全なレビュー履歴ですか?
いいえ。ストアページが表示するのと同じページ内スナップショットを返すもので、総合評価と最近のレビューのサンプルにとどまり、これまでに投稿されたすべてのレビューを網羅したページネーション済みフィードではありません。
Uber Eatsのレビューは個人データですか?
はい。レビュアー(利用者)名とレビュー本文はGDPR/CCPAのもとで個人データです。適法な根拠のもと、公開された事実に基づくフィールドのみを収集し、レビュアーの身元を再公開しないでください。