2026-08-21 ご提案
株式会社SOLEIL Libertad 御中

SNS運用自動化
ご提案書

市ノ澤様(株式会社SOLEIL Libertad代表取締役)ご要望を、規約準拠・コスト根拠・運用のしやすさの観点で整理いたしました。
提出者: LOP株式会社 / 提出日: 2026-08-21
※ 社名表記「株式会社SOLEIL Libertad」は現時点の最有力表記です(登記照会中)。確定後は本資料内の表記を一括置換します。
なぜ構築計300万円(第1期: 200万円+第2期: 100万円)か — 30秒でわかる3つの理由
1
現行の人力運用を仕組みに置換
月約43万円 → 月約12.4万円+実費
システム開発者委託20万円+秘書実費(5〜7月実測平均約22.7万円)=実測3ヶ月平均約42.7万円の人力運用を、規約違反リスクを低減する仕組みに置き換えます(詳細3.2章)
2
今回スコープの市場換算は204〜408万円
204〜408万円(目安)
今回の構築範囲(Phase1相当)を34〜51人日×6〜8万円/日で市場換算した目安です。公式ソース準拠の投稿設計・規約チェック・ナレッジ資産化(解約後も残る無形資産)を含む構築を、コーディングエージェント構築で実施します(使用ツールの詳細は付録A参照/詳細5.4章)
3
仕組みと知見は御社に残る
出口を増やすほど単価が下がる
digest.json基盤の上に配信先媒体を追加していく設計のため、段階を積むごとに1媒体あたりの追加コストが逓減します(詳細6.2章)

本日の進め方(15分・7画面)

使い方:本日のご説明は、以下7画面の順にご覧いただきます。タップすると該当セクションへ移動します。
※ 本編(1〜11章)でご説明した内容の詳細な根拠・技術仕様は、本資料末尾の「付録A〜E」にまとめています。左のサイドバー目次からいつでも各章へ移動できます。
本資料は市ノ澤様(株式会社SOLEIL Libertad代表取締役)のご要望を、規約準拠・コスト根拠・運用のしやすさの観点で整理したご提案書です。本編は「本日の進め方」7画面で参照する決裁ストーリー、付録は詳細な根拠・技術仕様です。数値・仕様は公式ソース・実測値で裏取り済みのもののみ記載し、未確認は「未確認」と明記しています。

1ご要望の確認

30秒でわかる:市ノ澤様のご要望3ステップに、本提案がどう応えるかを一覧で照らし合わせます。
投稿したら自動で動く
要約してから投稿文を作る
複数SNSに展開する
本提案で実現
ご要望内容本提案での回答
ステップ1 YouTube/Voicyに投稿すると、AIエージェントが自動で検知して動き出す 満たすRSS(新しい投稿を機械が自動で知るための公式の更新情報)検知+原音ルートで自動起動を実現
ステップ2 文字起こしをそのまま使わず、要約・図解資料にしてから複数投稿文を作る 満たすdigest.json(文字起こしから要点だけを抜き出した「素材シート」)を必ず経由し、生の文字起こしから直接投稿文は作らない設計
ステップ3 X/Threads/Substack/note等、複数媒体へ展開する 超えるTikTok/インスタリール台本・LINE教育配信も構造に組み込み済み(後続フェーズ)
原文引用(市ノ澤様ご要望・要旨): 「投稿したら自動で動く」「要約してから複数投稿文を作る」「複数SNSに展開する」——この3ステップを本提案書の設計起点にしています。

2今回のスコープ

30秒でわかる:今回ご提案する「フェーズ1(300万円スコープ)」は自動投稿までを対象とし、反応検知・プレゼント企画・診断機能は後続フェーズです。
Phase1(今回の300万円スコープ)の定義取込〜ナレッジ蓄積〜媒体別生成〜承認〜自動投稿(X・Threads先行、3ヶ月内にブログ/note/Facebook/Substackへ段階リリース)。反応検知・診断・LINE配信は後続フェーズです。本資料内でこの定義に統一しています。
フェーズ1(本提案・300万円)
投稿前後データ取得〜自動投稿
フェーズ1で構築すること YouTube/Voicyの投稿前後データを取得し、各SNSに最適化したコンテンツを生成、人間の承認を経て投稿するまでの一連の流れです。X・Threadsを先行させ、3ヶ月内にブログ・note・Facebook・Substackへ段階的にリリースします。
後続フェーズ(本提案スコープ外) ・投稿への反応(コメント・いいね等)の自動検知
・コメント連動のプレゼント企画(Private Reply連動)
・LINE診断LIFF機能・LINE配信

3現状の費用と課題

30秒でわかる:現在バックデスクに実費で支払っている運用コストの内訳と、現行運用費42.7万円/月がどの費目から成るかをご確認ください(費用対効果の試算は5章)。
結論(詳細な費用対比・3ケース試算は3.2章を正データとして参照)
現行ランニング実測平均月約43万円 → 導入後月約12.4万円+実費 → 差額(正常収益力への改善)月約30.6万円 → 標準ケースで約10ヶ月投資回収。悲観12ヶ月・楽観8ヶ月のケース別試算は5.2章をご覧ください。

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

業務単価目安(実測平均)月換算コスト
【FB】YouTube切り抜きリール投稿約959円/本約26,800円(約28本)
【インスタ】リール動画投稿約633円/本約17,700円(約28本)
【Facebook】shorts投稿約563円/本約12,200円(約22本)
Voicyストーリーアップ(毎朝)-約6,500円(31回)
その他(YouTubeショート・TikTok・FB切抜・ブログ転記・画像作成 等)-約21,500円
SNS系実費 計-約84,700円/月
数値は全てバックデスク実費集計(2026-08-01〜20・全124タスク・検算一致)に基づく実測値のみを使用しています。バックデスク秘書作業は「切り抜き済み動画の投稿作業」のみを対象としており、切り抜き制作そのもの・投稿文の企画は含まれていません。本提案は「制作+最適化+投稿」まで含む上位互換です。

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

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

