# レート制限エラーとは？ - 解説

> レート制限エラーとは、リクエストを短時間に送りすぎたためにサービスがリクエストを拒否している状態を指します。CI がレート制限に達する理由と、バックオフやリトライがどう役立つかを学びましょう。

Source: https://latchkey.dev/ja/learn/ci-explained/what-is-a-rate-limit-error  
Updated: 2026-06-26

レート制限エラーとは、ある期間内に許可された回数を超えたために、サービスが意図的にリクエストを拒否している状態で、一般的には HTTP 429 として返されます。

サービスは自身を保護するために、クライアントが単位時間あたりに送信できるリクエスト数に上限を設けています。CI がその上限を超えると、多くの場合はパッケージインストールやイメージのプルが集中したタイミングで、サービスはリクエストを処理する代わりにレート制限エラーを返します。これはウィンドウがリセットされれば解消される一時的な状態です。

## レート制限とは何か

レート制限とは、特定のクライアントや IP から一定期間（毎分、毎時）に一定数のリクエストしか許可しないというポリシーです。しきい値を超えると、サービスはウィンドウがリセットされるまで以降のリクエストを拒否し、通常はステータス 429 Too Many Requests、時には 403 を返します。

## CI がレート制限を引き起こす理由

- 多数の並列 job が、共有された 1 つの IP から同じイメージやパッケージをプルする。
- レジストリへの未認証リクエストは、通常より厳しい制限が課される。
- タイトなループでの API 呼び出し（ステータス更新、コメント）のバースト。
- バックオフなしのリトライが、制限されたウィンドウ中にさらにリクエストを積み上げる。

## レスポンスの読み方

レート制限のレスポンスには、いつ再試行してよいかを示す Retry-After ヘッダーや残りクォータのヘッダーが含まれることが多くあります。それらを尊重するのが正しい振る舞いです。すぐにリトライして問題を深刻化させるのではなく、指示された時間だけ待ちましょう。

## 一時的、ただし注意点あり

レート制限エラーはウィンドウがリセットされるため一時的で、待機後のリトライは通常成功します。ただし正しいリトライはバックオフを伴い Retry-After を考慮したものです。即座にリトライすると次のウィンドウを消費するだけです。認証とキャッシュにより、そもそも制限に達する頻度を減らせます。

## Latchkey の視点

Latchkey の自己修復マネージド runner は、レジストリの 429 のようなレート制限エラーを一時的なものとして扱い、適切なバックオフを伴ってリトライします。そのため、忙しい build 中の一度きりのレート制限で build が失敗することはなく、制限のかかったサービスに過度な負荷をかけることもありません。

## Applying this to your pipeline

- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

## FAQ

### What is What is a rate limit Error? explained?

To protect themselves, services cap how many requests a client can make per unit of time. When CI exceeds that cap, often during a burst of package installs or image pulls, the service responds with a rate limit error instead of serving the request. It is a transient condition that clears as the window resets.

### What rate limiting is?

A rate limit is a policy that allows only so many requests in a period (per minute, per hour) from a given client or IP. When you cross the threshold, the service refuses further requests until the window resets, typically with status 429 Too Many Requests, sometimes 403.

### How to read the response?

Rate limit responses often include a Retry-After header or remaining-quota headers telling you when you may try again. Respecting those is the correct behavior: wait the indicated time rather than retrying immediately and deepening the problem.

### Transient, with a caveat?

A rate limit error is transient because the window resets, so a retry after a wait usually succeeds. But the right retry is backed off and Retry-After-aware; retrying instantly just consumes the next window. Authenticating and caching reduce how often you hit limits at all.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt