GitLab.com レート制限の変更と運用ガイド

GitLab.com は、あらゆる規模のチームが信頼できるプラットフォームを必要とする数百万のプロジェクトをホストしています。需要の急速な高まりに伴い、同様の利用負荷が数倍になることを予想しています。すべての利用者（自動化やエージェントワークロードを含む）にとって快適に動作し続けるために不可欠なのは「予測可能な制限」です。

この拡大に合わせて持続可能にするため、レート制限の仕組みを更新いたします。

• 2026 年 10 月 19 日: 無料アカウントおよび認証されていないリクエストから適用開始
• 2027 年 1 月: Premium および Ultimate プランについても移行

変更される内容

GitLab.com のレート制限は、お客様のサブスクリプションプランと連携するようになります。

• サブスクリプション連動: Free、Premium、Ultimate の各プランには、ユーザーごとおよびトップレベルのグループごとに適用される独自のリミットが設定されます。
• スケジュール:
  • Free プランの変更は 2026 年 10 月 19 日 より実施。
  • Premium および Ultimate プランは 2027 年 1 月 に移行します。
• 認証による制限緩和:
  • サインインすると完全なリミットを享受いただけます。
  • 認証されたリクエストは、お客様のサブスクリプションプランに基づいて管理されます。
  • 認証情報なし（匿名）のリクエスト: IP アドレスあたり1 時間 60 回の制限が適用されます。
• 詳細情報: 各プランごとの詳細なリミット値は「レート制限」ドキュメントにて公開されています。

2026 年 10 月 19 日の変更内容とプレビューウィンドウ

Free プランおよび認証されていないトラフィックについては、正式な適用の前段階として以下の期間に「プレビューウィンドウ（ブラウンアウト）」を設定いたします。

• 実施時期:
  • 2026 年 10 月 7 日午後 15:00～19:00 (UTC)
  • 2026 年 10 月 14 日午後 15:00～19:00 (UTC)
• 対象: Free プランおよび匿名リクエストのみ。有料アカウントへのサインイン済みリクエスト（Premium/Ultimate）は影響を受けません。

プレビューウィンドウ（ブラウンアウト）とは？ 新しい制限を適用し、その後即時解除する短時間の計画的な試行期間です。

• サービスの他の機能は一切変更されません。
• 目的は、実際の制限が正式に適用される数週間前に、ワークロードが新しい制限下でどのように動作するかを実際に確認いただくことです。

新リミットの特徴 2026 年 10 月 19 日より発効する値は、GitLab.com の実態使用状況を踏まえて設定しています。

• 現状との比較: 現在すでに新リミットの範囲内に収まっているユーザーがほとんどです。利用上の変化をほとんど感じることなく過ごせるでしょう。
• 業界標準の考慮:
  • Free プランの匿名リクエスト上限は業界標準と一致します。
  • Premium および Ultimate プランはさらに generous（寛大） な設計となっており、他社プラットフォームがエンタープライズ向けプランに割り当てるレベルか、あるいは未公開の水準です。

リミットに近い状況にある場合への対応策

リミットに近づいている場合や超過する可能性がある場合は、以下の対応を検討してください。

• リクエストを認証してください
  • 通常はわずかな設定変更のみで済み、個人アクセストークン、OAuth トークン、または CI/CD ジョブトークンを呼び出すだけで、匿名枠（IP アドレスあたり 60 回）からお客様のプラン固有のリミット枠へと移行し、はるかに高い制限を享受いただけます。
• API の呼び出し方を確認してください
  • バッチ処理、キャッシュ活用、ページネーションの採用が効果的です。
  • 短い間隔で連続してポーリングを行う做法はリクエスト許容量を迅速に消費します。
• リミット超過時に適切に対応してください
  • リミットを超えると HTTP ステータスコード

    429 Too Many Requests

    に伴い、「Retry-After」ヘッダー（待機時間を示す）が返されます。
  • クライアント側でレスポンスヘッダーを確認すれば自動的に再試行タイミングを調整できます。
  • 指数関数的な退避戦略の方が、即座に再試行を行うよりも復旧が早くなります。
• Premium または Ultimate へのアップグレードを検討してください
  • アップグレードにより、ユーザーごとおよびトップレベルグループごとのリミット上限も引き上げられます。
• 追加キャパシティの購入をご検討ください
  • 継続的により高いリミットが必要である場合、本年後半に詳細発表を予定しています。
  • ニーズがある場合は、アカウントチームへお問い合わせいただくか、

    limits@gitlab.com

    へメールでご連絡いただき、具体的な要件をお知らせください。

変更される部分と変更されない部分

これらの制限は、特定のワークロードが他のすべての利用者にとってプラットフォームの速度を低下させることを防ぐために設定されています。通常のサインイン済みでの利用活動は対象外であり、ほぼすべてのユーザーにあっては日常の利用体験に変化はありません。

以下はこれまで通り正確に動作します：

• UI の閲覧
• エディタでの作業
• Git を用いたプッシュ・プル操作
• 自プラン内で実行される CI/CD

変更されない部分

• お客様ご自身のおデータとリポジトリへのアクセスおよびエクスポートはいつでも可能です。
• GitLab Self-Managed および GitLab Dedicated の制限設定は、お客様の管理者（operator）が保持いたします。本変更は GitLab.com 限定です。
• さらにの変更を加える際には、事前に通知いたします。

よくある質問

これに該当するかどうかはどのように確認すればよいですか？

最も混雑している 1 分間の利用状況を、公開されているお客様のプランごとの制限値と比較してください。

• ほとんどのお客様はまだその閾値に近づいていません。
• 間もなくして手に入る最速の信号としては、API レスポンスヘッダーに含まれる

  RateLimit-Remaining

  が挙げられ、これにより現在のウィンドウ内での残存分が示されます。
• 本年後半には製品内に使用状況を表示するビュー機能をリリース予定です。

私のプロジェクトは公開済みで非常にアクティブです。どのような選択肢がありますか？

以下の三つの対策が有効です：

1. 認証要求: プロジェクトを呼び出している自動化システムに対してサインインを求めることで、匿名枠（IP 制限）からそのシステム固有の制限枠へ移行させます。
2. 私有化: 構築対象の聴衆以外からのトラフィックである場合、プロジェクトを私有化することで、完全に匿名呼び出しを防ぐことができます。
3. アップグレード: Alternatively、はるかに高い制限を得るために Premium または Ultimate プランへのアップグレードを検討してください。

トップレベルグループに複数所属している場合どうなりますか？

お客様のユーザーリミットは、利用可能なサブスクリプションの中で最も高次のプランの制限値となります。Ultimate グループの一員であれば Ultimate の制限値を享受いただけます。

リミットを超えた場合どうなりますか？

• HTTP ステータスコード

  429 Too Many Requests

  が返されます。

• RateLimit-*

  ヘッダーおよび

  Retry-After

  （待機時間）付きで返信されます。
• 指定された間隔を過ぎた後に再試行を行ってください。

私の統合が genuinely に認証することができない場合どうすればよいですか？

• limits@gitlab.com

  へお問い合わせください。正当な匿名利用パターン（公開ステータスバッジが顕著な例）が存在します。
• ご所有の統合が影響を受ける可能性を懸念される場合は、ぜひご連絡ください。

これは GitLab Self-Managed または GitLab Dedicated にも適用されますか？

いいえ、本変更は GitLab.com 限定です。

追加リソース

• プラン別レート制限情報
• API リクエストの認証方法

ご質問や想定していないケースに遭遇された場合は？
アカウントチームへお問い合わせいただくか、

limits@gitlab.com

へメールでご連絡ください。