レート制限

エージェントワークフローと HTTP 呼び出しのための、ワークスペース単位および操作単位の制限、ヘッダー、リトライ動作。

UnifAPI は 2 層のレート制限を適用します。すべての Skills と API 呼び出しにわたってトラフィックを平準化するワークスペース単位の制限と、各公開データソースを保護する操作単位の制限です。

ヘッダー

すべてのレスポンス（2xx または 429）は、標準のヘッダーを保持します：

ヘッダー	意味
`X-RateLimit-Limit`	現在のウィンドウで許可されるリクエスト数
`X-RateLimit-Remaining`	現在のウィンドウで残っているリクエスト数
`X-RateLimit-Reset`	ウィンドウがリセットされる Unix タイムスタンプ（秒）
`Retry-After`	再試行までの待機秒数（`429` のみ）

ワークスペース制限とエンドポイント制限の両方が適用される場合、ヘッダーはより厳しい方を報告します。

デフォルト

プラン	ワークスペース制限	エンドポイント単位の制限
Free	60 req/min	ソースに応じて変動
Pay-as-you-go	600 req/min	ソースに応じて変動
Enterprise	カスタム	カスタム

`429` の処理

async function call(url: string, init: RequestInit, attempt = 0): Promise<Response> {
  const res = await fetch(url, init);
  if (res.status !== 429 || attempt >= 5) return res;

  const retryAfter = Number(res.headers.get("Retry-After") ?? 1);
  await new Promise((r) => setTimeout(r, retryAfter * 1000));
  return call(url, init, attempt + 1);
}

守るべき 2 つのルール：

Retry-After に従う。 UnifAPI は、その操作が必要とする待機時間を返します — 推測すると、たいてい事態を悪化させます。
繰り返しの 429 ではバックオフする。 Skill が連続して何度も制限に達する場合は、クエリを絞り込むか、並行数を減らすか、ワークスペース制限を引き上げてください。

バースト動作

制限はトークンバケット方式です。1 分間アイドル状態だったワークスペースは、定常状態の制限を一時的に上回ってバーストできます。本番トラフィックでこれに依存しないでください — 定常状態のレートに合わせて設計してください。

上限の引き上げを依頼する

より高い制限が必要ですか？ワークスペース ID、実行している Skill または操作、おおよその QPS 推定値を添えて support@unifapi.com にメールしてください。