n8nでAirtableからソーシャルメディアへ

Airtableは、コンテンツカレンダーとして理想に近いツールです。同じデータに対するグリッドビューとカレンダービュー、テキストと並ぶ添付ファイル、共同編集者、キャンペーンごとのビュー。

そこから公開済みの投稿にたどり着くまでの道のりは短いワークフローですが、信頼性を左右する2つの細部があります。

用意しておく価値のあるフィールド

Airtableの添付ファイルフィールドは、ここではスプレッドシートに対する本当の強みです。メディアは、どこかでホストしなければならないURLとしてではなく、行そのものと一緒に存在します。

ワークフロー

1. Scheduleトリガー。 15分または30分ごと。

2. Airtableノードでレコードを検索。 Status = "Ready"のフィルターを使います。これがゲートであり、このワークフローが書きかけの行を公開しない理由です。

3. 公開日でフィルター。 行がタイミングをコントロールすべき場合。

4. フィールドから投稿を組み立てる。 複数選択のチャンネルをチャンネル一覧にマッピングします。

5. BulkPublishノード、Post → Create。

6. Airtableノードでレコードを更新。 StatusをPublishedに設定し、投稿のURLを書き戻します。

ステップ6は省略できません

書き戻しがなければ、次回の実行でも同じ行がReadyのままとして見つかり、また公開されてしまいます。その次の実行でも同様です。15分ごとにポーリングするワークフローは、同じ投稿を1日に96回再公開することになります。

これはこの種のワークフローが失敗する、最も一般的なパターンであり、その症状は公の場で恥ずかしいものになります。

念には念を入れるなら、すでにPost URLを持つレコードも除外するフィルターを追加しましょう。独立した2つのチェックがあれば、片方が失敗しても重複は生まれません。

添付ファイル

AirtableのアタッチメントにはURLが付属しており、それをそのまま渡します。知っておくべきことが2つあります。

アタッチメントのURLには期限がある場合があります。 今URLを保存しておいて、再取得せずに数日後に使うようなワークフローは作らないでください。

ファイルをプラットフォームのルールと照合してください。 AirtableはInstagramが受け付けない50 MBの画像でも平気で保持します。メディアのルールは投稿作成時に検証されるため、静かに失敗するのではなく明確なエラーが返りますが、ワークフローはそれをどこかで確認できるようにログへ残すべきです。

スケジュールするか、今すぐ公開するか

ワークフローがたまたま実行されたタイミングで公開するのではなく、Publish atフィールドを予約時刻にマッピングすることを優先しましょう。

理由は2つあります。行がReadyになるのは誰かがデスクにいるタイミングであり、それはあなたのオーディエンスが読んでいるタイミングとは限りません。また、予約投稿であれば、その行が間違っていたと判明した場合にキャンセルできます。

まずドラフトで

最初の1週間は、下書きを作成しましょう。何も公開されないうちに、特にチャンネルと添付ファイルまわりで、フィールドのマッピングが実際にどう反映されるかを確認できます。

プランの上限

• チャンネル： Free：3（プラットフォームごとに1）。Pro：30（プラットフォームごとに2）。Business：75（プラットフォームごとに5）。
• 投稿： Free：3件/日。Pro：30件/日。Business：無制限。
• API リクエスト/日： Free：30。Pro：5,000。Business：50,000。

15分ごとにポーリングするワークフローは、何も公開しない時点で1日に96リクエストを消費するため、無料プランは実運用ではなくテスト用です。

BulkPublishは15のプラットフォームに公開します。

まとめ

ドラフトが公開されないよう、Statusフィールドでフィルターをかけましょう。そして公開後にAirtableへ書き戻し、行が再び拾われないようにしましょう。これが、このようなワークフローが重複投稿を生み出す仕組みです。Publish atは、トリガーのタイミングで投稿するのではなく予約時刻にマッピングし、添付ファイルはプラットフォームのメディアルールと照合しましょう。