〜止まらない運用のためのフィード設計〜
はじめに
WordPressの記事をX（旧Twitter）に流す方法として、これまではAPI連携やAutopostプラグインが主流でした。
しかし現在は、
- X APIの有料化
- 仕様変更の頻発
- プラグイン依存のリスク
といった理由から、API前提の自動投稿は運用として不安定になっています。
この記事では、RSSを起点に IFTTT / Zapier を使って投稿する構造を整理します。
自動投稿で本当に必要なのは「完全自動」ではない
実務で重要なのは、
- 毎回確実に流れること
- 突然止まらないこと
- 原因不明にならないこと
です。
「公開と同時に必ず投稿される」よりも、安定して続く構造を優先します。
WordPressのRSSは最も安定した出口
WordPressには標準でRSSが用意されています。
例：
- 全記事RSS
https://kinryu.work/feed/ - カテゴリ別RSS
https://kinryu.work/category/ec構造/feed/ - タグ別RSS
https://kinryu.work/tag/rss/feed/
このRSSは、
- テーマに依存しない
- プラグインに依存しない
- WordPressが動く限り吐き続ける
という意味で、非常に壊れにくい出口です。
IFTTT / Zapier を「中継点」にする構造
構造は以下の通りです。
この構造のポイント
- WordPressは「公開するだけ」
- Xの仕様変更は中継側で吸収
- 問題が起きても、切り分けが簡単
API直結より、責任範囲が明確になります。
RSS設計で意識するポイント
① 全記事を流さない
すべての記事をXに流す必要はありません。
- 構造記事だけ
- 実務ログだけ
- 告知用カテゴリだけ
用途ごとにRSSを分けると、投稿の質が安定します。
② 投稿文は最小構成にする
IFTTT / Zapier 側では、
- 記事タイトル
- URL
だけを流すのが基本です。
装飾や説明は、X側で人が補う前提にします。
③ 即時投稿にしない選択肢も持つ
RSS → 即X投稿 ではなく、
- 一度下書き
- 手動承認
- 時間指定
といった設定も可能です。
ECや実務系では、「今日は流さない」判断ができる余白が重要です。
noteとの役割分担も明確になる
この構造にすると、
- WordPress：構造・保管
- RSS：配信の起点
- X：外向け速報
- note：一次ログ・補足
が自然に分かれます。
無理に全部を自動化しないことで、かえって運用は楽になります。
まとめ
- X API前提の自動投稿はリスクが高い
- RSSは最も安定した連携手段
- IFTTT / Zapier は「緩衝材」として使う
- 自動化より、壊れにくさを優先する
WordPressのRSSは、今後もこのサイトの中核インフラとして使っていく予定です。
EC運営 GCP nginx WordPress X(Twitter) モール運営 円安 再現性 在庫管理 実践ログ 業務改善 構造化 自動投稿 設計
#WordPress #実践ログ #構造化 #設計 #再現性 #業務改善
コメント