Claude CodeでX運用を自動化する方法｜下書き・承認・効果測定

Claude CodeでX運用のどこまでを自動化できるか

Claude Codeが扱うのは、渡された資料・指示・利用を許可されたツールです。たとえば、原稿ファイルを作ること、過去の自社原稿と見比べること、取得済みの集計データを表にすることが作業候補になります。Xとの認証、配信日時の管理、投稿結果の取得は、別途用意する連携先の機能と権限に左右されます。Claude Code公式の機能概要でも、ファイル操作とツールの実行が説明されています。

「下書きができた」「予約を受け付けた」「公開された」はそれぞれ違う状態です。原稿を何本生成できたかだけで、運用全体を自動化できたとは判断しません。

X運用の下書きをClaude Codeで作る3ステップ

公式画像確認 2026-10-10

画像を拡大 ↗

1. 公開可能な資料と合格条件をそろえる

最初の題材は、自社で公開済みのサービス案内やイベント告知など、事実を照合しやすいものにします。必要なのは大量の資料ではなく、対象読者、伝える事実、出典、書いてよい範囲、確認する担当者です。顧客の未公開情報や、利用許可のない第三者の投稿・画像を試行用の素材に含めないようにします。

合格条件の例は「日付と申込先が資料と一致」「根拠のない実績を追加しない」「読者が次に取る行動が分かる」の3点です。文章の雰囲気だけで合否を決めると、事実の間違いを見逃しやすくなります。

2. 出典と未確認事項も一緒に出させる

次は、公開済み資料から下書きを作るための依頼例です。これは説明用のテンプレートであり、実際の投稿結果ではありません。

指定した資料だけを使い、X向けの下書きを1本作ってください。
対象読者：［読者］
目的：［読んだ後に理解してほしいこと］
根拠資料：［公開可能なファイル名・URL］
出力：本文案／事実の出典／確認が必要な箇所
資料にない実績、感想、日付は作らないでください。
投稿・予約・外部送信はせず、drafts/post-001.mdへ保存してください。
日本語の短文投稿1本に絞り、URLと画像の有無も記録してください。

Claude Codeの初回設定が必要なら、導入・設定ガイドから進められます。繰り返す依頼を手順としてまとめる段階では、Skillsの作り方が役立ちます。

3. 原稿・画像・リンクを人が確認する

本文の内容だけでなく、画像内の文字、出典の対象期間、リンク先が意図したページかまで確かめます。機械検品で調べられるのは、出典欄の空欄や、同じ原稿IDの登録の有無などです。一方、体験談の真偽や顧客名を出してよいかは、資料の管理者に確認する必要があります。

修正したら、承認の対象も修正版へ切り替えます。承認後に本文や画像を差し替えた場合は、変更部分を再確認してください。

毎日の依頼をCLAUDE.mdとSkillsに分ける

運用を続けるなら、専用フォルダに公開可能な資料、下書き、公開済み記録を分けて置きます。CLAUDE.mdにまとめるのは対象読者・口調・公開禁止情報などの共通方針で、Skillにまとめるのは繰り返す作業の手順です。Skillは作業手順をまとめたSKILL.mdで、Anthropicの公式説明では/スキル名からも呼び出せます。

x-operation/
  CLAUDE.md                 # 読者・口調・禁止事項
  sources/                  # 公開可能な根拠資料
  drafts/                   # 確認前の原稿
  published/                # 公開URLと最終原稿
  .claude/skills/x-draft/SKILL.md

フォルダ名は設計例です。指示ファイルに「投稿禁止」と書くだけで技術的に送信を止められるとは限りません。下書き担当に投稿ツールを許可しないなど、実行権限も分けます。採用した言い回しと差し戻し理由を蓄積すると、翌週の下書きにも自社らしさを反映できます。

X運用の連携方法を選ぶ：手動・予約サービス・X API

最初から配信機能まで自作する必要はありません。原稿を用意した後に、どこへ渡し、誰が結果を確認するかで選びます。

