1人で8つのSNSを自動運営している話 ― 仕組みと学びを全部書く

「SNS、ちゃんとやりたいんだけど時間がなくて」

この言葉を、ここ1年で何度聞いたか分かりません。僕自身もまったく同じことを思っていました。会社員をしながら、空いた時間で何かを発信したい。でも毎日コンテンツを作って、しかも複数のプラットフォームに投稿し続けるなんて、現実的に無理だと。
でも今は、状況が変わりました。

毎朝、僕が寝ている間に動画が1本生成され、YouTube・Threads・Instagram・Facebook・TikTok・BlueSky・Mastodon・WordPress の8チャネルに投稿が自動で流れていきます。日によっては、スマホで「ちゃんと出てるな」と確認するだけ。手作業はほぼゼロです。
この記事では、その仕組みを包み隠さず全部書きます。技術の話も、ビジネスの話も、そして失敗談も。「個人でもここまでできるのか」という一例として読んでもらえたら嬉しいです。少し長くなりますが、これから自分でも自動化を組んでみたい人に向けて、設計の「考え方」までできるだけ言語化してみました。

なぜ「8つも」やることになったのか

そもそものきっかけは、楽天モバイルの紹介（アフィリエイト）でした。
「いいサービスだと思うから、紹介リンクをSNSで広めてみよう」。最初はそれだけの、ごくシンプルな動機です。X（Twitter）に少し投稿してみる、くらいの軽い気持ちでした。
ところが、すぐに壁にぶつかります。
1つのプラットフォームだけでは、届く人が限られる。 Xにいる人、YouTubeで検索する人、Instagramを眺める人、それぞれ別の層です。同じ「楽天モバイルが気になっている人」でも、どこで情報を得るかは人によってまったく違う。だったら、できるだけ多くの入り口を用意したい。
でも今度は別の問題が立ちはだかります。8つのSNSに毎日手で投稿するのは、絶対に続かない。 1日15分かかるとして、8チャネルで2時間。本業のある会社員には不可能です。
ここで僕が立てた方針はひとつでした。

そして目標を、こう定義しました。「毎朝、自分が何もしなくても投稿が出ている状態を作る」。これがすべての設計の出発点になりました。

「チャネルポートフォリオ」という発想

もう少し踏み込んで、なぜ「8つ」なのかを書かせてください。これは単に「数が多いほうが偉い」という話ではなくて、僕の中ではれっきとした事業判断でした。
ひとつのチャネルに依存することには、見えにくいリスクがあります。

• アルゴリズムの変更: ある日突然「おすすめに乗らなくなる」ことがある。表示ロジックは運営側の都合で変わり、こちらは制御できない。

• アカウント凍結・仕様変更: APIが急に有料化されたり、規約が変わったり、最悪アカウントが止まる。たった1つのチャネルに全部を乗せていると、それが起きた瞬間にゼロになる。

• ユーザー層の偏り: 1つのSNSにいる人は、どうしても似た属性に寄ります。

僕はこれを、投資の「分散」と同じだと考えるようになりました。1つのチャネルに全張りするのではなく、性質の違う入り口を複数持っておく。 どれかが落ち込んでも、別のどれかが拾ってくれる。これが「チャネルポートフォリオ」の考え方です。
実際、各チャネルのユーザー層はかなり違います。YouTubeは「比較検討してから動く人」、Threads/Xは「日々の話題に反応する人」、Instagram/TikTokは「ビジュアルでなんとなく知る人」、WordPressは「検索で能動的に調べに来る人」。同じメッセージでも、刺さる人が違う。だから入り口を増やすほど、取りこぼしが減っていきます。

「限界費用ゼロ」だから増やせる

ただ、ここで多くの人が「いや、それは分かるけど物理的に無理でしょ」と止まります。僕も最初はそうでした。
転機になったのが、一度自動化を組んでしまえば「チャネルを1つ増やす手間」がほぼゼロになるという気づきです。経済学でいう「限界費用ゼロ」の状態です。

