n8nの予約投稿が動かない？公開・日時・状態を確認する5つのポイント

AIに下書きを考えさせ、承認済みの予約を決まった条件で公開できれば、担当者が毎回投稿時間に画面を開く作業を減らせます。ただ、その手前には、たとえばこんな困りごとがあります。「予約を登録したのに、時間になっても動かない」。

この記事で扱うのは、その土台にあたる「まず1件の予約が、時刻を迎えて正しく処理されるか」の確認です。AIによる下書き生成や承認フローまでは実装しません。ASUNO編集部が教材で使っている構成（n8n 2.38.7、ローカル環境）をもとに、動かない原因を5つのポイントで切り分けます。ワークフローのJSON全体は配布しませんが、原理と診断手順だけで、自分のワークフローのどこを見ればいいかが分かるようにまとめました。

完成のイメージ：予約1件が処理されるまで

教材の構成は、準備・1件登録・予約チェックの3つのワークフローです。予約はn8nのData tableに1行ずつ入ります。

• text：投稿する文
• scheduled_at：予約日時（日時型）
• status：予約の状態
• send_live：本番送信するかどうか（Boolean）
• post_id：投稿後に保存されるID
• result：処理結果の記録

予約チェックのワークフローは、次の順で動きます。

1. 「1分ごとに確認」するSchedule Triggerが起動する
2. statusがqueuedで、予約時刻を迎えた行を、時刻の早い順に1件だけ取り出す
3. その行をprocessingに変えて、送信対象として確保する
4. send_liveがfalseなら練習完了を記録してpractice_doneに、trueならXへ送信し、成功後にpostedと投稿IDを保存する

つまり状態は、queued → processing → practice_done または posted と進みます。「動かない」ときは、この流れのどこで止まっているかを順に見ていきます。

ポイント1：実行履歴と公開状態を見る

最初に見るのは、ワークフローがそもそも定期的に動いているかです。

編集画面のExecute workflowで手動実行しただけでは、定期実行は始まりません。Schedule Triggerで動かすワークフローは、設定と認証を確認したうえでPublishして初めて、決めた間隔で動き始めます。これはn8nの公式ドキュメントにも明記されています。止めたいときはUnpublishです。

確認のしかたは、実行履歴に1分ごとの実行が並んでいるかを見ることです。並んでいないときは、原因をひとつに決めつけず、次の点を順に確かめます。

• ワークフローがPublishされているか
• n8nが起動しているか。ローカル環境の場合、PCの電源が落ちている間やn8nを終了している間は動きません
• 実行履歴の保存設定によって、履歴が残っていない、または表示されていないだけではないか
• エラーで失敗した実行が記録されていないか
• Schedule Triggerの間隔が、意図どおり1分ごとになっているか

ポイント2：時刻とタイムゾーンをそろえる

実行はされているのに予約が拾われないなら、次は時刻です。

ワークフローのSettingsでtimezoneをAsia/Tokyoにします。公式ドキュメントによると、n8nはワークフローのタイムゾーン設定を使い、未設定ならインスタンスの設定に従います。セルフホストの既定はニューヨーク時間なので、未設定のままだと日本時間とずれます。

予約日時のscheduled_atは日時型で、2026-10-01T18:30:00+09:00 のように書きます。末尾の +09:00 が日本時間であることを示します。試すときは、この例をそのまま使わず、自分が試す時点より少し先の未来の日時に置き換えてください。登録ノードで {{ $now.plus({ minutes: 2 }).toISO() }} と書けば、登録した時刻の2分後が入ります。

たとえば、過去の日付の例をそのまま入れていた、というケースがあります。また、+09:00 のような時差の指定を省いた日時がどの時間帯として解釈されるかは、入力のしかたや環境によって変わります。登録後の行を見て、意図した時差で解釈されているかを確認してください。

ポイント3：取り出す条件を確かめる

予約を取り出すData Tableノードの条件は、All Conditionsで次の2つです。

• status Equals queued
• scheduled_at Less Than or Equal {{ $now.toISO() }}

「状態がqueued」かつ「予約時刻が今以前」の行だけが対象で、その中から時刻の早い順に1件を取り出します。

ここで大事なのは、「No output data returned」と表示されても、故障とは限らないことです。予約時刻より前に実行された場合や、対象の行がすでに処理済みの場合は、取り出す行がないのが正しい動きです。

この表示を消したくてAlways Output Dataをオンにし、無理に先のノードへ進めるのは避けてください。対象がないのに送信処理へ進む原因になります。

ポイント4：練習と本番を取り違えていないか

