【完全自動化】n8n × X（Twitter）APIで記事公開を自動ポスト！microCMS Webhook連携の実践手順

ブログやWebメディアで新しい記事を公開したあと、「X（旧Twitter）を開いて、記事タイトルとURLをコピペして、ハッシュタグを付けて告知ポストを投稿する」という作業を毎回手作業で行っていないでしょうか？

1回あたりは数分の作業でも、記事数が20本、30本と増えるにつれて地味な負担になり、「今日は疲れたからSNS告知は明日でいいや…」と後回しにして初期流入のチャンスを逃してしまうケースは少なくありません。

結論からお伝えすると、ヘッドレスCMSの「microCMS」と、VPS上にセルフホストしたワークフロー自動化ツール「n8n（エヌエイトエヌ）」、そして「X API v2（無料枠）」を組み合わせれば、microCMSで記事の「公開」ボタンを押した瞬間に、裏側で自動的にXへ告知ポストを投稿する完全自動化パイプラインをランニングコスト0円（VPS代のみ）で構築できます。

さらに本記事では、単なるAPI連携だけでなく、AstroやCloudflare Pagesなどの静的サイト（Jamstack）環境で必ず直面する「サイトのビルドが終わる前にURLがポストされてしまい、クリックした読者が404エラーになる問題」をn8nのWaitノードで回避する実践テクニックまで徹底解説します。

なぜ個人メディアのX（旧Twitter）自動告知に「microCMS × n8n」が最強なのか？

ブログの更新をXへ自動投稿する方法としては、WordPressのプラグインや、Zapier・Makeといったクラウド自動化SaaSを使う方法もあります。しかし、モダンな個人メディア運営においては「microCMS × 自前VPS上のn8n」という組み合わせがコスト面でも機能面でも圧倒的に有利です。

比較項目	手動でXへコピペ投稿	クラウドSaaS（Zapier等）	microCMS × n8n（VPS自前構築）
X連携の月額追加コスト	0円（ただし毎回手間がかかる）	有料プラン必須のケースが多い（月3,000円〜）	0円（既存のVPS内でタスク無制限）
ビルド完了待ち（遅延実行）	人間が確認して投稿	Delayステップ追加でタスク数を消費	Waitノードで何分でも無料で待機可能
AI（Dify等）による紹介文生成	自分で毎回考える	複数ステップ連携でコスト増	同居するDifyと内部通信で自在に連携可能

1. X API v2の「無料枠（Freeプラン）」の範囲内で十分に運用できる

現在、X（旧Twitter）のAPIは有料化が進んでいますが、「ポストの投稿（Write専用）」だけであれば、無料の「Freeプラン（月間500ポストまで・1日あたり上限あり）」が引き続き提供されています。

個人メディアや技術ブログで新規記事やリライト記事を公開するペース（1日1〜数本程度）であれば、無料枠の制限に引っかかることなく完全に0円で自動ポストを回し続けることが可能です。

2. Jamstack特有の「デプロイ完了待ち（タイムラグ問題）」をn8nで吸収できる

Astro × microCMS × Cloudflare Pagesのような構成では、microCMSで「公開」ボタンを押してから、Cloudflare Pages側でサイトのビルドが走り、本番URL（https://あなたのドメイン/blog/slug）が実際に表示可能になるまでに約1分〜2分前後のタイムラグが発生します。

もしWebhookが飛んだ瞬間にXへ即時ポストしてしまうと、「投稿直後にリンクを踏んでくれた熱心なフォロワーに404 Not Found画面を見せてしまう（さらにXのOGPカード画像も取得に失敗する）」という致命的なミスが起きます。n8nを使えば、Webhookを受け取ってから「3分間だけ待ってポストする」といった制御がノード1つで簡単に実装できます。

💡 前提となる「n8nのVPS構築」および「microCMS Webhookの基本連携」はこちら：
まだVPSにn8nを導入していない方や、microCMSのWebhook設定の基礎を確認したい方は、以下の記事を先にチェックしてください。
・【脱Zapier】n8nを格安VPSにDocker構築する完全手順！タスク無制限のAPI自動化基盤を作る
・【実践】n8n × microCMSをWebhook連携！記事公開からの自動化ワークフロー構築ガイド

