X自動投稿の手順を初心者向けに詳しく解説

今回の仕組みは、Googleスプレッドシートに投稿文を一覧化し、n8nで毎日1件ずつ取得し、X APIを使って自動投稿する流れです。元データでは、WordPress初心者向けTipsを「カテゴリー」「元ネタ」「X投稿文」として台帳化し、投稿ステータスを使って管理する構成になっています。

全体の流れ
事前に準備するもの
手順1：Googleスプレッドシートを準備する
手順2：投稿文をスプレッドシートに貼り付ける
手順3：投稿文の文字数を確認する
手順4：X Developerでアプリを作成する
手順5：Xアプリの権限を設定する
手順6：Callback URLを設定する
手順7：n8nで認証情報を作成する
手順8：n8nでワークフローを作成する
手順9：Schedule Triggerを設定する
手順10：Google Sheetsから予約済みの行を取得する
手順11：投稿前にステータスを「投稿中」にする
手順12：HTTP RequestでX APIへ投稿する
手順13：投稿成功後にステータスを更新する
手順14：エラー時の処理を作る
手順15：最初はテスト用の投稿で確認する
手順16：実運用前のチェックリスト
おすすめの運用方法
失敗しないための注意点
まとめ

全体の流れ

完成形は、次のような仕組みです。

Googleスプレッドシートに投稿文を準備する
投稿ステータスを「予約済み」にしておく
n8nを毎日決まった時間に起動する
n8nが「予約済み」の投稿を1件だけ取得する
X APIで投稿する
投稿成功後、ステータスを「投稿済み」に変更する

つまり、Googleスプレッドシートを「投稿予約リスト」として使い、n8nを「自動投稿ロボット」として使うイメージです。

X APIで投稿する場合、POST /2/tweets が投稿作成用のエンドポイントとして用意されており、本文は JSON の text に入れて送信します。X公式ドキュメントにも、POST先として https://api.x.com/2/tweets を使い、Content-Type: application/json で本文を送る例が掲載されています。

事前に準備するもの

この自動投稿を作るには、次の4つが必要です。

Googleアカウント
Googleスプレッドシート
n8nの環境
X DeveloperアカウントとX APIのアプリ

まずは、いきなりn8nを触るのではなく、先に投稿文の台帳をきれいに作ることが重要です。台帳が雑だと、後から「どれを投稿したか」「どこでエラーが出たか」が分からなくなります。

手順1：Googleスプレッドシートを準備する

新しいGoogleスプレッドシートを作成します。

シート名は、分かりやすく次のようにしておくと管理しやすいです。

X自動投稿リスト

1行目には、次の見出しを作ります。

ID
カテゴリー
元ネタ
X投稿文
投稿ステータス
投稿予定日
投稿日時
投稿URL
エラー内容

最低限必要なのは「カテゴリー」「元ネタ」「X投稿文」「投稿ステータス」です。ただし、実際に運用するなら「ID」「投稿日時」「投稿URL」「エラー内容」も入れておいた方が安全です。

手順2：投稿文をスプレッドシートに貼り付ける

添付データにあるWordPress Tipsの投稿文を、スプレッドシートに貼り付けます。

例として、次のように整理します。

ID	カテゴリー	元ネタ	X投稿文	投稿ステータス
1	初期設定	ログインURLの変更	WordPressのセキュリティ対策、まずは「ログインURLの変更」から始めましょう。	予約済み
2	functions.php	バージョン情報の非表示	HTMLのソースコード内にWordPressのバージョンが表示されているのは、攻撃者にヒントを与えているようなものです。	予約済み
3	SEO対策	画像のAlt属性設定	画像をアップロードする際、「代替テキスト」を空欄にしていませんか。	予約済み

投稿ステータスは、最初はすべて「予約済み」にしておきます。

ステータスは、次の4種類にすると管理しやすいです。

ステータス	意味
予約済み	これから投稿する
投稿中	n8nが処理している途中
投稿済み	Xへの投稿が完了した
エラー	投稿に失敗した

「投稿中」を入れておくと、n8nが途中で止まった場合でも、どの行で止まったか確認しやすくなります。

手順3：投稿文の文字数を確認する

Xは投稿できる文字数に制限があります。自動投稿では、文字数オーバーがあるとAPI側で失敗する可能性があります。

そのため、スプレッドシートに「文字数」列を追加しておくと安全です。

たとえば、X投稿文がD列にある場合、E列に次のような関数を入れます。

=LEN(D2)

文字数が長すぎる投稿は、事前に短くします。

自動投稿では「人間が投稿ボタンを押す前に気づけるミス」を、スプレッドシート側で先に潰しておくことが大切です。

手順4：X Developerでアプリを作成する

X APIを使うには、X Developer側でアプリを作成します。

流れは次の通りです。

X Developerにログインする
Developer Consoleを開く
Projectを作成する
Appを作成する
App名、説明、利用目的を入力する
API KeyやClient IDなどの認証情報を取得する