区分内訳月額
現行(導入前)システム開発者委託 月20万円 + オンライン秘書実費(5〜7月実測: 229,606円/231,553円/219,634円・3ヶ月平均約22.7万円)月約43万円
(実測3ヶ月平均42.7万円)
導入後保守5万円+残す秘書業務(架電等・実測約7.4万円。下記ブリッジ表参照)月約12.4万円
+API実費別途(月1〜2万円目安)
現行(導入前・実測)
月約43万円
導入後(保守+残す秘書業務)
月約12.4万円+API実費

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

費目現行月額(実測)分類導入後の扱い
システム開発者委託20.0万円本システムへ移管保守5万円/月に置換(詳細は5.1章)
SNS系秘書業務(投稿作業)約8.5万円廃止投稿作業そのものが自動化されるため終了(4章バックデスク実費に対応)
架電等秘書業務約7.4万円残存自動化範囲外のため継続。導入後の「残す秘書業務」として引き続き計上
その他秘書費(企画・ディレクション等)約6.8万円廃止企画・ディレクション業務の一部が仕組みに置換されるため終了
現行合計約42.7万円
※ 再計算: 導入後12.4万円 = 保守5万円(開発委託20万円の移管先)+ 残存する架電等秘書業務7.4万円。差額30.6万円 ≈ 廃止分(8.5万円+6.8万円=15.3万円)+ 開発委託の圧縮分(20万円-5万円=15万円)。端数は実測値の丸めによるものです。
現行(導入前)
約42万円/月
導入後
約12.4万円/月+API実費
※ 本グラフの幅比率は12.4万円 ÷ 42万円 = 29.5%で算出(見出しの実測平均43万円は端数調整前の概算値です)。オンライン秘書実費の3ヶ月分実測値(5〜7月)は内部台帳に基づく数値で、3.1章のバックデスク実費(2026-08・約84,700円/月=SNS投稿作業のみ)とは集計範囲が異なります(本欄は開発委託費・秘書業務全体を含む)。

4本提案の違い

30秒でわかる:本提案が市販ツール・Lark CoWork・単なる開発委託と何が違うのかを、4.1〜4.3の3つの対比でご説明します。

4.1 市販ツールとの違い

結論市販ツールは“投稿する道具”。本提案は“何をどう投稿すべきかまで設計する仕組み”です。
30秒でわかる:月数万円のSNS自動投稿ツールと何が違うのかを、規約遵守・トンマナ一貫性・運用統合の3点でご説明します。
市販ツール
月数万円
規約リスクは自己責任
トンマナ学習なし
運用は分断
本提案
構築300万円(2期)
規約違反リスクを
低減するチェック体制
トンマナ一貫・Lark統合

4.1.1 比較表

観点市販ツール(X自動投稿/note代筆ツール等・月3万円級)本提案
投稿ロジック 時間指定の予約投稿のみ。反応の良し悪しは考慮しない Xが公開するソースコード(xai-org/x-algorithm)を参考にした仮説設計+実測検証。共有20.0/リプライ5.0/いいね0.5の公開値・48時間窓・連投減衰の記載を踏まえて設計します(公開値と本番運用のスコアリングは異なる可能性があり、翌週から実測検証を開始します)[5][6]
規約遵守 ツール利用者の自己責任。垢BAN・シャドウバンのリスクは考慮されない 媒体規約に沿ったチェックと人の最終承認を予防統制(ガードレール)として構造に実装(後述4章)。X収益化(OCR)の「automated means」除外条項[6]を踏まえ、収益化を狙うアカウントは人間最終投稿を既定にする設計
トンマナ 汎用テンプレート。個別の話し方は学習しない 黒字社長のトンマナを学習し、媒体をまたいで一貫した文体で生成
業務統合 ツール単体で完結。他業務との連携なし Lark Base承認・チャット1カード承認・全履歴台帳と統合。既存のLark運用にそのまま乗る
継続改善 ツールのアップデート待ち 投稿→計測→チューニングのエージェント継続改善ループを構築に含める(構築期間内のチューニング1ヶ月)
投稿フォーマット 媒体特性を考慮しない一律フォーマット スレッド式投稿等、媒体別の規約準拠フォーマットで生成

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

機能市販ツール(月数万円)本提案(構築計300万円・第1期+第2期)
予約投稿
規約チェック標準機能では未対応(当社確認時点)
トンマナ学習標準機能では未対応(当社確認時点)
業務統合標準機能では未対応(当社確認時点)
継続改善標準機能では未対応(当社確認時点)
「ツールを買う」のではなく「運用の質を買う」のが本提案です。市販ツールが代替できるのは投稿予約という作業だけで、規約遵守の設計・アルゴリズム準拠の投稿設計・トンマナの一貫性・業務統合・継続改善は、ツール単体では得られません。

4.2 CoWork(Lark内自動化)との違い

結論CoWorkは“Lark内を動かす自動化”。本提案は“外部SNS公式APIに直結し、規約対応まで機械強制する自動化”です。

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

サービス比較表(市販ツール/CoWork/当方の3列統合)

観点市販ツール(月数万円)CoWork系(アプリ内自動化)当方(コーディングエージェント構築)
規約対応利用者の自己責任Lark内は対応・外部媒体は対象外チェック+人の最終承認
アルゴリズム対応時間指定のみ未対応公開ソース参考の仮説設計+実測検証
トンマナ学習汎用テンプレート未対応個別学習・媒体横断で一貫
業務統合単体完結Lark内は得意Lark統合+外部API直結
継続改善ツールのアップデート待ち未対応実測データでの継続チューニング
データ資産化蓄積されないLark内データのみナレッジDBが自社に残る
二重投稿防止未対応未対応状態管理(D1)で防止
拡張性(出口追加)媒体ごとに再契約対象外同一基盤で追加・限界費用が逓減
人依存度運用は人手運用は人手自動化+承認のみ人が関与
※ 本表は4.1.1章・4.1.2章・付録A.1章(境界表)の要点を1枚に統合した早見表です。詳細な根拠・条件は各章を参照してください。

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

