Bluesky APIのレート制限の実際（ポイント制）

Blueskyの書き込みAPIは「回数」ではなく「ポイント」で制限されています。1時間5,000ポイント、レコード作成3ポイント、削除1ポイント。この仕組みを踏まえて4アカウントを1台のVPSで回した結果、レート制限エラーが0件になるまでの整理をまとめます。

Blueskyのレート制限は「回数」ではなくポイント制

Blueskyの書き込み系APIを触りはじめて最初につまずいたのが、制限の単位が「API呼び出し回数」ではないという点でした。上限は1時間あたり5,000ポイントで、操作の種類によって消費するポイントが違います。

操作	消費ポイント
レコード作成（投稿・フォロー・いいね）	3ポイント
レコード削除（アンフォローなど）	1ポイント

つまりcreateRecord系は重く、deleteRecord系は軽い。ここを取り違えると、体感の「操作回数」と実際の消費が3倍ズレます。

ポイント

いいねもフォローも投稿も、すべて「レコード作成」なので一律3ポイントです。種類ごとに別枠があるわけではなく、同じ5,000ポイントを食い合うと考える必要があります。

5,000ポイントを操作ごとに割ると、1時間の理論上限はこうなります。

5000 ÷ 3 = 約1,666回  … フォロー / いいね / 投稿
5000 ÷ 1 = 5,000回     … アンフォロー（削除）

この数字は「絶対に超えられない壁」であって、「ここまで回していい数字」ではありません。上限の数字を目標にした瞬間に設計が壊れます。実際に私が壊しました。

現在は4アカウントを1台のVPSから運用しています。1アカウントあたりの1日の処理量は次の通りです。

実測

RateLimitExceeded 0件

時間を分散させる設計に変えてから、レート制限エラーは出ていません

この量でも上限には当たっていません。理由は単純で、1日の総量を24時間に散らせば、1時間あたりの消費はポイント上限に対してかなり余裕があるからです。1時間の窓に対する制限なので、「1日でいくら回すか」よりも「1時間の中でどれだけ固まっているか」が効きます。

うまくいったこと

処理を時間帯で分散させたこと。同じ1日700いいねでも、まとめて実行するのと散らすのとでは1時間あたりの消費が全く違います。総量を減らさずにエラーを0にできたのは、ここだけの変更でした。

私が RateLimitExceeded を踏んだのは、設計を誤っていた時期に限られます。処理を時間的に集中させていたことが原因で、量そのものが多すぎたわけではありませんでした。

失敗したこと

1日分のタスクを短い時間に詰め込んで実行していた時期に、レート制限に当たりました。「1日あたりの数字が上限内なら大丈夫」という思い込みが原因です。制限は1時間の窓に対してかかるので、日次の総量を見ていても意味がありません。

これだけで、エラーは出なくなりました。リトライ処理の作り込みや上限の逐次監視といった凝ったことは、結果的に必要ありませんでした。

4アカウントを同一VPSから動かしていますが、上限には当たっていません。ポイント上限がアカウント単位で管理されているのか、他に何らかの要素が絡むのかについては、私の運用範囲では上限に当たっていないので検証できておらず、分かっていません。

注意

「4アカウントで問題なかった」は、それ以上のアカウント数で問題ないことを意味しません。私が確認できたのは4アカウント・上記の1日あたりの処理量までです。ここを超える構成での挙動については、何も言えません。

結論として、Blueskyの書き込みレート制限で重要なのは「作成は3ポイント、削除は1ポイント、1時間5,000ポイント」という単位の理解と、処理を1時間の窓に固めないことの2点でした。上限の数字自体は、日常的な運用量に対してはかなり大きい方だと感じています。

まとめ