MCPは、Claude Codeから外部サービスの機能を呼び出すための共通の接続方式です。MCPでつないだ場合も、接続先の契約や認証、操作の権限は別途必要です。用意された機能を呼べることと、そのアカウントで対象の操作が認められていることを別々に確認します。

定期実行の場所も決めます。手元のPCで動く仕組みなら、PCの稼働・スリープ・通信状態に依存します。予約サービスやクラウド側で実行する場合も、停止・遅延時の確認方法は必要です。「毎朝9時」という指定にはタイムゾーンを添え、予定時刻を過ぎても結果がないときに誰が調べるかを決めてください。

X運用をTypefully MCPにつなぐ設定手順

ここでは、下書きと予約を一つのサービスで管理したい方向けに、Typefullyの公式MCPを例にします。以下は2026年11月3日に公式資料と照合した接続例で、この手順を今回新規接続・投稿まで実演した記録ではありません。Typefullyの利用条件と、対象Xアカウントの接続を先に確認してください。

1. 接続先を追加し、本人のアカウントで認証する

ターミナルでClaude Codeを使っている作業フォルダを開き、次のコマンドを実行します。AnthropicのHTTP接続構文に、Typefully公式の接続URLを指定した例です。

claude mcp add --transport http typefully https://mcp.typefully.com/mcp
claude mcp list

続いてClaude Code内で/mcpを開き、TypefullyのOAuth認証を完了します。OAuthは、パスワードをAIへ渡さずにサービスへのアクセスを認可する仕組みです。認証後は「接続されたSNSアカウントの一覧を取得し、投稿や予約はしないで」と依頼し、Xのユーザー名まで照合します。接続状態が正常でも、意図した投稿先とは限りません。出典：Claude CodeのMCP接続、Typefully公式MCPガイド。

2. まず下書きだけを保存し、管理画面で確認する

drafts/post-001.mdを読み、照合済みの［Xユーザー名］向けに
Typefullyの下書きとして1本保存してください。
投稿・予約はしないでください。
本文、添付画像、リンク、保存先アカウントを報告し、
下書きIDを記録してください。
同じ原稿IDの下書きがある場合は、新規作成せず知らせてください。

保存された下書きを管理画面で開き、文章・画像・リンクを確認します。Typefullyにある下書きは、X公式画面の下書きと同じ保存場所ではありません。下書きIDが取れたことと、X上で公開されたことも区別します。

3. 確認した版に限って予約し、公開後に照合する

承認には「下書きID・版・投稿先・日時・日本時間」を含めます。例えば「D-001の第2版を、確認したXアカウントへ11月10日9時（日本時間）に予約」のように指定します。これは書式例です。本文を直したら再確認し、配信後は公開URL・本文・画像・アカウントを照合します。

Typefullyの公式資料では、下書きの作成・編集・予約、投稿一覧の確認などを案内しています。使える機能は契約と接続状態を確認して選びます。X APIを自分で直接契約する方式とは費用を分けて比較してください。

X APIやX公式MCPを直接使う場合

自社の承認台帳・独自の配信処理へつなぐ場合は、X Developer Consoleでアプリ、必要な権限、課金条件を確認します。X公式MCPガイドには、API操作用のhttps://api.x.com/mcpと、開発資料検索用のhttps://docs.x.com/mcpが案内されています。資料検索用につないでも投稿機能は増えません。

ユーザーとして操作する接続は、公式のxurl mcpブリッジでアプリ情報とOAuthを扱う構成です。アプリ専用のBearer認証は読み取り用で、投稿者としての認証とは異なります。実際の操作可否は接続先が提供する機能と権限を確認してください。予約時刻の管理・承認台帳・失敗通知は、自分で実装するか対応サービスに任せます。秘密情報は共有ファイルや会話へ貼らず、適切な認証情報管理を使います。

X運用の承認・予約・公開をつなぐ記録

連携先を選ぶ前に、原稿がどの段階にあるかを追えるようにします。最低限、次の項目があれば、予約の受付と実際の公開を混同せずに確認できます。

通信が途中で切れたときは、送信側にエラーが出ても投稿が成立している場合を想定します。まず予約一覧や投稿履歴を照合し、同じ原稿が存在しないと確認してから再実行を判断します。「応答がないからもう一度送る」という処理は、二重投稿の原因になります。