結論コーディングエージェント構築だからこそ、規約ガードレール・二重投稿防止・継続改善ループまでを一つの基盤に組み込めます。

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

規約ガードレール(全工程に常駐)
取込
RSS検知
生成
媒体別コンテンツ
承認
Lark Base
配信
各SNS投稿
検知
反応計測(後続)
改善
継続チューニング
改善で得た知見は生成工程へ還流(ループ)。承認・改善の各工程を人間が随時確認できる構造です。
たとえるなら、CoWork系の自動化は「優秀な事務員に定型マニュアルを渡す」ことに近く、コーディングエージェント構築は「品質検査装置まで据え付けた専用工場ラインを建てる」ことに近いイメージです。だから初期構築費はかかりますが、一度ラインが回り始めれば、日々の運用は人手の質に依存しなくなります。

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

#評価軸CoWork系コーディングエージェント構築なぜこの点差か(根拠)
1規約安全性39当方は媒体別ガードレールを機械チェック+人承認で通す設計。CoWorkは外部媒体の規約判断が対象外
2アルゴリズム最適化28当方はXの公開ソースを参考にした仮説設計+実測検証。CoWorkはアルゴリズム対応機能を持たない
3媒体ネイティブ生成38当方は媒体特性ごとに個別生成。CoWorkは汎用データ操作が中心で媒体別生成の機能を持たない
4トーン&マナー一貫性39当方はトンマナを学習し媒体横断で一貫。CoWorkはトンマナ学習機能を持たない
5継続改善ループ28当方は投稿→計測→チューニングの継続ループを構築に含む。CoWorkは実行結果の分析・反映機構を持たない
6監査性・二重投稿防止49当方はD1で投稿履歴を状態管理し二重投稿を防止。CoWorkはLark内操作の監査ログはあるが外部投稿の状態管理は対象外
7データ資産化(ナレッジDBが自社に残る)29当方はdigest.json等のナレッジが自社基盤に蓄積される。CoWorkはLark内データに限定される
8拡張性(出口追加の限界費用)38当方は同一digest基盤に出口を追加でき、6.2章のとおり限界費用が逓減。CoWorkは外部媒体の追加が対象外
9時代追従(規約・アルゴ変更の検知・反映)28当方はpolicy registryで公式ソースの変更を定期検知し人の承認後に反映。CoWorkは提供元のアップデート待ち
10人依存度(低いほど良い=逆軸)63当方は承認等の意思決定のみ人が関与し運用は自動化。CoWork系・市販ツールとも実行後の確認作業を人手で行う前提が残る
合計(軸10は逆軸のため参考値・単純合算せず)3079軸1〜9(正順9軸・各10点満点=90点満点)の単純合計。軸10(逆軸)は別掲
※ いずれも実測値ではなく、当方の設計判断に基づく定性評価(10点満点のスコアリング)です。捏造数値ではありません。軸10のみ「点数が低いほど望ましい」逆軸のため、合計点の単純合算には含めず参考値として別掲しています。
※ 境界表(付録A.1)・想定問答(付録A.2)はあわせて付録Aをご参照ください。

5費用対効果

30秒でわかる:費用構造・投資回収の3ケース試算・月次時系列・市場換算・計測設計をご確認ください。
結論
差額約30.6万円で構築計300万円(第1期: 200万円+第2期: 100万円)を割ると約10ヶ月(標準ケース)で投資回収。悲観・楽観を含む3ケースの詳細(前提条件つき)は5.2章を正データとして参照してください。

5.1 費用構造(初年度/2年目以降)

区分内訳
初年度構築計300万円(第1期: 200万円+第2期: 100万円/3ヶ月構築+チューニング1ヶ月・この期間の調整費込み)+ 保守5万円 × リリース後の月数(初年度目安8〜9ヶ月分)+ 外部API実費(月次上限を事前合意・超過分は翌月繰り越し)
2年目以降保守5万円 × 12ヶ月 = 年60万円 + 外部API実費のみ
初年度(目安)
約340〜345万円(構築300万+保守5万×8〜9ヶ月)
2年目以降(年間)
60万円/年
※ 構築計300万円(第1期: 200万円+第2期: 100万円)には3ヶ月の構築期間+1ヶ月のチューニング期間中の調整費が含まれます。保守5万円/月はリリース後(構築完了後)から発生し、初年度は8〜9ヶ月分(5章ロードマップから逆算した目安)を見込みます。外部API実費(X API従量・LINE通数・LLM利用料等)はいずれの区分にも別途加算されます(月次上限を事前合意)。

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

ケース前提差額/月回収期間
悲観API実費・想定外対応を高めに見積り、導入後コストが月約18万円程度になる場合約25万円約12ヶ月
標準導入後コスト月約12.4万円+API実費目安1〜2万円で試算約29.6〜30.6万円約10ヶ月
楽観秘書残業務も段階的に圧縮し、API実費を低めに抑えられた場合約37.5万円約8ヶ月
※ 3ケースはいずれも内部試算による目安(シナリオ分析)であり、確約する数値ではありません。回収期間は「構築計300万円(第1期200万円+第2期100万円) ÷ 差額/月」で算出しています。

5.3 費用の月次時系列(実測+予測)

年月区分秘書実費開発委託費月合計(目安)
2026-01〜04再取得後に追記
2026-05実績(承認済み)229,606円200,000円429,606円
2026-06実績(承認済み)231,553円200,000円431,553円
2026-07実績(承認済み)219,634円200,000円419,634円
2026-08(20日時点)実績(月途中)105,100円200,000円305,100円(月途中)
2026-09〜2027-03予測値(直近3ヶ月平均ベース)約226,931円/月200,000円/月約426,931円/月
05月(実績)
429,606円
06月(実績)
431,553円
07月(実績)
419,634円
08月(月途中)
305,100円(20日時点)
09月〜03月(予測)
約426,931円/月(予測)
※ 淡色・斜線のバーは「予測値(直近3ヶ月平均ベース)」です。2026年1〜4月の実績は未取得のため、取得後にプレースホルダ行へ追記します。8月は20日時点の月途中実績であり、他月と単純比較できません。

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