「処理は終わったのに、Xに投稿されていない」場合は、send_liveを見ます。

send_liveがfalseの行は練習モードです。練習完了が記録されてstatusがpractice_doneになり、post_idは空のままで、Xへは送信されません。これは正常な結果です。

画像は、練習完了を記録するノードの出力です。statusがpractice_doneで、投稿IDが空になっていることを確認できます。

練習でつまずきやすい点が3つあります。

• すでに保存した行は、登録ノードの内容を編集しても変わりません。変わるのは次に登録する行です
• 登録のワークフローをもう一度実行すると、別の予約が1件増えます。結果が見えないからと連打しないでください
• practice_doneの行を、理由なくqueuedに戻さないでください。同じ予約がもう一度処理されます

なお、Xへ実際に投稿するにはX APIの認証が必要で、X APIは投稿のリクエストごとに利用料がかかる従量課金です。練習モードはXへ送信しないので、X APIの費用はかかりません。まず練習モードで流れを確かめるのが安全です。

ポイント5：送信結果が分からないときは、再投稿しない

本番（send_liveがtrue）では、Xへの送信が成功したあとに、statusがpostedになり、post_idに投稿IDが保存されます。

注意したいのは、成功したかどうか分からない状態です。通信エラーが出た、statusがprocessingのまま止まっている、needs_checkになっている。こうしたときは自動で再投稿せず、Xの実際のタイムラインと、n8nの実行履歴を見て確かめます。送信自体は成功していて、結果の保存だけ失敗していることがあるからです。

同じ文を別の行として登録すれば、それは別の予約として扱われます。この仕組みは二重投稿を減らすためのもので、どんな場合でも1回しか送信されないことを保証するものではありません。

時刻の精度にも限りがあります。1分ごとの確認で、1回に1件を処理する設計なので、投稿は予約時刻から1分程度ずれることがあり、同じ時刻の予約が複数あれば1件ずつ順に処理されます。処理の負荷やエラーでさらに遅れることもあり、指定した時刻どおりの投稿を保証する仕組みではありません。ASUNO編集部の教材制作時の確認（2026年9月14日）では、定期実行からの実投稿1件と投稿IDの保存、次の実行で対象なしになることまでを確認しています。長期間の連続稼働は未検証です。

理解の確認：この3行のうち、出力されるのは？

次の3行が同じテーブルに入っていて、今の時刻が18:31だとします。予約チェックが動いたとき、出力されるのはどの行でしょうか。

この場合、出力されるのはA行だけです。BやCのような行しかテーブルにないときは、対象がないので「No output data returned」になります。どちらも仕組みどおりの結果です。

動かないときのチェックリスト

• 実行履歴に、1分ごとの実行が並んでいるか
• 並んでいない場合、Publishの状態、n8nの起動、履歴の保存設定、エラーの有無、Schedule Triggerの間隔を確かめたか
• 手動のExecute workflowだけで済ませていないか
• PCとn8nは起動したままか（ローカル環境の場合）
• Settingsのtimezoneは Asia/Tokyo か
• 登録時：scheduled_atに未来の日時を指定したか。意図した時差で保存されているか
• 取り出す時点：対象の行のscheduled_atが、今以前になっているか
• 対象の行のstatusは queued か
• 取り出し条件は「status Equals queued」かつ「scheduled_at が今以前」になっているか
• Always Output Dataで、対象なしのまま先へ進めていないか
• send_liveは意図どおりか。falseなら、Xに投稿されないのが正常
• processingやneeds_checkの行を、Xと実行履歴を確認せずに再投稿していないか

無料で学べる範囲と、本講座の違い

ここまでの診断は、この記事だけで完結します。条件の考え方をもう少し練習したい場合は、ASUNOの無料教材で、3行の条件判定の練習を、画像と答えつきで読めます。無料教材で完全なワークフローを配布しているわけではありません。

本講座では、この土台の先を扱います。基礎の予約投稿、CSVでの一括登録、AIによる下書きと承認、本番公開の流れを、操作動画と画像付き手順でたどり、目的別のワークフローJSON、予約CSV、セットアップキットを使って自分の環境に組み立てます。認証は受講者が自分のアカウントで設定します。冒頭に書いた「承認済みの予約を決まった条件で公開する」形は、ここで完成します。

ASUNOの全講座プランは、月額2,980円・年額29,800円（税込・予定）です。年額は一括払いで、月額を12回払う場合の35,760円より5,960円少なくなります。決済の受付は現在準備中で、無料登録だけで課金されることはありません。n8nやX APIなど外部サービスの料金は別にかかります。

講座の内容・料金を見る