GitLab.comのレート制限が変わります

GitLab.comは、信頼できるプラットフォームを必要とするあらゆる規模のチームに向けて、数百万件のプロジェクトをホストしています。需要の伸びは急速で、今年はプラットフォームの負荷が数倍に達する見込みです。利用者全員がGitLab.comを高速に使い続けられるために欠かせないのは、予測可能な制限です。チームがプラットフォーム上で構築している自動化やエージェントのワークロードも、その例外ではありません。

スケールを続けながらこの状態を維持するために、レート制限の仕組みを見直します。2026年10月19日より、GitLab.comのレート制限はサブスクリプションプランに応じた内容へと変わります。まず対象となるのは、10月19日のFreeアカウントと未認証リクエスト。PremiumとUltimateは2027年1月に移行します。

変更内容

制限はサブスクリプションに応じた内容になります。 Free、Premium、Ultimateの各サブスクリプションプランには、それぞれ個別の制限が設定され、ユーザー単位とトップレベルグループ単位で適用されます。適用開始はFreeが10月19日、PremiumとUltimateが2027年1月です。

サインインすれば上限いっぱいまで使えます。 認証済みのリクエストには、サブスクリプションプランに応じた制限が適用されます。認証情報のないリクエストは、IPアドレスごとに1時間あたり60リクエストまでです。

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

10月19日に起こること

Freeと未認証のトラフィックを対象に、プレビューウィンドウを2回設けます。日程は10月7日と10月14日、時間はいずれも15:00〜19:00 UTCです。サインイン済みのPremiumとUltimateのリクエストは影響を受けません。これらの制限が変わるのは1月からだからです。一方、未認証のリクエストは送信元を問わず上限の対象となり、有料アカウントに対して認証情報なしで実行している自動化も含まれます。プレビューウィンドウ（エンジニアはブラウンアウトと呼びます）とは、新しい制限を一時的に有効にし、その後また無効に戻す、短時間の計画的な実施期間です。実施中、サービスのそれ以外の挙動は変わりません。目的は、制限が恒久的に適用される数週間前に、自分たちのワークロードが新しい制限下でどう動くかを実際に確認していただくことにあります。

10月19日、新しい制限が適用されます。

今回の制限値は、GitLab.comの実際の利用状況を分析して設定しました。ほぼすべてのユーザーはすでに新しい制限の範囲内にあり、変化に気づくことはありません。他の類似プラットフォームが許容している水準も参考にしています。Freeの制限と匿名リクエストの許容量は業界標準と同等の水準です。PremiumとUltimateはそれよりも余裕があり、他のプラットフォームがエンタープライズ向けプランに限定していたり、そもそも公開していないような水準に設定しています。

制限に近づいている場合

制限に近づいているとわかったら、リクエストを認証してください。多くの場合、必要な変更はごくわずかです。パーソナルアクセストークン（PAT）、OAuthトークン、CI/CDジョブトークンのいずれかを使えば、匿名の1時間あたり60リクエストからプランごとの制限へと切り替わります。プランごとの制限は、それよりはるかに大きい値です。

次に、APIの呼び出し方を見直してみてください。バッチ処理、キャッシュ、ページネーションは効果が大きく、反対に、短い間隔でのポーリングは許容量をあっという間に消費します。実際に制限を超えると、HTTP 429 が返り、待機時間を示す Retry-After ヘッダーが付きます。自身のレスポンスヘッダーを読むクライアントであれば、ほぼ自動的に問題は解消するはずです。すぐに再試行するよりも、指数的にバックオフしたほうが早く復帰できます。

PremiumまたはUltimateへのアップグレードでも、ユーザー単位・トップレベルグループ単位の制限が引き上がります。

継続的にさらに高い制限が必要な場合に向けて、標準のプラン制限を超えるキャパシティを購入できる仕組みを準備しています。詳細は本年内にお知らせする予定です。該当する場合は、担当のアカウントチームにご相談いただくか、limits@gitlab.com までご要望をお寄せください。

変わることと変わらないこと

今回の制限は、特定のワークロードがプラットフォーム全体の速度を低下させないようにするためのものです。サインインした通常の作業は対象ではなく、ほぼすべてのユーザーにとって日常の使い勝手は今までと変わりません。UIの操作、エディタでの作業、gitでのプッシュとプル、プランの範囲内でのCI/CDの実行は、いずれも現在とまったく同じように続けられます。一方で、負荷の高い一部の自動化と、ごく一部のFreeプランのワークロードは、新しい上限に達する見込みです。

変わらない点は次のとおりです。

• 自分のデータとリポジトリには、いつでもアクセスしてエクスポートできます。
• GitLab Self-ManagedとGitLab Dedicatedの制限は、これまでどおり運用者の管理下にあります。今回の変更はGitLab.comのみが対象です。
• 今後さらに変更を加える場合は、事前にお知らせします。

改めてのご案内 GitLab.comへのリクエストは必ず認証し、より高い制限をご利用ください。

よくある質問

この変更が自分に影響するかどうかを確認する方法
最も負荷の高い1分間の値を、プランごとに公開されている制限と比較してください。多くのお客様は制限に近づいていません。当面もっとも手早い目安になるのは、APIレスポンスに含まれる RateLimit-Remaining ヘッダーです。現在のウィンドウの残量がわかります。また、プランの制限に対する使用状況を確認できる画面を製品内に用意しており、本年内のリリースを予定しています。

公開プロジェクトへのアクセスが多い場合の選択肢
有効な方法は3つあります。1つ目は、プロジェクトを呼び出している自動化にサインインしてもらうことです。匿名の許容量ではなく、その自動化自身の制限が適用されます。2つ目は、想定した読者以外からのトラフィックであれば、プロジェクトをプライベートにすることです。匿名の呼び出しは一切届かなくなります。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 までメールでお問い合わせください。