Threads Media Fleet

🧵 Threads運用 全体フロー
— クライアントワーク / 自社・アフィリエイト

仮説化から投稿までの共通パイプラインと、マネタイズ形態による分岐(2026-07-30決定)。誤情報チェックはクライアントワークのみ必須、自社サービス・アフィリエイトでは省略する。

👤 人間の工程 ✅ 稼働済 🔧 部品あり・配線待ち 🔜 未実装 📣 Discord通知
共通 1

リサーチ & 仮説ストック

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

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

  2. 仮説レビュー 🔜 未実装

    Fableがレビュー — FMTの切り出しは妥当か、Whyに根拠の飛躍はないか、Howは検証可能な打ち手か、既存仮説と重複していないか。

  3. fix 👤 人間

    レビュー指摘を反映して仮説を確定させる。

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

    仮説単位のレコード(FMT / Why / How / 根拠事例 / 検証状態)で蓄積。量が膨大になるためSupabase。ここが全事業共通の資産になる。

    🗄️ Supabase — 仮説ストックテーブル(FMT×Why×How単位)
↓
共通 2

投稿内容の作成

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

    Fableが仮説ストック+事業ごとの事実情報(クライアントならbriefs)を材料に台本を生成。開始をDiscordに知らせる。

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

    できあがった台本をDiscordに報告。

↓
共通 3

人間の確認・修正

  1. 投稿内容確認 → 台本修正 👤 人間

    担当者が台本を読み、トンマナ・企画意図を確認して直す。クライアントワークでは修正版を投稿確認スプシの✍️タブに貼る。

↓
マネタイズ形態で分岐
🤝 クライアントワーク例: 紀伊乃国屋グループ(送客受託)
  1. 誤情報チェック ✅ 稼働済

    クライアントの事実(施設情報・価格・提供内容)を扱うため誤情報ゼロが絶対条件。Discordの /checksheet・/check で起動、事実ベース+公式サイト巡回と突合(fail-closed)。

  2. 完了通知 → 確認 → 修正 📣 👤

    ✅/⚠️/🚫の結果を受けて修正。

  3. 投稿 🔧 手動 → AUTOPOST

    当面は担当者が手動投稿。トークン登録が進んだらAUTOPOST段階ON。

↩ 修正したら再チェック — ✅が出るまで繰り返す

🚀 自社サービス / アフィリエイト自社責任で完結する事業
  1. 投稿 🔜 事業ごとに配線

    人間確認を通ったらそのまま投稿へ。チェックループが無いぶんフル自動化(AUTOPOST前提)に一番近いルート。

↓

📈 共通: 数値計測 → 仮説の検証・更新

両ルートとも投稿後の実績数値(閲覧・いいね・フォロワー・送客)を計測し、元になった仮説の検証状態を更新してSupabaseの仮説ストックへ還流する。この「仮説 → 投稿 → 数値検証 → 仮説更新」のループが、事業をまたいで効く共通資産になる。

→ 紀伊乃国屋の詳細フロー版はこちら

最終更新 2026-07-30 ・ 分岐ルール=クライアントワークのみ誤情報チェック必須(2026-07-30ユーザー決定)