🏨 紀伊乃国屋 Threads運用 — 最終理想フロー

1. リサーチ & 分析 — FMT × Why × How で仮説化 👤 人間

   伸びている投稿を収集し、FMT(どんな型・フォーマットか)・Why(なぜ伸びたか)・How(どうやったらもっと伸ばせるか)の3軸で分解して仮説を立てる。生データではなく仮説の形でストックしていく。

2. リサーチ内容レビュー 🔜 未実装

   Fableが仮説をレビュー — FMTの切り出しは妥当か、Whyは根拠と飛躍がないか、Howは検証可能な打ち手になっているか、既存仮説との重複はないか。誤情報チェックWorkerにレビュー用の口を増設する想定。

3. fix 👤 人間

   レビュー指摘を反映して確定版にする。

4. fix版の仮説をストック 🔜 未実装

   確定した仮説を投稿生成の材料として貯める。量が膨大になるためSupabase一択。仮説単位のレコード(FMT / Why / How / 根拠事例 / 検証状態)で持ち、投稿の実績数値で後から仮説を検証・更新できる形にする。

   🗄️ Supabase — 仮説ストックテーブル(新設・FMT×Why×How単位)

1. 投稿内容作成 🔧 部品あり 📣 作成開始を通知

   Fableが蓄積リサーチ+briefs(施設事実)を材料に台本を生成。開始した時点でDiscordに知らせる。生成部隊の型とWebhook5本は既存、配線が未。

2. 完了報告 🔧 部品あり 📣 完了を通知

   できあがった台本をDiscordに報告(Webhookは既存、配線のみ)。

1. 投稿内容確認 👤 人間

   担当者が台本を読み、トンマナ・企画意図を確認する。

2. 台本修正 👤 人間

   修正した文面を投稿確認スプシの自分のアカウントタブ(✍️)に貼る。

   📋 スプシ「紀伊乃国屋投稿確認」— ✍️アカウント別タブ ✅

1. 誤情報チェック ✅ 稼働済

   Discordから起動: /checksheet(✍️タブ一括)・/check(単発)・右クリックメニュー。事実ベース=Supabase briefs+facts、公式サイト12施設の毎朝巡回と突合。fail-closedで⚠️要確認も止める。メンション起動にしたい場合は常駐化の設計判断が必要。

2. 完了通知 ✅ 稼働済 📣 結果サマリー

   ✅/⚠️/🚫の内訳をDiscordに返信。指摘の詳細はスプシの「指摘内容」列に書き戻し。

3. 確認 → 修正 👤 人間

   🚫・⚠️の指摘を反映して文面を直す。

↩ 修正したら再チェック — ✅が出るまでこのフェーズを繰り返す(誤情報ゼロが絶対条件)

1. Threadsへ投稿 🔧 手動 → 将来AUTOPOST

   当面は担当者が本人アカウントで手動投稿。トークン登録が進んだらAUTOPOSTを段階ON(配線済み・既定OFF)。