手動運用だと、チャネルを1つ足すたびに、毎日の作業時間がまるまる増えます。9個目を足したら、また15分。これは線形に増えていくので、どこかで必ず破綻する。
でも自動化されたパイプラインなら話が違います。新しいSNSのAPIに「投稿する」処理を1回書いてしまえば、あとは毎朝勝手にそこへも流れる。追加の運用コストは事実上ゼロ。 だから「やらない理由」がなくなる。Mastodonを8媒体目として足したときも、追加の日々の負担はほぼ感じませんでした。手動運用と自動運用の決定的な違いは、ここにあります。

全体の仕組み ― 1本のパイプライン

まず全体像から。毎朝2時、僕が寝ている時間に、こんな順番で処理が走ります。

1. 台本生成 ― その日のテーマに沿って、AIが動画の台本（ナレーション原稿）を作る

2. 動画生成 ― Remotion（ReactでMP4を作るツール）でスライド形式の動画を組み立てる

3. 音声生成 ― Irodori-TTSで、決まったキャラクターの声でナレーションを生成する

4. サムネイル生成 ― Geminiの画像生成で、その日の内容に合ったサムネを作る

5. YouTubeへアップロード ― できあがった動画をPythonでアップする

6. 全SNSへクロスポスト ― YouTubeのリンクや派生コンテンツを、残りのチャネルへ自動配信する

この6ステップを、1本のPowerShellスクリプトが順番に呼び出しています。それをWindowsのタスクスケジューラに登録して、毎朝2時に自動起動させているだけ。

なぜ「巨大な1本のスクリプト」にしなかったのか

ここが設計上、一番こだわったところです。
最初に思いつくのは、「全部入りの巨大なスクリプトを1本書く」という発想です。台本も動画も音声も投稿も、全部1つのファイルの中で完結させる。一見シンプルに見えます。
でも、僕はあえてそうしませんでした。代わりに、各ステップを独立した小さなプログラムに分けて、その間を「ファイル」で受け渡すという設計にしました。

具体的には、こんなふうにバトンが渡って

台本生成 → script.txt （その日のナレーション原稿）
動画生成 → video.mp4 （スライド動画。script.txt を入力に使う）
音声生成 → narration.wav （ナレーション音声）
サムネ生成 → thumbnail.png （サムネイル画像）
アップロード→ video_id （YouTube上の動画ID）
クロスポスト→ 各SNSへ投稿 （video_id とリンクを使う）

この**疎結合（各ステップが互いに直接依存せず、ファイルだけでつながる）**には、地味だけど大きな利点が2つあります。

(1) 1ステップだけ差し替えられる。 たとえば「音声生成のツールを別のものに替えたい」と思ったとき、音声のステップだけを書き換えればいい。入力（台本）と出力（音声ファイル）の形さえ守れば、前後のステップは何も知らなくていい。巨大な1本だと、1か所いじるたびに全体が壊れないか怖くなりますが、分かれていればその心配がない。

(2) 途中から再実行できる。 朝起きて「サムネだけ気に入らないな」と思ったら、サムネのステップだけ動かし直せばいい。台本も動画も音声も、すでに出力ファイルがあるので作り直す必要がない。これが地味に効きます。
骨格のイメージを、考え方が伝わる範囲で擬似コードにするとこんな感じです（実コードではなく概念です）。

$script = New-Script -theme $today # → script.txt
$video = New-Video -script $script # → video.mp4
$voice = New-Voice -script $script # → narration.wav
$thumb = New-Thumb -theme $today # → thumbnail.png
$id = Upload-YouTube -video $video -thumb $thumb # → video_id
Crosspost-All -videoId $id # → 各SNSへ

各 New-* や Upload-* は、それぞれ独立したPythonやNodeのプログラムを呼んでいるだけ。PowerShellは「順番に呼ぶ指揮者」に徹しています。

なぜ「深夜2時」なのか

スケジューリングにも理由があります。タスクスケジューラの起動を朝ではなく深夜2時にしているのは、主に2つの狙いです。

• API混雑を避ける: 各SNSのAPIも、人が活動する昼間より深夜のほうが安定して速いことが多い。重い動画生成も、誰も使っていない時間に走らせたい。