今回スコープ(Phase1相当)の市場換算
204〜408万円
34〜51人日 × 市場単価6〜8万円/日(内部台帳の試算・6.2章の4ブロック分)。本提案はコーディングエージェント構築の効率化により構築計300万円(第1期 200万円+第2期 100万円)で提供します
全フェーズ完了時(後続フェーズ含む)の市場換算
330〜670万円
55〜84人日 × 市場単価6〜8万円/日。LINE基盤・検知・診断(後続フェーズ)まで含めた場合の参考値です(内訳は8.2章「300万円の内訳」参照)
単機能ツール積み上げの場合
X自動投稿・note代筆等の単機能ツール(各月3万円級)を媒体数分・12ヶ月契約しても合計額に見合う「仕組み」は残りません。契約終了と同時に蓄積したナレッジ・履歴管理も失われます
※ 市場相場(204〜670万円・日単価6〜8万円)はいずれも一般的な市況の目安であり、特定業者の見積書に基づく数値ではありません。「今回スコープ」と「全フェーズ完了時」はスコープが異なるため、単純に合算・比較しないでください。

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

目標KPIと検証方法 将来のインプレッション数・売上等の具体的な数値目標は、媒体アルゴリズムの変動要因が大きく本資料では提示しません。代わりに「インプレッション拡大 → 高単価講座・LMU入会への転換」を目標KPIの方向性として設定し、週次実測レポートで実際の数値を継続検証する計測設計とします。7章の運用ループ(承認・失敗確認・数字確認)で得られる実測データが、この検証の基礎になります。

6進め方とロードマップ

30秒でわかる:構築3ヶ月+チューニング1ヶ月でPhase1(基盤)〜Phase3(ブログ・note・Facebook・Substack)まで対応媒体を広げ、後続フェーズでPhase4(Instagram)→Phase5(LINE・次点TikTok)へ展開する計画です。
結論(Phase順の図は6.2章のリリース階段図を正データとして参照)
P1基盤構築(digest)→ P2 X・Threads本格稼働 → P3 ブログ・note・FB・Substack → 後続P4 Instagram → 後続P5 LINE(次点TikTok)。以下は本フェーズ(P1〜P3)の月次スケジュールです。

6.1 スケジュール(構築3ヶ月+チューニング1ヶ月)

M1 基盤構築+X/Threads本格稼働
1ヶ月目
M2 ブログ・note・FB・Substack
2ヶ月目
M3 チューニング+計測
3ヶ月目
月次保守(継続)
リリース後〜
マイルストーン期間目安何ができるようになるか
M1(Phase1+Phase2)1ヶ月目digest基盤の構築とX/Threads本格稼働。YouTube/Voicyの投稿検知〜承認〜投稿までが通しで動く
M2(Phase3)2ヶ月目ブログ・note・Facebook・Substackを追加(推奨: 同時期。既存FB運用実績があり移行が滑らかなため)
M33ヶ月目+チューニング1ヶ月実運用データに基づくチューニングと計測レポート体制が整う
後続フェーズ(Phase4・Phase5)本提案スコープ外Phase4: Instagram対応 → Phase5: LINE(教育配信・リスト獲得の受け皿。次点でTikTok)へ展開
着工時期開発着工: 2026年9月第1週(予定)・構築は提案者本人(Masa)が実施します。

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

Phase1YouTube/Voicyナレッジの
自動蓄積(digest基盤)
Phase2X・Threads投稿
Phase3ブログ・note・
Facebook・Substack記事
Phase4Instagram
Phase5LINE
(次点: TikTok)
この図は「スコープの境界線」ではなく「リリースする順序」を表しています。Phase1でYouTube/Voicyの投稿データをAIフレンドリーな形(digest.json)で自動蓄積するデータ資産化を最初に済ませ、以降のPhaseはこの同じ基盤の上に配信先(出口)を追加していく構造です(6章ロードマップの媒体順と一致)。基盤が先・出口は後から増えるため、段階を積むごとに1媒体あたりの追加コストが逓減します。

7運用体制

30秒でわかる:毎朝10分以内で完結する運用イメージ、Cloudflare×コーディングエージェント×SNS公式API×Larkの4層連携アーキテクチャ、危険領域の除外方針、そして「どこで人が関与するか」の管理体制をご確認ください。
承認5分
失敗確認3分
数字確認2分

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

7.1 Visual Architecture(全体構造図)— 4層連携

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

層1: 実行基盤
Cloudflare
Workflows・D1・R2で取込〜配信〜履歴管理を裏側で常時稼働
層2: 構築と改善
コーディングエージェント
設計・実装・継続チューニングを担当(使用ツールの詳細は付録A参照)
層3: 出口
SNS各社公式API
X・Meta・LINE等の公式APIで各媒体へ投稿
層4: 管理・承認
Lark
Base台帳・カード承認・週次レポートで人が状況を把握
YouTube/Voicy
投稿

RSS検知
Cloudflare Workflows
取込〜承認〜配信
[層1: 実行基盤]
digest.json
素材シート
[層2: コーディングエージェント生成物]
媒体別生成
X/Threads/note/FB…
[層2: コーディングエージェント]
Lark Base承認
毎朝10分以内
[層4: Lark]

承認
各SNSへ投稿
[層3: 公式API出口]
D1
投稿履歴(監査証跡)・重複防止
[層1: 実行基盤]
※ 承認カードで「要修正」の場合は媒体別生成へ差し戻し(再生成ループ)。4層は常時連携し、どこか1層だけが単独で動くことはありません。

7.2 危険領域の除外方針

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

※ 景品表示法・金融商品取引法に関する記載は当方の設計方針の説明であり、法的助言ではありません。最終的な適法性の判断は、弁護士等の専門家へのご確認を推奨します。

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

