Notionでコンテンツを計画し、それを手作業で公開すること——このギャップを埋めるのがこの方法です。Zap自体は短いものです。うまく動くかどうかを決めるのはデータベース設計と2つの特定の落とし穴です。
まずデータベースを設計する
| プロパティ | 型 | 目的 |
|---|---|---|
| Content | テキスト | 投稿本文 |
| Status | セレクト | Draft、Ready、Published |
| Channels | マルチセレクト | 対象プラットフォーム |
| Publish at | 日付 | いつ公開されるか |
Statusは省略できません。 Notionのページは作成された瞬間から連携に見えてしまい、誰かがそこに入力している最中でも同じです。ゲートがないと、書きかけの考えを公開してしまいます。
Zap
トリガー：Notionの更新されたデータベース項目。 データベースを監視します。
フィルタ：StatusがReadyのときだけ続行する。 これがゲートです。
フォーマッター（任意）。 テキストを整えます。
アクション：BulkPublishでPostを作成。 コンテンツ、チャンネル、予約時刻。
アクション：Notionのデータベース項目を更新。 StatusをPublishedに設定します。
2つの落とし穴
落とし穴その1：書き戻さないこと。 ZapがStatusをPublishedに設定しない場合、その行はReadyのままです。そのページへの以降の編集はすべて再びZapをトリガーし、再度公開されます。これが重複投稿を生む失敗であり、起きたときには公になります。
ステータスを戻し、二重の安全策が欲しければ、すでに投稿URLを持っている行を除外するフィルタも加えましょう。
落とし穴その2：Notionのリッチテキスト。 Notionのコンテンツは構造化されています。見出し、太字、箇条書き、トグル、インラインリンク。ソーシャルプラットフォームが受け付けるのはプレーンテキストです。
Notionのブロックをそのまま渡すと、Markdown文字が文字どおりに表示されるか、フィールドマッピングが間違ったプロパティを選んだ場合は空の投稿になります。意図的にプレーンテキストを抽出し、信頼する前に実際の行が何を生成するか確認しましょう。
これにZapierは必要か
Zapを介さずに公開する直接のNotion連携があります。ワークフローが「行がreadyとマークされたら投稿が出る」だけなら、それは可動部分が少なく、タスクごとのコストもかかりません。
Zapを構築するのは、その中間が必要な場合です。複数のプロパティでのフィルタリング、テキストの変換、コンテンツタイプによるルーティング、あるいはNotionと別のソースを結合する場合です。
トリガー時ではなく予約する
Publish atプロパティを予約時刻にマッピングしましょう。行が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。
BulkPublishはFacebook、Instagram、TikTok、YouTube、X、Threads、Bluesky、Pinterest、Google Businessプロフィール、LinkedIn、Mastodon、Discord、Telegram、Tumblr、Snapchatの15プラットフォームに公開します。
まとめ
Statusプロパティでゲートをかけなければ、下書きを公開してしまいます。公開後にStatusを書き戻さなければ、以降の編集のたびにその行を再公開してしまいます。Notionの書式はそのままでは持ち運べないため、プレーンテキストを抽出しましょう。そして、維持すべきZapを追加する前に、直接のNotion連携があなたのケースをカバーしているか確認しましょう。