この記事で分かること
Bluesky APIの書き込みレート制限が「回数」ではなく「ポイント制」で管理されていること、そして実際に4アカウントを1台のVPSから運用してみて、どのくらいの操作量なら上限に当たらなかったのかをまとめます。理論上限と実運用の数字の距離感をつかむための記事です。
Blueskyの書き込み制限はポイントで数える
Blueskyの書き込み系操作には、1時間あたり5,000ポイントという上限があります。ここが最初に理解しておくべき点で、「1時間に何回まで」という単純な回数制限ではありません。操作の種類ごとに消費するポイントが違います。
レコード作成（投稿・フォロー・いいね） 3ポイント レコード削除（アンフォローなど） 1ポイント 1時間の上限：5,000ポイント
つまり、同じ「1回のAPI呼び出し」でも、フォローとアンフォローではコストが3倍違うということです。
理論上限を計算してみる
5,000ポイントを操作種別ごとに割り切ると、1時間の理論上限はこうなります。
- フォロー（3ポイント）だけを回した場合：約1,666回
- アンフォロー（1ポイント）だけを回した場合：5,000回
いいねも投稿もレコード作成なので3ポイント、つまりフォローと同じ枠を食い合います。「いいねは軽い操作だから多めに回せる」という発想は、Blueskyのポイント制では成り立ちません。ここを勘違いすると設計を間違えます。
実際に運用している量
私が現在回している量は、1アカウントあたり1日でこの程度です。
いいね 700 /日 フォロー 400 /日 アンフォロー 600 /日
これをポイントに換算すると、いいねとフォローが作成系なので (700 + 400) × 3、アンフォローが 600 × 1 です。1日単位の合計としては、1時間の上限5,000ポイントを大きく上回る量になります。したがって、この運用は「1時間に詰め込む」やり方では絶対に成立しません。24時間に分散させることが前提の数字です。
この状態で4アカウントを1台のVPSから動かしていますが、上限に当たったことはありません。レート制限はアカウント単位で効いているため、1台のVPSに何アカウント載せているかは（少なくともこの規模では）問題になっていません。
RateLimitExceeded が出たのは設計ミスの時期だけ
正直に書くと、`RateLimitExceeded` を踏んだことはあります。ただしそれは設計を誤っていた時期に限られます。処理を時間軸に分散させる仕組みを入れてからは、エラーは0件です。
教訓としては単純で、1日の総量が上限を超えているかどうかではなく、ある1時間に何ポイント集まっているかだけが問題だということです。1日700いいねという数字自体は何の危険信号でもなく、それを起動時に一気に流すか、時間をかけて散らすかで結果が変わります。
設計するときに意識していること
- いいね・フォロー・投稿はすべて3ポイントの同じ枠なので、合算して見積もる
- アンフォローは1ポイントなので、整理系の処理は比較的余裕がある（それでも同じ5,000ポイントを共有している）
- 1日の総量から逆算して、1時間あたりの消費ポイントが5,000に届かないよう時間を分散させる
- 複数アカウントでも、それぞれのアカウントのポイント消費だけを見る
分かっていないこと
私が確認できたのは、上に書いた運用量では上限に当たらなかった、という事実だけです。この量よりどこまで増やせるのか、上限に近づいたときにどういう挙動になるのかは、意図的に試していないので分かりません。また、ここで挙げたポイント値以外の操作のコストについても、私は検証していません。「この数字なら安全」と一般化できる根拠は持っていない、というのが正確な状態です。
まとめ
- Blueskyの書き込み制限は1時間あたり5,000ポイントのポイント制
- レコード作成（投稿・フォロー・いいね）は3ポイント、削除（アンフォロー）は1ポイント
- 理論上限はフォローで約1,666回/時、アンフォローで5,000回/時
- 実運用は1アカウント1日あたり700いいね・400フォロー・600アンフォローで、4アカウントを1台のVPSから回して上限に当たっていない
- 1日の総量ではなく「1時間に何ポイント集まるか」が本質。時間分散を入れてから RateLimitExceeded は0件
- これ以上の量でどうなるかは検証していないため分からない