全自動で暴走させない。止まる場所を設計してあるから、安心して自動化できます。
区分内容関与のタイミング
Human-in-the-loop人が承認してから動く 投稿内容の最終承認/プレゼント企画の内容/新媒体の追加/規約グレー判定時 毎朝のLark Baseカード承認、および企画・追加媒体の意思決定時
Human-on-the-loop自動で動き人は監視 検知・データ収集・下書き生成・計測レポート 常時自動稼働。異常時は自動停止して通知(circuit breaker=安全装置)
自動: 検知・下書き生成・計測
人: 毎朝カード承認
自動: 配信・履歴記録

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

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

30秒でわかる:本提案は「投稿予約」で終わりません。すでに本文でご説明した仕組み(アルゴリズム準拠設計・媒体規約ガードレール・継続改善ループ)を、常時ループとして毎週回し続ける運用構想です。新しい能力を追加するのではなく、構築する仕組みを最大限使い切るという位置付けです。
AIマーケ
リサーチ
最適曜日・
時間帯の決定
媒体規約の
変更検知・反映
公開アルゴリズム
準拠の最適化
学習して
翌週へ反映
  • 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章の継続改善ループ(生成→承認→配信→検知→改善→生成)に沿って、実測結果を翌週の投稿案生成へフィードバックします。
上記5点はいずれも本資料の本文(4.1.1/4.3/7.1/7.2/付録C)ですでにご説明した仕組みの運用面での言い換えです。新規の能力を主張するものではなく、「構築した基盤を止めずに回し続ける」という運用姿勢を明文化したものです。

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.4.1の6点も新規の能力主張ではなく、①〜⑤(本文4.1.1/4.3/7.1/7.2/付録Cで裏取り済みの仕組み)の運用面での展開です。「求められている以上をやる」という運用姿勢を、既存の裏取り済み機構の範囲内で明文化しています。

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

30秒でわかる:定型投稿だけでなく、リプライ・引用・時事便乗の各枠を日次運用表として明示します。すべてAI下書き+人間承認(当方)の体制です。
運用枠1日あたりの目安担当
定型投稿枠最大10投稿(7.3章の承認カード運用)AI下書き+人間承認(当方)
リプライ枠主要な反応への返信下書きを日次で準備AI下書き+人間承認(当方)
引用枠関連性の高い投稿への引用コメント下書きAI下書き+人間承認(当方)
時事便乗枠7.7章「速報レーン」のSLAに準拠AI下書き+人間承認(当方)(速報は別SLA)
※ 本数・頻度は目安です。実際の運用量は構築後のチューニング期間(M3)で確定します。

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

30秒でわかる:税額断定・節税の再現性示唆・投資助言まがい・成功報酬ニュアンスを投稿単位で止める予防統制(ガードレール)と、シャドウバン疑い時の復旧手順です。

7.6.1 投稿前チェック項目(予防統制)

チェック項目止める理由
税額の断定表現個別事情により結果が異なるため、断定表現は誤解・トラブルの原因になります
節税の再現性を示唆する表現「誰でも同じ効果」という誤解を招く表現は避けます
投資助言まがいの表現資格・登録のない投資助言と誤認されるリスクがあるため回避します
成功報酬ニュアンスの表現誤解を招く報酬体系の示唆を避けます
※ 本チェックは当方の設計方針の説明であり、法的助言ではありません(7.2章の免責と同様)。最終的な表現の適否は専門家へのご確認を推奨します。

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

検知
投稿停止
原因調査

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

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

30秒でわかる:税制改正・金融政策等の時事は、通常の承認フローとは別に30〜60分以内承認の速報SLAで対応します。出せない日の代替運用もあわせて明記します。
速報レーンSLA 税制改正・金融政策等の速報性が求められる話題は、通常の「毎朝10分以内承認」(7章)とは別に、30〜60分以内の承認を目標とする速報レーンで対応します。
状況対応
速報を出せる日AI下書き生成 → 30〜60分以内に当方承認 → 投稿
速報を出せない日(承認者不在等)リプ専任枠に切り替え、または下書きストックとして翌営業日に繰り越し

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

30秒でわかる:投稿から入会までの導線をファネルとして可視化し、フォロワー数ではなく相談予約起点で回収効果を説明します。90日後に実測数値で継続判定を行います。
投稿
反応
予約導線
クリック
相談予約
面談
入会
90日後の継続判定基準 本ファネルの各段階の転換率(投稿→反応、反応→予約導線クリック、クリック→相談予約、相談予約→面談、面談→入会)を、導入後90日間の実測データで初めて設定します。フォロワー数の増減ではなく、相談予約起点のCTA(Call To Action)を評価基準とします。具体的な目標転換率・目標件数は本資料の時点では未確定であり、実測後に当方・当方と協議のうえ設定します。
※ 将来の具体的な転換率・件数はこの場では記載しません(5.5章の計測設計と同じ方針)。90日間の実測を経て、目標値を協議・設定します。

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

30秒でわかる:本格運用を開始する前に完了しておくべき項目のチェックリストです。
  • プロフィール最適化(各媒体のプロフィール文・リンク・アイコンの統一)
  • 固定ポストの設定(各媒体の顔となる投稿の設置)
  • なりすまし対策(公式マーク申請・類似アカウントの監視)
  • 初期リプ先リストの整備(経営者・他士業・メディア関係者等、優先的に関係構築する相手のリスト化)
  • 同一文クロスポスト禁止・媒体別改稿ルールの適用確認(4.1.1章・付録Cの媒体ネイティブ生成方針に準拠)

8金額

30秒でわかる:構築計300万円を第1期(200万円)第2期(100万円)の2段階に分け、第1期検収後に第2期へ着手します。リリース後は月次保守5万円です。
第1期
200万円
第2期
100万円
リリース後
保守5万円/月
第1期 200万円第2期 100万円構築計300万円(第1期検収後に第2期へ着手)+リリース後保守5万円/月

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

含むもの含まないもの
含む設計・実装・チューニング(M1〜M3)/Lark承認基盤の構築/障害監視・フォールバック設計/月次保守(リリース後) 別途外部API実費(X API従量・LINE通数・LLM利用料等)は別途。処理量に応じた実費のため、月次の上限額を事前に合意し、超過分は翌月へ繰り越す設計とします

