「Claude が管理者」の解釈は2通りあって、どちらに振るかで実装が大きく変わる：
新セッションの最初の問い：Otakeさんに「Slackは A 型／B 型／ハイブリッド（自動はA、Otake指示時のみB）」を確認すること。
| サイト | URL | ソース | デプロイ手段 |
|---|---|---|---|
| yamato-club（会員ハブ） | yamato-club.pages.dev | output/deploy/yamato_club/ | wrangler個別 |
| 施設ガイド × 11施設 | yamato-{slug}-guide.pages.dev | output/guides/_deploy/{slug}/（晴海のみ別系統） | wrangler個別 |
| yamato-admin（内部） | yamato-admin.pages.dev | PostToolUseフックで自動生成 | 同上 |
| その他（personal-docs等） | 各*.pages.dev / *.netlify.app | 各種 | Cloudflare / Netlify |
11施設の一覧と詳細は scripts/build_member_guides.py の FACILITIES dict が事実上の SoT。哲学は design_refs/member_guide_photos.md。デプロイ先一覧は DEPLOY_TARGETS.md。
構成: Slack Events API → Cloudflare Worker (薄い受け口) → Otakeさんのローカル/サーバ上の Claude Code CLI を headless モードで起動 → 結果を Slack スレッドへ返信
◎ Claude Codeの全ツール・スキル・MEMORYがそのまま使える
◎ ローカル開発環境と同等のコンテキスト
× 起動先がOtake PC依存だと、Otakeのマシンが起動していないと動かない
× サーバ常駐ならVPS/Cloud Run等の運用コスト発生
構成: Slack Events API → Worker → Claude Agent SDK 経由でAPI呼び出し → bash/file_edit/computer toolsで作業 → gitリポにcommit/push → CIがCloudflareへデプロイ
◎ クラウドネイティブで24/7稼働
◎ 認証・履歴・並列実行が整理しやすい
× Claude Code の MEMORY/skills を再現するため初期セットアップ大
× サイトソースを Git 化して CI に乗せる前提（現状は output/ にローカル生成）
構成: Anthropic 側の Remote Agent サービスを Slack に紐付け、リモートでブラウザ操作・ファイル操作させる
◎ 運用コスト最小
× 出たばかりのサービス、機能・料金・制限が流動的（もしかしたら2026年中に大幅に進化する可能性。新セッションで最新調査）
× ローカルファイル（G:ドライブ・H:ドライブ・素材フォルダ）に直接アクセスできないので、すべて GDrive API 経由になり遅い
構成: 既存の Claude Code scheduled-tasks 機能で「Slack #yamato-管理 を5分おきに見て、未処理メンションを処理」のループを回す
◎ 既存インフラ流用、新規サーバ不要
◎ プロトタイプとして最速
× レイテンシ5分。即時返答にならない
× ポーリングは Slack API ベストプラクティスから外れる（イベント駆動の方が良い）
#yamato-管理 一本 / 施設別 / プロジェクト別 / DM「Slack bot」と決め打つ前に、これらの選択肢も俎上に乗せた上で Slack を選ぶのが健全：
Slackが第一の理由（推察）: 運営チームが既に使っている／スレッド・絵文字で状態管理が楽／添付ファイル（差替画像など）を直接渡せる。これらが本当に効いてくるかを新セッションで確認すべき。
1. Slack App を作成 (bot user + Events API + chat:write/files:read 権限) 2. プライベートチャンネル #yamato-管理 を作って bot を招待 3. Cloudflare Worker （or 既存 yamato-admin の Functions）で Slack Events 受信 4. 受信メッセージを Notion DB「Slack依頼キュー」に append 5. Claude Code 側で scheduled-task：5分おきに DB をポーリング - status="新規" の行を取得 - 内容を解釈 → 該当サイト編集 → 再ビルド → 再デプロイ - 完了したら Slack スレッドへ返信＋ DB 行を status="完了" 6. 失敗時は status="要対応" + Otake さんにメンション
この最小構成で1〜2週間運用してから、案①/②へ移行するかを決める。
| 種類 | パス／URL | 用途 |
|---|---|---|
| SoT（施設定義） | scripts/build_member_guides.py FACILITIES dict | 11施設の全フィールド・theme・photo_picks |
| 写真選定哲学 | design_refs/member_guide_photos.md | 5スロット・ステータス4段階・棚卸し手順 |
| デプロイ先マップ | DEPLOY_TARGETS.md | Cloudflare/Netlify使い分け |
| Notion参照マップ | NOTION_MAP.md | 各プロジェクト・施設のNotion ID |
| memory ルール | memory/feedback_* | wrangler非ループ／写真選定全件スキャン／デプロイ無確認 等 |
| 既存scheduled-tasks | scheduled-tasks MCP / CronCreate | 案④の土台に使える |
| 既存LINEエージェント | project_line_ai_agent | 類似アーキテクチャの先例（v4.1稼働中） |
| 既存PostToolUse hook | yamato-admin 自動更新 | 「ファイル編集→外部反映」パターンの先例 |
| 前回ハンドオフ | 2026-05-24-new5guides.html | 新5施設構築の流れ |
design_refs/member_guide_photos.md）に沿って差し替え、output/guides/_deploy/{karuizawa_core1,kawaguchiko}/ までリサイズ済みwrangler pages deploy の2施設分（+ yamato-club のヒーローサムネ差替＆再デプロイ）scripts/build_member_guides.py FACILITIES dict（11施設）と design_refs/member_guide_photos.md を Read（管理対象の現状把握）