立ち飲み店舗データ構築・標準作業フロー Vol.2 完全版

京都エリアでの店舗データ構築・WordPress反映作業、大阪府での大規模店舗取得テストをもとに、 1,000件を超える大量店舗データでも、Deep Research・Workモード・WPVibeを無駄に消費せず、途中停止しても確実に続きから再開できる標準作業手順を以下のとおり定めます。

Vol.2では、ChatGPTが1店舗ずつWeb巡回してデータを集める方式を標準方式とせず、 「先に全店舗マスターを確保 → PC上で詳細取得 → CSVへ逐次保存 → 完成後にWordPressへ一括反映」 を基本方式とします。

最重要原則	WPVibeを使いながらデータを完成させない。調査・取得・整理・CSV作成・住所確認・位置情報生成・写真整理・投入前マスター作成は、 WordPressへ反映する前にすべて完了します。 WPVibeは調査ツールとして使用せず、完成済みデータをWordPressへ反映するための最終投入手段としてのみ使用します。基本方針は以下です。全店舗マスター確保 ↓ PC上で詳細取得 ↓ CSV逐次保存 ↓ 住所・位置情報・写真等を整理 ↓ 投入前マスター完成 ↓ 最終サマリー報告 ↓ ユーザー許可 ↓ WPVibe一括実行 ↓ 結果報告
Vol.2で廃止する旧方式	以下を大量店舗取得の標準方式として使用しません。・ChatGPTが1店舗ずつWeb検索して詳細を埋める方式・Deep Researchで1,000件以上の店舗詳細を巡回する方式・Workモードで1,000件以上の店舗を連続処理する方式・調査途中でWPVibeを使用する方式・店舗詳細取得と緯度経度取得を同時に行う方式・取得できない情報を別サイトで無理に補完する方式大量データは、ChatGPT側のWeb取得枠・Deep Research利用枠・Work利用量を消費する方法ではなく、 PC上の取得処理とCSV保存を中心に構築します。
基本データソース	大阪府の大量取得では、食べログ「大阪府 × 立ち飲み」検索結果に掲載されている店舗を母集団とします。店舗基本情報・詳細情報についても、食べログから取得できる情報を基本データとします。食べログに記載されていない項目については、別サイトから無理に補完せず、空欄として確定します。大阪府のように公式サイト・公式SNSが存在しない店舗が多い地域では、「公式情報で全件補完する」方式を標準フローにしません。
STEP 1 全店舗マスター作成	この段階では WPVibeを使用しません。まず店舗詳細ページを開かず、対象都道府県の食べログ「立ち飲み」検索結果ページから、掲載店舗を上から順番に取得します。大阪府の場合は約1,500件規模であり、 1ページ約20店舗として約76ページを処理する想定です。このSTEPで最低限取得する項目は以下とします。掲載順店舗名食べログ店舗URL Tabelog ID 検索結果ページ番号検索結果一覧上で取得できる場合は、以下も同時に保存します。最寄駅ジャンル評価口コミ件数予算最終成果物は、都道府県別の全店舗マスターCSV とします。例： osaka_tabelog_master.csv
STEP 2 PC取得環境で一覧取得	大量ページ取得は、 PC上のPython＋Playwright を基本とします。 ChatGPTの通常Web取得・Deep Research・Workモードは、 1,000件以上を連続取得する主処理として使用しません。処理イメージは以下です。食べログ検索結果1ページ目 ↓ 店舗情報取得 ↓ CSV保存 ↓ 待機 ↓ 次ページ ↓ CSV追記 ↓ 最終ページまで繰り返す各ページ処理後にデータを保存し、最終ページまで一度に保持しない設計とします。
STEP 3 マスター件数確認	STEP 1〜2で取得した全店舗マスターについて、掲載件数とCSV行数が一致しているかを確認します。大阪府の場合は、食べログ検索結果に表示された母集団件数を基準とし、その件数分の店舗名・URL・Tabelog IDが存在することを確認します。この段階では、閉店判定・長期休業判定・重複除外を行いません。食べログの母集団に含まれている店舗は、原則そのままマスターへ保持します。同一ブランドの支店違いも、食べログ上で別店舗として掲載されていれば別レコードとして保持します。
STEP 4 店舗詳細情報取得	STEP 1で確保した全店舗URLを使用し、初めて各店舗の食べログ詳細ページを順番に開きます。この段階でも WPVibeは使用しません。基本取得項目は以下とします。掲載順 Tabelog ID 店舗名食べログURL 郵便番号住所電話番号営業時間定休日予算支払方法最寄駅予約可否席数喫煙情報オープン日ジャンル食べログ評価口コミ件数食べログに記載がない項目は、推測せず空欄とします。公式サイト・Instagram・X・LINE・Facebook等を、全件について追加探索することは標準フローにしません。
STEP 5 途中保存・再開管理	1,000件以上の処理は、途中停止することを前提とします。 1店舗処理するごと、または小さなまとまりごとにCSVへ保存します。「30店舗ずつ」はシステム上限ではなく、管理しやすくするための単なる区切りです。 CSVには以下の管理列を追加します。取得状態取得日時エラー内容再取得要否取得状態の例：取得済み未取得取得失敗アクセス停止例として536店舗まで取得した場合は、 1〜536：取得済み 537以降：未取得として保存し、次回は537番から再開します。毎回1番から再取得しません。
STEP 6 アクセス制限時の処理	大量アクセスによる取得失敗を避けるため、ページ取得の間に待機時間を設定します。処理イメージ： 1ページ取得 ↓ CSV保存 ↓ 数秒待機 ↓ 次ページ CAPTCHA、アクセス拒否、異常レスポンス等が表示された場合は、回避処理を行わず停止します。停止位置をCSVへ保存し、次回再開位置を明確にします。アクセス制限を回避するための突破・迂回・偽装等は行いません。
STEP 7 住所・位置情報確定	緯度・経度は、食べログ詳細ページから収集する基本項目に含めません。正確な住所を取得した後、 WordPress投入前の別工程で、住所から緯度・経度を自動生成します。基本フロー：正確な住所取得 ↓ 住所正規化 ↓ ジオコーディング ↓ 緯度・経度生成 ↓ 取得失敗店舗のみ個別確認これにより、調査時に座標まで1件ずつ探す作業を廃止します。
STEP 8 既存・新規判定	店舗データ取得完了後、 tachi-nomi.com上の既存店舗と照合します。この段階でも WPVibeは使用しません。 WordPress上ですでに登録済みの店舗は更新対象、未登録店舗は新規登録対象とします。既存店舗については、可能な範囲で WordPress投稿ID を管理します。食べログ内の重複チェックをするためではなく、 tachi-nomi.comへの二重登録を防止するための照合とします。
STEP 9 代表写真処理	写真処理は、店舗基本データ取得と別工程とします。店舗データ取得を写真待ちで停止させません。代表写真候補を確保できる店舗は、店舗名・支店名・住所が一致していることを確認します。画像URLが不安定、外部取得不可、店舗一致を確認できない場合は、無理に画像を採用せず NO PHOTO とします。 CAPTCHAやアクセス制限を回避して画像を取得しません。
STEP 10 投入前マスター完成	WordPressへ投入する前に、対象都道府県の投入前マスターを完成させます。最低限、以下を管理します。掲載順 Tabelog ID 店舗名食べログURL 郵便番号住所電話番号営業時間定休日予算支払方法最寄駅予約可否席数喫煙情報オープン日ジャンル評価口コミ件数新規／更新判定 WordPress投稿ID（既存の場合）都道府県都道府県タームID 緯度経度代表写真あり／NO PHOTO 代表写真URLまたは画像ファイル取得状態公開情報から確認できない項目は、空欄として確定します。「あとで確認」「調査中」のまま大量に残さないことを原則とします。
STEP 11 投入データ固定・実行前報告	投入前マスター完成後、 WordPressの実際のフィールド名へ変換し、最終投入データを作成します。この時点でも WPVibeはまだ使用しません。以下を1つの投入データとしてまとめます。新規登録既存更新店舗情報住所都道府県ターム緯度経度営業時間定休日写真情報 NO PHOTO情報この時点で投入データを固定します。 ChatGPTは以下の形式で報告し、作業を停止します。「大阪 ○件データ完成」食べログ母集団：○件マスター取得：○件詳細取得完了：○件詳細取得失敗：○件新規登録：○件既存更新：○件代表写真あり：○件 NO PHOTO：○件緯度経度完成：○件／○件エリア設定：大阪空欄確定項目：○件予定WPVibe使用回数：○回エラー発生時：再実行せず停止実行してよいですか？
STEP 12 ユーザー最終確認・WPVibe実行	ユーザーが最終サマリーを確認し、明確に「実行」と指示した場合のみWPVibeを使用します。原則として可能な限り少ない呼び出し回数で、店舗新規登録・既存更新 ↓ 店舗情報反映 ↓ 都道府県設定 ↓ 緯度経度反映 ↓ 営業時間・定休日反映 ↓ 写真保存 ↓ メディアID取得 ↓ 店舗投稿へ紐付け ↓ アイキャッチ設定までを一括処理します。 1店舗ごとにWPVibeを呼び出す運用は行いません。
WPVibe使用ルール	以下の作業ではWPVibeを使用しません。・食べログ掲載件数確認・検索結果ページ取得・全店舗マスター作成・店舗詳細取得・CSV保存・取得状態管理・住所整理・緯度経度生成・既存／新規判定・写真候補確認・投入前マスター作成・投入データ作成・投入前チェック・最終サマリー作成 WPVibeは、完成済みデータをWordPressへ本番反映するときだけ使用します。
Deep Research・Work使用ルール	大量店舗取得では、 Deep Research・Workモードを主処理として使用しません。使用する場合は、以下のような限定用途とします。・取得方式の検討・数店舗の特殊ケース確認・取得エラー原因の確認・データ構造の調査 1,000件以上の個別店舗ページ巡回は、 PC上のPython＋Playwright＋CSV保存を標準方式とします。
エラー発生時の絶対ルール	取得処理またはWPVibe実行中にエラーが発生した場合は、その時点の状態を保存して停止します。 ChatGPTの判断だけで、以下を行いません。・アクセス制限回避を試みる・CAPTCHAを迂回する・同じWPVibe処理を再実行する・確認目的でWPVibeを追加使用する・SQLで直接WordPressを書き換える・別APIで勝手に続行するエラー発生時は、エラー内容最終取得済み番号未取得件数影響店舗数次回再開番号次に必要な処理を報告します。
WPVibe使用回数管理	WPVibe実行前に、予定使用回数を必ず報告します。ユーザーが許可した回数を超えて、 ChatGPTの判断だけで追加使用しません。追加処理が必要な場合は、改めてユーザーの許可を受けます。