複数アカウントを扱う場合は、アカウント名と原稿の対応を確認画面に表示し、文章と画像をひとまとまりで承認できる設計にします。違う顧客やブランドの原稿が混ざったら、配信を止めて対象を確認する条件も決めます。

通信が切れた場合の記録例：架空の原稿D-001・第2版を10月15日9時・日本時間に予約した直後、応答が途切れたとします。予約IDがあればそのIDを照会し、本文・画像・アカウント・日時を照合します。IDがなければ該当アカウントの予約一覧と公開履歴を調べ、見つからない理由まで確認できるまでは「結果不明・再送保留」にします。送信側のエラーだけを失敗と決めつけないことが、二重投稿を防ぐ要点です。

X運用の自動化にかかる費用を計算する

費用は、Claude Codeの利用料＋配信サービスまたはX APIの利用料＋運用・保守の工数で考えます。下書きだけならX APIは不要ですが、Claude Code自体の利用条件は別です。画像生成や別のAI APIを使う場合も、その料金を足します。

X公式の従量課金表（2026年11月3日確認）では、投稿作成は1リクエスト0.015米ドル、URL付き投稿作成は0.200米ドルです。読み取りは対象やエンドポイントで料金が異なります。ここでは比較しやすいよう、投稿作成部分だけを試算します。

これは当社の請求実績でも総額でもありません。読取り、メディア処理、追加リクエスト、税・為替、AI、配信サービスの料金を含みません。検索や分析を頻繁に行う運用では、投稿本数だけで費用を見積もらないでください。単価は変更され得るため、実行前にDeveloper Consoleの現行料金と利用上限を確認します。

費用対効果は「減った人の作業時間 × 社内で定めた時間単価 − 増えた利用料・保守費」で一次判断できます。例えば月4時間減り、時間単価を3,000円、追加費用を2,000円と置けば差額は10,000円です。これは仮定の計算例で、削減実績ではありません。確認や修正に時間が増える場合も同じ式に含めます。

Xの自動化ルールと、連携先の確認点

Xは自動化の方法や行為にルールを設けています。公式のX自動化ルールは、非API方式でXのWebサイトをスクリプト操作する自動化や、複数アカウントへの同一・実質的に類似した投稿などを制限しています。APIを使えば、どのような投稿でも認められるという意味ではありません。ここでの確認日は2026年11月3日です。

導入するサービスでは、投稿・予約・削除・分析のうち必要な操作ができるか、どのアカウントにアクセスするか、料金の単位、利用上限、失敗時の挙動を確認します。Xの仕様とサービス側の仕様は別なので、片方の説明だけで実装を決めないことが大切です。

認証情報は下書きや指示書へ貼り付けず、連携先が提供する認証手段で管理します。読者への返信やDMなどは、原稿の作成とは目的も相手への影響も異なります。発信の下書きが安定したことだけを理由に、別の外部操作まで自動化の範囲を広げないようにします。

X運用の自動化は何を測れば評価できるか

最初に「何を改善したいか」を1つ決めます。投稿準備の時間を減らしたいなら、人の確認・修正時間まで含めます。法人の問い合わせを増やしたいなら、表示回数だけでは判断できません。

たとえば、投稿数を増やした時期にフォロワーが増えても、過去投稿の反応、ニュース、広告、他の発信の影響があり得ます。対象期間と取得条件がそろわないデータは、そのまま優劣の根拠にせず、次に検証する仮説として扱います。

試行用の記録テンプレート

対象アカウント：
試行期間・タイムゾーン：
AIへ任せた工程／人が担当した工程：
作成数／承認数／公開数：
人の準備時間／確認・修正時間／配信後の確認時間：
開始時・終了時のフォロワー数と取得日時：
対象投稿ID／反応の取得日時／欠測：
問い合わせ数と確認できた流入元：
AI・配信・分析の費用：
同期間に実施した広告やキャンペーン：
次に変更する条件：

