System Concept ・ Owner Report Web

オーナー報告Webシステム

BookingDBのライブ数値と施設の正本から、施設別オーナーレポートを毎回生成する読み取りビュー。
SoT → 共通データ層 → ビルダ → 多階層サイト → capability-URL 配信 までの全体像。

TATEYAMA PILOT ・ 生成 2026-06-02

この一枚で見えること

① 全体フロー

手で直すのは左の SoT だけ。数値は同期DBから毎回ライブ算出され、ビルダが4ページの自己完結HTMLを生成し、capability-URLで配信される。

flowchart TB subgraph SOT["① SoT ・ 手で直す一次情報"] direction LR DB[("BookingDB 同期DB
GSheet ライブ数値")] FM["facility.md
施設の事実"] OE["Owner & Events
予定(未連携)"] AS["assets/
実写真"] end subgraph DL["② 共通データ層"] LB["booking_data
load_bookings()
テスト除外・会員判定"] end subgraph BLD["③ ビルダ owner_report/"] DATA["data.py 集計・指標"] FMD["facility_md.py"] CH["charts.py SVG"] RN["render.py 多階層HTML"] BU["build.py CLI/配信"] end subgraph OUT["④ 生成物 ・ 多階層サイト"] IDX["index ハブ"] MON["month 月次"] BOO["bookings 予約一覧"] FAC["facility 施設情報"] end CF["⑤ Cloudflare Pages
capability-URL ・ noindex"] OW(["オーナー
タップで常時最新"]) SYNC["毎日19時 booking-sync"] DB --> LB --> DATA FM --> FMD OE --> FMD --> DATA AS --> BU DATA --> RN CH --> RN --> BU BU --> IDX & MON & BOO & FAC IDX & MON & BOO & FAC --> CF --> OW SYNC -.->|build.py --all --deploy| BU classDef sot fill:#1A1A18,color:#C8A870,stroke:#C8A870; classDef out fill:#C8A870,color:#0A0A0A,stroke:#A8863F; classDef gap fill:#5A4A28,color:#F0EDE8,stroke:#C8A870,stroke-dasharray:4 3; class DB,FM,AS sot; class IDX,MON,BOO,FAC,CF,OW out; class OE gap;
↑ TOP

② 5つの層

① SoT — 手で直す一次情報 編集する唯一の場所

  • BookingDB「同期DB」(GSheet)— 予約・稼働・売上の唯一の数値ソース。AirHost→CSV→同期
  • facility.md — 施設の事実(名称・スペック・特徴)。facilities/{slug}/_sot/
  • ## Owner & Events — オーナー滞在・工事の予定(現在サンプル=未連携
  • assets/ — 実写真(cover・gallery)

② 共通データ層 分析の正本

  • scripts/occupancy/booking_data.pyload_bookings()
  • テスト予約除外(テスト/森下/stg)・会員判定・クリーニングを一手に。全分析がここを通る

③ ビルダ scripts/owner_report/

  • data.py — 稼働/受取/ADR/RevPAR/前年比/推移/流入(会員OTA直接)/キャンセル率/リードタイム/カレンダー/タイムライン
  • charts.py — inline SVG(二軸推移・積み上げ・ドーナツ・年間ヒートマップ)
  • render.py — 共有CSS+共通シェルで多階層HTML
  • build.py — CLI・トークン発行・画像複製・--all一括・--deploy

④ 生成物 self-contained 多階層サイト

  • index.html — ハブ(今月KPI/ハイライト/カレンダー/予定/推移/流入/内訳/傾向/見どころ/リンク)
  • month.html — 月次明細+ヒートマップ / bookings.html — 予約一覧(ソート/フィルタ) / facility.html — 施設情報

⑤ 配信 Cloudflare Pages

  • yamato-owner-reports.pages.dev/<token>/ — 推測不能トークンをパスに埋込(=鍵)・noindex
  • オーナーはURLをタップするだけで常時最新を閲覧
↑ TOP

③ SoT原則 — 読み取りビュー

数値は Markdownに焼き込まない。レポートHTMLは BookingDB+facility.md から 毎回ライブ算出する読み取りビュー
だから「いつ開いても最新」で、二重管理が起きない。手で直すのはSoTだけ、HTMLは常に派生物。

↑ TOP

④ 残された未連携 — 予定の入力

予約・稼働・売上・内訳・傾向はすべてライブ連携済み。唯一ライブでないのが「施設の予定」(オーナー滞在・工事)

To wire

facility.md の ## Owner & Events が予定の唯一の入力元。現在はサンプル3件。
ここに Slack → Claude → facility.md 更新 の経路を通せば、カレンダーとタイムラインに実予定が反映され、システムは「完全ライブ」になる。

↑ TOP

⑤ 横展開 — 施設を足すだけ

パイプラインは施設非依存。新施設は data.SLUG_REGISTRY に物件名を1行、build.ASSET_SETS に写真を足すだけ。build.py --all --deploy が全施設を一括生成・配信する。

Next facilities

京都(The 禅 SPA Kyoto Suite)・渋谷(The SAUNA Escape Shibuya)等。facility.md と写真が揃えば即ページ化。

↑ TOP

⑥ ファイルマップ

取得・正本
scripts/occupancy/booking_data.py — 共通データ層(テスト除外・会員判定)
集計
scripts/owner_report/data.py — 全指標・トレンド・カレンダー・予約一覧
事実読取
scripts/owner_report/facility_md.py — facility.md+Owner&Events
作図
scripts/owner_report/charts.py — inline SVG 各種
組版
scripts/owner_report/render.py — 共有CSS+4ページ
CLI・配信
scripts/owner_report/build.py--facility / --all / --deploy / --audit
SoT(事実)
facilities/{slug}/_sot/facility.mdassets/
生成物
facilities/{slug}/outputs/owner/*.html
配信先
output/deploy/owner_reports/<token>/ → Cloudflare Pages
↑ TOP

⑦ ここから策を練る

土台は固まった。次の打ち手の候補(この図を見ながら選ぶ)。

↑ TOP