SNS運用自動化
ご提案書

本日の進め方（15分・7画面）

1ご要望の確認

1.1 目的 — リスト獲得（LINE登録）につながる発信

また、Voicyは本システムの「投稿検知の入力データ源」であると同時に、市ノ澤様の「LINEのリストを取りつつVoicyへ流していく」というご方針のとおり、コンテンツの出口（受け皿）でもあります。各SNS投稿からはLINE登録とVoicyの両方へ誘導する二面の導線を設計します。

1.2 プレゼント企画の位置づけ

2今回のスコープ

3現状の費用と課題

3.1 バックデスク実費（2026-08 実測・全124タスク検算一致）

この実費（バックデスク約8.5万円/月）は、3.2章で示す現行費用全体（システム開発者委託＋オンライン秘書実費・実測3ヶ月平均約42.7万円）とは集計範囲が異なります。バックデスク実費はSNS投稿作業のみを対象とした部分集計で、企画・ディレクション・秘書業務全体を含む数値は3.2章を参照してください。

3.2 現行費用との具体対比（実測ベースROI）

3.2.1 現行費用ブリッジ表 — 何が廃止・残存・移管されるか

4本提案の違い

4.1 市販ツールとの違い

4.1.1 比較表

4.1.2 市販ツール vs 本提案 — 機能マトリックス

4.2 CoWork（Lark内自動化）との違い

Lark CoWorkのような「アプリ内自動化」は、Lark内のデータ操作や定型処理を素早く組み立てるのに向いています。一方、外部SNSの公式APIに直結し、規約違反リスクの低減・二重投稿防止・継続改善までを仕組みとして組み込むには、コーディングエージェントでの構築でハーネス（Cloudflare等の実行基盤[9]）・予防統制（ガードレール）・検証ループを一から設計・構築する必要があります。本提案はこの「コーディングエージェント構築」の方式で作ります。

サービス比較表（市販ツール／CoWork／当方の3列統合）

4.3 コーディングエージェント構築だからできること

4.3.1 Workgraph（工程グラフ）— ガードレール常駐型パイプライン

4.3.2 価値差（10点満点スコアリング・10軸完全差分）

5費用対効果

5.1 費用構造（初年度／2年目以降）

5.2 投資回収 — 3ケース試算

5.3 費用の月次時系列（実測＋予測）

5.4 この構築を市場で頼むと

5.5 計測設計（将来の具体的な数値は約束しません）

6進め方とロードマップ

6.1 スケジュール（構築3ヶ月＋チューニング1ヶ月）

6.2 リリース順序 — 基盤が先、出口は後から増える

7運用体制

毎朝、Lark Baseに並んだ投稿案をチェックボックスで確認し、予約実行・予約時刻を設定します。1日分（最大10投稿）を1枚のカードにナンバリングし、まとめて承認・個別修正指示ができる運用です。承認者は御社または当方の指名承認者とし、運用開始時に確定します。

7.1 Visual Architecture（全体構造図）— 4層連携

本システムは4つの層が常時連携する構造です。Cloudflare（実行基盤）×コーディングエージェント（構築と改善を担当・使用ツールの詳細は付録A参照）×SNS各社公式API（出口）×Lark（管理・承認・台帳）の4層です。構築時に使うエンジニアリング手法は、ワークフロー設計（処理の流れの設計図）・プロンプト設計（AIへの指示の作り方）・ガードレール（規約違反を機械的に防ぐ仕組み）・コンテキスト管理（AIに渡す情報の取捨選択）の4つです（以降、本文では平易な言葉で説明します）。

7.2 危険領域の除外方針

景品表示法・金融商品取引法に抵触し得る表現（収益保証の断定・診断結果の断定等）、各媒体規約でグレーまたは禁止される自動化手法（インセンティブ付きエンゲージメント誘導・自動化された手段でのプラットフォームアクセス等）は、設計段階で除外するか、規約に沿う安全な代替（例: X＝投稿本文での明示的リポストキャンペーンのみ許可、IG/FB＝コメント募集からのPrivate Replyのみ許可）に置き換えます。

7.3 管理体制 — どこで人が関与するか

異常検知時は自動停止（circuit breaker）してLarkへ通知し、人の判断を待ちます。管理面（承認履歴・投稿台帳・週次レポート）は全てLarkに集約し、Lark外の別ツールで状況確認が必要になることはありません。

7.4 運用構想 — ここまでやる

• 1
  AIマーケリサーチ黒字社長のトンマナを維持しながら、直近で伸びている同文脈コンテンツを日次で調査します（4.3章のAIエージェント基盤・トンマナ学習機構の運用適用です）。
• 2
  データ分析による最適曜日・時間帯の決定固定観念で投稿時刻を決めず、実測データ（7.1章のD1投稿履歴）に基づいて曜日・時間帯を判断します。
• 3
  媒体規約の変更検知・反映7.2章の危険領域除外方針・付録Cの媒体別公式ポイントを基準に、公式ソースの変更を定期検知し、人の承認後に運用へ反映します。反映漏れを防ぐための定期照合です。
• 4
  公開アルゴリズムの取得と投稿最適化4.1.1章のX公式アルゴリズム実装（共有20.0／リプライ5.0／いいね0.5・48時間窓等）のように、各媒体の公開情報に基づく投稿設計を継続的に反映します。