記入例（当社の実記録・2026年10月23日）：AIが収集と下書きの検品を担当する当社のX運用では、2026年10月23日に集めた候補140件を採用2件・再検討3件・見送り135件に分けました。採用した2件については、自動チェックの通過を確認したうえで、同日6時43分と11時52分（日本時間）にXとThreadsへ予約し、予約先の配信サービス側で受付状態まで照合しています。一方、確認作業の所要時間のように当日の記録に残していない項目は、推定値で埋めずに空欄のままにします。無い記録を作らないことが、後から試行を正しく評価するための条件です。

【2026-10-23 実運用の入力条件（原記録からの原文抜粋）】
X運用パイプライン（claude-code-buzz-system）が2026年10月23日の「候補収集→選定→予約」で実際に受け取った入力条件です。運用記録からの原文抜粋で、内容の書き換えはしていません。
出典: 同日のgeneration_context.json（凍結コピーSHA-256先頭16桁 bac4a9d8e7c8f3fe）と selection_decisions.json（同 b84be2267638ac72）

■ 実行日
2026-10-23

■ 候補の収集条件（selection_decisions.json「collection_route」「collection_note」原文）
chrome_gateway_ids+syndication+fxtwitter（x-research-profileはCloudflare確認画面とみられ全クエリ0件・4日目）
36時間窓・6クエリ183行→139件。3Dオフィスは10/22選定見直しの差替え第1候補で、今回の検索結果に出なかったため同じ36時間窓内の原典をfxtwitterで再取得しgeneration_context.itemsへ追加。採用基準は2026-10-22市岡指示（500以上かつ内容）。2本で本数合わせはしない。

■ 編集部フィードバック指示（generation_context.json「editorial_feedback.instructions」原文）
本人の判断・理由・修正指示を候補収集と選定で先に読む。再検討は原典を再確認し、今回の採否理由に対応を記録する。採用希望でも品質・重複・投稿承認のゲートは維持。実績未記録を0と見なさず、相関を因果と断定しない。

■ 運用AIへの指示（generation_context.json「instructions_for_claude」原文）
MASTER_DAILY_RUN.md を唯一の正として読むこと。生成、自然化、記事CTA、メディア、main_thread、出力スキーマ、validate前投稿禁止はすべて MASTER_DAILY_RUN.md に従う。

【メディア最重要ルール（2026-09-18 市岡指示・恒久・全Xレーン共通）】動画 → media_plan.video_url を /video/1 形式で本文3〜4行目に埋め込む（従来どおり・秒数不問）。画像（投稿者が公式アカウント／公式関係者）→ 元画像をそのまま使う（2026-09-18 市岡追加指示）。パイプラインが保存済みで media_plan.images（と本人スレッドの写真）に local_path・source_policy=official_source で入っている。それをそのまま attached_media_plan に引き継ぎ、needs_diagram にしない。画像（それ以外の投稿者）→ 元投稿やWebの画像は保存も添付もしない。needs_diagram: true にしてImage 2.5（gpt-image-2.5-sunburst）でこちら側で生成する。media_plan.source_image_refs とmain_thread[*].media の写真は『元画像が何を示していたか』を理解するための参照専用で、attached_media_plan.images / thread_media_assets / media_ids へ入れない。元画像から読み取れた要点は attached_media_plan.image_brief に日本語で書く（見た目の模写ではなく伝える内容）。画像も動画も無い → needs_diagram: true。添付できる画像は証明（.provenance.json）つき＝自前生成（Image 2.5）か公式の物だけで、validate と投入直前ゲートが機械検査する。正本: x-operations-specialist/knowledge/media-policy.md

