MENU

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

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

京都エリアでの実運用、大阪府1,200店舗の大規模取得・一括登録・曜日別営業時間化・紹介文生成・写真取得までの実績をもとに、 全国の立ち飲み店舗データを効率よく構築するための標準作業手順を以下のとおり定めます。

Vol.3では、Vol.2の「全店舗マスター確保 → PC取得 → CSV保存」という基本方針を維持しつつ、 大阪府で実際に成功した 「曜日別営業時間構造化 → REST API一括登録 → 紹介文一括生成 → 食べログ画像URL一括取得 → 写真分割投入」 を正式な標準フローとして追加します。

最重要原則 地域ごとに別ロジックを作らない。

京都・大阪・今後の全国すべてで、 同じデータ構造・同じ営業時間判定・同じWordPress投入方式 を使用します。

標準フローは以下です。

全店舗マスター確保
↓
PC上で詳細取得
↓
CSV逐次保存
↓
曜日別営業時間へ構造化
↓
WordPress投入用JSON作成
↓
REST APIで一括登録
↓
紹介文一括生成
↓
写真URL一括取得
↓
写真を分割投入
↓
不足分のみ後追い補完
WordPress反映方式 Vol.3では大量登録の標準方式として、 WordPress REST API + PowerShell を使用します。

エンドポイント：
POST /wp-json/tn/v1/bulk-upsert

WPVibeはこの大量投入フローでは使用しません。
調査・登録・更新・写真投入は、完成済みJSONをREST APIへ送信する方式を基本とします。
基本データソース 都道府県ごとの食べログ「立ち飲み」検索結果を母集団とします。

基本情報・詳細情報は、 食べログから取得できる情報を基本データ とします。

食べログにない情報を、別サイトで全件補完することは標準フローにしません。
取得できない項目は空欄として確定します。
STEP 1
全店舗マスター作成		 対象都道府県の食べログ検索結果から、まず全店舗の名簿を作成します。

最低限取得する項目：

掲載順
店舗名
食べログURL
Tabelog ID
検索結果ページ番号

一覧上で取得できる場合は、最寄駅・ジャンル・評価・口コミ件数・予算も保存します。
STEP 2
PC上で詳細取得		 大量取得はPC上の自動取得処理を基本とします。

1店舗ずつ取得し、取得後は逐次CSVへ保存します。

基本取得項目：

店舗名
住所
電話番号
営業時間
定休日
予算
支払方法
最寄駅
予約可否
席数
喫煙情報
オープン日
確認元URL
STEP 3
途中保存・再開		 1,000件以上の処理は、 途中停止することを前提 とします。

CSVへ以下の管理情報を保存します。

取得状態
取得日時
エラー内容
再取得要否

次回は最初の未取得レコードから再開し、毎回1番から再取得しません。
STEP 4
曜日別営業時間へ構造化		 Vol.3で最重要となる追加工程です。

business_hours の文章だけでは「現在営業中／営業時間外」の正確な判定ができないため、必ず曜日別 hours を作成します。

例：
"hours": {
  "monday": "16:00-05:00",
  "tuesday": "16:00-05:00",
  "wednesday": "16:00-05:00",
  "thursday": "16:00-05:00",
  "friday": "16:00-05:00",
  "saturday": "16:00-05:00",
  "sunday": "16:00-05:00"
}

定休日は該当曜日へ 「定休日」 を設定します。

曜日指定がなく共通営業時間のみ判明している場合は、京都方式と同様に全曜日へ共通営業時間を入れます。
不定休・情報不足・解析不能は無理に固定しません。
STEP 5
営業状態表示ルール		 shop_status と現在営業中判定を混同しません。

shop_status は店舗自体の営業継続状態として保持します。

一方、画面上の
営業中／営業時間外
および
「現在営業中」フィルター
は、曜日別営業時間をもとに tn_get_shop_current_status() で判定します。

京都・大阪・全国すべて同じ判定ロジックを使用します。
STEP 6
WordPress投入用JSON作成		 店舗情報をWordPressの実フィールドへ変換します。

主要項目：

title
address
postal_code
reservation_contact
nearest_station
walk_minutes
price_note
payment_methods
reservation_availability
seat_count
smoking
open_date
catchphrase
shop_status
business_hours
closed_days
source_url
source_name
hours
area_id / default_area_id
featured_image_url
STEP 7
一括登録		 PowerShellからREST APIへ送信します。

基本形：
$json = Get-Content "C:\tachi-nomi\地域フォルダ\FILE.json" -Raw -Encoding UTF8

