REST API のレート制限

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

この記事の内容

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

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

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

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

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

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

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

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

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

これらの要求はすべて、1 時間あたり 5000 件の個人的レート制限に向けてカウントされます。 GitHub Enterprise Cloud organization によって所有される GitHub App がユーザーに代わって行う要求のレート制限はそれより高く、1 時間あたり 15,000 要求です。 同様に、ユーザーが GitHub Enterprise Cloud organization のメンバーである場合に、GitHub Enterprise Cloud organization によって所有または承認された OAuth app がユーザーに代わって行う要求のレート制限も、1 時間あたり 15,000 要求と高い値です。

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

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

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

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

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

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

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 要求です。

Note

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

GitHub Actions 内の GITHUB_TOKEN のプライマリ レート制限

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

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 を介して実行されるアクションが含まれます。

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

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

一部のセカンダリ レート制限は、要求のポイント値によって決まります。 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 エンドポイントを呼び出して、レート制限をチェックすることもできます。 このエンドポイントの呼び出しは、プライマリ レート制限に対してカウントされませんが、セカンダリ レート制限に対してカウントされる可能性があります。 「レート制限用 REST API エンドポイント」を参照してください。 可能な場合は、API を呼び出してレート制限をチェックするのではなく、レート制限応答ヘッダーを使用する必要があります。

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

レート制限の超過

プライマリ レート制限を超えた場合は、403 または 429 応答を受け取り、x-ratelimit-remaining ヘッダーは 0 です。 x-ratelimit-reset ヘッダーで指定された時刻 (UTC エポック秒数) まで要求を再試行しないでください。

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

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

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

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

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

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

Organization 内の自動化に personal access token を使用している場合は、GitHub App が代わりに機能するかどうかを検討してください。インストール アクセス トークンを使用する GitHub Apps のレート制限は、リポジトリの数と organization のユーザー数に応じてスケーリングされます。「GitHub App の作成について」を参照してください。

GitHub Apps または OAuth apps を使用している場合は、GitHub Enterprise Cloud へのアップグレードを検討してください。 GitHub Enterprise Cloud を使用する組織では、GitHub Apps または OAuth apps には、より高いレート制限があります。