Xへの投稿を自動化するために、n8nでワークフローを組んだ。
最初は「投稿できればOK」という前提で作ったが、運用してみるとすぐに問題が出た。
同じ投稿を繰り返してしまう。
1本目の記事で書いた通り、状態管理の不備によって同じ投稿を連発し、最終的にアカウントを凍結させてしまった。
この記事では、その反省を踏まえて見直した
X投稿自動化の全体構成と設計の考え方を整理する。
この記事で分かること
・n8nでのX投稿自動化の基本構成
・重複投稿が起きる理由
・事故を防ぐための設計ポイント
X投稿自動化でやりたかったこと
やりたいことはシンプル。
・動画付きポストを検索
・一定以上の反応がある投稿を抽出
・内容を整えて投稿
・投稿済みのものは二度と使わない
処理自体は難しくない。
ただし一番重要なのは、
「投稿済みのデータをどう管理するか」
ここになる。
全体フローは「検索 → 判定 → 投稿 → 記録」
n8nでの全体構成はシンプル。
検索
↓
スコアリング
↓
投稿
↓
状態保存この中で一番重要なのが最後の「状態保存」。
ここが曖昧だと、
・ワークフローの再実行
・途中停止からの復旧
といったタイミングで、過去の投稿を再び拾ってしまう。
実際に起きた事故も、この部分の設計が甘かったことが原因だった。
なぜ重複投稿が起きるのか
原因は大きく2つある。
① tweet_idベースの管理
現在の構成では、投稿単位（tweet_id）で重複判定を行っている。
同じツイートを二度使わないという意味では、この方法でも成立する。
ただし、この設計には限界がある。
Xでは、同じ動画や画像が別のツイートとして投稿されることがある。多くの自動化では、投稿単位（tweet_id）で重複判定を行う。
同じ動画
↓
違うtweet_id
↓
別投稿扱い
この状態だと、自動化から見るとすべて「新規」になる。
つまり、
tweet_idだけでは、同じコンテンツの再投稿は防げない。
② static dataでの状態管理
もともとは、n8nの static data を使って状態管理していた。
ただ、この方法がうまく機能しなかった。
・データが保存されないケースがあった
・再実行時に状態が引き継がれない
・確認がしづらい
結果として、
未使用判定
↓
投稿
↓
また未使用判定
↓
再投稿
という状態になり、同じ投稿を繰り返してしまった。
今回の改善：Postgresで状態管理
この問題を解決するために、状態管理を Postgres に変更した。
これによって、
・投稿履歴を確実に保存できる
・重複チェックの精度が安定する
・データを後から確認できる
といった改善ができた。
少なくとも、
「同じツイートを何度も投稿する」問題は防げるようになった。
ただし、まだ限界がある
現在は tweet_id ベースで管理しているため、
・同じ動画の別ツイート
・類似コンテンツ
までは防げない。
つまり、
ツイート単位の管理には限界がある。
本来やりたい設計
理想は、
・動画URL
・media_key
・コンテンツのハッシュ
といった「コンテンツ単位」で管理すること。
ここまでやると、
同じ動画の再投稿をかなり防げるようになる。
まとめ
今回の改善で、
・static data → Postgres に変更
・状態管理が安定
・同一ツイートの重複投稿は防止
まではできた。
ただし、
コンテンツ単位の重複まではまだ防げていない。
実装と構成について
今回の構成や実装については、noteにまとめている。
・Postgresでの状態管理
・n8nでのワークフロー構成
・重複投稿を防ぐための考え方
など、実装レベルで解説している。
