ソーシャルメディア予約投稿API：完全ガイド

APIを通じて即座に公開するのは単純です。興味深い問題があるのは予約のほうです。予約された投稿は未来についての約束であり、未来には夏時間、障害、そして気が変わった投稿が含まれるからです。

タイムゾーン：明示的に渡す

もっともよくある予約のバグは、年に2回1時間ずれてしまう投稿です。

予約時刻には2つのものが必要です。ISO-8601形式のタイムスタンプとしての瞬間と、America/New_YorkのようなIANA名として表現されたゾーンです。

await bp.posts.create({
  content: 'Morning update.',
  channels: [{ channelId: 1, platform: 'linkedin' }],
  status: 'scheduled',
  scheduledAt: '2026-04-10T14:00:00Z',
  timezone: 'America/New_York',
});

一度きりの投稿ならUTCの瞬間だけを保存しても問題ありません。しかし繰り返しのものには誤りです。「毎平日ローカル時間の午前9時」は、夏時間の切り替え前後で異なるUTCの瞬間になるからです。それを正しく保つのがゾーンです。

-05:00のような生のオフセットを、ゾーンの代わりとして保存しないでください。オフセットは変わりますが、ゾーンは変わりません。

2つ以上の状態をモデル化する

投稿は単に「予約済み」か「公開済み」だけではありません。少なくとも以下のために設計してください。

• draft：作成されたがキューには入っていない
• scheduled：時刻に対してキューに入っている
• processing：プラットフォームに送信済みで、結果は不明
• published：確認済みで公開中
• failed：理由付き
• partial：一部の対象には公開され、一部には公開されていない

人が忘れがちなのはprocessingとpartialです。

processingが存在する理由は、複数のプラットフォームが投稿を受理し、非同期に公開するからです。200は公開そのものではなく、本当の結果は後から届きます。

partialが存在する理由は、ひとつの投稿が通常、複数のプラットフォームを対象とするからです。3つが成功し1つが失敗した場合、「公開済み」も「失敗」もどちらも真ではなく、無理にどちらかに押し込めば、ユーザーに嘘をつくUIができあがります。

プラットフォームがダウンしたときに起きること

これに備えて設計してください。実際に起こることだからです。

**一時的な失敗はバックオフしながらリトライすべきです。**あるプラットフォームが2分間503を返しても、投稿を失うべきではありません。

**リトライは安全でなければなりません。**タイムアウトした作成リクエストは、実は成功していたかもしれません。盲目的にリトライすると投稿が重複し、それは元の失敗より悪い結果です。リトライする前に確認してください。

**恒久的な失敗はまったくリトライすべきではありません。**期限切れのトークンや無効なキャプションは自然には直らず、リトライはクォータを消費し通知を遅らせるだけです。

**誰かに知らせる必要があります。**午前3時に失敗した予約投稿は、あなたがそれを目立たせない限り静かなままです。Webhookが適切な仕組みです。

編集とキャンセル

予約された投稿は、破る必要が生じるかもしれない約束です。あなたの連携は、時刻の変更、内容の編集、完全なキャンセルをサポートすべきです。

いったんプラットフォームが投稿を保持すると、それを許すかどうかはプラットフォームによって異なります。これが、自分自身の層で予約管理し、最後の瞬間に送信するほうが、プラットフォームに未来の日付の投稿を渡すよりうまくいく理由のひとつです。

キュースロットと明示的な時刻

2つの予約モデルがあり、どちらにも居場所があります。

明示的な時刻は、投稿がある瞬間に届く必要がある場合に望ましいものです。ローンチ、イベント、協調した発表などです。

キュースロットは、安定した滴下配信に望ましいものです。投稿の頻度を定義すれば、次の投稿は次に空いているスロットを取るため、バッチ内のすべての投稿についてタイムスタンプを選ぶ必要がありません。

大量の作業では後者のほうがはるかに手間が少なく、「30件の投稿をキューに入れる」を30回の判断ではなく、意味のあるひとつの操作にするモデルです。

繰り返しスケジュール

予約された投稿とは別物です。繰り返しスケジュールは、毎日・毎週・隔週・毎月といった頻度で投稿を生成し続けるルールです。

設計すべきことが2つあります。ここではゾーンが上記の夏時間の理由でさらに重要になります。そして、繰り返し投稿に添付されたメディアは、公開後に削除されるのではなく保持される必要があります。スケジュールが次回もそれを再び必要とするからです。

プランの上限

まとめ

すべての予約タイムスタンプにIANAタイムゾーンを添えて渡してください。特に繰り返しのものではそうです。processingとpartialを実在する状態としてモデル化してください。非同期の公開と複数プラットフォームへの投稿が、どちらも実際に発生させるからです。一時的な失敗はバックオフしながらリトライし、作成リクエストは決して盲目的にリトライせず、Webhookを使って午前3時の失敗が静かに終わらないようにしましょう。