X公式ドキュメントでは、Developer ConsoleでNew Appを作成し、アプリの詳細や利用目的を入力すると、API keysやtokensが生成されると説明されています。

ここで取得する情報は非常に重要です。特にClient ID、Client Secret、API Key、API Secret、Access Tokenなどは、外部に漏れると不正投稿につながる可能性があります。

手順5：Xアプリの権限を設定する

Xへ投稿するには、読み取りだけではなく、書き込み権限が必要です。

X API v2でPOST /2/tweetsを使う場合、公式の認証マッピングでは tweet.read、tweet.write、users.read のスコープが必要とされています。

設定する権限は、基本的に次の内容です。

tweet.read
tweet.write
users.read
offline.access

offline.access は、毎回手動ログインしなくても継続的に認証を使うために必要になる場合があります。X公式ドキュメントでは、offline.access スコープを使うとリフレッシュトークンが発行され、ユーザーに再認証を求めずに新しいアクセストークンを取得できると説明されています。

手順6：Callback URLを設定する

OAuth 2.0で接続する場合、Callback URLの設定が必要です。

n8n側でOAuth2認証情報を作成すると、Redirect URLまたはCallback URLが表示されます。そのURLをコピーして、X DeveloperのApp設定画面に登録します。

注意点は、Callback URLは完全一致で登録する必要があることです。X公式ドキュメントでも、OAuth 2.0のredirect_uriはApp設定に登録したCallback URLと一致している必要があると説明されています。

よくある失敗は、次のようなものです。

失敗例	原因
http と https が違う	URLが完全一致していない
末尾のスラッシュが違う	別URLとして扱われる
n8nのURLを変更した	古いCallback URLが残っている
localhostのURLを登録している	外部からアクセスできない場合がある

Callback URLがずれていると、認証画面までは進んでも、n8nに戻るところで失敗します。

手順7：n8nで認証情報を作成する

n8n側で、X APIに接続するための認証情報を作ります。

n8nでは、ワークフローを開始するTriggerノードと、処理を実行するActionノードを組み合わせます。公式ドキュメントでも、Triggerノードはワークフローを開始して初期データを供給し、Actionノードはデータ処理や外部サービス操作を行うものと説明されています。

n8nでOAuth2 APIの認証情報を作る場合、考え方は次の通りです。

項目	設定内容
認証方式	OAuth2
Grant Type	Authorization Code
Auth URL	https://x.com/i/oauth2/authorize
Access Token URL	https://api.x.com/2/oauth2/token
Client ID	X Developerで取得したClient ID
Client Secret	X Developerで取得したClient Secret
Scope	tweet.read tweet.write users.read offline.access

X公式ドキュメントでは、OAuth 2.0のAuthorize URLとして x.com/i/oauth2/authorize を使う例が示されています。また、リフレッシュトークンによるアクセストークン取得例では、POST先として https://api.x.com/2/oauth2/token が示されています。

手順8：n8nでワークフローを作成する

n8nで新しいワークフローを作成します。

構成は、次の順番にします。

Schedule Trigger
↓
Google Sheets：予約済みの行を取得
↓
Google Sheets：ステータスを投稿中に変更
↓
HTTP Request：X APIで投稿
↓
Google Sheets：ステータスを投稿済みに変更
↓
エラー時：ステータスをエラーに変更

この順番が重要です。

いきなりXへ投稿するのではなく、先にステータスを「投稿中」に変更しておくことで、途中停止した場合でも二重投稿を防ぎやすくなります。

手順9：Schedule Triggerを設定する

最初にSchedule Triggerを置きます。

これは、毎日決まった時間にワークフローを起動するためのノードです。

設定例は次の通りです。

項目	設定例
起動頻度	Every Day
時刻	08:00
タイムゾーン	Asia/Tokyo

これで、毎朝8時に自動投稿処理が始まります。

最初は毎日1回で十分です。慣れてきたら、朝・昼・夜の3回に増やしてもよいですが、まずは1日1投稿から始める方が安全です。

手順10：Google Sheetsから予約済みの行を取得する

次に、Google Sheetsノードを追加します。

ここでやることは、「投稿ステータスが予約済みの行を1件だけ取得する」ことです。

取得条件は、次のようにします。

投稿ステータス = 予約済み

さらに、投稿順を安定させるために、IDが小さい順、または投稿予定日が古い順で取得します。

おすすめは次の条件です。

投稿ステータス = 予約済み
投稿予定日 <= 今日
IDが小さい順
取得件数 = 1

これにより、投稿予定日を過ぎたものから順番に1件ずつ投稿できます。

Google Sheets Triggerノードには「Row added」「Row updated」「Row added or updated」といったイベントがありますが、今回のような定期投稿では、Schedule Triggerで定期起動し、Google Sheetsノードで対象行を取りに行く形が分かりやすいです。

手順11：投稿前にステータスを「投稿中」にする