【事前準備】X Developer PortalでのAPI v2設定とOAuth 2.0認証情報の取得

n8nからXへ自動投稿を行うために、まずはXの開発者ポータル（X Developer Portal）でアプリを作成し、OAuth 2.0の認証キー（Client ID / Client Secret）を取得します。権限設定の順番を間違えると「403 Forbidden」エラーになるため、以下の手順通りに進めてください。

STEP 1：X Developer PortalでプロジェクトとAppを作成する

自動投稿を行いたいXアカウントにログインした状態で、X Developer Portal にアクセスします。
無料枠（Freeアカウント）の登録を済ませ、ダッシュボードの「Projects & Apps」を開きます。
デフォルトで作成されているProject内のAppを選択するか、新規でApp（例：core-media-lab-autobot）を作成します。

STEP 2：「User authentication settings」でRead and Write権限とCallback URLを設定する

ここが最も重要な設定箇所です。初期状態のAppは「Read（読み取り専用）」になっており、そのままではポストを投稿できません。

作成したAppの設定画面（Settingsタブ）を下へスクロールし、「User authentication settings」の「Set up」（またはEdit）をクリックします。
App permissions（アプリの権限）： 必ず Read and write（読み取りと書き込み）を選択します。
Type of App（アプリの種類）： Web App, Automated App or Bot（Confidential client）を選択します。
App info（Callback URI / Redirect URL）： お使いのn8nの画面で「X（旧Twitter）OAuth2 API」のクレデンシャル新規作成画面を開き、そこに表示されている OAuth Redirect URL（例：https://あなたのn8nドメイン/rest/oauth2-credential/callback）をコピーして正確に貼り付けます。
Website URL： あなたのメディアのトップページURL（例：https://coremedialab.com）を入力し、画面下部の「Save」を押して保存します。

⚠️ OAuth認証時の重要な注意点：
XのOAuth 2.0リダイレクト認証を行う際、セルフホスト版n8nを「IPアドレス直打ち（http://...）」のまま運用していると、X側のセキュリティ制限やブラウザのCookie制限でCallback認証が通らないケースがあります。n8nで外部OAuth連携を行う場合は、独自ドメインまたはCloudflare Tunnel等でHTTPS化しておくことを強く推奨します。

STEP 3：OAuth 2.0の「Client ID」と「Client Secret」をn8nへ登録する

設定を保存すると、画面に OAuth 2.0 Client ID and Client Secret が表示されます（後からは「Keys and tokens」タブで確認・再生成できます）。
n8nの画面に戻り、「Credentials」➔「Add Credential」から X (Formerly Twitter) OAuth2 API を検索して開きます。
コピーした Client ID と Client Secret を入力し、表示された 「Connect my account」 ボタンをクリックします。
Xの連携承認ポップアップが開くので「アプリにアクセスを許可」を押します。n8n側で「Account connected（緑色の表示）」になれば、X APIとの接続は完了です！

これでXへ投稿する準備が整いました。次のセクションでは、microCMSのWebhookを受け取って実際に自動ポストを行うn8nワークフローを4ステップで構築していきます。

【実践構築】n8nで「microCMS Webhook受信 ➔ ビルド待機 ➔ X自動ポスト」を組む4ステップ

X APIのOAuth 2.0認証が済んだら、いよいよn8nのキャンバス上で自動化ワークフローを組み立てます。全体像は「① Webhook（受信） ➔ ② IF（初回公開のみ通過） ➔ ③ Wait（3分間ビルド待ち） ➔ ④ X（自動ポスト）」という非常にシンプルな4ノード構成です。

STEP 4：n8nに「Webhook」ノードを配置し、microCMS側にURLを登録する