大阪府の実務フロー Vol.2

大阪府については、以下の順序を標準とします。

食べログ「大阪府 × 立ち飲み」の母集団件数確認
↓
検索結果ページから全店舗マスター作成
↓
店舗名・URL・Tabelog IDを全件確保
↓
マスター件数確認
↓
PC上で各店舗詳細を順番に取得
↓
取得するたびCSV保存
↓
途中停止時は次回番号を記録
↓
未取得位置から再開
↓
住所から緯度経度生成
↓
WordPress既存／新規判定
↓
写真あり／NO PHOTO整理
↓
投入前マスター完成
↓
WordPress投入データ固定
↓
最終サマリー報告
↓
ユーザーがGO／STOPを判断
↓
「実行」の指示
↓
WPVibe一括反映
↓
結果報告
↓
作業停止

PC取得プログラム標準仕様

実行環境	Windows PC ＋ Python ＋ Playwright Chrome系ブラウザを自動操作し、食べログ検索結果・店舗詳細を順番に取得します。
保存形式	CSVを基本とします。 osaka_tabelog_master.csv osaka_tabelog_complete.csv
保存タイミング	各店舗処理後、または少数店舗ごとに保存します。全件完了までメモリ上だけで保持しません。
再開方式	取得状態を確認し、最初の未取得レコードから自動再開します。
停止条件	CAPTCHA アクセス拒否異常レスポンス連続取得エラーページ構造の大幅変更を検出した場合は停止します。
禁止事項	アクセス制限回避 CAPTCHA迂回偽装による突破無限リトライは行いません。

