ORIGINALS — Internal Design Doc / 2026-07-05
SNS動画工場.
SNS担当者1名＋AIエージェント群で、PR動画の量産 → 人の承認 → 配信 → 計測 → 改善を毎日回す仕組み。数字が良かった動画の傾向が、翌日の量産に自動で反映される「閉ループ」を作る。
ブランド BATT / Bwarm（求肥屋は別PCへ複製）
投稿先 Reels・TikTok・Shorts・X
目標 日2〜3本以上
運用者 非エンジニア1名
全体像 — 1本の動画がたどる道
企画AGENT
→
制作AGENT ×N 並列
→
品質チェックAGENT
→
承認担当者（人間）
→
配信AGENT → Publer
→
計測AGENT 日次
↩
分析エージェントが週次で 勝ちパターン.md を更新 → 翌日の「企画」が必ずこれを読む。良い動画の傾向が次の量産に自動反映される
エージェントが自動で実行
人間だけが押せるゲート（完全自動投稿はしない）
§1
エージェントチームの編成
5つの役割
企画ネタ出し
台帳と勝ちパターン.mdを読み、次に作る動画の「レシピ型 × フック × 商品」を決める。
毎晩 自動仕込み
制作並列×N
企画1件につき1エージェント。動画＋キャプション＋ハッシュタグを生成して「承認待ち」へ納品。
企画直後に並列実行
品質チェック法規・トーン
景表法・薬機法（寝具は特に）・ブランドトーンのNG検査。台帳タグの記録漏れも検査。
承認待ちに入る前
配信予約投稿
担当者がOKした動画をPublerに下書き送信し、4つのSNSへ予約投稿。
担当者の承認後
分析計測・改善
各SNSの指標を台帳へ書き戻し、週次で勝ちパターンを更新。月次で生成ツールも評価。
日次 / 週次 / 月次
設計の背骨: 分析の出力（勝ちパターン.md）を企画エージェントが必ず読む。これでループが閉じ、工場は使うほど賢くなる。
§2
置き場所とフォルダ構成
~/dev/sns-factory
sns-factory/
├── CLAUDE.md # 工場全体のルール（担当者は開かなくてよい）
├── レシピ/ # 動画テンプレのスキル群 ＝ ツールを閉じ込める抽象化層
│ ├── スライドショー型/ # 商品写真＋テロップ＋BGM。最速・最量産向き
│ ├── 実写カット型/ # みたらしプリンCMのffmpegパイプラインを一般化
│ └── AI生成型/ # Veo等。どのツールを叩くかはこの中だけが知っている
├── batt/
│ ├── BRAND.md # トーン・NG表現・訴求ポイント
│ ├── 素材庫/ # スマホ撮影・商品写真を放り込むだけの場所
│ ├── 承認待ち/ # 生成済み動画。ギャラリーHTMLで確認
│ └── 投稿済み/
├── bwarm/ # batt/ と同構成
└── 分析/
├── 勝ちパターン.md # 週次更新。企画エージェントの必読ファイル
├── 週次レポート/
└── ツール評価レポート/ # 月次
レシピ層にツール名を閉じ込めるのは意図的な設計。VeoからSora等へ乗り換えるときも、レシピ1ファイルの差し替えで済み、工場の他の部分は何も変わらない。
§3
投稿台帳（Google Sheets）
1動画 = 1行
担当者が普段のブラウザで見られるよう台帳はGoogle Sheetsに置く。生成時にタグを必ず記録するから「どのレシピ × フックが勝つか」を分析できる — ここがこの設計の背骨。
※ 行はサンプル。ほかに商品・投稿日・各SNSのURL・担当者フィードバック（NG理由）も記録する。GMV MAXは素材単位で成果が見えるため、出店後は動画IDにそのまま紐付く。
§4
計測の自動化
二段構え＋将来枠
第一
Publerのアナリティクス4SNS横断で再生・エンゲージを一括取得。API審査不要で最も確実。分析エージェントが定期収集して台帳へ。
補完
YouTube / Instagram の公式API ＋ ブラウザ自動化視聴維持率などの詳細指標をAPIで追加（初回設定のみ）。API制約が強いTikTok・Xの不足分は、ブラウザ自動化で管理画面から読み取る。
将来
GMV MAX（TikTok Shop出店後）Seller Center・広告管理画面から素材単位の成果を取得し、台帳の動画IDに紐付け。「稼ぐ動画」がそのまま特定できる。
§5
改善ループは2系統
動画 × ツール
週次 — 動画の勝ちパターン
何を作るべきかを更新する
- 台帳を「レシピ型 × フック × 商品」で集計し週次レポート化
- 勝ちパターン.mdを更新 → 翌週の企画に自動反映
- 判断指標は二層: 認知（再生・保存・フォロー転換）と 獲得（GMV・CV / Shop開始後）
月次 — 生成ツールの勝ちパターン
何で作るべきかを更新する
- リサーチエージェントが新モデル・価格改定・評判をWeb調査
- 台帳のツール別成果（1保存あたりコスト等）を実データで比較
- 有望な新ツールは週数本のA/Bで小さく検証 → 勝ったらレシピ内の実装だけ差し替え
§6
担当者の1日
ターミナル・コード不要
朝
承認待ちを確認。前夜の自動仕込みで動画が2〜3本並んでいる。ギャラリーページで動画とキャプションをプレビュー。
判断
OKならPublerへ、NGなら一言だけ。「テロップが多い」等のフィードバックは台帳に残り、次の企画に反映される。
随時
スマホ素材は素材庫に放り込むだけ。追加が欲しければClaude Codeに日本語で「BATTの動画あと2本」と話しかける。
週1
分析レポートを受け取る。「今週はスライドショー型 × 価格訴求が保存率2倍」のような形で届く。
§7
構築順序
最速で1本目を出す → ループを閉じる
PHASE 1
まず1本出す
- リポジトリ骨格＋CLAUDE.md＋BRAND.md（batt / bwarm）
- レシピ: スライドショー型
- 投稿台帳Sheets＋ギャラリーHTML
- Publer契約・連携＋配信フロー
PHASE 2
量産化する
- レシピ: 実写カット型・AI生成型
- 夜間自動仕込み（スケジュールタスク）
PHASE 3
ループを閉じる
- 計測: Publer → 公式API → ブラウザ自動化
- 週次分析＋勝ちパターン.md、月次ツール評価
- 求肥屋PCへの複製
- TikTok Shop出店後: GMV計測の接続
§8
コスト・リスクと対策
生成コストAI生成型は高コストのため選択的に使用。コストを台帳に記録し、費用対効果で制御する。
法規リスク（景表法・薬機法）品質チェックエージェントが承認前に機械的に検査。最終判断は必ず人間の承認ゲート。
プラットフォーム規約投稿は公式API連携済みのPubler経由のみ。非公式な自動投稿は行わない。
API変動計測はPubler第一・API/ブラウザ自動化は補完とし、単一手段に依存しない。