n8nで新規ワークフローを作成し、最初のトリガーとして Webhook ノードを追加します。
Webhookノードの設定画面で、以下の通り指定します。
- HTTP Method： POST
- Path： 任意の文字列（例：microcms-x-autopost）
- Authentication： Header Auth（推奨：microCMS側のカスタムヘッダーと共通のシークレット文字列を設定しておくと、第三者からの不正実行を防げます）
まずテスト受信を行うため、Webhookノード上部の「Test URL」をコピーし、「Listen for test event」ボタンをクリックして待機状態にします。
別タブでmicroCMSの管理画面を開き、対象API（例：blogs）の「API設定」➔「Webhook」➔「追加」から「カスタム通知」を選択します。
URL欄にコピーしたn8nのURLを貼り付け、通知のタイミングは「コンテンツの公開」のみにチェックを入れて保存します（誤爆を防ぐため、更新や削除のチェックは外しておきます）。
microCMS側でテスト記事を1本公開（または下書きから公開）し、n8nのWebhookノードにJSONデータが届くことを確認します。

STEP 5：「IF」ノードで新規公開時のみ通過させる（誤爆防止フィルター）

microCMSから届くWebhookのJSONデータには、変更前の状態（contents.old）と変更後の状態（contents.new）が含まれています。すでに公開済みの記事を微修正した際に何度もXへ同じ投稿が流れてしまうのを防ぐため、「変更前のステータスが公開状態（PUBLISH）ではなかった場合のみ通過させる」という条件分岐を入れておくと安心です。

Webhookノードの後ろに If ノードを繋ぎます。
Conditions（条件）を以下のように設定します（Expressionモードで指定）。

// 条件1：変更後（new）のステータスに "PUBLISH" が含まれていること
{{ $json.body.contents.new.status[0] }}  [is equal to]  PUBLISH

// 条件2（任意・初回公開のみに限定する場合）：変更前（old）が空、またはDRAFTだった場合のみ通過
{{ $json.body.contents.old ? $json.body.contents.old.status[0] : 'NONE' }}  [is not equal to]  PUBLISH

※もし「リライトして再公開したときも毎回Xへ告知したい」という運用であれば、条件1のみで問題ありません。

STEP 6：「Wait」ノードでCloudflare Pagesのビルド完了（3分間）を待つ

ここがJamstack構成（Astro × Cloudflare Pages等）における最重要ポイントです。IFノードの true 分岐の後ろに Wait ノードを追加します。

Resume： After Time Interval
Wait Amount： 3
Wait Unit： Minutes（分）

この「3分間の待機」を挟むことで、裏側でGitHub ActionsやCloudflare Pagesのビルド・デプロイが完全に終了し、新しい記事ページのHTMLとOGP画像がインターネット上に公開された状態になってから次のX投稿ステップへ進むことができます。これで「投稿直後の404エラー」や「Xのリンクカード（OGP）が真っ白になる現象」を100%防げます。

💡 Cloudflare Pagesの自動ビルド環境や画像高速化の仕組みはこちら：
・GitHub × Cloudflare Pagesで実現する「完全無料・自動デプロイ環境」の作り方
・microCMSの画像最適化（imgix）とAstroを組み合わせてPageSpeed Insights 100点を目指す高速化ガイド

STEP 7：「X（Formerly Twitter）」ノードで記事タイトルとURLを自動ポストする

最後に、Waitノードの後ろに X (Formerly Twitter) ノードを追加し、ポストの文面を作成します。

Credential to connect with： STEP 3で作成したOAuth2認証を選択します。
Resource： Tweet / Operation： Create を選択します。
Text欄： 右上の「Expression（式）」タブに切り替え、以下のテンプレートを貼り付けます（ドメイン部分はご自身のサイトURLに変更してください）。

📝 新着記事を公開しました！

{{ $('Webhook').item.json.body.contents.new.publishValue.title }}

▼ 記事はこちら
https://あなたのドメイン.com/blog/{{ $('Webhook').item.json.body.contents.new.publishValue.slug || $('Webhook').item.json.body.id }}

#個人開発 #業務効率化 #AI活用

