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

Blueskyの書き込み制限は「1時間あたり何回」ではなくポイント制です。この記事では、実際に4アカウントを1台のVPSから回している立場から、ポイントの計算方法と、実運用の消費量、そしてRateLimitExceededを出さなくなるまでに直した設計を書きます。

Blueskyの書き込み制限は「回数」ではなく「ポイント」

自動化を組むときにまず引っかかるのが、Blueskyのレート制限が回数ではなくポイントで管理されている点です。仕組みはシンプルで、次の3つを押さえれば計算できます。

つまり、いいねもフォローも投稿も「レコードを作る」という点では同じ扱いで、コストは一律3ポイントです。ここを「いいねは軽い操作だから安いはず」と勝手に思い込むと、見積もりが3倍ずれます。

ポイント

作成が3、削除が1。アンフォローは、フォローの3分の1のコストしかかからないということです。フォロー／アンフォローを回す設計では、この非対称性がそのまま設計の自由度になります。

5,000ポイントを操作の単価で割ると、1時間あたりの理論上限が出ます。

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

数字だけ見ると、かなり余裕があるように見えます。実際、この上限は「人力では絶対に届かない水準」です。問題は、自動化を組むと1分で届いてしまうことです。

私が回している設定は、1アカウントあたり1日で次の量です。

これをポイントに換算します。作成は 700＋400＝1,100回で3ポイントずつ、削除は600回で1ポイントずつです。

作成 1,100 × 3 ＝ 3,300 pt
削除   600 × 1 ＝   600 pt
────────────────────
1日あたり合計   ＝ 3,900 pt

一方、1時間5,000ポイントの枠は、24時間ぶんに均せば120,000ポイントに相当します。1日ぶんの作業を全部足しても、1日ぶんの枠の3％強にしかなりません。実際、この量で4アカウントを回していて、上限に当たったことはありません。

実測

RateLimitExceeded 0件

4アカウントを1台のVPSから運用。時間を分散させて以降は発生していません

RateLimitExceeded が出たのは、設計を誤っていた時期だけでした。原因は総量ではなく、1日の総量が枠内に収まっていても、それを短時間に固めて投げれば普通に落ちるという当たり前のことを見落としていたからです。

制限は「1日5,000ポイント」ではなく「1時間5,000ポイント」です。1日3,900ポイントぶんの処理でも、それを1時間の中に詰め込めば枠の78％を一気に食います。そこに4アカウントぶんが重なれば、当然あふれます。

失敗したこと

その日のタスクを起動直後にまとめて流す設計にしていたこと。1日の合計だけを見て「枠の3％だから余裕」と判断していたのが誤りでした。制限が見ているのは1時間の窓です。

うまくいったこと

いいね・フォロー・アンフォローの実行を時間軸に分散させ、さらに4アカウントの実行タイミングを重ねないようにしただけで、RateLimitExceeded は0件になりました。総量は変えていません。変えたのは配置だけです。

正直に書いておきます。この制限がアカウント単位で数えられているのか、送信元IP単位でも合算されているのかは、私の運用では確かめられていません。

理由は単純で、4アカウントを1台のVPSから動かしていても一度も上限に当たっていないからです。当たっていない以上、「IPで合算されていないから当たらない」のか「合算されているがそれでも余裕がある」のかを区別できません。

注意

私の運用が無事だからといって、同じVPSにアカウントを増やし続けても安全だ、という保証にはなりません。1アカウントあたり1日3,900ポイント程度という前提が変われば、話は変わります。台数やアカウント数を増やすなら、増やす前後でエラー件数を必ず記録してください。

手順3を飛ばして「1日の合計」だけで判断すると、私と同じ失敗をします。

まとめ