• 朝には「完成品」を確認できる: 2時に走り始めれば、僕が起きる頃には全部終わっている。寝ている間に作業が終わり、朝はスマホで「ちゃんと出てるな」と確認するだけ。もし何か失敗していても、人が動ける朝の時間帯に気づける。これが大事で、「投稿の直前に処理する」設計だと、失敗したときに対応する余裕がありません。

べき等性 ― 「2回走っても壊れない」こと

もうひとつだけ、概念として触れておきたいのが**べき等性（idempotency）**です。難しい言葉ですが、要は「同じ処理を2回走らせても、結果がおかしくならない」という性質です。
なぜ重要か。自動化は、必ずどこかで失敗します。ネットワークが切れる、APIが一瞬詰まる、PCが再起動する。そのとき僕がやりたいのは「失敗したところからもう一度走らせる」ことです。でも、もし再実行で「同じ動画が2本投稿される」ようなことが起きたら台無しです。だから、各ステップは「すでに出来ているものは作り直さない／同じ投稿は二重に出さない」ように作っておく必要がある。

ここを最初に意識しておくかどうかで、運用の安心感がまったく変わります。詳しい実装の工夫は連載の技術編で書く予定なので、ここでは「なぜ重要か」だけ押さえておいてください。

各プラットフォームの「クセ」と付き合う

8つもあると、それぞれにクセがあります。一つずつ紹介します。

YouTube ― 動画の本拠地

メインの動画置き場です。Remotionでスライド形式の動画を生成しています。ショート動画は朝に即時公開、長尺は内容を確認してから手動公開、という運用にしています。

Threads / Instagram ― Meta Graph API

どちらもMetaのGraph API経由で投稿します。Threadsは「1日4回の紹介投稿ローテーション」と「キャンペーン専用投稿」の2系統が動いていて、ここで後述する厄介なバグも踏みました（その話はDay2以降の記事で詳しく書きます）。

BlueSky / Mastodon ― オープンなプロトコル

この2つは技術的に一番扱いやすい。BlueSkyはAT Protocol、MastodonはActivityPubという、オープンな仕組みの上に乗っているので、HTTPリクエストを直接投げれば投稿できます。広告審査のような壁もありません。チャネルを増やす「限界費用ゼロ」を一番実感したのが、この2つの追加でした。

Facebook ― OGP付きリンク投稿

YouTubeのリンクを、サムネ付き（OGP）でページに投稿します。Page IDを指定してAPIで直接ポスト。

TikTok ― 半自動

正直、ここはまだ完全自動化できていません。動画の直接投稿APIは審査（App Review）が必要で、まだ取得できていない。なので投稿自体は手動ですが、「投稿する準備ができたよ」という通知だけは自動化しています。正直に言うと、ここが今いちばんの伸びしろです。

WordPress ― 記事の自動生成

これは動画とは別系統のパイプラインです。AIで生成した記事を、REST API経由で自動投稿しています。3サイト運営していて、累計で約15,000記事、月間PVは12万を超えました。動画とは「反応の窓」がまったく違うチャネルで、後述するように検索流入という別の時間軸で効いてきます。

技術スタックの全部

「特別なものを使っているんでしょう?」とよく聞かれますが、答えはNoです。

一番難しかったのは、技術じゃなかった

ここまで技術の話をしてきましたが、一番苦労したのは実はコードではありません。
「どこから来たのか」を測ることでした。
8つのSNSに、同じ紹介リンクを貼っています。すると、成約が発生したときに「どのSNSが効いたのか」がまったく分からなくなる。全チャネルで同一URLを使っているので、URLのパラメータでは区別できないんです。
解決策として、2つのことをやりました。

1. 成約ログの自動取得: 毎朝、紹介経由の成約データを自動で取得して、履歴として蓄積する

2. Threadsだけは個別計測: ThreadsのAPIには「投稿別のクリック数」を取れるエンドポイントがあるので、それを専用スクリプトで取得する

でも正直に言うと、完全なチャネル別アトリビューション（どのSNSが何件成約に貢献したか）は、まだ解けていません。