※ポイント：直前のノードが「Wait」になっているため、$json ではなく $('Webhook').item.json... のようにWebhookノードのデータを明示的に参照すると確実です。また、カスタムスラッグフィールド（slug）を使っている場合はその値を、デフォルトのコンテンツIDを使っている場合は id をURL末尾に結合します。

テスト実行（Test step）を押し、実際に自分のXアカウントへ記事タイトルとURLがポストされることを確認したら、WebhookのURLを「Production URL（本番用URL）」に差し替えて、n8n右上のスイッチを Active（本番稼働） に切り替えます。

リライト時の「誤爆（二重ポスト）」やAI要約生成を組み込む応用テクニック

基本の自動ポストが開通したら、さらにクリック率（インプレッション・エンゲージメント）を高め、運用事故をゼロにするための2つのカスタマイズを取り入れてみましょう。

1. microCMSスキーマに「SNS自動投稿フラグ（真偽値）」を追加して完全制御する

「誤字を1文字直して更新しただけなのにXへ再投稿されてしまった」「特定の事務連絡ページはXに流したくない」といったケースを完全にコントロールしたい場合は、microCMSのAPIスキーマ（記事設定）に1つだけ真偽値フィールドを追加するのが最もスマートです。

フィールドID： isAutoTweet（種類：真偽値 / デフォルト値：false または true）
n8n側のIFノード条件： {{ $json.body.contents.new.publishValue.isAutoTweet }} が true のときだけXへ投稿する

また、スプレッドシート（GAS）からmicroCMSへ自動入稿している場合は、シート側の列でON/OFFを指定できるようにしておけば、管理画面を開くことすらなく投稿有無を制御できます。

💡 スプレッドシート（GAS）からmicroCMSへのワンクリック自動入稿手順はこちら：
・【脱コマンド】GoogleスプレッドシートからmicroCMSへワンクリック自動入稿する完全手順（GASコード付き）

2. 同じVPS上の「Dify」を間に挟み、読者を惹きつける140字紹介文をAI生成する

常に同じ定型文（「新着記事を公開しました！＋タイトル＋URL」）ばかりだと、フォロワーに見飽きられてクリック率が下がってしまいます。

WaitノードとXノードの間に HTTP Request ノード を1つ挟み、同じVPS上で稼働している「Dify」のワークフローAPIへ記事タイトルと概要（description）を送信して、「読者が思わずクリックしたくなる3行の要約フック文＋関連ハッシュタグ2個」をAI生成させてからXノードへ渡す構成に進化させれば、人間が丁寧に書いたような熱量のある告知ポストを24時間全自動で発信できます。

🚀 n8nとDifyを連携させてAIワークフローを自動化する方法はこちら：
・【Dify×n8n連携】AIワークフローを24時間完全自動化する構築手順！Webhook・API接続の実践ガイド

まとめ：記事公開からSNS拡散までを完全自動化し、執筆と改善に集中しよう

本記事では、microCMSのWebhookとVPS上のn8n、そしてX（旧Twitter）API v2を連携させ、記事公開と同時にXへ自動ポストする実践手順を解説しました。

ランニングコスト0円で自動化： X API v2の無料枠（Freeプラン）と自前VPS上のn8nを組み合わせることで、有料の自動化SaaSを契約することなく無制限にワークフローを回せる。
Waitノードで404エラーを完全回避： 静的サイト（Astro × Cloudflare Pages等）のビルド・デプロイ時間を考慮し、3分間の待機ノードを挟むことでリンク切れやOGP表示崩れを防げる。
IF分岐やDify連携でさらに進化： 初回公開判定フィルターによる二重投稿防止や、Dify APIを使ったAI紹介文生成もノード追加だけで簡単に拡張できる。

これで「記事の入稿 ➔ サイトの自動ビルド ➔ XへのSNS告知」までが人間の手を一切介さずに回るようになります。ルーティン作業はすべてVPS上のn8nに任せて、あなたにしかできないコンテンツ企画やSEO改善に時間を投資していきましょう！