ソーシャルメディアAPIのレート制限：計画しておくべきこと

プログラムから公開する場合、2つの別々のレート制限が適用され、そのうち自分でコントロールできるのはひとつだけです。

2つの階層

**プラットフォーム側の制限。**あらゆるソーシャルネットワークは、任意のアプリケーションがそのAPIでできることを、独自のウィンドウ、独自のヘッダー、超過時の独自の挙動で制限しています。これはプラットフォームごとに異なり、あまり予告なく変わります。

**プロバイダー側の制限。**統合APIを通じて公開している場合、そのサービスにも通常はプランに紐づいた制限があります。

後者は読み取りやすく、計画も立てやすいものです。厄介なのは前者です。統合APIを使っている限り、直接目にすることはないからです。プロバイダーがそれを吸収してくれるのは、支払っている料金の大きな理由のひとつですが、それが消えてなくなるわけではありません。あるプラットフォームが全ユーザーをスロットリングしている場合、それでもあなたの投稿は遅延します。

エラーだけでなく遅延も設計に含める

公開パイプラインでもっともよくある間違いは、「受理された」を「公開された」として扱うことです。

複数のプラットフォームでは、投稿の送信は成功を返し、実際の公開はその後に行われます。そのため失敗はもっと後、あなたのリクエストが200を返してからずっと経ってから、帯域外で届きます。データモデルに「送信済み」と「失敗」しかなければ、「これはおそらく公開中である」を置く場所がありません。

3つの状態のために設計し、保留中の状態を目に見えるようにしてください。

実践的なルール

**指数的にバックオフする。**429が返ってきたら、待ってから増加する遅延でリトライしてください。即座のリトライは状況を悪化させ、スロットルを長引かせることがあります。

**リトライに上限を設ける。**永遠にリトライを続けるパイプラインは、クォータを数分で消し去ります。あきらめて、大きくログを残し、人間に見てもらいましょう。

**作成リクエストを盲目的にリトライしない。**作成リクエストがタイムアウトした場合、それが成功したかどうかは分かりません。リトライすると重複した投稿が生まれることがあり、それは元の失敗より悪い結果です。リトライする前に確認するか、リトライを安全にするアプローチを使ってください。

**エンドポイントが対応していればバッチ処理する。**1回のリクエストで多数の投稿を作成すれば、コストは1リクエスト分です。同じ作業を50回の個別呼び出しで行えば、コストは50リクエスト分です。

BulkPublish自身の制限

無料プランの1日30リクエストは、APIを評価したり、軽くて個人的なものを動かしたりするために意図的に設定されたサイズです。本物のパイプラインを動かすには足りず、バックオフのないループは数秒でこれを使い果たします。

APIリクエストと投稿は別々の制限であることに注意してください。チャンネルの一覧取得、ステータス確認、メディアのアップロードはいずれも投稿を作らずにリクエストを消費するため、注意深く使えば、リクエストの予算は投稿数から想像するより長持ちします。

複数のキーは容量ではなく分離のためのもの

有料プランには複数のAPIキーが含まれますが、その理由はスループットを増やすためではありません。本番パイプライン、ステージング環境、AIエージェントといった異なるものに、異なる認証情報を持たせるためです。

その価値は何かが問題を起こしたときに現れます。すべてが共有するひとつの認証情報をローテーションするのではなく、午前2時にひとつのキーだけを失効させられます。

公開ジョブの適切な形

1. チャンネルは投稿ごとではなく起動時に一度だけ調べる
2. メディアをアップロードしてから、そのIDを参照する投稿を作成する
3. 存在する場合はバッチエンドポイントを使う
4. 429は指数的バックオフとリトライ上限で処理する
5. すべての失敗をレスポンスボディとともにログに残す。誰も見ていないのだから

まとめ

2つの制限が適用されます。統合APIを通しては見えないプラットフォーム側の制限と、見えるプロバイダー側の制限です。指数的にバックオフし、リトライに上限を設け、作成リクエストを盲目的にリトライせず、可能な場所ではバッチ処理し。そして「受理された」を「公開された」とは別の状態として扱ってください。複数のプラットフォームでは、それは文字どおり別の状態だからです。