8.2 300万円の内訳(第1期: 200万円/第2期: 100万円)

金額主な内容
第1期 200万円 ナレッジ基盤(取込〜digest)/媒体別生成(トーン&マナー設計込み)/承認フロー/X・Threads自動投稿/規約ガードレール実装/ブログ・note・Facebook・Substackへの段階リリース
第2期 100万円 各SNS媒体のアルゴリズムに合わせた定期チューニング/発信内容の編集・内容スキルのチューニング/規約に基づくAI運用の定着/計測と改善ループ(チューニング期間1ヶ月+運用固め)
合計 300万円 第1期検収後に第2期へ着手(8.3 支払マイルストーン参照)
※ 第1期・第2期の金額は、構築(第1期)と運用定着・チューニング(第2期)という性質差を踏まえた配分であり、下表(機能ブロック別工数目安)の人日数から単純比例で算出したものではありません。

8.2.1 機能ブロック別・工数目安(第1期+第2期 合計=今回スコープ)

機能ブロックスコープ工数目安(人日)
コンテンツ生成基盤(digest.json・媒体別生成)今回スコープ8〜12人日
承認UI(Lark Base承認・カード)今回スコープ10〜15人日
自動投稿(各社公式API連携・状態管理)今回スコープ12〜18人日
計測(週次レポート体制)今回スコープ4〜6人日
今回スコープ(第1期+第2期=Phase1相当)小計34〜51人日
LINE基盤後続フェーズ5〜8人日
検知後続フェーズ10〜15人日
診断後続フェーズ6〜10人日
全フェーズ合計55〜84人日
今回スコープを市場単価6〜8万円/日で換算すると204〜408万円相当のところを、コーディングエージェント構築(使用ツールの詳細は付録A参照)の効率化により構築計300万円(第1期 200万円+第2期 100万円)で提供します。全フェーズ完了時点では市場換算330〜670万円相当になる見込みです。
※ 工数(人日)は市場換算の目安であり、実際の内部工数の実測値ではありません。LINE基盤・検知・診断の3ブロックは2章のとおり本提案(第1期+第2期=今回スコープ)のスコープ外(後続フェーズ)です。「今回スコープ」と「全フェーズ合計」はスコープが異なるため、単純に合算・比較しないでください。

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

マイルストーン成果物(例)検収条件(例)
①第1期着手要件定義v2の確定・開発環境のセットアップ要件定義書への双方合意
②第1期検収(M1〜M2完了時点)ナレッジ基盤・媒体別生成・承認フロー・X/Threads自動投稿・規約ガードレール・ブログ/note/FB/Substack段階リリースが稼働投稿成功率・承認所要時間等のKPI例を基準とした動作確認。第1期検収書への合意をもって第2期着手の条件とする
③第2期着手第2期要件(チューニング計画)の確認第1期検収完了が着手条件
④第2期検収(M3・チューニング完了時点)継続改善ループの稼働・週次計測レポート体制・規約に基づくAI運用の定着確認本番相当環境での通し稼働確認
※ 第1期=6章スケジュールのM1〜M2、第2期=同M3(チューニング期間)に対応します。
※ 各マイルストーンへの金額配分・支払期日・検収条件の具体的な基準値は、この場では確定させず10章(契約条件)のとおり契約時に確定します。本表は例示です。

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

30秒でわかる:本日の決裁事項(Go/条件付きGo/見送り)と、着手にあたり先方・当方それぞれにご準備いただきたい項目です。
Go(着手合意)
本日第1期(200万円)の着手に合意
条件付きGo
条件を本日確認の上で第1期に着手
見送り
今回は見送り
対象
第1期(200万円・ナレッジ基盤+X・Threads等)の着手合意。第2期(100万円)は第1期検収後の継続判断(詳細は8章)
金額
第1期 200万円+第2期 100万円=構築計300万円+リリース後保守5万円/月(詳細は8章)
着工
2026年9月第1週(予定)
安心材料 30日時点でナレッジ基盤〜承認フローが稼働しない場合は計画を見直します(中間マイルストーンで停止判断可能)。

9.1 明日ご依頼したいこと

30秒でわかる:構築を進めるにあたり、明日の商談で先方にご準備・ご共有いただきたい項目のチェックリストです。ご準備が難しいものは順次で構いません。
先方にお願いしたいこと
  • Instagram/Facebook: Meta Business Manager への招待(ビジネスアカウント確認)
  • ブログの現状(WordPressか・投稿権限のご確認)
  • Facebook運用状況の共有
  • YouTube: 字幕取得のためのチャンネルOAuth協力(または収録原音データの共有ルート確立)
  • Voicy: 収録元音源の受け渡し方法
  • LINE公式アカウントのプラン確認
  • X: Premiumプラン種別+OCR収益化を狙うか(投稿方式の分岐点)
  • プレゼント企画の中身(景表法確認用)
当方準備(自社側)
  • YouTube Data APIキー発行
  • Meta App Review着手

10ご契約条件(契約書で定める事項)

30秒でわかる:金額以外の契約条件は、本資料ではなく契約書で確定します。ここでは契約書で定める項目の一覧のみを示し、この場で数値・条件を確定させるものではありません。
以下は「契約書で確定する項目」の一覧です。本資料の提示はあくまで目安であり、正式な条件は契約書の締結をもって確定します。
項目契約書で定める内容(例)
金額表記税別表記(消費税別途)
支払時期着手金・中間金・完了金等の分割条件と支払期日
検収条件投稿成功率・承認所要時間等のKPI例を基準に、検収の合否基準を契約書側で確定
修正回数構築期間中の仕様修正・軽微調整の対応回数の上限
移管範囲ソースコード・データ・運用手順書のうち、御社へ移管する範囲
API仕様変更時の対応各社公式APIの仕様変更を検知 → 一時停止 → 通知 → 修正、の対応フロー
解約・追加開発条件解約時の精算方法、スコープ外の追加開発を依頼する場合の条件
※ 本章は「契約書で確定する項目」の見出し一覧であり、具体的な数値・期日・回数はこの場では確定させません。正式なご契約時に個別協議のうえ契約書へ記載します。

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

