Claude CodeでSNS運用を自動化する方法 — ネタ収集・下書き・予約・分析の4工程

SNS運用を「4つの工程」に分解する

SNS運用を自動化しようとすると「全部AIに任せる／全部人がやる」の二択で考えがちですが、実務では工程ごとに任せる度合いを変えるのが安定します。SNS運用は大きく①ネタ収集②下書き作成③予約・投稿④効果分析の4工程に分けられ、Claude Codeが最も力を発揮するのは①②④で、③の「公開する」瞬間だけは人の確認か機械的なチェックを挟む設計が基本になります。

先に決めるのは「媒体ごとに、どこまで任せるか」

4工程の前に決めておくべきなのが、媒体ごとの「任せる上限」です。同じ会社の運用でも、媒体によって公式APIの有無・利用規約・投稿の重みが違うため、一律に「全自動」とはなりません。当社では次の3段階に分けています。

Instagramを「AIは一切触らない」に置いているのは、利用規約が自動化された手段によるアクセスを認めていないためです。当社では過去に、本人がログインしているブラウザからAIに操作させたところアカウントに自動アクセスの痕跡が残った経験があり、以後はAIからの閲覧・取得・操作を全面的に禁止し、ツール側でも機械的に拒否する設定にしています。数値が必要なときは人がスクリーンショットを撮って渡します。

投稿の手段は「公式APIがある媒体はAPI、無い媒体はブラウザ操作、規約上NGの媒体は手動」が使い分けの基本です。APIはブラウザ操作より確実で、無人の定期実行に向きます。

投稿用のAPIが無い、または使わない媒体（当社ではX記事・note・LinkedInなど）は、Claude in Chromeなどのブラウザ操作ツールで補います。API連携の考え方はMCP・CLI・API連携の解説にまとめています。

①ネタ収集 — ニュースやトレンドを毎日拾わせる

Claude CodeにはWeb検索を行うツールが備わっており、業界ニュースや競合の投稿、過去によく読まれた自社コンテンツの傾向などを、指定した条件で毎日拾わせることができます。「良いネタが無い日は無理に投稿しない」という判断も、基準を指示文に書いておけばAI自身に行わせられます。

• 情報源を絞る。「このジャンルのニュースサイト」「このアカウント群の投稿」など対象を限定しないと、関係の薄い話題まで拾ってしまう
• 採用基準を先に言語化する。「読者の実務に関係するか」「既に自社で書いた話題と重複していないか」など、選ぶ・捨てるの判断軸を指示文やルールファイルに書いておく
• 在庫として溜めさせる。毎回ゼロから探すのではなく、見つけたネタを候補リストに積み、下書き工程で選んで使う設計にすると、良いネタが無い日でも過去の在庫から拾える

以前は媒体ごとのフォルダにネタを置いていましたが、ある媒体の運用を止めた期間にそこのネタが死蔵する失敗があり、「ネタは媒体に依存しない資産、媒体ごとの書き方は媒体側」に分離しました。採否の基準は「半年前にも書けた話なら不採用」（鮮度）と「出所が紐付かないネタは捨てる」の2つで、候補が全滅した日は「ネタ切れ」として投稿しません。

②下書き作成 — トーンと禁止表現を型にして守らせる

下書き作成でつまずきやすいのは、「毎回トーンがぶれる」「気づくと禁止表現を使っている」という点です。これはCLAUDE.mdなどのルールファイルに、文体・文字数・使ってはいけない言い回しを書いておき、下書きのたびにそこを参照させることで防げます。ルールを毎回言葉で説明し直す必要がなくなり、担当者が変わっても同じ品質を保てます。

• 文字数・改行位置などの形式面は具体例つきで書く。「120字以内」だけでなく良い例・悪い例を1つずつ添えると再現性が上がる
• 禁止表現・恐怖訴求などのトーン規定は明文化する。基準が曖昧だと、AIは前後の文脈から「それらしい強い言葉」を選びがちになる
• 媒体ごとに下書きの型を分ける。短文SNS・記事・メールでは求められる長さも構成も違うため、同じルールを使い回さない

当社で実際に媒体別のルールファイルに書いている型の例を挙げます。Threadsでは「1投稿目は一行で、固有名詞（ツール名・業務名）を必ず入れる」「APIやターミナルなどの実装用語は1投稿目に出さず2投稿目から」「2投稿目は450〜500字で、上限は改行込みの実カウントで測る」。Xでは「本文にリンクを置かず、案内はリプライに書く」。

Facebookでは「本文にリンクを入れず、申込URLは1コメント目に置く」（本文リンクは配信が抑制されるため）。記事媒体では「全段落に太字を1か所入れる」「見出しは2階層までにする」などです。

こうした型は、最初から完璧に書けたものではありません。たとえば「太字などのMarkdown記法を使わない」というルールは、記法の記号がそのまま画面に表示された事故の後に追加したものです。事故が起きるたびにルールファイルへ1行足していくことで、同じ失敗が二度と起きない仕組みになります。

③予約・投稿 — 「公開する」瞬間だけは人か機械ゲートを挟む

ここが最も注意が必要な工程です。Claude Code自体にX（旧Twitter）などSNSへ直接投稿する機能は無く、各SNSの公式APIやMCPサーバー、ブラウザ操作ツールと組み合わせて実現する構成になります。

投稿という操作は一度公開すると取り消しが効きにくい不可逆操作なので、権限設定の考え方に沿って、公開の直前に必ず人の確認を挟むか、機械的なチェックを通してから公開するかのどちらかを設計しておく必要があります。

