Slack駆動 サイト管理アーキテクチャ — 設計確定版

依頼受信時のフローチャート

受信
  ├─ 依頼者 == Otake?
  │   ├─ YES → アクション種別チェック
  │   │   ├─ 追加・差替 → 即実行
  │   │   └─ 削除・リネーム・構造変更 → スレッドで「実行していい？」確認
  │   │
  │   └─ NO（他メンバー）→ 私が内容を判定
  │       ├─ 明らかにOK（哲学・SoT・運営情報と整合）
  │       │   └─ アクション種別チェック
  │       │       ├─ 追加・差替 → 即実行
  │       │       └─ 削除・リネーム・構造変更 → Otakeへエスカレ
  │       ├─ 明らかにNG（哲学違反・施設情報の誤りなど）
  │       │   └─ 差戻し（理由つきで丁寧にスレッド返信）
  │       └─ 曖昧（判断つかない）
  │           └─ Otakeへ通知＋判断仰ぐ

判定材料: その場で関連する哲学MD・SoT・memory feedback だけを引く（重い全件Readはしない）。
例: 画像差替なら design_refs/member_guide_photos.md ＋ scripts/build_member_guides.py の該当施設エントリだけ。

ファイル

YAMATO_Slack依頼ログ.gsheet（My Drive直下／タイトル要相談）

列スキーマ

status 7値の遷移

新規        ← Worker が行追加した直後
  ↓
確認待ち    ← 他メンバー依頼で曖昧→Otake通知中／確認返し中
  ↓
承認済      ← Otake判断 or 確認返しに対する依頼者OK
  ↓
処理中      ← 私がファイル編集・ビルド・デプロイ実行中
  ↓
完了        ← Slackに完了報告済み

別系列：
差戻し      ← 明らかNGで差し戻したケース（理由は備考列）
要対応      ← 自己修復2回失敗 or 構造変更系で停止中

競合対策

scheduled-task は「status=新規 の行を取得 → 最初に status=処理中（or 確認待ち）に書き換え → 処理開始」の順で動かす。書き換えがアトミックなら二重処理を回避できる。

Slackスレッドへの完了報告は下記テンプレート。

✅ 完了しました

【変更要約】
館山ガイド > 到着の章 > メイン写真
旧: arrival_old.jpg
新: arrival_v2.jpg（添付いただいたもの）

【確認URL】
https://yamato-tateyama-guide.pages.dev/arrival/

【before / after】
（画像2枚をSlackに直接アップロード）

注: 文言修正など画像差分が成立しない依頼の場合は before/after を省略し、変更要約だけリッチに書く。

新規App名（案）

• YAMATO Site Manager / メンション表示は @yamato-site あたり
• アイコンは YAMATO ヘックスマーク（黒）を流用

必要スコープ（OAuth & Permissions → Bot Token Scopes）

Event Subscriptions

• Enable Events: ON
• Request URL: Cloudflare Workers のエンドポイント（P0で発行）
• Subscribe to bot events: app_mention（必須）, message.channels（スレッド内追加発言用・必要に応じて）, reaction_added（将来用）

インストール

• ヤマト本体ワークスペースへ Otakeさんが管理者権限でインストール
• プライベートチャンネル #yamato-site-管理 に bot を招待
• Bot Token を Otake から私に共有（.env に SLACK_SITE_BOT_TOKEN として追加。既存 SLACK_BOT_TOKEN は review_monitor 用なのでそのまま）

本日の前半

1. Slack App 作成（Otakeさん作業 / 私が manifest.json と手順メモ提供）
2. GSheet YAMATO_Slack依頼ログ.gsheet 作成（私が gspread で生成）
3. Cloudflare Worker 受け口の作成（pages-functions or 専用Worker）
4. scheduled-task 登録：ClaudeAuto_site_slack_poll（5分おき）
5. SCHEDULED_TASKS.md 更新

本日の中盤

1. Worker が Slack app_mention イベントを受信
2. イベントペイロードを GSheet に行追加（status=新規）
3. 「📥 受け付けました」をスレッドに即返信
4. 添付ファイルがあれば GDrive の作業フォルダにダウンロード保存し、パスを G列に記録

この時点でまだ実処理はしない。GSheetが正しく埋まり、Slack返信が出ることだけ確認する。

本日の後半〜数日運用

1. 私が GSheet を眺めて、status=新規 の行を手で処理（編集・ビルド・デプロイ）
2. 処理ごとに status を順次更新（処理中→完了）
3. 完了したら手動で Slack スレッドに完了報告（テンプレ通り）
4. 1週間ほど運用して「実際にどんな依頼が飛んでくるか」を観察

P2運用ログから「依頼の8割パターン」を抽出して、P3の自動化設計に活かす。

P2で得たパターンを元に

• 自然言語の依頼を解釈して該当ファイル特定する解析層を実装
• 画像差替・文言修正など定型パターンの自動化
• 哲学チェック層の組み込み
• 確認返し（曖昧時）の自動文生成

• before/afterサムネの自動生成
• 自己修復ロジック（リサイズ・パスtypo fallback等）
• 👍リアクションでの承認検知
• 権限テーブル拡張（Otake / 他メンバー以外への分岐）