30秒でわかる:本提案書と、根拠となるBase・調査報告・仕様書等の関係を1枚で確認します。各サブドキュメントには「何が書いてあるか」を1行で添えています。
本提案書(本Doc)
提案Base
根拠/投稿台帳
投稿台帳Base
本提案書(本Doc)
調査報告
要件定義v2
仕様書
開発計画
提案Base(事実・根拠・ワークフロー一覧) 本資料の数値・規約claimの根拠となる一次情報カード、比較表の元データ、ワークフロー定義を格納したBaseです。 提案Base を開く
投稿台帳Base 構築後に実際運用する投稿履歴・承認ログ・計測データを記録するBaseの雛形です。 投稿台帳Base を開く
  • 調査報告 — 現行運用の実態調査(バックデスク実費集計・媒体別公式規約の一次情報調査)
  • 要件定義v2 — Phase1(今回スコープ)の機能要件・非機能要件の詳細定義
  • 仕様書 — システムの詳細仕様(API連携仕様・データ構造・状態管理設計)
  • 開発計画 — M1〜M3の詳細タスク分解とスケジュール(5章ロードマップの元データ)
付録 — 詳細根拠・技術仕様

ここから先は、本編の結論を裏付ける詳細な比較表・スコアリング・Q&A・全媒体規約対応表・出典・用語集です。決裁のご判断には本編(1〜11章)で十分です。技術的な根拠を掘り下げたい場合にご参照ください。

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

このページの内容:4章「本提案の違い」の根拠となる詳細データです。CoWork系とコーディングエージェント構築(Claude・Codex・Gemini)の境界表と想定問答をまとめています。10点満点スコアリングの全軸データは4.3.2章本文に掲載しています。

A.1 境界表

項目CoWork系(アプリ内自動化)コーディングエージェント構築(本提案)
定型処理・Lark内データ操作 得意フォーム連携・承認フロー・Base更新等はCoWorkで十分 対象外に近いLark内で完結する定型処理まで作り直す必要はない
外部公式API直結(X・Meta・LINE) 標準機能では未対応(当社確認時点)アプリ内の自動化の枠を超えるため対象外 対応各社公式APIへの認証・投稿・エラーハンドリングを個別実装
アルゴリズム実装準拠の投稿設計 標準機能では未対応(当社確認時点)投稿予約の枠組みしか持たない 対応X公式アルゴリズム実装等を踏まえた投稿ロジックを組み込み
状態機械と冪等性(二重投稿防止) 標準機能では未対応(当社確認時点)実行状態の管理は設計対象外 対応D1等での投稿履歴管理により同一内容の二重実行を防止
規約ガードレールの機械強制 標準機能では未対応(当社確認時点)人間が都度チェックする前提 対応景表法・媒体規約に抵触し得る表現を設計段階で機械的に除外
多段レビューと自己修正ループ 標準機能では未対応(当社確認時点)単発の処理実行のみ 対応生成→承認→要修正→再生成のループを構造化
実測データでの継続チューニング 標準機能では未対応(当社確認時点)実行結果の分析・反映機構を持たない 対応投稿→計測→チューニングの継続改善ループを構築に含める

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

Q1. 市販ツールでもXに自動投稿できますよね?
A. 投稿はできます。ただしXが公開するソースコードを参考にした仮説設計+実測検証(共有20.0/いいね0.5等の公開値ベース)・規約チェック+人の最終承認・二重投稿防止・学習ループは載っていません。翌週から実測検証を開始する体制の有無が差になります。
Q2. Lark CoWorkで同じことは作れませんか?
A. Lark内のデータ操作・承認フローまでは得意です。ただしX/Meta/LINEの公式API直結、状態機械による二重投稿防止、規約変更の定期検知・反映(人の承認後)はアプリ内自動化の対象外で、コーディングエージェントでの個別構築が必要です(付録A.1 境界表参照)。
Q3. トンマナ学習は市販ツールにもある機能では?
A. 「テンプレートの型」を提供する機能はありますが、黒字社長個人のトーン&マナーを学習し、媒体をまたいで一貫させる仕組みではありません。汎用テンプレートと個別学習は別物です(4.1.1章 比較表)。
Q4. 300万円は初期費用として高くありませんか?
A. 単体の投稿予約機能だけを見れば高く映ります。しかし本提案は規約遵守設計・二重投稿防止の状態管理・継続改善ループまでを含む「仕組み」です。この仕組みとナレッジDBは構築後、御社に資産として残ります(5章参照)。
Q5. 媒体規約やアルゴリズムが変わったらどうなりますか?
A. 市販ツールは提供元のアップデート待ちになりますが、本提案は規約・アルゴリズムの変更をガードレール(policy registry的な定期チェック)として組み込むため、変更への追従を運用の一部として設計しています(7.4章参照)。

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

30秒でわかる:本提案が対象とする全媒体について、規約上の制約と当方の対応方針を1表にまとめました。各行に出典番号を付し、巻末「出典一覧」で公式ソースを確認できます。
媒体規約上の制約当方の対応出典
YouTubeyt-dlp等による自動取得は規約上の制約があります原音・公式API経路(YouTube Data API・OAuth)を採用[1][2]
Voicy公式APIが提供されていません(未確認=現時点で当方が確認できた公式情報なし)原音ルート(収録元音源の受け渡し)を採用
Instagram・Facebook自動投稿・Private Reply機能の利用にはApp Review(事前審査)が必須。Private Replyはコメントへの1回のみ送信が原則。インセンティブ付きの誘導は禁止App Review着手を当方準備事項に計上。Private Replyはコメント募集経路に限定して利用[3][4]
X自動化には複数条件(本人確認・重複投稿禁止等)があり、OCR(収益化プログラム)はautomated meansで作成・投稿されたコンテンツを対象外とする規定があります収益化を狙うアカウントは人間の最終投稿を既定に設計[5][6]
TikTok自動化・API利用に関する審査があり、転載コンテンツには制限があります媒体ネイティブ生成を原則とし、後続フェーズで審査対応を検討[7]
note公式投稿APIが提供されていません(未確認)下書き生成+人による手動投稿を採用
Substack投稿用の公式APIが提供されていません(未確認)下書き生成+人による手動投稿を採用
LINEプッシュ配信は通数課金制です友だち追加直後のあいさつメッセージ等、価値提示のタイミングを設計(後続フェーズ)[8]
※ 「未確認」と記載した項目は、当方が2026-08時点で確認できる公式情報が見当たらなかったことを意味し、「制約が存在しない」ことを意味しません。最新の規約は各社公式サイトでの確認を推奨します。

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

