SNSの自動投稿をノーコードツールで組み始めると、あるところで頭打ちになります。テキストだけなら問題ありませんが、画像を生成して添えようとした瞬間に自由度が足りなくなるのです。
この検証では、n8nベースの構成からNode.js基盤へ移行し、テキスト+画像付きツイートの自動投稿を実現しました。ノーコードを捨てる判断をどこで下したかを共有します。
この検証の概要
検証時期 | 2025年11月(11/8〜11/21) |
|---|---|
使用ツール | Node.js / Render / X API / Gemini API(Imagen・Nano) |
やりたかったこと | 最新AI情報の収集・加工・発信を完全に自動化し、24時間稼働の運用体制をつくる |
方針転換 | n8nのみでは画像生成・投稿の自由度が低いため、Node.js基盤へ舵を切った |
達成できたこと | テキストおよび画像付きツイートの成功確認/6時間間隔でのXリスト取得とタグ自動選別ロジック |
状況 | 基盤移行および画像投稿検証フェーズ |
本記事は自社での検証記録です。エンゲージメントの変化などの測定は行っていないため、数値は掲載していません。
結論:画像生成でノーコードの限界に当たった
この移行の理由は明確です。
n8nのみでは、画像生成・投稿の自由度が低いという判断に至りました。
ノーコードツールは、用意されたモジュールの範囲では非常に速く組めます。テキストを取得して要約して投稿する、という流れであれば問題ありません。
しかし画像を生成し、内容に合わせて調整し、投稿に添える——この工程はモジュールの組み合わせでは表現しきれませんでした。細かい制御が必要な部分ほど、ノーコードの制約が効いてきます。
そこでNode.jsを基盤としたシステム構築へ切り替え、Renderで公開する構成にしました。
構成
6時間間隔で X のリストを取得
↓ 独自ロジックでエンゲージメント計算 → 上位5件を抽出
Gemini API(Imagen / Nano)で画像生成
↓
Node.js(Render で公開)
↓
X API でテキスト+画像を投稿テキストメッセージと画像付きツイートの両方で、投稿の成功を確認しています。
ノーコードから移行する判断基準
今回の経験から、切り替えを検討すべきタイミングを整理します。
状況 | 判断 |
|---|---|
用意されたモジュールで組める | ノーコードのまま |
細かい制御が必要になってきた | 移行を検討 |
回避策の実装がコードを書くより複雑 | 移行すべき |
ノーコードで無理やり実現するための工夫が、素直にコードを書くより複雑になったら、それが移行のサインです。今回の画像生成・投稿がまさにその状態でした。
選別ロジックは維持している
基盤は変わりましたが、6時間間隔でXのリストを取得し、エンゲージメント計算で上位5件を抽出してタグ付けするという選別ロジックはそのまま引き継いでいます。
新着順ではなくエンゲージメント基準で選ぶことが、自動投稿の質を担保する要です。実行環境を変えても、この設計思想は変えていません。
よくある質問
なぜn8nをやめたのですか?
画像生成・投稿の自由度が低かったためです。テキストのみの投稿であればn8nで足りますが、画像を生成して内容に合わせて調整する工程はモジュールの組み合わせでは表現しきれませんでした。
ノーコードからコードへ移るタイミングは?
ノーコードで実現するための回避策が、コードを書くより複雑になったときです。今回の画像生成・投稿がその状態でした。
画像はどう生成していますか?
Gemini APIのImagen・Nanoを使用しています。テキストと画像の両方を含むツイートの投稿成功を確認済みです。
どこで動かしていますか?
Node.jsで実装し、Renderで公開しています。24時間稼働を前提とした構成です。
まとめ
- n8nでは画像生成・投稿の自由度が低く、Node.js基盤(Render公開)へ移行
- テキスト+画像付きツイートの自動投稿に成功。画像生成はGemini API(Imagen/Nano)
- 移行の判断基準は「回避策がコードを書くより複雑になったとき」
- 基盤は変えてもエンゲージメント基準の選別ロジックは維持。設計思想は実行環境と独立している
ノーコードは着手を速くしますが、要件が細かくなるほど制約が効いてきます。どこで乗り換えるかを見極められると、無駄な作り込みを避けられます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。