{
 "schema": "x_result_records_verified_v1",
 "run_date": "2026-10-23",
 "verified_at": "2026-10-25T04:26:24+09:00",
 "inputs": {
  "selection_decisions_sha256": "b84be2267638ac7272351f5118689929b7000adfa368558c1c9db7d64fce5bc0",
  "schedule_verification_sha256": "87f1c69b27cfea62d402a06fadbce58e2dddbf0afc3813a0185b61d8274eea55"
 },
 "figures": {
  "candidates": 140,
  "adopted": 2,
  "reconsideration": 3,
  "passed_over": 135,
  "scheduled_jst": [
   "10-23 06:43",
   "10-23 11:52"
  ],
  "typefully_checked_at": "2026-10-22T23:13:05.011352+09:00"
 },
 "adopted": [
  {
   "tweet_id": "2112890224426553836",
   "title_ja": "参考画像2〜3枚から1,876個の物が並ぶ3Dオフィス",
   "author": "@rewind02"
  },
  {
   "tweet_id": "2112940526559232469",
   "title_ja": "スマホを9層に分解する動く図解（anatomy）",
   "author": "@elvar_official"
  }
 ],
 "assertions_passed": [
  "candidates==140",
  "adopted==2",
  "reconsideration==3",
  "passed_over==135",
  "schedule_verification.status=='verified'",
  "scheduled ids match adopted_ids",
  "JST times == ['10-23 06:43','10-23 11:52']"
 ]
}

検証済みの運用実記録（2026年10月23日）を保存 ↓2026年10月23日の候補収集→選定→予約の実記録を、内容を変更できない形で保存したコピー（凍結コピー）にし、読み取り専用スクリプトで照合した結果です。合格した7項目は、候補140件・採用2件・再検討3件・見送り135件・予約受付照合「verified」・予約IDと採用IDの一致・予約時刻（日本時間10月23日 06:43と11:52）です。

週1回、同じ条件で次の1点を決める

投稿の反応は「公開から24時間後」など経過時間をそろえ、投稿IDごとに表示回数・反応・リンククリックを記録します。取得できない指標は欠測です。反応率を計算するときも、分子に含む反応と分母を固定します。例えば「いいね＋返信＋リポスト」を表示回数で割る独自指標なら、その定義を明記し、サービス側のエンゲージメント率と混ぜません。

添付した今週と前週の投稿別データを比較してください。
公開後の経過時間が同じ行だけを使い、欠測は補完しないでください。
テーマ別の反応、人の確認時間、リンククリックを分けて要約し、
改善候補を3つ、来週試す変更を1つ提案してください。
少数の投稿や同時期の広告から因果関係を断定しないでください。

最初の週は品質と記録を整え、次の週から冒頭文・テーマ・投稿時刻など一つずつ変更すると、結果を振り返りやすくなります。期間が短い、投稿数が少ない場合は結論を急がず、同じ条件で観測を続けます。

X運用の自動化でつまずく場面と対処法

公式画像確認 2026-10-10

画像を拡大 ↗

よくある質問

「X運用のAI社員」は何を用意すれば作れますか？

担当する工程、参照資料、作業手順、使えるツール、承認者、結果の記録先を一組にします。呼び名を付けるだけで動くのではなく、この記事の下書き・確認・配信・測定をつなぐ設計が必要です。法人で複数担当者や既存システムへつなぐ場合は、AI社員導入支援の内容をご確認ください。

人の作業をゼロにできますか？

この記事の設計では、公開判断と事実確認を人の担当にしています。生成時間が短くなっても、確認・修正を含む総工数が減ったかは別途計測します。

下書きを作るだけでもX APIの契約は必要ですか？

手元にある公開可能な資料から原稿ファイルを作り、人がXへ投稿する段階では、原稿生成のためにX APIを呼ぶ必要はありません。自動投稿や反応の取得へ進むと、選ぶ連携先に応じた契約・認証・料金の確認が必要です。

自動化すればフォロワーは増えますか？

増加は保証できません。自動化の効果を確かめるには、まず、任せた工程が完了したか、修正の負担がどう変わったかを記録します。発信内容への反応と事業成果は分けて評価してください。

最初から複数アカウントで運用すべきですか？

まず1つのアカウントで、原稿・承認・公開結果が一致するところまで確かめると、問題を切り分けやすくなります。増やすときは投稿先と権限、計測表をアカウントごとに管理します。

最初の一歩は、公開可能な資料1件で下書きを作り、確認にかかった時間と修正点を残すことです。Claude Codeでのファイル活用は基本ガイド、繰り返す作業の設計は使いこなし教科書で続けて学べます。