X以外の全媒体も各社の公式説明のみを根拠に投稿設計へ反映。共通原則は5つ: 保存・シェア・返信を狙う/完視聴を取る/媒体ネイティブに作る(転載しない)/テーマ一貫/煽り・スパム挙動の排除。
媒体公式に明記されたポイント本システムでの対応
Instagram保存・シェア・反応の速さが主要シグナル。他媒体ロゴ入り・文字主体・転載リールは推薦制限と公式明記媒体ネイティブに1本ずつ生成(使い回し転載をしない)。保存されやすい要点型を優先
TikTokいいね/シェア/コメント+キャプション・音源・タグ。フォロワー数は直接要因でないと公式明言タグ・音源のテーマ一貫設計。新規アカウントでも戦える
YouTubeショート視聴選択率・平均視聴時間・視聴率で決まる冒頭数秒で完視聴を取る台本構成
YouTube通常検索一致+視聴時間+満足度。投稿頻度・時刻での優遇はしないと公式明記頻度より1本の満足度。タイトル/説明の検索意図一致
Facebookシェア・滞在の予測でスコア。怒り誘発・報告は降格シェア予測型の構成。煽り表現の機械チェック
Threadsフォロー+推薦ブレンドのエンゲージ予測返信を誘う会話型
note / Voicyおすすめロジックの公式説明なし(未確認)推測でKPIを立てず、外部誘導と固定読者維持を主軸
LINEアルゴリズムなし(プッシュ配信・通数課金)。あいさつメッセージが最大接点友だち追加直後の1通に価値提示を集約
「毎日投稿すればアルゴリズムに優遇される」という俗説は、どの媒体にも公式根拠がありません(YouTubeは公式に否定)。本提案は量ではなく、各媒体の公式シグナルに沿った質で設計します。出典一覧は根拠Base・調査台帳、および下記の出典一覧を参照。

付録D: 出典一覧

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

番号内容公式ソース(ドメイン)
[1]YouTube 自動取得・スクレイピングに関する制約support.google.com
[2]YouTube Data API・OAuthsupport.google.com
[3]Meta App Review・プラットフォーム利用規約transparency.meta.com
[4]Instagram/Facebook Private Reply仕様transparency.meta.com
[5]X 自動化ルールhelp.x.com
[6]X Original Content Rewards(OCR)・アルゴリズム公開ソースdocs.x.com/github.com(xai-org/x-algorithm)
[7]TikTok 自動化・API利用規約support.tiktok.com
[8]LINE公式アカウント・通数課金developers.line.biz
[9]Cloudflare Workflows・実行基盤developers.cloudflare.com
※ 各URLの詳細ページ(記事単位)は裏取り台帳(根拠Base)に一次情報カードとして保管しています。本表はドメイン単位の索引です。

付録E: 用語集

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

用語ひとことで言うと本件での使い方
yt-dlp動画サイトから動画を自動保存する外部ツール規約違反になるため本件では使いません
APIサービス同士をプログラムでつなぐ公式の窓口YouTube Data API・X API・LINE APIなど、各サービスの公式な操作口として利用します
Webhook相手側で何かが起きた瞬間に自動で通知が届く仕組み後続フェーズの反応検知(コメント等)に使う想定です
whisper音声を文字に起こすAIYouTube/Voicyの原音を文字起こしする工程で使用します
Cloudflare Workflows処理の流れを止まらず順番に実行してくれるクラウドの仕組み。承認待ちで何日でも待機できる取込〜承認〜配信までの一連の処理を裏側で管理する基盤として使用予定です
digest.json文字起こしから要点だけを抜き出した「素材シート」ここから各SNSの投稿文を作ります。生の文字起こしから直接投稿文は作りません
D1実行記録を正確に残すデータベース同じ内容を二重に投稿してしまうことを防ぐために使います
Private Replyコメントをくれた人にだけ1回DMを送れるInstagram/Facebookの公式機能後続フェーズのプレゼント企画等で、規約に沿う形で使う想定です
OCR(Original Content Rewards)Xの新しい収益化プログラム(2026-09-08〜)「automated meansで作成・投稿されたコンテンツは対象外」のため、収益化を狙う場合はXの投稿を人間の最終操作にします
qualified impressions収益計算の対象になる閲覧数。課金ユーザーがホーム画面で見た分だけ数えられるX収益化の計算根拠となる指標です(本提案の主対象ではありません)
LIFFLINEの中で動くWebアプリ後続フェーズで予定している診断機能をここに載せます
SDK開発を楽にする公式部品セット各SNSへの投稿機能を実装する際に利用します
PoC本採用の前に小さく試す検証構築初期に一連の流れが通しで動くかを検証します
RSS新しい投稿が出たことを機械が知るための公式の更新情報YouTubeの新規投稿を自動検知する入口として使います
Batch API急ぎでない処理をまとめて安く実行する方式(半額になる)週次レポート等、急がない処理のコスト削減に使用予定です
OAuth本人確認のうえで公式に権限を借りる仕組みYouTube Data APIを自チャンネルの権限で呼び出す際に使います
App Review(アプリ審査)Meta(Instagram/Facebook)側の事前審査後続フェーズで自動投稿・Private Reply機能を使うために必要な手続きです
R2Cloudflareのファイル保管サービス取り込んだ原音ファイルの保管先として使用予定です