京都・大阪作業から得た最重要事項

京都で最も非効率だったのは、データが完成していない状態でWPVibeを使用し、店舗情報・写真・エリア・位置情報等をWordPress上で確認・修正しながら進めたことです。

大阪で新たに判明した問題は、約1,500件規模の店舗をChatGPT側で1店舗ずつ詳細調査すると、 Deep ResearchやWeb取得枠を大きく消費し、全件取得前に処理上限へ達する可能性が高いことです。

今後は、 「ChatGPT自身が何千ページも巡回する」 のではなく、 「ChatGPTが取得プログラム・CSV・WordPress投入工程を設計・管理する」 方式へ変更します。

必ず、「全店舗マスター確保 → 詳細取得 → 逐次保存 → 位置情報生成 → 既存／新規判定 → 写真整理 → 投入前マスター → データ固定 → 最終サマリー → ユーザー許可 → WPVibe一括反映 → 結果報告」の順序で進めます。

最終原則

先に全店舗の名簿を確保する。
1店舗目から全項目を深掘りしない。

大量取得はPCで行う。
ChatGPTのWeb取得枠を大量消費しない。

途中保存を前提とする。
停止しても続きから再開できる状態を維持する。

緯度・経度は住所から生成する。
調査時に1件ずつ探さない。

