悩みの正体は「HTML か スプレッドシートか」ではなく、「編集する場所」と「見る場所」を混ぜていたこと。この2つを分けると、散乱もリンクの不便も共同編集の不安も、同じ1枚の地図で解ける。
I.三層モデル — 編集と閲覧を分離する
真実（正本）は1つだけ。そこから見る画面を何枚でも生成する。
③ View — 見る場所（使い捨て可）
HTML / GSheet / Notion / PDF
脳内ネットワークのように広がる閲覧体験。誰も直接は編集しない。正本から毎回生成し直す。
▲ 生成される
② 翻訳層
Claude（私）
Slackや会話の自然言語を受け取り、正本に構造化して書き込む。人とデータの間の通訳。
▲ 書き込む
① SoT — 正本（ここだけが真実）SINGLE SOURCE OF TRUTH
Markdown（git） ＋ 一部 GSheet
滅多に変わらない施設マスター＝Markdown。刻々変わる価格・予約＝GSheet。性質で2分する。
→ 「HTMLは共同編集できない」は問題ですらない。HTMLは③の閲覧画面。編集は②経由で①に入る。
II.役割マトリクス — どこに何を置くか確定
散乱の正体は「ツールに役割が割り当たっていない」こと。固定すれば迷いが消える。
| ツール | 役割 | 位置 |
|---|
| Slack | 全員の「修正を投げる」唯一の窓口 | 編集入口 |
Markdown
(git) | 施設マスター。滅多に変わらない真実 | 正本 ◎ |
| GSheet | 価格・予約・稼働。刻々変わる数値 | 正本 ◎ |
| Obsidian | 日次・思考の書き殴り（書き手の場所） | 一次 |
| Notion | 案件の状態管理DB＋モバイルメモ捕獲 | 補助DB |
HTML
yamato-monitor | 社内が眺める俯瞰ビュー・施設ハブ | 閲覧 |
HTML
Cloudflare公開 | ゲスト向け利用案内・LP | 閲覧 |
| Google Drive | 写真・PDF原本の素材倉庫に降格 | 倉庫 |
Notionは「脱Notion方針」通り新規蓄積先にはしない。Driveは正本から外し、素材置き場に徹する。
III.共同編集問題の解 — Slackを唯一の書き込みAPIに
「私だけしか直せないと困る／誰かが気づいたらパッと直せる」唯一の本物の論点。
誰かがSlackに「館山のIN 15→16時」
→
Claudeが正本Markdownを直す
→
HTML再生成・再デプロイ
体裁の知識も編集権限もゼロで直せる。履歴はgitに残る。まず館山1施設・PC依存のまま実証し、効いたら将来クラウド実行（GitHub Actions等）に逃がして「あなたのPCが開いている時だけ」の弱点を外す。
IV.対ゲスト — 1つの正本から2つのビュー
社内SoTとゲスト向けは分離する（混ぜると機密が漏れ、表現も雑になる）。
SoT/facilities/tateyama.md（正本・全情報）
outputs/internal/
社内ハブHTML。運営の全情報・機密含む
outputs/guest/
ゲスト公開HTML。利用案内のみ・機密除外
ゲストの「メインページ」は施設ごとの公開HTML（Cloudflare）で確定。スプレッドシートより見やすいという直感は正しい。
V.移行フェーズ — 一気にやらない
全施設HTML化は手作業地獄になる。生成パイプラインで量産する。
- 館山で縦に貫通NEXT
tateyama.md を本物の正本に整え、社内HTML＋ゲストHTMLを自動生成するビルダを作る
- Slack修正を実証
Slack→Markdown修正→再生成 を館山1施設で通す（PC依存のまま）
- 11施設へ横展開
ビルダが量産。手作業では作らない
- クラウド実行化
余裕が出たらPC依存を外し、24時間誰の修正でも反映
本日の決定事項
正本Markdown（git）。価格・予約など刻々変わる数値だけGSheet（ハイブリッド）
修正経路まずSlack（PC依存のまま館山で実証 → 効けばクラウド化）
移行方針全施設一気にHTML化せず、生成パイプラインで量産
対ゲスト社内SoTと分離。1正本から internal / guest の2ビュー生成