Tony Wang4 分で読めますOpenTableのレストラン・予約データをスクレイピングする方法(2026年版・API & Python)
2026年にOpenTableのレストラン検索、プロフィール、メニュー、レビュー、ライブのタイムスロットをスクレイピング — DIY、ノーコード、または構造化APIで。法的な基本事項も解説します。
2026年にOpenTableのレストラン・予約データをスクレイピングする最速の方法は、OpenTableの内部予約フローをリバースエンジニアリングする代わりに、正規化されたJSONを返す構造化APIを呼び出すことです。このJSONにはレストランプロフィール、メニュー、来店客のレビュー、そして予約可能なライブタイムスロットが含まれます。本ガイドでは、3つのアプローチすべてについて、それぞれが何を返し、どこで破綻し、そして法的な基本事項がどうなっているのかを解説します。
なぜOpenTableをスクレイピングするのか?
OpenTableはレストランの発見、メニュー、レビュー、そしてライブの空き状況を一元化しており、次のような用途に役立ちます。
- 予約空き状況モニタリング — 予約の取りにくいレストランでテーブルが空いたタイミングを追跡します。
- レストラン・ホスピタリティ市場リサーチ — 都市圏全体にわたる料理ジャンル、価格帯、エリアのカバレッジ。
- レビュー・センチメント分析 — カテゴリー別の来店客評価(料理、サービス、雰囲気、価格満足度、騒音レベル)。
- メニュー・価格ベンチマーキング — レストラン間で料理や価格を比較します。
OpenTableのスクレイピングは合法か?
選択肢 1: Python での DIY(そしてなぜ破綻するのか)
OpenTableのレストランページとライブの空き状況ウィジェットは内部予約APIに支えられているため、DIYスクレイパーは実質的にそのフローをリバースエンジニアリングすることになります。
import requests
# OpenTable's live-availability widget calls an internal booking API,
# not a documented public endpoint
resp = requests.get("https://www.opentable.com/s?term=dinner&latitude=37.7749&longitude=-122.4194")
デモでは動きますが、その後すぐに破綻します。
- 公式の公開APIがない。 OpenTableはサードパーティによる検索や空き状況アクセス向けのデベロッパーAPIを公開していないため、ドキュメント化されたエンドポイントもキーもありません。コンシューマー向けサイトとアプリのプライベートな呼び出しを再現することになります。
- リアルタイムの空き状況が難所。 タイムスロットはテーブルが予約されたり解放されたりするたびに変化するため、スクレイピングしたスナップショットは数分で古くなります。短い間隔で再ポーリングする必要がありますが、これはまさにアンチボットシステムがフラグを立てる負荷パターンです。
- アンチボット対策。 検索や空き状況のエンドポイントへの繰り返し自動リクエストはレート制限やブロックを引き起こすため、現実的なヘッダー、プロキシ、そして絶え間ないメンテナンスが必要です。
- 移り変わる内部スキーマ。 プライベートな予約APIのレスポンス形式は予告なく変更され、再現したクエリを破綻させます。
選択肢 2: ノーコードツール
マーケットプレイスの「OpenTableスクレイパー」アクターはCSV/JSONをエクスポートし、単発の取得には適していますが、プロダクト内のパイプライン — 特にライブの空き状況を追跡するもの — では扱いづらく、同じ内部APIの脆さを引き継ぎます。
選択肢 3: 構造化された OpenTable API
繰り返し行うワークフローには、OpenTableスクレイピング APIが、メンテナンスすべき内部予約フローなしで正規化されたJSONを返します。キーワード、位置情報、日時、人数で検索でき、ライブの空き状況もインラインで含まれます。
curl "https://api.crawlora.net/api/v1/opentable/search?term=dinner&latitude=37.7749&longitude=-122.4194&party_size=2" \
-H "x-api-key: $CRAWLORA_API_KEY"
続いて、レストランのidを解決し、Pythonでプロフィール、メニュー、レビューを取得します。
import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/opentable"
results = requests.get(f"{base}/search", headers=h,
params={"term": "dinner", "latitude": 37.7749, "longitude": -122.4194}).json()["data"]["results"]
rid = results[0]["id"]
restaurant = requests.get(f"{base}/restaurant", headers=h,
params={"restaurant_id": rid, "party_size": 2}).json()["data"]
menus = requests.get(f"{base}/restaurant/menus", headers=h,
params={"restaurant_id": rid}).json()["data"]["menus"]
reviews = requests.get(f"{base}/restaurant/reviews", headers=h,
params={"restaurant_id": rid, "page": 1}).json()["data"]["reviews"]
レストランプロフィールのレスポンスは、そのまま保存できる正規化されたJSONです(実際のフィールド)。
{
"code": 200,
"msg": "OK",
"data": {
"id": "131459",
"name": "El Gaucho Argentinian Steakhouse - Hai Ba Trung",
"city": "Ho Chi Minh city",
"dining_style": "Casual Dining",
"cuisines": [{ "id": "029cd931-...", "name": "Steak" }],
"timeslots": [{ "date_time": "2026-08-04T19:00", "available": true, "price_amount": null, "token": "..." }]
}
}
レビューは総合スコアだけでなく、カテゴリー別の評価とともに返ってきます。
{ "id": "OT-131459-908-...", "reservation_date": "2026-05-29T13:45", "author": "kim", "text": "Australian beef, top notch.", "recommended": true, "statistics": { "overall_rating": 5.0, "food": 5.0, "service": 5.0, "ambience": 5.0, "value": 4.0, "noise": 3.0 } }
レストランごとに1行を保存し(空き状況モニタリングの場合はタイムスロットのチェックごとに1行)、実際の空き状況の変化スピードに合わせたスケジュールで再ポーリングしてください。
収集できるもの
公開されたフィールド: ライブの空き状況をインラインで含むレストラン検索結果(id、name、location、cuisines、timeslots)、レストランプロフィール(location、hours、price band、dining style、dress code、features、review summary)、リアルタイムで予約可能なタイムスロット(date/time、availability、人数に応じた価格)、メニュー(sections、items、prices)、そしてカテゴリー別評価(総合、料理、サービス、雰囲気、価格満足度、騒音レベル)を伴う来店客のレビュー。
制約とよくある課題
- 公式デベロッパーAPIがない。 サードパーティによる検索や空き状況へのアクセスは、OpenTableの内部予約フローをスクレイピングすることを意味します。構造化APIなら1つのキーの裏でこれを処理します。
- 空き状況は常に変動する的です。 タイムスロットはある時点のスナップショットにすぎません。「テーブルが空くかどうか」をモニタリングする場合は、1回の取得を信頼するのではなく、スケジュールに沿ってポーリングしてください。
- レビューは個人データ。 投稿者名、レビュー本文、都市圏の位置情報はGDPR/CCPAのもとで個人データです。適法な根拠のもと、公開された事実に基づくフィールドを収集してください。
- 繰り返しポーリングに対するアンチボット。 同じレストランへの頻繁な自動リクエストはレート制限を引き起こします — 構造化APIならキーの裏でこれを吸収します。
どのような場面で使われるか
- 予約空き状況モニタリング — 満席のレストランでキャンセルが出たときにアラートを出します。旅行・ホスピタリティリサーチのユースケースを参照してください。
- レストラン市場リサーチ — 都市圏全体にわたる料理ジャンルの密度、価格帯、カバレッジ。
- レビュー・評判モニタリング — カテゴリー別の来店客センチメントの推移。レビュー・評判モニタリングのユースケースを参照してください。
出典
収集を始める
まずは無料で試す: 任意の公開URLを無料ウェブスクレイパーで実行するか、アンチボットチェッカーでサイトがボットをブロックするかどうかを確認できます。サインアップは不要です。
Playgroundで検索エンドポイントをテストし、APIドキュメントでスキーマを確認し、料金を確認してください。あわせて、ローカルビジネスの評価についてはYelpをスクレイピングする方法、旅行・施設レビューについてはTripAdvisorをスクレイピングする方法、このデータが実際にどう流れるかについてはモバイルアプリAPIの仕組み、そしてウェブスクレイピングは合法かもあわせて参照してください。
本記事はhow-to-scrapeガイドシリーズの一部です — 私たちが扱うすべてのプラットフォームを、1つのインデックスにまとめています。
よくある質問
OpenTableには公式APIがありますか?
サードパーティによる検索や空き状況アクセス向けの公開デベロッパーAPIはありません。OpenTableのレストラン、メニュー、レビュー、タイムスロットのデータを収集するにはスクレイピングが必要です。構造化APIなら1つのキーの裏でこれを処理し、メンテナンスすべき内部予約フローなしで正規化されたJSONを返します。
空き状況データはどのくらい新鮮ですか?
タイムスロットはある時点のスナップショットであり、テーブルが予約されたり解放されたりするたびに変化します。「テーブルが空いたら知らせる」といったモニタリング用途では、1回のスナップショットを信頼するのではなく、実際の空き状況の変化スピードに合わせたスケジュールでポーリングしてください。
OpenTableのレストランはどうやって指定しますか?
レストランは数値のOpenTable idで指定され、検索エンドポイントがレストラン詳細エンドポイントと同じ位置情報やライブの空き状況フィールドとともにこれを返します。
OpenTableのどのようなデータを収集できますか?
公開されたフィールドです: ライブの空き状況をインラインで含むレストラン検索、レストランプロフィール(場所、営業時間、価格帯、ダイニングスタイル、特徴、レビューの要約)、リアルタイムで予約可能なタイムスロット、メニュー(セクション、項目、価格)、そしてカテゴリー別評価(料理、サービス、雰囲気、価格満足度、騒音レベル)を伴う来店客のレビュー。
OpenTableのレビューは個人データですか?
はい。投稿者名、レビュー本文、都市圏の位置情報はGDPR/CCPAのもとで個人データです。適法な根拠のもと、公開された事実に基づくフィールドのみを収集し、レビュアーの身元を再公開しないでください。
どのくらいの頻度で更新できますか?
プランと責任ある利用の範囲内でスケジュールに沿って再ポーリングしてください — ライブの空き状況モニタリングでは短い間隔で、レビュー/センチメント追跡ではより緩やかな間隔で構いません。