「個人でもCAC/LTVで考える」と判断が変わる

ここで、ビジネス的な視点を1つ共有させてください。
企業のマーケティングでは当たり前に使う言葉に、

**CAC（顧客獲得単価＝1件の成約を得るのにかかったコスト）と
LTV（顧客生涯価値＝1人の顧客が生涯でもたらす価値）**

があります。

これ、個人の発信でもまったく同じ枠組みで考えられます。

「再生数が伸びた」「いいねが付いた」という指標は、見ていて気持ちいい。でも、それ自体はお金を生みません。本当に見るべきは、**「最終的に何件の成約につながったか」「その1件にいくらかかったか」**です。
ここで僕の構造が効いてきます。サーバー代は固定（月数千円）で、自動化されているのでチャネルを増やしても追加コストはほぼゼロ。ということは、チャネルを増やして成約の総数が増えるほど、1件あたりの獲得コスト（CAC）はどんどん下がっていく。固定費を、より多くの成果で割り算していく構造です。これは手動運用では絶対に作れない経済性で、自動化の本当の旨味はここにあると思っています。
だから僕は、「再生数やいいね」ではなく「アウトカム（成約）」を北極星に置くようにしました。とはいえ、冒頭に書いた通り「どのチャネルが効いたか」の精密な切り分けはまだできていない。次回のDay2は、まさにこの話を正面から扱います。

この経験から学んだ一番大きな教訓は、**「計測の設計は、運用を始める前に決めておくべきだった」**ということです。作り始めてから「あれ、どこから来たか分からない」となると、後から追跡する仕組みを足すのは本当に大変。この話だけで記事が1本書けるので、Day2で詳しく扱います。

やってみて初めて分かったこと

実際に8チャネルを動かしてみて、一番面白かった発見がこれです。
SNSごとに「反応の窓」が、まったく違う。

• Threads は、投稿直後の数分が勝負。最初のリアクションが付くかどうかで、その後の伸びが決まる

• BlueSky / Mastodon は、数時間で反応が落ち着く

• YouTube / Facebook は、翌日以降にじわじわPVが伸びてくる

• WordPress に至っては、記事が検索にインデックスされてから数週間後に流入が始まる

同じコンテンツを出しても、反応が来るタイミングがこれだけバラバラなんです。だから「全部同じ時間に同じ投稿」では最適化できない。それぞれの「窓」に合わせて投稿時間と内容を変えるだけで、数字が変わりました。
そしてもう一つ、運用を続けて辿り着いた考え方があります。

手作業でやっていたら、1週間かけて確認できる量。それが自動化すると1日で確認できる。この「観察の速度」の差が、そのまま「改善の速度」になる。自動化の本当の価値は、空いた時間そのものより、その時間で回せる試行回数にあると感じています。8チャネル × 毎日、という観察データが勝手に溜まっていくこと自体が、一番の資産かもしれません。

まとめ ― 個人でもSNSは自動化できる

長くなりましたが、伝えたいことは3つです。

1. 「パイプライン」として設計する。個別ツールの寄せ集めではなく、入力から出力まで1本で繋がった流れとして考える。各ステップは独立させ、ファイルでつなぐ。そうすれば差し替えも部分再実行もできる

2. 計測設計を、作る前に決める。後から「どこから来たか分からない」状態になると、取り返しがつかない。見るべきは再生数ではなく「成約というアウトカム」

3. 自動化の目的を「観察量の拡大」に置く。速くなった分だけ、試す数を増やす。チャネルを増やす限界費用がゼロになれば、ポートフォリオとして分散も効く

技術的な難易度は、実はそれほど高くありません。むしろ「何を自動化して、何を測るか」という設計判断が、結果の9割を決めている気がしています。
次回（Day2）は、この記事で一番難しかったと書いた**「計測（アトリビューション）」の話**を深掘りします。8つのSNSに同じリンクを貼った人間が、どうやって「効いているチャネル」を見極めようとしているか。技術的な工夫と、それでも残る限界について書きます。

楽天モバイルのご紹介はこちらから: https://r10.to/h5z92p?openExternalBrowser=1 #PR