1 チャンネルあたり月 5 ドル。更新画面でずっと見つめていたのがこの数字でした。どれだけの場所に投稿してよいかを、静かに決めていたからです。4 チャンネルなら 5 ドルの 4 倍。あとで 2 つ目のブランドを足せば、自分で書いている同じ予約投稿のために、請求額はまた上がります。
もともと別件の自動化 2 つのために n8n を VPS で動かしていたので、週末を使って、それを X・LinkedIn・Instagram・Facebook 向けの n8n ソーシャルメディアスケジューラーに仕立てられるか試してみました。稼働は現在 4 か月目です。この乗り換えに実際いくらかかり、何が壊れ、どんな場合には今でも勧めないのかを書きます。
短いバージョン
- X・LinkedIn・Facebook・Instagram への投稿を同じワークフローから出せるようにはなりましたが、4 つの分岐に必要な作業量は同じではありませんでした。
- 問題は Instagram でした。プロアカウント必須、メディアの制約、公開上限、トークンのライフサイクル。どれも Buffer では発生しなかった保守作業を生みました。
- TikTok は外しました。n8n の組み込みアプリノードのカタログに載っておらず、独自ノードやコミュニティノードを投稿スケジュールの一部にする気はなかったからです。
- Community Edition がなくすのはソフトウェア料金であって、コストではありません。ホスティング代は払い続け、アップデート、認証情報、バックアップ、監視、失敗した投稿の復旧は自分持ちでした。
- 結論。この乗り換えは価値がありました。下書きと公開を 1 本のパイプラインにまとめたかったからです。もし欲しかったのが視覚的なカレンダーと信頼できるキューだけなら、そのまま留まっていたでしょう。
何に払っていたのか、そして最後に決め手になったもの
Buffer の現行料金 では、年払いの場合 Essentials は 1 チャンネルあたり月 5 $ とされており、無料プランは最大 3 チャンネル、チャンネルごとに 10 件の予約投稿までとなっています。したがって有料 4 チャンネルは年払いで月 20 $ という表示価格でした。作り込まれたスケジューラーの売り方としては妥当ですが、私が広げたかったことにこそ課金される仕組みでした。つまり、1 つのアイデアを複数の場所向けに作り替える、という点にです。
最後に背中を押したのは価格ではありませんでした。投稿はすでに別ウィンドウでモデルを使って下書きし、それを手作業でスケジューラーに貼り付けていたのです。2 つのツールが、どう見ても 1 本のパイプラインを担っていました。欲しいワークフローの形が見えた時点で、下書きと公開を別々の半分に保つために月額を払い続けるのは、私にとって筋が通らなくなりました。
私のワークフローがしていること
私のワークフローは意図的に退屈です。Schedule Trigger が 1 日に数回発火し、Google Sheet から次の承認済み行を読み、各プラットフォーム向けに文面を調整し、それぞれのバージョンを専用の公開ブランチへ送り、結果を記録します。承認状態はシート上で人が管理し、承認済みの行だけを公開します。失敗したブランチは n8n の外へアラートを飛ばすので、壊れた認証情報が実行ログの中に埋もれてしまうことはありません。
下書きのステップはホスト型モデルの API を呼び出します。同じマシンでモデルを動かすことも少し検討しましたが、月に数十件の投稿という規模では、 モデルを自前ホストする際のコスト要因 が私の API 料金を上回っていました。利用量やプライバシー、レイテンシ次第で判断は変わり得ますが、ソーシャル投稿を書き直すためだけに追加のインフラを抱える理由はありませんでした。このワークフローは巧妙ではありません。信頼できた理由の一つはそこにあります。
プラットフォーム別の実情（問題は Instagram）
4 つの分岐のうち 3 つは、ほぼ何事もなく動きました。Instagram だけがプロジェクトの他すべてを合わせたより多くの時間を食い、投稿の抜けを私が最も無視しづらいプラットフォームでもありました。表は私が使った、あるいは検討した経路です。その下の詳細が、実際に構成へ影響した部分です。
| プラットフォーム | n8n での経路 | 主な制約 | 判定 |
|---|---|---|---|
| X | 組み込みの X ノード | エンドポイントの上限は X の開発者プラン次第 | API アクセスがあれば動作 |
| 組み込みの LinkedIn ノード | 組織としての投稿には LinkedIn のアプリ審査が必要 | 審査通過後に動作 | |
| Facebook Graph API ノード | ページ権限、トークン、Graph API のバージョン | 設定を行えば動作 | |
| Meta Graph API | プロアカウント、メディア規則、上限、トークンのライフサイクル | 保守を続ければ動作 | |
| TikTok | 組み込みアプリノードの掲載なし | HTTP、独自、またはコミュニティの連携が必要 | どうしても必要ならスケジューラーを使う |
LinkedIn については、 LinkedIn ノードのドキュメント が個人と組織向けの投稿作成をカバーしており、 n8n の LinkedIn 認証情報ガイド には、組織として投稿するにはアプリを LinkedIn の Community Management App Review に通す必要があると記されています。私の用途はこれで足りました。 X の認証情報のドキュメント には、X が開発者アクセスプランの階層に応じてエンドポイントごとに時間ベースのレート制限を適用する、と書かれています。私の投稿量では上限に達しませんでしたが、これは n8n の保証ではなく X がいつでも変えられる制限だと捉え続けています。
Meta のコンテンツ公開ガイド では、対応する画像形式は JPEG のみであること、そして文書化された経路では移動する 24 時間の枠内で API 経由の投稿が 100 件までであることが示されています。この JPEG の規則には一晩取られました。書き出しが既定で PNG になっていたうえ、n8n の中からは失敗の理由が分かりにくかったからです。この公開上限は恒久的なものとは考えず、現行の API 経路とバージョンに紐づくものとして扱っています。
4 か月で 2 回壊れました。どちらも Instagram です。長期アクセストークンは永続ではなく、 Meta のトークン更新リファレンス には、トークンを更新できるのは有効期限内で、かつ発行から 24 時間以上経っている場合に限る、とあります。この窓を逃せば、更新はもはや復旧手段ではありません。私の失敗は、認証を継続的な保守ではなく初期設定の作業として扱ったことでした。投稿ワークフローには、期限の監視、早めの更新、そして更新が失敗したときのアラートが必要です。
TikTok は、そもそも今回の置き換えの対象ではありませんでした。 組み込みアプリノードのカタログ には載っていません。HTTP Request ノードや独自ノード、コミュニティノードを使うこともできましたが、そうすれば認証情報の管理と故障をさらに背負うことになります。私が置き換えていたのはスケジューラーであって、プラットフォーム連携の保守にもう一つ手を挙げるつもりはありませんでした。
自分の時間も入れたコスト計算
基準には 4 チャンネルの Buffer Essentials を使いました。以下の公表価格は年払いのもので、2026 年 8 月に確認しています。ドルとユーロの金額は、直接同額であるかのように扱わず、それぞれ公表されている通貨のまま記載しています。
| オプション | 公表されている月額 | 含まれるもの | 自分で運用するもの |
|---|---|---|---|
| Buffer Essentials、4 チャンネル | $20, billed yearly | スケジューラーの UI と無制限の予約投稿 | インフラなし |
| n8n Cloud Starter | 20 €、年払い | ワークフロー実行 2,500 回 | ワークフローと認証情報 |
| n8n Cloud Pro | 50 €、年払い | ワークフロー実行 10,000 回 | ワークフローと認証情報 |
| n8n Community Edition | ソフトウェア費用なし | 自前ホストのワークフローエンジン | サーバー、アップデート、データ、バックアップ、監視 |
n8n のクラウド料金 では、Starter はおおむね私の Buffer Essentials 4 チャンネルと同じ入口価格帯にあります。これで、私のケースではマネージド版は消えました。ワークフローエンジンに同程度の月額を払ったうえ、より使いやすい公開インターフェースを失うことになるからです。 Community Edition の比較表 を見て、基本的なセルフホスト版をソフトウェア料金なしで使い続けられることは確認できました。ただし、それでサーバー代も私の時間も無料になるわけではありません。
自分のマシンのサイズを、4 GB RAM と 2 vCPU という万能の本番最低ラインに仕立てるつもりもありません。 n8n のデプロイ前提条件 は、かなり幅のあるリソース範囲を示しています。私の負荷は小さいのですが、別の構成なら同時実行、メディアのペイロード、コードステップ、データベース負荷、長い実行履歴によって状況は一気に変わり得ます。正直な答えは、ワークロードから出発してメモリと CPU を見張る、ということです。
SQLite は n8n の既定のデータベース であり、低ボリュームの単一インスタンス構成なら十分なこともあります。それでも、実行履歴が重要になったり、デプロイの拡大が見込まれる場合には PostgreSQL を選びます。PostgreSQL は、分散した キューモードの構成 が必要とするものでもあります。n8n はそのアーキテクチャを SQLite 上ではサポートしていないからです。ワークフローが重要になってからデータベースを移行するより、セットアップの段階でこの判断を下しておきたいところです。
高くついたのは VPS ではありません。私の週末でした。そこに JPEG で潰れた一晩、トークンの失敗、そして投稿が本当に出たかを繰り返し確認する作業が積み上がります。自分の時間に少しでも値段をつければ、節約分はみるみる縮み、マイナスにもなり得ます。まさにそこが、 セルフホスティングが安くなくなる地点です。乗り換えは今でも価値があったと思っていますが、1 週目にそう言えたかというと無理でした。
壊れたものと、変えたこと
目に見えた障害は 2 回とも Instagram のトークン失敗でしたが、より根の深い問題は沈黙でした。サブスクのスケジューラーには、アカウントの不調を見せるために設計された製品画面があります。私の最初のワークフローは n8n の内側で失敗し得るのに、外から見える症状は「その日投稿がなかった」だけでした。ここから学んだのは、自前ホストの配信システムは派手に失敗し、重複なしで復旧しなければならない、ということです。
- 失敗のアラートは n8n の外のチャンネルへ送り、プラットフォームの応答とワークフローの実行 ID を添えます。壊れたことを知らせてもらうのに、同じシステムに頼らずに済むようにするためです。
- トークンの有効期限とアプリ審査のステータスを追い、更新のテストは、予約投稿が最初の警告になる前に再認可できるだけ早い時点で行います。
- 公開の前に一意のコンテンツ ID を記録しておきます。これにより、失敗したプラットフォームのブランチだけが再試行でき、すでに成功したブランチへ重ねて投稿することはありません。
- n8n のデータボリュームとデータベースをバックアップし、リストアのテストまでをバックアップの一部と考えています。コピーしたファイルがきっと助けてくれる、とは想定しません。
- プロバイダーが許すところでは API のバージョンを固定し、変更履歴に目を通し、n8n 側またはプロバイダー側に変更があるたびに、すべてのプラットフォームブランチをテストします。
- 実行履歴とメディアファイルは、自分に本当に必要な保持期間に合わせて削っています。ソーシャル用の素材は、ごく小さな自動化を必要以上に大きなバックアップに変えてしまうからです。
これを自宅のマシンから動かす気はありません。午前 9 時に予約した投稿は、9 時にワークフローが立っていることを要求します。一方で家庭用の電源、回線、NAT、受信コールバックは、コンテンツカレンダーに持ち込みたくない変数を増やします。VPS はそうした自宅ネットワークの変数を取り除きます。ただし、TLS、バックアップ、監視、アップデート、復旧に対する私の責任までは取り除きません。
root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。
Linuxプランを見るこれをやるべきでない人
欲しいのがスケジューラーそのものなら、有料のスケジューラーに留まってください。それは慰めの選択肢ではありません。カレンダー、プレビュー、簡単な承認、幅広いチャンネル対応、そして最小限の保守が、あなたにとって月額に見合うなら、それを買うのが正しい判断です。独自の自動化が必要でないなら、あのインターフェースをワークフローのキャンバスに置き換えるのは、手順が増えるだけの後退です。
Buffer のような形の製品を、自分の手元に置きたいのであれば、n8n の前に Postiz Postiz を検討します。オープンソース版は自分のサーバーで動かせますし、対応チャンネルは 30 以上で、その中に TikTok も含まれます。ワークフローのキャンバスではなく公開カレンダーなので、有料スケジューラーから移る多くの人にとって、より自然な着地点になります。
もう一度やるとしたら、その理由はただ一つ、リサーチ、下書き、承認、公開、ログを 1 本のパイプラインにまとめたかったからです。私が受け入れた取引はこれです。無料のスケジューリングではなく、注意力で支払うコントロール。必要なのがスケジューリングだけなら、私は月額に戻ります。
同じセルフホストの道を進みたい場合、 当社のワンクリック n8n デプロイ を使えば、最初のサーバー導入という手順はなくなります。ただし、私がより重要だと感じた作業まではなくなりません。ワークフローの認証情報、プラットフォームの審査、アップデート、バックアップ、監視、そして失敗した投稿の復旧です。
よくある質問
Buffer の認可は n8n に引き継がれますか？
いいえ。Buffer に許可していたプラットフォーム連携は、Buffer 側のアプリと認可フローに属するものでした。私の n8n ワークフローには、独自の認証情報、トークン、スコープ、そしてアカウントや公開経路に必要なプラットフォーム審査が別途必要でした。
ソーシャルプラットフォームごとにブランチを分けるべきですか？
たいていは分けるべきです。私は文面、メディア、認証情報、エラー処理をプラットフォームごとに調整できるよう、ブランチを分けました。おかげで、Instagram のリクエストが失敗しても、X や LinkedIn ですでに成功した投稿を出し直すことなく再試行できました。
1 つの n8n ワークフローで複数のクライアント向けに配信できますか？
できます。ただし、認証情報、コンテンツソース、承認状態、ログはクライアントごとに分離します。プラットフォームの権限とクォータは、あくまで該当するアプリとアカウントに適用されるので、1 つの接続が成功したからといって、それを万能のアクセス権と考えてはいけません。
ワークフローは逃した投稿をどう取り戻すべきですか？
予定時刻を過ぎた承認済みの投稿を照会し、成功結果のないレコードだけを公開します。一意のコンテンツ ID と保存したプラットフォームの応答があるので、再起動や再試行によってすでに出た投稿が重複することはありません。
