レート制限

提供元が制限を設けるのは、単純な理由からです。容量には限りがあり、共有されているので、暴走した一つのスクリプトが他のみんなを遅くしてはいけません。制限は費用を抑え、盗まれたキーでサービスを溢れさせるような悪用も防ぎます。制限がなければ、ループのバグが一分間に何千もの呼び出しを送りかねません。行列に並ぶお客さんをさばくパン屋を思い浮かべてください。一人のお客さんに最初の一分で全部のパンを買わせては、残りの人に不公平なので、パン屋は一人あたりの数に上限を設けます。良い制限とは、公平な取り分を数字で書いたものにすぎません。

制限にはいくつかの形があります。分ごとの短い制限は、急な集中を吸収します。日ごとなどのより長い制限は、総使用量を抑えます。決まった時刻にリセットされる固定の窓の場合もあれば、直近の一定時間をいつも振り返る、ローリングの窓の場合もあります。リクエストの数を数えるサービスもあれば、トークンを数えるサービスもあり、同時に実行できる呼び出し数にも上限を設けるサービスがあります。制限はプランによって異なることが多く、上位のプランほど上限が高くなります。

制限への対処は、ちょっとした技術です。Retry-After ヘッダーがあれば読み、その時間だけ待ちます。なければ、指数的なバックオフと少しのランダムなジッターで再試行し、決して間断のないループにはしません。回答をキャッシュしたり作業をまとめたりして呼び出しを減らし、負荷を時間に分散させます。レート制限は支出の上限ではないことを覚えておいてください。残高がなくなるのは別のエラーで、対処も違います。ライブラリは、丁寧に再試行し、試行の間に一時停止するこの処理を包んでいることが多く、自分でクライアントを書くときは、突発的な集中と持続的な負荷のどちらが原因かがわかるよう、すべての429を時刻とともに記録してください。小さなパン屋の例のように、公平な取り分を守る仕組みだと理解しておけば、制限に出会っても慌てずに済みます。

NeverNo の API ドキュメントが規則を定めています。各アカウントには、プランに応じて、直近24時間あたりの API リクエスト数があります。それを超えると、窓が進むまで、呼び出しはコード rate_limited を伴う429を受け取ります。分ごとの短い制限も適用され、その場合の429には Retry-After ヘッダーが付きます。トークン数や画像数にかかわらず、すべての呼び出しは一つのリクエストと数えられますが、トークンを数えるエンドポイントは数えられません。窓がローリングなので、容量は、午前0時にいっせいにではなく、古い呼び出しが時間とともに外れていくにつれて、少しずつ戻ります。

プランごとの正確な数字は API ドキュメントの表にあり、このページが古くならないよう、ここでは繰り返しません。クレジットが尽きた場合は別で、API は insufficient_credits を伴う402を返します。Dev のサブスクリプションは、Pro+のリクエスト制限を使います。数字の唯一の出典はドキュメントなので、スクリプトは推測を書き込むのではなく、そこから上限を読み、429エラーが急に増えたら、減速して作業を待ち行列に入れる合図と受け止めるべきです。