• 5
  結果を学習して翌週の生成に反映4.3.1章の継続改善ループ（生成→承認→配信→検知→改善→生成）に沿って、実測結果を翌週の投稿案生成へフィードバックします。

7.4.1 拡張運用（同じ設計思想の応用・すべて本提案の設計で実現する運用）

• 6
  規約・アルゴリズム変更の検知・反映③の媒体規約チェックをpolicy registry（規約・仕様の変更点を定期チェックする仕組み）として運用し、各社の公式ソースの変更点を定期検知した上で、人の承認を経て反映します。
• 7
  炎上・ブランドセーフティの投稿前チェック7.2章の危険領域除外方針（景表法・金商法抵触表現の除外）を投稿の都度のチェック工程として運用し、公開前に機械的にふるいにかけます。
• 8
  A/Bテストと勝ちパターンの学習反映⑤の継続改善ループ（D1投稿履歴による実測データ管理）を活用し、複数パターンの結果を比較して翌週の生成に反映します。
• 9
  週次の競合・同文脈ベンチマーク①のAIマーケリサーチ（直近で伸びている同文脈コンテンツの日次調査）を週次の定点観測としてまとめ、レポート化します。
• 10
  AI検索時代のSEO・LLMO付録Cの媒体別公式ポイント（保存・シェア・完視聴等のシグナル）に沿った構造化生成を、AI検索・AI要約に引用されやすい構造（見出し・要点の明確化）にも適用します。
• 11
  過去コンテンツのエバーグリーン再活用digest.json（4.3.1章の素材シート基盤）に蓄積された過去の要点データを再利用し、ネタ切れを防ぎます。

7.5 日次運用枠 — 誰が何を担当するか

7.6 会計士特有の発信チェックリスト — 予防統制と復旧手順

7.6.1 投稿前チェック項目（予防統制）

7.6.2 シャドウバン疑い時の復旧手順

異常な反応低下等を検知した場合、まず投稿を停止し、直近投稿の内容・頻度を調査したうえで、頻度調整を行ってから再開します（7.3章の統制設計に準拠）。

7.7 速報レーン — 時事対応の別SLA

7.8 計測ファネル — 何をもって成果と見るか

7.9 立ち上げ完了条件チェックリスト

• プロフィール最適化（各媒体のプロフィール文・リンク・アイコンの統一）
• 固定ポストの設定（各媒体の顔となる投稿の設置）
• なりすまし対策（公式マーク申請・類似アカウントの監視）
• 初期リプ先リストの整備（経営者・他士業・メディア関係者等、優先的に関係構築する相手のリスト化）
• 同一文クロスポスト禁止・媒体別改稿ルールの適用確認（4.1.1章・付録Cの媒体ネイティブ生成方針に準拠）

8金額

8.1 含むもの／含まないもの

8.2 300万円の内訳（第1期: 200万円／第2期: 100万円）

8.2.1 機能ブロック別・工数目安（第1期＋第2期 合計＝今回スコープ）

8.3 成果物・検収条件・支払マイルストーン（例・第1期／第2期の2段階）

9本日ご確認いただきたいこと

対象

第1期（200万円・ナレッジ基盤＋X・Threads等）の着手合意。第2期（100万円）は第1期検収後の継続判断（詳細は8章）

金額

第1期 200万円＋第2期 100万円＝構築計300万円＋リリース後保守5万円/月（詳細は8章）

着工

2026年9月第1週（予定）

9.1 明日ご依頼したいこと

• Instagram/Facebook: Meta Business Manager への招待（ビジネスアカウント確認）
• ブログの現状（WordPressか・投稿権限のご確認）
• Facebook運用状況の共有
• YouTube: 字幕取得のためのチャンネルOAuth協力（または収録原音データの共有ルート確立）
• Voicy: 収録元音源の受け渡し方法
• LINE公式アカウントのプラン確認
• X: Premiumプラン種別＋OCR収益化を狙うか（投稿方式の分岐点）
• プレゼント企画の中身（景表法確認用）

• YouTube Data APIキー発行
• Meta App Review着手

10ご契約条件（契約書で定める事項）

11文書相関図・関連資料（サブドキュメント）

• 調査報告 — 現行運用の実態調査（バックデスク実費集計・媒体別公式規約の一次情報調査）
• 要件定義v2 — Phase1（今回スコープ）の機能要件・非機能要件の詳細定義
• 仕様書 — システムの詳細仕様（API連携仕様・データ構造・状態管理設計）
• 開発計画 — M1〜M3の詳細タスク分解とスケジュール（5章ロードマップの元データ）

付録A: コーディングエージェント構築の詳細比較（境界表・Q&A）

A.1 境界表

A.2 「何がこんなに違うの？」— 1問1答

付録B: 全媒体の規約対応要約

付録C: 全媒体アルゴリズム・規約対応表（公式一次情報）

付録D: 出典一覧

本文中の脚注番号[1]〜に対応する公式ソースです。裏取り台帳（根拠Base）にも同一URLを記録しています。

付録E: 用語集

本文中に出てくる専門用語を一覧にまとめました。