結論
n8nで同じ動画が投稿される原因は「状態管理の設計が弱いこと」です。
特に
・tweet_idだけで重複管理
・static dataのみで状態保存
この2つは事故の原因になりやすいです。
Xへの動画投稿を自動化していたとき、
同じ動画が何度も投稿される現象にハマった。
処理自体は正常に見えるのに、
なぜか過去の動画が再び拾われてしまう。
今回は、そのときに気づいた設計上のポイントと、
自動化でありがちな落とし穴について整理しておく。
n8nで動画投稿を自動化したときに起きた問題
X APIとn8nを使って動画投稿を自動化していた。
検索 → スコアリング → 投稿 → 登録
という流れで組んでいたが、
気づくと同じ動画が何度も投稿される状態になっていた。
処理はエラーなく流れているのに、
「なぜ？」という状態が続いた。
なぜ同じ動画が投稿され続けたのか
原因はシンプルで、
「すでに投稿した内容」を判定する仕組みが弱かった。
最初は、投稿に使ったツイートIDを記録して、
同じツイートを二度使わないようにする設計にしていた。
ただ、この方法には問題がある。
Xでは、同じ動画が別のツイートとして投稿されることがよくある。
つまり、
同じ動画
↓
違うツイートID
↓
自動化から見ると「新規」
という状態になる。
さらに今回のケースでは、
n8nのstatic dataで状態管理をしていたため、
ワークフローの再実行時に状態がうまく保存されていないこともあった。
その結果、同じ投稿を繰り返してしまう状態になっていた。
この手の自動化では、
状態管理の設計を最初に考えておかないと簡単に事故る。
実際にこの事故でアカウントを一度凍結させてしまった。
同じ失敗を避けるために、自動化の設計を見直した。
設計段階で考えるべきポイント
この問題を通して感じたのは、
「処理が動く」と「運用できる」は全く別だということ。
・何をキーに重複判定するか
・どこに状態を保存するか
・途中で止まった場合にどう復旧するか
こういった部分を最初に考えておかないと、
自動化はすぐに“暴走”する。
n8nは柔軟だけど、
そのぶん設計の甘さがそのまま結果に出る。
仕組み全体と実装例について
今回組んだワークフローでは、
投稿履歴をDBで管理する構成や、
コンテンツ単位で重複を避ける仕組みなども取り入れている。
ただ、コードや構成をそのまま貼っても再現性は低いので、
設計の考え方から実装までをまとめてnoteに書いた。
この仕組みの全体構成や、
重複投稿を避けるための具体的な実装については、
noteで詳しくまとめています。
▶n8nで作ったX自動化の設計と実装をnoteにまとめました
まとめ
n8nで動画投稿を自動化する場合、
・tweet_idだけで重複管理しない
・状態管理をきちんと設計する
・DB管理を検討する
このあたりを最初に決めておかないと
同じ投稿を繰り返す事故が起きやすい。