当社では投稿前に人がGOを出す代わりに、「機械ゲートを全部通過したことをGOの代替とする」と明文化して無人で公開しています。ゲートは大きく3種類あります。

1. 1形式のチェック。文字数（APIが実際に数える方式で測る）・段落数・禁止語句の有無・表記ゆれ（正規表現で機械検出）を、スクリプトで判定する
2. 2内容のチェック。ファクトチェック担当と公開安全（顧客情報・未公表情報の混入がないか）担当を別々のサブエージェントとして並列で走らせ、さらに複数の観点で採点し、基準に届かなければ差し戻して書き直させる（上限回数を決め、超えたら公開せず通知）
3. 3重複・タイミングのチェック。直近の投稿と本文を照合して二重投稿を防ぐ、当日すでに公開済みならスキップする、定刻から大きく遅れて動いた場合は投稿せず「取りこぼし」として通知する

• 1日に5本を一気に公開してしまった後は、「1日1本」をスクリプト側で強制し、当日公開済みなら拒否するようにした
• 文字数の上限を「改行を除いた文字数」で測っていたために本番のAPIで超過し、連投の途中で止まって片方だけ公開された後は、投稿直前に全パートを再検証し、1本でも超過があれば全部出さない設計に変えた

無人で公開するなら、「止まる側に倒す」設計が原則です。判断に迷う状態（本人確認が取れない・前回の投稿状態が不明・時間が大きくずれた）では投稿せず、人に通知して終わる。多少の取りこぼしよりも、誤投稿・二重投稿の方が取り返しがつかないためです。

④効果分析 — 数字を次のネタ選定に返す

投稿して終わりにせず、閲覧数や反応の良し悪しを週次でまとめ、次のネタ選定の基準に反映するところまでを自動化すると、運用が回すほど改善されるループになります。「当たったテーマの傾向」「反応が薄かった時間帯・形式」を定期的に言語化させ、①のネタ収集の基準を更新していく設計です。数値の集計自体はデータ分析の自動化と同じ考え方が使えます。

当社の週次レビューは、APIで直近2週間の数字を取得し、今週と前週を比べて「当たり・外れ」と「次に試すネタ」を書き出すところまでをClaude Codeが行います。ここで守っているのが、「同じ傾向が3週連続で出るまで、運用方針そのものは書き換えない」というルールです。

1〜2週の変動で方針を変えると、AIが毎週違う方向に振れてしまいます。書き出し先は「次ネタ帳」と「週次の観測ログ」の2ファイルだけに限定し、方針の正本は3週続いたときだけ更新します。

数字の読み方にも型を作っています。Threadsでは「閲覧数は1投稿目（見出し）の成績、いいね率など反応の質は本文の成績」と分けて読み、閲覧数上位の投稿はコメント欄を開いて反発が多いものを当たり判定から除外します。閲覧数だけで判断すると、反発で伸びた投稿を「成功パターン」として量産してしまうためです。

実測の例を挙げます。Threadsで120,925viewsを記録した投稿は、いいね57・返信1で、いいね率は0.05%でした。広く配られても、読み手が想定読者（事業者）でなければ反応にも問い合わせにも転換しないことを示す数字で、以後は閲覧数の大きさより「誰に届いたか」を優先して型を選んでいます。

同じ型を続けると反応が落ちることも数字で確認しています。ある型の投稿を同じ週に3本続けたところ、閲覧数は21,154→11,082→2,069と3本目で10分の1になりました。この結果から「同じ型は週2本まで」という摩耗ガードをルールファイルに入れ、生成時に機械的に守らせています。

Xでは、記事を公開した後に引用リポストで拡散する運用を試しましたが、2026年7月の3週間の実測で記事本体の表示回数が引用リポストを一貫して上回りました（例: 本体2,515 vs 引用875）。この結果から「本体を主役に設計し、引用は補助」と方針を確定しました。

うまくいっている数字だけではありません。2026年8月のThreadsは、週合計の閲覧数が64,719→57,521→14,804と3週で大きく落ちました。自動化は「投稿を止めない」ことは保証しますが、「伸びる」ことは保証しません。この落ち込みも週次レビューが機械的に捕捉し、型の配分見直しに入っています。

週次レビューには運用の監視という副作用もあります。2026年8月末、当社のX運用で週次レビューが「投稿本数が前週比で8割減」を検出し、原因を調べたところ定期実行の一部が動いていないことが分かり、翌日にルーティンを再設計しました。無人運用は静かに止まるので、数字を毎週見る仕組み自体が事故の検知装置になります。

定期実行の仕組みそのものはどう作るか

①②④を「毎日決まった時間に」「PCを起動していなくても」動かす仕組みの作り方は、SNS運用に限らない一般的な話です。デスクトップアプリのスケジュールタスク・クラウドのルーティン・ヘッドレスモードの使い分けは、Claude Codeの定期実行・自動化の解説記事にまとめています。SNS運用はこの仕組みの上に「ネタ収集→下書き→機械ゲート→投稿→分析」という業務固有のワークフローを乗せた応用形です。

非エンジニアでも設計できるのか

設計自体は非エンジニアでも可能です。「どの情報源からネタを拾うか」「文章のトーンをどう定義するか」「投稿前にどんなチェックを通すか」「どの媒体はAIに触らせないか」はマーケティング・広報の実務知識そのものであり、プログラミングの知識は不要です。エンジニアの助けが必要になりやすいのは、各SNSの投稿APIとの接続部分と、文字数チェックなどのスクリプト化です。

当社のClaude Code研修では、こうした「業務のどこをAIに任せ、どこに人の確認や機械ゲートを残すか」という設計そのものを、自社の運用を題材に組み立てるところまで扱っています。