REST API のレート制限

REST API のレート制限、それを超えないようにする方法、およびそれを超えた場合の処理方法について説明します。

この記事で

プライマリ レート制限について

          GitHub では、特定の時間内に行うことができる REST API 要求の数が制限されます。 この制限は、不正使用やサービス拒否攻撃を防ぐのに役立ち、すべてのユーザーが API を使用できるようにします。

検索エンドポイントなどの一部のエンドポイントには、より厳しい制限があります。 これらのエンドポイントの詳細については、「レート制限用 REST API エンドポイント」を参照してください。 GraphQL API には、個別のプライマリ レート制限もあります。 「GraphQL API のレート制限とクエリ制限」を参照してください。

プライマリ レート制限を超えた要求など、organization の API アクティビティを表示する方法については、「組織内での API のインサイトの表示」をご覧ください。

一般に、次に説明するように、認証の方法に基づいて REST API のプライマリ レート制限を計算できます。

認証されていないユーザーのプライマリ レート制限

パブリック データのみをフェッチする場合は、認証されていない要求を行うことができます。 認証されていない要求は、要求を行ったユーザーまたは申請ではなく、発信元の IP アドレスに関連付けられます。

認証されていない要求のプライマリ レート制限は、1 時間あたり 60 要求です。

認証されたユーザーのプライマリ レート制限

personal access token を使用して API 要求を行うことができます。 さらに、GitHub App または OAuth app でも、次にユーザーに代わって API 要求を行うことができます。

これらの要求はすべて、1 時間あたり 5000 件の個人的レート制限に向けてカウントされます。 GitHub App 組織が所有する GitHub Enterprise Cloud によってユーザーに代わって行われた要求には、1 時間あたり 15,000 要求のより高いレート制限があります。 同様に、OAuth app 組織が所有または承認している GitHub Enterprise Cloud によってユーザーに代わって行われる要求は、もしあなたが GitHub Enterprise Cloud 組織のメンバーである場合、1時間あたり15,000件に制限された高いリクエストレートを持ちます。 ただし、上限が高いアプリによって要求された場合、下限の認証方法で使用できる残りの予算が削減されます。 たとえば、リクエストの上限が15,000のアプリがユーザーに代わって10,000件のリクエストを行う場合、アプリには5,000件のリクエストが残っていますが、personal access tokens の5,000リクエスト分の予算はすでに使い果たされています。