Xへ投稿する前に、取得した行の投稿ステータスを「投稿中」に変更します。

理由は、二重投稿を防ぐためです。

たとえば、n8nが投稿処理の途中で止まった場合、ステータスが「予約済み」のままだと、次回の実行時に同じ投稿が再び選ばれる可能性があります。

そのため、処理開始時点で一度「投稿中」にします。

予約済み
↓
投稿中

投稿に成功したら、最後に「投稿済み」に変更します。

投稿中
↓
投稿済み

投稿に失敗したら「エラー」に変更します。

投稿中
↓
エラー

この流れにしておくと、トラブルが起きた時に原因を追いやすくなります。

手順12：HTTP RequestでX APIへ投稿する

次に、HTTP Requestノードを追加します。

設定は次の通りです。

項目	設定内容
Method	POST
URL	https://api.x.com/2/tweets
Authentication	OAuth2
Content-Type	application/json
Body	JSON

Bodyには、スプレッドシートから取得したX投稿文を入れます。

イメージは次の通りです。

{
  "text": "ここにスプレッドシートのX投稿文を入れる"
}

X公式ドキュメントでも、POST /2/tweets に対して、JSONで text を送信する投稿例が示されています。

n8nでは、固定文ではなく、Google Sheetsから取得した「X投稿文」列を差し込みます。

たとえば、n8nの式では次のような形になります。

{{ $json["X投稿文"] }}

そのため、HTTP RequestのBodyは次のような考え方になります。

{
  "text": "{{ $json[\"X投稿文\"] }}"
}

実際のn8n画面では、Expression機能を使って該当列を選択すれば問題ありません。

手順13：投稿成功後にステータスを更新する

Xへの投稿が成功したら、Google Sheetsノードで該当行を更新します。

更新する内容は、次の通りです。

列	入れる内容
投稿ステータス	投稿済み
投稿日時	実行日時
投稿URL	投稿後に取得できるURL
エラー内容	空欄

X APIのレスポンスには、投稿IDが返ってきます。

その投稿IDを使えば、投稿URLを組み立てられます。

https://x.com/ユーザー名/status/投稿ID

ユーザー名が固定なら、スプレッドシートに投稿URLを保存しておくと、後から確認しやすくなります。

手順14：エラー時の処理を作る

自動化では、成功時よりもエラー時の設計が重要です。

エラーが出た場合は、何もせず止めるのではなく、スプレッドシートにエラー内容を残します。

エラー時の更新内容は次の通りです。

列	入れる内容
投稿ステータス	エラー
エラー内容	APIから返ってきたエラーメッセージ
投稿日時	空欄または失敗日時

よくあるエラーは次の通りです。

エラー	主な原因
401 Unauthorized	認証情報が間違っている
403 Forbidden	書き込み権限がない
429 Too Many Requests	投稿回数やAPI制限に達している
400 Bad Request	JSON形式や本文に問題がある
文字数オーバー	投稿文が長すぎる

特に最初に多いのは、403エラーです。これは、Xアプリ側でReadのみになっていて、Write権限が付いていないケースが多いです。

手順15：最初はテスト用の投稿で確認する

いきなり30件すべてを自動投稿するのではなく、最初はテスト用の1件だけで確認します。

テスト文は、次のような短い内容で十分です。

X APIとn8nを使った自動投稿テストです。

確認するポイントは次の通りです。

n8nが指定時間に起動するか
Google Sheetsから1件だけ取得できるか
Xへ投稿できるか
投稿後にステータスが「投稿済み」になるか
エラー時に「エラー内容」が保存されるか
同じ投稿が二重投稿されないか

ここまで確認できれば、実運用に進めます。

手順16：実運用前のチェックリスト

公開前に、次の項目を確認してください。

チェック項目	確認内容
投稿文	誤字脱字がないか
文字数	長すぎないか
ステータス	予約済みになっているか
権限	tweet.write が有効か
Callback URL	n8nとX Developerで一致しているか
投稿頻度	多すぎないか
エラー処理	失敗時に記録されるか
二重投稿対策	投稿中ステータスを使っているか

このチェックをしておくと、運用開始後のトラブルをかなり減らせます。

曜日	投稿テーマ
月曜日	初期設定
火曜日	セキュリティ
水曜日	SEO対策
木曜日	高速化
金曜日	functions.php
土曜日	プラグイン
日曜日	運用・保守

失敗しないための注意点

X自動投稿で一番避けたいのは、機械的な投稿ばかりになってしまうことです。

自動投稿は便利ですが、すべてを自動にすると、読者との距離が遠くなります。

おすすめは、次のような運用です。

種類	役割
自動投稿	毎日のTips発信
手動投稿	日々の気づきやリアルな発信
リプライ	読者との交流
引用投稿	関連情報へのコメント

自動投稿は「投稿を継続する土台」として使い、人間らしい投稿や交流は手動で行うのが理想です。