GitLab.com のレート制限が変更されます

GitLab.com のレート制限が変更されます

GitLab.com は、あらゆる規模のチームが信頼できるプラットフォームとして、何百万ものプロジェクトをホストしています。需要は急速に高まっており、今年中にプラットフォームの負荷が数倍になると予想されます。予測可能な制限こそが、プラットフォーム上で構築されている自動化やエージェントのワークロードを含む、すべてのユーザーにとって GitLab.com を高速に保つ鍵となります。

スケールアップしながらこれを維持するため、レート制限の仕組みを更新します。2026年10月19日より、GitLab.com のレート制限はサブスクリプションティアに準拠するようになります。無料アカウントと認証されていないリクエストは10月19日に、Premium および Ultimate は2027年1月に適用されます。

変更点

制限がサブスクリプションに準拠します。 無料、Premium、Ultimate のサブスクリプションプランには、それぞれユーザーごとおよびトップレベルグループごとに適用される独自の制限が設けられます。無料プランは10月19日、Premium および Ultimate は2027年1月に発効します。

サインインすると、制限が最大限に適用されます。 認証されたリクエストは、以下のサブスクリプションプランによって管理されます。資格情報なしで到着したリクエストは、IPアドレスあたり1時間あたり60リクエストに制限されます。

プランごとの制限は、レート制限のドキュメントに公開されています。

10月19日に何が起こるか

無料および認証されていないトラフィック向けに、10月7日と10月14日の15:00から19:00 UTCにかけて、2回のプレビュー期間が設けられます。サインインした Premium および Ultimate のリクエストは、これらの制限が1月まで変更されないため、影響を受けません。認証されていないリクエストは、資格情報なしで有料アカウントに対して実行される自動化を含む、どこから来たとしても制限されます。プレビュー期間（エンジニアはこれをブラウンアウトと呼びます）は、新しい制限を一時的に有効にしてから元に戻す、短く計画された期間です。サービスに関するその他の変更はありません。その目的は、新しい制限が正式に適用される数週間前に、自身のワークロードがどのように動作するかを実際に確認してもらうことです。

10月19日に新しい制限が発効します。

これらの制限は、GitLab.com が実際にどのように使用されているかを分析して設定しました。ほぼすべてのユーザーはすでに新しい制限内に収まっており、変更に気づかないでしょう。また、類似プラットフォームが許可しているレベルも調査しました。無料プランの制限と匿名での利用可能数は業界標準に合致しており、Premium および Ultimate はさらに寛大で、他のプラットフォームがエンタープライズティア向けに予約しているか、まったく公開していないレベルです。

制限に近い場合

制限に近づいていることに気づいた場合は、リクエストを認証してください。これは通常、小さな変更です。たとえば、パーソナルアクセストークン、OAuthトークン、または CI/CD ジョブトークンを呼び出すことで、リクエストは匿名での1時間あたり60リクエストから、はるかに高いプランの制限に移行します。

次に、APIの呼び出し方法を確認してください。バッチ処理、キャッシング、ページネーションは非常に効果的であり、タイトなループでのポーリングは割り当てを急速に消費します。制限を超えた場合、HTTP 429 エラーと、待機時間を指定する Retry-After ヘッダーが返されます。そのため、レスポンスヘッダーを読み取るクライアントは、ほとんどの場合自動的に修正されます。指数バックオフは、すぐに再試行するよりも早く回復します。

Premium または Ultimate へのアップグレードも、ユーザーごとおよびトップレベルグループごとの制限を増加させます。

継続的に高い制限が必要な場合は、標準プランの制限を超える容量を購入する方法を開発中です。詳細は今年後半に発表します。もし該当する場合は、アカウントチームに連絡するか、limits@gitlab.com までメールで必要な内容をお知らせください。

変更される点とされない点

これらの制限は、単一のワークロードが他のすべてのユーザーのプラットフォームを遅くできないように設定されています。通常のサインインした作業は対象ではなく、ほとんどのユーザーにとって、通常の日は何も変わりません。UIの閲覧、エディタでの作業、gitでのプッシュとプル、プラン内でのCI/CDの実行はすべて、今日と同じように継続されます。一部の重い自動化と少数の無料ティアのワークロードは、新しい上限に達する可能性があります。

変更されない点：

• 自分のデータやリポジトリには常にアクセスしてエクスポートできます。
• GitLab Self-Managed および GitLab Dedicated の制限は、オペレーターによって管理されます。これは GitLab.com のみの変更です。
• 追加の変更を行う前に通知します。

リマインダー： GitLab.com へのリクエストを認証して、制限を高く保つようにしてください。

FAQ

これが自分に影響するかどうかはどうすればわかりますか？
最も忙しい1分間を、プランごとの公開されている制限と比較してください。ほとんどの顧客は制限に近くありません。それまでの間、最も簡単な指標は、APIレスポンスの RateLimit-Remaining ヘッダーです。これは現在のウィンドウの残り量を示します。また、今年後半にリリース予定の製品ビューで、プランの制限に対する使用状況を表示できるように開発中です。

私のプロジェクトは公開されていて、トラフィックが多いです。どのような選択肢がありますか？
3つの方法があります。プロジェクトにアクセスする自動化にサインインを要求し、匿名での利用可能数ではなく、それ自身の制限に移行させます。トラフィックが構築したオーディエンスから来ていない場合はプロジェクトをプライベートにし、匿名での呼び出しを完全に停止します。または、Premium または Ultimate にアップグレードして、はるかに高い制限を利用します。

複数のトップレベルグループのメンバーである場合、どうなりますか？
ユーザー制限は、利用可能な最も高いサブスクリプションティアになります。もしあなたがUltimateグループのメンバーであれば、Ultimate 制限にアクセスできます。

制限に達するとどうなりますか？
429 Too Many Requests エラーと RateLimit-* ヘッダー、および Retry-After が返されます。指定された間隔を待ってから、再試行してください。

私のインテグレーションは本当に認証できません。どうすればよいですか？
limits@gitlab.com までご連絡ください。公開ステータスバッジのように、正当な匿名パターンが存在します。所有しているインテグレーションが影響を受ける可能性があると懸念している場合は、ご連絡ください。

これは GitLab Self-Managed または GitLab Dedicated に適用されますか？
いいえ。これは GitLab.com 限定の変更です。

追加リソース

• プランごとのレート制限
• API リクエストの認証
• 質問がある場合、または想定外のケースに遭遇した場合は？アカウントチームに連絡するか、limits@gitlab.com までメールしてください。