データを完成させてからWordPressを触る。
WordPressを触りながらデータを完成させない。

調査時のWPVibe使用は0回を原則とし、完成後の一括反映に必要な最小回数のみ使用する。

コピペ用 STEP1〜8 指示文 Vol.2

大阪以降は、以下の指示文をSTEP1から順番に使用します。対象都道府県が変わる場合は、「大阪府」「大阪」の部分を対象地域へ変更します。 STEP1〜8の間は、明示的な許可がない限りWPVibeを使用しません。

STEP 1 全店舗マスター取得	大阪府の立ち飲み店舗データ構築 Vol.2 を開始する。この段階ではWPVibeを絶対に使用しない。 Deep Research・Workモードを大量取得には使用しない。食べログ「大阪府 × 立ち飲み」の検索結果に掲載されている店舗を母集団とする。まず個別店舗ページを開かず、検索結果ページから全店舗について以下を取得する。掲載順店舗名食べログ店舗URL Tabelog ID 検索結果ページ番号検索一覧上で取得できる場合は、最寄駅ジャンル評価口コミ件数予算も取得する。食べログ掲載店舗について、この段階では閉店・休業・重複除外を行わない。全店舗マスターCSVを作成する。終了時に、・食べログ母集団件数・マスター取得件数・未取得件数・最終取得ページを報告して停止する。
STEP 2 マスター件数確認	STEP1で作成した大阪府の全店舗マスターを確認する。 WPVibeは絶対に使用しない。食べログ検索結果の母集団件数と、 CSV内の店舗レコード数を照合する。各レコードについて最低限、掲載順店舗名食べログURL Tabelog ID が存在することを確認する。このSTEPでは閉店・休業・重複判定を行わない。件数不足がある場合は、不足ページ・不足掲載順を特定する。終了時に、・母集団件数・マスター完成件数・不足件数・不足範囲を報告して停止する。
STEP 3 店舗詳細取得	完成した大阪府マスターの店舗URLを使って、店舗詳細情報を順番に取得する。この段階でもWPVibeを絶対に使用しない。大量取得はPC上のPython＋Playwrightを基本とする。 ChatGPTのDeep Research・Workモードで1,000件以上を個別巡回しない。各店舗について食べログから以下を取得する。掲載順 Tabelog ID 店舗名食べログURL 郵便番号住所電話番号営業時間定休日予算支払方法最寄駅予約可否席数喫煙情報オープン日ジャンル評価口コミ件数食べログにない項目は推測せず空欄とする。緯度・経度はこのSTEPでは取得しない。取得後はCSVへ逐次保存する。終了時または停止時に、・詳細取得完了件数・未取得件数・取得失敗件数・最終取得済み番号・次回再開番号を報告する。
STEP 4 住所・緯度経度生成	詳細取得済みの大阪府店舗について、住所を整理し、緯度経度を生成する。この段階でもWPVibeを絶対に使用しない。緯度・経度は食べログから探さず、取得済みの正確な住所からジオコーディングして生成する。処理順は、住所正規化 ↓ ジオコーディング ↓ 緯度経度保存 ↓ 取得失敗店舗のみ個別確認とする。終了時に、・対象件数・緯度経度生成成功件数・生成失敗件数・個別確認必要件数を報告して停止する。
STEP 5 既存・新規判定	データ取得済みの大阪府店舗について、tachi-nomi.com上の既存店舗と新規店舗を分類する。この段階でもWPVibeを絶対に使用しない。 WordPress上ですでに登録済みの店舗は「更新対象」、未登録の店舗は「新規登録対象」とする。既存店舗については、可能な範囲でWordPress投稿IDも特定する。この照合は食べログ内の重複判定ではなく、 tachi-nomi.comへの二重登録を防ぐために行う。終了時に、・新規登録予定件数・既存更新予定件数・投稿ID特定件数・判定保留件数を報告して停止する。
STEP 6 代表写真整理	大阪府の投入対象店舗について、代表写真情報を整理する。この段階でもWPVibeを絶対に使用しない。写真処理は店舗基本データ取得と分離する。店舗名・支店名・住所が一致する写真候補のみ採用する。画像取得が不安定、外部取得不可、店舗一致が確認できない場合は、無理に採用せず「NO PHOTO」とする。アクセス制限やCAPTCHAを回避して画像を取得しない。終了時に、・代表写真あり件数・NO PHOTO件数・写真判定保留件数を報告して停止する。
STEP 7 投入前マスター完成	大阪府のWordPress投入前マスターを完成させる。この段階でもWPVibeを絶対に使用しない。全店舗について最低限、以下を確定する。掲載順 Tabelog ID 店舗名食べログURL 郵便番号住所電話番号営業時間定休日予算支払方法最寄駅予約可否席数喫煙情報オープン日ジャンル評価口コミ件数新規／更新判定既存店舗の投稿ID 大阪エリア大阪エリアID 緯度経度代表写真あり／NO PHOTO 代表写真URLまたは投入用画像ファイル取得状態取得できない項目は推測で埋めず、空欄として確定する。終了時に、・総投入対象件数・新規件数・更新件数・写真あり件数・NO PHOTO件数・緯度経度完成件数・空欄確定項目数を報告して停止する。
STEP 8 最終投入データ固定・実行前報告	大阪府のWordPress最終投入データを完成・固定する。この段階ではまだWPVibeを絶対に使用しない。投入前マスターをWordPressの実際のフィールド名へ変換し、以下を1つの一括投入データとしてまとめる。新規登録既存更新店舗情報住所大阪エリア緯度経度営業時間定休日写真情報 NO PHOTO情報既存店舗については更新対象の投稿IDを確定する。この時点で投入データを固定し、勝手に追加調査や変更を行わない。最後に以下を報告して停止する。「大阪 ○件データ完成」食べログ母集団：○件マスター取得：○件詳細取得完了：○件詳細取得失敗：○件新規登録：○件既存更新：○件代表写真あり：○件 NO PHOTO：○件緯度経度完成：○件／○件エリア設定：大阪空欄確定項目：○件予定WPVibe使用回数：○回エラー発生時：再実行せず停止最後に必ず、「実行してよいですか？」と確認して止まる。ユーザーから明確に「実行」と言われるまでWPVibeを使用しない。