メモ

          [Enterprise 監査ログ API エンドポイント](/rest/enterprise-admin/audit-log#get-the-audit-log-for-an-enterprise)には、ユーザーと IP アドレスごとに 1 時間あたり 1,750 クエリのレート制限があります。 統合がレート制限エラー (通常は 403 または 429 応答) を受け取った場合は、GitHub API に対して別の要求を行う前に待機する必要があります。

Git LFS アクセスの基本的なレート制限

Git LFS コンテンツをアップロードまたはダウンロードするときは、API 要求が必要です。 これらは個別のレート制限バケットに加算され、その制限は、認証されていない要求の場合は 1 分あたり 300 要求、認証された要求の場合は 1 分あたり 3,000 要求です。

Git LFS で使われるバッチ API の既定では、API 要求ごとに 100 個の Git LFS オブジェクトが処理されます。 つまり、認証されていないユーザーは 1 分あたり 30,000 個の Git LFS オブジェクトをダウンロードでき、認証されたユーザーは 1 分あたり 300,000 個の Git LFS オブジェクトをアップロードまたはダウンロードできます。

          GitHub Appインストールのプライマリ レート制限

インストール アクセス トークンを使って認証された GitHub Apps は、インストールの最小レート制限である 1 時間あたり 5,000 要求を使います。 GitHub Enterprise Cloud organization または Enterprise 上のインストールの場合、インストールには 1 時間あたり 15,000 要求というレート制限があります。

GitHub Enterprise Cloud organization または Enterprise 上ではないインストールの場合、インストールのレート制限はユーザーとリポジトリの数に応じてスケーリングされます。 20以上のリポジトリを持つインストールでは、リポジトリごとにⅠ時間あたり50リクエストが追加されます。 ユーザー数が 20 人を超える組織のインストールでは、ユーザーごとに 1 時間あたり別の 50 要求を受け取ります。 レート制限は、1 時間あたり 12,500 要求を超えて増やすことはできません。

GitHub App ユーザー アクセス トークンのプライマリ レート制限 (インストール アクセス トークンとは対照的) は、認証されたユーザーのプライマリ レート制限によって決まります。 このレート制限は、別の GitHub App または OAuth app がそのユーザーに代わって行う要求と、ユーザーが personal access token で行った要求と組み合わされます。 詳しくは、「REST API のレート制限」をご覧ください。

のプライマリ レート制限 OAuth apps

          OAuth appによって生成される OAuth アクセス トークンのプライマリ レート制限は、認証されたユーザーのプライマリ レート制限によって決まります。 このレート制限は、別の GitHub App または OAuth app がそのユーザーに代わって行う要求と、ユーザーが personal access tokenで行った要求と組み合わされます。 「[認証されたユーザーのプライマリ レート制限](#primary-rate-limit-for-authenticated-users)」を参照してください。

OAuth アプリでは、クライアント ID とクライアント シークレットを使用してパブリック データをフェッチすることもできます。 次に例を示します。

curl -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET -I https://api.github.com/meta

これらの要求では、レート制限は OAuth app ごとに 1 時間あたり 5,000 要求です。 アプリが GitHub Enterprise Cloud 組織によって所有されている場合、レート制限は 1 時間あたり 15,000 要求です。

メモ

アプリのクライアント シークレットを、クライアント側のコードやユーザー デバイスで実行されるコードに含めないでください。 クライアント シークレットを使用して、アプリを承認したユーザーの OAuth アクセス トークンを生成できるため、常にクライアント シークレットをセキュリティで保護する必要があります。

          GitHub Actionsの`GITHUB_TOKEN`に対するプライマリ レート制限

組み込みの GITHUB_TOKEN を使用して、 GitHub Actions ワークフローで要求を認証できます。 「ワークフローでの認証に GITHUB_TOKEN を使用する」を参照してください。

GITHUB_TOKEN のレート制限は、リポジトリごとに 1 時間あたり 1,000 要求です。GitHub Enterprise Cloud アカウントに属するリソースへの要求では、制限はリポジトリごとに 1 時間あたり 15,000 要求です。

セカンダリ レート制限について

プライマリ レート制限に加えて、GitHub では、乱用を防ぎ、すべてのユーザーが API を使用できるように、セカンダリ レート制限が適用されます。

次の場合、セカンダリ レート制限が発生する可能性があります。

  • 同時実行要求が多すぎます。 同時要求は 100 個以下です。 この制限は、REST API と GraphQL API 全体で共有されます。
  • 1 分あたりの 1 つのエンドポイントに対する要求が多すぎます。 REST API エンドポイントには 1 分あたり 900 ポイント以下、GraphQL API エンドポイントには 1 分あたり 2,000 ポイント以下を使用できます。 ポイントの詳細については、「セカンダリ レート制限のポイントの計算」を参照してください。
  • 1 分あたりの要求が多すぎます。 リアルタイムの 60 秒あたりの CPU 時間は 90 秒以下です。 GraphQL API、この CPU 時間の 60 秒以下を使用できます。 API 要求の合計応答時間を測定することで、CPU 時間を大まかに見積もることができます。
  • 短時間に過剰なコンピューティングリソースを消費するリクエストを大量に送信します。
  •           _短時間のうちに GitHub 上で過度に多くのコンテンツを作成します。_ 一般に、1 分あたり 80 件以下のコンテンツ生成要求と、1 時間あたり 500 件を超えるコンテンツ生成要求は許可されません。 一部のエンドポイントでは、コンテンツ作成の制限が低くなります。 コンテンツ作成の制限には、GitHub ウェブ インターフェイスに対して実行されるアクションと、REST API と GraphQL API を介して実行されるアクションが含まれます。
  • 短時間で OAuth アクセス トークン要求が多すぎます。 GitHub Apps と OAuth apps に対して、1 時間あたり 2,000 個以下の OAuth アクセス トークン要求が許可されません。

これらのセカンダリ レート制限は、予告なしに変更される場合があります。 また、未公開の理由により、セカンダリ レート制限が発生する可能性もあります。

セカンダリ レート制限のポイントの計算

一部のセカンダリ レート制限は、要求のポイント値によって決まります。 GraphQL 要求の場合、これらのポイント値は、プライマリ レート制限のポイント値の計算とは別です。

要求ポイント
変更のない GraphQL 要求1
変更を含む GraphQL 要求5
ほとんどの REST API GET、 HEAD、および OPTIONS 要求1
ほとんどの REST API POST、PATCH、PUT または DELETE 要求5

一部の REST API エンドポイントでは、パブリックに共有されていないポイント コストが異なります。

レート制限の状態のチェック

各応答で送信されるヘッダーを使用して、プライマリ レート制限の現在の状態を判断できます。

ヘッダー名説明
x-ratelimit-limit1 時間あたりで行うことができる要求の数の上限。
x-ratelimit-remaining現在のレート制限ウィンドウ内の残っている要求の数。
x-ratelimit-used現在のレート制限ウィンドウ内の行った要求の数。
x-ratelimit-reset現在のレート制限ウィンドウが UTC エポック秒単位でリセットされる時刻。
x-ratelimit-resource要求のカウント対象のレート制限リソース。 さまざまなリソースについては、「レート制限用 REST API エンドポイント」を参照してください。
          `GET /rate_limit` エンドポイントを呼び出して、レート制限をチェックすることもできます。 このエンドポイントの呼び出しは、プライマリ レート制限に対してカウントされませんが、セカンダリ レート制限に対してカウントされる可能性があります。 「[AUTOTITLE](/rest/rate-limit/rate-limit)」を参照してください。 可能な場合は、API を呼び出してレート制限をチェックするのではなく、レート制限応答ヘッダーを使用する必要があります。

セカンダリ レート制限の状態をチェックする方法はありません。

レート制限の超過

プライマリ レート制限を超えた場合は、403 または 429 応答を受け取り、x-ratelimit-remaining ヘッダーは 0 です。 指定された時間になるまでx-ratelimit-resetヘッダーが示す時刻までリクエストを再試行しないでください。

セカンダリ レート制限を超えた場合は、403 または 429 応答およびセカンダリ レート制限を超えたことを示すエラー メッセージが表示されます。 retry-after 応答ヘッダーが存在する場合は、その秒数が経過するまで要求を再試行しないでください。 x-ratelimit-remaining ヘッダーが 0、x-ratelimit-reset ヘッダーで指定された時刻 (UTC エポック秒数) まで要求を再試行しないでください。 それ以外の場合は、少なくとも 1 分間待ってから再試行します。 要求が二次レート制限により継続して失敗する場合は、再試行の間は指数関数的に増加する時間を待ち、特定の回数の再試行の後にエラーを発生させます。

レート制限中に要求を続けると、統合を禁止する可能性があります。

レート制限を超えないようにする

レート制限を維持するには、ベスト プラクティスに従う必要があります。 「REST API を使用するためのベスト プラクティス」を参照してください。

API 要求を表示するために、監査ログをストリーミングすることもできます。 これは、レート制限を超える統合のトラブルシューティングに役立ちます。 「企業の監査ログのストリーミング」を参照してください。

より高いレート制限を取得する

より高いプライマリ レート制限を希望する場合は、認証されていない要求ではなく、認証された要求を行うことを検討してください。 認証された要求には、認証されていない要求よりも大幅に高いレート制限があります。

組織の自動化に personal access token を使用している場合は、代わりに GitHub App が機能するかどうかを検討してください。 GitHub Apps GitHub Enterprise Cloudアカウントで使用される場合、personal access tokensよりも高いレート制限があります。 「GitHub アプリの作成について」を参照してください。