Invoke-RestMethod `
  -Uri "https://tachi-nomi.com/wp-json/tn/v1/bulk-upsert" `
  -Method POST `
  -Headers $headers `
  -ContentType "application/json; charset=utf-8" `
  -Body $json

大阪府では100件単位で新規登録し、 1,200件を正常投入 できました。
STEP 8
紹介文一括生成		 紹介文は外部サイト本文をコピーせず、 既存の事実データからオリジナル生成 します。

使用する情報：

最寄駅
予算
予約可否
席数
営業時間
支払方法
喫煙情報

生成後は catchphrase へ保存します。

大阪府では1,200件を生成し、 400件 × 3ファイル に分けて更新しました。
STEP 9
紹介文の品質ルール		 同一テンプレートを全店舗へ繰り返さないようにします。

書き出し・語順・使用する事実項目を複数パターンへ分散します。

ただし、大量生成では一定の類似性が残るため、 最初から完全な広告コピー品質を目指さず、 まず全店舗に事実ベースの紹介文を入れることを優先 します。
STEP 10
写真URL一括取得		 店舗写真は基本データ取得と分離して後工程で実施します。

大阪府では、各店舗の食べログURLから og:image / twitter:image を取得し、 featured_image_url としてJSONへ追加しました。

1,200店舗をPC上のPowerShellで自動処理し、 1,200件すべてについて画像URL取得処理を完了 しました。

公開利用にあたっては、必要に応じて画像の権利・利用条件を確認します。
STEP 11
写真投入		 写真投入は、通常データ更新より処理が重くなります。

理由：
外部画像取得
↓
WordPressメディア保存
↓
サムネイル生成
↓
アイキャッチ設定

400件一括ではサーバー側でタイムアウト表示が出る場合があります。

そのため、 写真投入の標準単位は200件 とします。

大阪では最初の400件がタイムアウト表示後も実処理され、 サイト上では約400件の写真登録が確認できました。
以後は200件単位で安定して投入しました。
STEP 12
タイムアウト時の判断		 タイムアウト表示が出ても、 即座に再送しません。

まずサイト上で実際の登録件数を確認します。

既に写真が入っている場合は、再送すると無駄な処理になるため、 実登録状況を確認してから再実行判断 します。

importerは、既にアイキャッチがある店舗について画像処理をスキップする仕様とします。
bulk-import.php 標準仕様 大阪実績をもとに以下を標準とします。

1回最大400店舗
set_time_limit(600)
catchphrase対応
walk_minutes対応
hours対応
featured_image_url対応
default_area_id対応

PHP内へ特殊空白（NBSP）が混入しないように注意します。
特殊空白は構文エラーの原因になります。
CoreServer PHP設定 大阪投入時に確認した設定：

max_execution_time = 600
max_input_time = 600
max_input_vars = 3000
memory_limit = 1024M
post_max_size = 512M
成功判定 REST API結果は以下を確認します。

100件新規：created 100 / updated 0 / failed 0 / total 100

100件更新：created 0 / updated 100 / failed 0 / total 100

200件更新：created 0 / updated 200 / failed 0 / total 200

400件更新：created 0 / updated 400 / failed 0 / total 400

failed = 0 を最優先で確認します。
エラー発生時の原則 エラー発生時は、同じ処理を無条件で繰り返しません。

確認する項目：

最終成功番号
未処理件数
実際のサイト反映件数
タイムアウトか処理失敗か
再実行が本当に必要か

CAPTCHA・アクセス拒否等の回避処理は行いません。

大阪府で確立した最速フロー

1,200店舗マスター取得
↓
詳細情報取得
↓
曜日別営業時間化
↓
100件単位で1,200件登録
↓
紹介文1,200件生成
↓
400件 × 3で紹介文更新
↓
食べログ画像URL1,200件自動取得
↓
写真は200件単位で更新
↓
不足写真・不足情報だけ後追い補完

全国展開の標準ルール

都道府県単位 都道府県ごとに tachinomi_area のタームIDを確認し、 default_area_id を設定します。
投入順序 データ完成前にWordPressへ入れず、 データ完成 → JSON固定 → 一括投入 の順序を守ります。
営業時間 business_hoursだけで終わらせず、 必ず曜日別hoursを作成 します。
紹介文 既存データから自動生成し、 400件単位 で更新します。
写真 PC上で画像URLを一括取得し、 WordPressへの写真投入は 200件単位 を標準とします。
最終補完 最初から100%完成を目指さず、 大量店舗を先に揃え、不足分だけ後追い補完 します。

コピペ用 全国展開指示文 Vol.3

次の都道府県からは以下を基本指示文として使用します。 

対象都道府県の立ち飲み店舗データ構築 Vol.3 を開始する。

大阪府1,200店舗で確立した方式に完全準拠する。

作業順序は以下。

1. 食べログ検索結果から全店舗マスター作成
2. PC上で店舗詳細情報を取得しCSVへ逐次保存
3. 住所・電話・営業時間・定休日・予算・支払方法・最寄駅・予約可否・席数・喫煙情報等を整理
4. 営業時間を曜日別hoursへ構造化
5. WordPress投入用JSON作成
6. REST API /wp-json/tn/v1/bulk-upsert へ一括投入
7. 既存事実データから紹介文を一括生成しcatchphraseへ反映
8. 食べログURLから代表写真URLを1枚ずつ自動取得
9. 写真付きデータは200件単位で更新
10. 不足写真・不足情報のみ最後に補完

地域別の独自ロジックを作らない。
京都・大阪と同じtn_get_shop_current_status()判定を使用する。
business_hoursだけでなく必ず曜日別hoursを持たせる。
WPVibeは使用しない。
エラー時は勝手に再実行せず、実反映状況を確認してから判断する。

終了時に、
・母集団件数
・マスター取得件数
・詳細取得完了件数
・曜日別営業時間完成件数
・WordPress反映件数
・紹介文反映件数
・写真URL取得件数
・写真反映件数
・不足写真件数
・エラー件数
を報告する。

最終原則

大阪方式を全国共通テンプレートとする。
都道府県ごとに作り方を変えない。

大量データはPCで取得・整形する。
WordPressには完成済みデータだけを投入する。

営業時間は必ず曜日別に構造化する。
「営業中／営業時間外」は全国共通ロジックで判定する。

紹介文は400件単位、写真は200件単位。
大量処理は分割して安定性を優先する。

まず全国の店舗母数を埋める。
不足情報・不足写真は後から補完する。