APIレート制限計算機

公開・非公開を問わず、APIはほぼ必ずレート制限を公開します。たとえば1分あたり100リクエスト、1時間あたり1000リクエストなどです。1つの時間窓が許す量を超えるトラフィックを送る必要がある技術者は、作業をバッチに分割し、その間で待機しなければ、プロバイダからHTTP 429が返ったり資格情報が失効したりします。このAPIレート制限予算計算機は、1時間窓あたりの最大リクエスト数、送信予定の総リクエスト数、任意の時間窓秒数を受け取ります。必要な時間窓数、制限を超えない最大バッチサイズ、最後の部分バッチのサイズ、バッチ開始間に入れる遅延、最初のバッチを即時開始した場合の最小経過時間、および毎秒の最大リクエスト相当値を返します。正でないレート制限はinvalid_inputで失敗し、課金されません。

時間窓・バッチ・遅延で制限内に収める仕組み

長さW秒の時間窓あたりRリクエストというレート制限は、長さW秒の任意のスライディングまたは固定時間窓において、プロバイダが成功する呼び出しを最大R件まで受け入れることを意味します。合計D件のリクエストが必要でDがRより大きい場合、一度にすべてを送ることはできません。計算機は遠隔APIを呼び出しません。

入力契約、応答フィールド、検証ルール

POSTでJSON本体を送ります。rate_limitは時間窓あたり許可される正の整数リクエスト数、desired_requestsは実施予定の非負整数の呼び出し数、任意のwindow_secondsはその時間窓の正の有限秒数で、省略時は60です。各フィールドはJSON数値でも数値文字列でも構いません。欠落フィールド、非有限値、小数のdesired_requests、小数のrate_limit、厳密に正でないrate_limitはinvalid_inputとなり、フィールド名を含むメッセージを返します。成功時はrate_limit、desired_requests、window_secondsをエコーし、windows_needed、batch_size（完全バッチあたりの最大リクエスト数。作業が残るときはrate_limitに等しい）、last_batch_size（末尾の部分バッチ、またはDが割り切れるときの完全バッチ）、full_batches（余り前に最大サイズを使うバッチ数）、delay_between_batches_seconds、min_elapsed_seconds、rate_limitをwindow_secondsで割ったmax_requests_per_second、および天井規則を述べる短いformula文字列を返します。例：rate_limitが100、desired_requestsが350、window_secondsが60なら、時間窓4、バッチサイズ100、最終バッチ50、遅延60秒、最小経過180秒です。desired_requestsが0なら、エラーなく時間窓0・遅延0を返し、ドライラン計画に便利です。

APIレート制限予算計算機が役立つ場面

その件数とベンダーのレート制限をこの計算機に渡すと、試行錯誤の429嵐なしでワーカーループに入れられるスリープ予定が得られます。一括エクスポートの所要時間を見積もるプロダクト担当は、顧客に当日完了を約束する前に、文書件数を壁時計時間へ変換できます。検証失敗は残高を消費しません。Webhookの埋め戻し、検索ドキュメントの再インデックス、テナント移行などを行う統合スクリプトは、開始前に総件数を知っていることが多いです。可観測性やカオスツールは、公開制限から導いたmax_requests_per_secondを合成負荷ジェネレータが超えないことを検証できます。スケジュール論理はクライアント側に置き、このendpointを算術の唯一の正として使い、モバイル・エッジワーカー・CIジョブが同じ計画になるようにしてください。