{"meta":{"title":"GraphQL API のレート制限とクエリ制限","intro":"GitHub GraphQL API には、GitHubのサーバーに対する過剰または不正な呼び出しから保護するための制限があります。","product":"GraphQL API","breadcrumbs":[{"href":"/ja/graphql","title":"GraphQL API"},{"href":"/ja/graphql/overview","title":"概要"},{"href":"/ja/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api","title":"レートとクエリの制限"}],"documentType":"article"},"body":"# GraphQL API のレート制限とクエリ制限\n\nGitHub GraphQL API には、GitHubのサーバーに対する過剰または不正な呼び出しから保護するための制限があります。\n\n## プライマリ レート制限\n\nGraphQL API は、各クエリにポイントを割り当て、特定の時間内に使用できるポイントを制限します。 この制限は、不正使用やサービス拒否攻撃を防ぐのに役立ち、すべてのユーザーが API を使用できるようにします。\n\nREST API には、個別のプライマリ レート制限もあります。 詳しくは、「[REST API のレート制限](/ja/rest/using-the-rest-api/rate-limits-for-the-rest-api)」をご覧ください。\n\n一般に、認証の方法に基づいて GraphQL API のプライマリ レート制限を計算できます。\n\n* *ユーザーの場合*: 1 ユーザーごとに 1 時間あたり 5,000 ポイント。 これには、 personal access token で行われた要求と、アプリを承認したユーザーに代わって GitHub App または OAuth app によって行われた要求が含まれます。\n GitHub App組織が所有するGitHub Enterprise Cloudによってユーザーに代わって行われた要求のレート制限は、1 時間あたり 10,000 ポイントと高くなります。 同様に、OAuth app組織によって所有または承認されたGitHub Enterprise Cloudによってユーザーに代わって行われた要求は、GitHub Enterprise Cloud組織のメンバーである場合、1 時間あたり 10,000 ポイントという高いレート制限があります。\n* \\_\n GitHub App組織GitHub Enterprise Cloud企業以外の\\_ インストールあたり 1 時間あたり 5,000 ポイント。 20 以上のリポジトリを持つインストールでは、リポジトリごとにⅠ時間あたり 50 ポイントが追加されます。 ユーザー数が 20 人を超える組織のインストールでは、ユーザーごとに 1 時間あたり別の 50 ポイントを受け取ります。 レート制限は、1 時間あたり 12,500 ポイントを超えて増やすことはできません。 ユーザー アクセストークン（インストール アクセストークンではなく）のレート制限は、ユーザーのプライマリ レート制限によって決まります。\n* \\_\n GitHub App組織GitHub Enterprise Cloudまたは企業での\\_ インストールあたり 1 時間あたり 10,000 ポイント。 ユーザー アクセストークン（インストール アクセストークンではなく）のレート制限は、ユーザーのプライマリ レート制限によって決まります。\n* \\_\n OAuth appsの場合\\_: 1 時間あたり 5,000 ポイント、アプリがGitHub Enterprise Cloud組織によって所有されている場合は 1 時間あたり 10,000 ポイント。 これは、アプリがクライアント ID とクライアント シークレットを使用してパブリック データを要求する場合にのみ適用されます。\n OAuth appによって生成される OAuth アクセス トークンのレート制限は、ユーザーのプライマリ レート制限によって決まります。\n* \\_\n `GITHUB_TOKEN` ワークフローのGitHub Actionsの場合\\_: リポジトリあたり 1 時間あたり 1,000 ポイント。 GitHub.com のエンタープライズ アカウントに属するリソースに対する要求の場合、制限はリポジトリあたり 1 時間あたり 15,000 ポイントです。\n\n次のセクションで説明するように、クエリのポイント値をチェックしたり、予想されるポイント値を計算したりすることができます。 ポイントとレート制限を計算するための数式は、変更される可能性があります。\n\n### プライマリ レート制限の状態のチェック\n\n各応答で送信されるヘッダーを使用して、プライマリ レート制限の現在の状態を判断できます。\n\n| ヘッダー名 | 説明 |\n| ----------------------- | ------------------------------------------------------ |\n| `x-ratelimit-limit` | 1 時間あたりで使用できるポイントの数の上限 |\n| `x-ratelimit-remaining` | 現在のレート制限ウィンドウ内の残っているポイントの数 |\n| `x-ratelimit-used` | 現在のレート制限ウィンドウ内の使用したポイントの数 |\n| `x-ratelimit-reset` | 現在のレート制限ウィンドウが UTC エポック秒単位でリセットされる時刻。 |\n| `x-ratelimit-resource` | 要求のカウント対象のレート制限リソース。 GraphQL 要求の場合、これは常に `graphql` です。 |\n\n`rateLimit` オブジェクトのクエリを実行して、レート制限をチェックすることもできます。 可能な場合は、API のクエリを実行してレート制限をチェックするのではなく、レート制限応答ヘッダーを使用する必要があります。\n\n```graphql\nquery {\n viewer {\n login\n }\n rateLimit {\n limit\n remaining\n used\n resetAt\n }\n}\n```\n\n| フィールド | 説明 |\n| ----------- | ------------------------------------- |\n| `limit` | 1 時間あたりで使用できるポイントの数の上限 |\n| `remaining` | 現在のレート制限ウィンドウ内の残っているポイントの数 |\n| `used` | 現在のレート制限ウィンドウ内の使用したポイントの数 |\n| `resetAt` | 現在のレート制限ウィンドウが UTC エポック秒単位でリセットされる時刻。 |\n\n### クエリのポイント値を返す\n\n`cost` オブジェクトの `rateLimit` フィールドに対してクエリを実行すると、クエリのポイント値を返すことができます。\n\n```graphql\nquery {\n viewer {\n login\n }\n rateLimit {\n cost\n }\n}\n```\n\n### クエリのポイント値の予測\n\nクエリを作成する前に、クエリのポイント値を大まかに計算することもできます。\n\n1. 呼び出し中のそれぞれのユニークなコネクションを満たすために必要なリクエスト数を加算していきます。 すべての要求が `first` または `last` 引数の制限に達するとします。\n2. その数字を **100** で除算し、結果を最も近い整数に丸めて最終的な集計ポイント値を取得します。 このステップは、大きな数値を正規化します。\n\n> \\[!NOTE]\n> GraphQL API の呼び出しの最小ポイント値は **1** です。\n\n以下は、クエリとスコアの計算の例です。\n\n```graphql\nquery {\n viewer {\n login\n repositories(first: 100) {\n edges {\n node {\n id\n\n issues(first: 50) {\n edges {\n node {\n id\n\n labels(first: 60) {\n edges {\n node {\n id\n name\n }\n }\n }\n }\n }\n }\n }\n }\n }\n }\n}\n```\n\nこのクエリを完了するには、5,101リクエストが必要です。\n\n* 100 個のリポジトリが返されますが、API でリポジトリのリストを取得するために表示者のアカウントに接続する必要があるのは**一度**だけです。 したがって、リポジトリの要求 = **1** です\n* 50 個の Issue が返されますが、API では Issue のリストを取得するために **100** 個のリポジトリそれぞれに接続する必要があります。 したがって、課題に対するリクエストは**100**です。\n* 60 個のラベルが返されますが、API ではラベルのリストを取得するために潜在的に合計 **5,000** 個の Issue のそれぞれに接続する必要があります。 したがって、ラベルの要求 = **5,000** です\n* 合計 = **5,101** です\n\n100 で除算して丸めると、最終的なクエリのスコアは **51** になります。\n\n## セカンダリレート制限\n\nプライマリ レート制限に加えて、GitHub では、乱用を防ぎ、すべてのユーザーが API を使用できるように、セカンダリ レート制限が適用されます。\n\n次の場合、セカンダリ レート制限が発生する可能性があります。\n\n* *同時実行要求が多すぎます。* 同時要求は 100 個以下です。 この制限は、REST API と GraphQL API 全体で共有されます。\n* *1 分あたりの 1 つのエンドポイントに対する要求が多すぎます。* REST API エンドポイントには 1 分あたり 900 ポイント以下、GraphQL API エンドポイントには 1 分あたり 2,000 ポイント以下を使用できます。 ポイントの詳細については、「[セカンダリ レート制限のポイントの計算](#calculating-points-for-the-secondary-rate-limit)」を参照してください。\n* *1 分あたりの要求が多すぎます。* リアルタイムの 60 秒あたりの CPU 時間は 90 秒以下です。 GraphQL API、この CPU 時間の 60 秒以下を使用できます。 API 要求の合計応答時間を測定することで、CPU 時間を大まかに見積もることができます。\n* *短時間に過剰なコンピューティングリソースを消費するリクエストを大量に送信します。*\n* ```\n _短時間のうちに GitHub 上で過度に多くのコンテンツを作成します。_ 一般に、1 分あたり 80 件以下のコンテンツ生成要求と、1 時間あたり 500 件を超えるコンテンツ生成要求は許可されません。 一部のエンドポイントでは、コンテンツ作成の制限が低くなります。 コンテンツ作成の制限には、GitHub ウェブ インターフェイスに対して実行されるアクションと、REST API と GraphQL API を介して実行されるアクションが含まれます。\n ```\n* *短時間で OAuth アクセス トークン要求が多すぎます。* GitHub Apps と OAuth apps に対して、1 時間あたり 2,000 個以下の OAuth アクセス トークン要求が許可されません。\n\nこれらのセカンダリ レート制限は、予告なしに変更される場合があります。 また、未公開の理由により、セカンダリ レート制限が発生する可能性もあります。\n\n### セカンダリ レート制限のポイントの計算\n\n一部のセカンダリ レート制限は、要求のポイント値によって決まります。 GraphQL 要求の場合、これらのポイント値は、プライマリ レート制限のポイント値の計算とは別です。\n\n| 要求 | ポイント |\n| --------------------------------------------------- | ---- |\n| 変更のない GraphQL 要求 | 1 |\n| 変更を含む GraphQL 要求 | 5 |\n| ほとんどの REST API `GET`、 `HEAD`、および `OPTIONS` 要求 | 1 |\n| ほとんどの REST API `POST`、`PATCH`、`PUT` または `DELETE` 要求 | 5 |\n\n一部の REST API エンドポイントでは、パブリックに共有されていないポイント コストが異なります。\n\n## レート制限の超過\n\nプライマリ レート制限を超えた場合、応答の状態は引き続き `200` になりますが、エラー メッセージが表示され、`x-ratelimit-remaining` ヘッダーの値は `0` になります。 指定された時間になるまで`x-ratelimit-reset`ヘッダーが示す時刻までリクエストを再試行しないでください。\n\nセカンダリ レート制限を超えた場合は、応答の状態は `200` または `403` になり、セカンダリ レート制限に達したことを示すエラー メッセージが表示されます。\n`retry-after` 応答ヘッダーが存在する場合は、その秒数が経過するまで要求を再試行しないでください。\n`x-ratelimit-remaining` ヘッダーが `0`、`x-ratelimit-reset` ヘッダーで指定された時刻 (UTC エポック秒数) まで要求を再試行しないでください。 それ以外の場合は、少なくとも 1 分間待ってから再試行します。 要求が二次レート制限により継続して失敗する場合は、再試行の間は指数関数的に増加する時間を待ち、特定の回数の再試行の後にエラーを発生させます。\n\nレート制限中に要求を続けると、統合を禁止する可能性があります。\n\n## レート制限を超えないようにする\n\nレート制限を超えないようにするには、変更要求間で少なくとも 1 秒一時停止し、同時要求を回避する必要があります。\n\nAPI でデータをポーリングする代わりに、Webhook イベントをサブスクライブする必要もあります。 詳しくは、「[Webhook ドキュメント](/ja/webhooks)」をご覧ください。\n\nAPI 要求を表示するために、監査ログをストリーミングすることもできます。 これは、レート制限を超える統合のトラブルシューティングに役立ちます。 詳しくは、「[企業の監査ログのストリーミング](/ja/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise)」をご覧ください。\n\n## ノードの制限\n\n[schema](/ja/graphql/guides/introduction-to-graphql#schema) 検証に合格するには、すべての GraphQL API [calls](/ja/graphql/guides/forming-calls-with-graphql) が次の標準を満たしている必要があります。\n\n* クライアントは、任意の`first`に対して、`last` または [](/ja/graphql/guides/introduction-to-graphql#connection) 引数を指定する必要があります。\n* `first` と `last` の値は 1 から 100 である必要があります。\n* 個々の呼び出しでは、合計 500,000 を超える [nodes](/ja/graphql/guides/introduction-to-graphql#node) を要求することはできません。\n\n### 呼び出し中のノードの計算\n\n以下の2つの例は、呼び出し中の合計ノード数を計算する方法を示しています。\n\n1. 単純なクエリ：\n\n 
query {\n     viewer {\n       repositories(first: 50) {\n\nedges {\nrepository:node {\nname\n\nissues(first: 10) {\ntotalCount\nedges {\nnode {\ntitle\nbodyHTML\n}\n}\n}\n}\n}\n}\n}\n}
\n\n計算:\n\n 
50         = 50 repositories\n    +\n   50 x 10  = 500 repository issues\n\n= 550 total nodes
\n\n1. 複雑なクエリ：\n\n 
query {\n     viewer {\n       repositories(first: 50) {\n\nedges {\nrepository:node {\nname\n\npullRequests(first: 20) {\nedges {\npullRequest:node {\ntitle\n\ncomments(first: 10) {\nedges {\ncomment:node {\nbodyHTML\n}\n}\n}\n}\n}\n}\n\nissues(first: 20) {\ntotalCount\nedges {\nissue:node {\ntitle\nbodyHTML\n\ncomments(first: 10) {\nedges {\ncomment:node {\nbodyHTML\n}\n}\n}\n}\n}\n}\n}\n}\n}\n\n```\n   followers(first: 10) {\n```\n\nedges {\nfollower:node {\nlogin\n}\n}\n}\n}\n}
\n\n計算:\n\n 
50              = 50 repositories\n    +\n   50 x 20       = 1,000 pullRequests\n    +\n   50 x 20 x 10 = 10,000 pullRequest comments\n    +\n   50 x 20       = 1,000 issues\n    +\n   50 x 20 x 10 = 10,000 issue comments\n    +\n   10              = 10 followers\n\n= 22,060 total nodes
\n\n## タイムアウト\n\nGitHub API 要求の処理に 10 秒以上かかる場合、GitHubは要求を終了し、タイムアウト応答と\"要求に時間内に応答できませんでした\" というメッセージを受け取ります。\n\nこのような場合は、 `502` または `504` 状態コードを受け取る可能性があります。 どちらの状態コードも、要求がタイムアウトしたことを示しています。\n\nGitHub は、API の速度と信頼性を保護するためにタイムアウト 期間を変更する権利を留保します。\n\n[githubstatus.com](https://www.githubstatus.com/) で GraphQL API の状態をチェックして、タイムアウトの原因が API の問題かどうかを判断できます。 また、要求を簡略化したり、後で要求を試したりすることもできます。 クエリのパフォーマンス向上に関するヒントについては、「 [クエリの最適化戦略](#query-optimization-strategies)」を参照してください。\n\nいずれかの API 要求でタイムアウトが発生した場合、API の速度と信頼性を保護するために、その後の 1 時間、プライマリ レート制限から追加のポイントが差し引かれます。\n\n## その他のリソース制限\n\nAPI の速度と信頼性を保護するために、 GitHub では他のリソース制限も適用されます。 GraphQL クエリで消費されるリソースが多すぎる場合、 GitHub は要求を終了し、リソースの制限を超えたことを示すエラーと共に部分的な結果を返します。\n\n**リソース制限を超える可能性があるクエリの例:**\n\n* 何千ものオブジェクト、または入れ子構造が深いリレーションシップを 1 つのクエリで要求する。\n* 大きな `first` または `last` 引数を複数の接続で同時に使う。\n* 各オブジェクトの詳細な情報として、すべてのリポジトリにあるコメント、反応、関連する issue を取得する。\n\n## クエリの最適化戦略\n\n* **オブジェクト数を制限する**: `first` または `last` 引数に小さい値を使い、結果を複数ページに分割します。\n* **クエリの深さを減らす**: 必要でない場合は、入れ子構造が深いオブジェクトを要求しないようにします。\n* **結果をフィルター処理する**: 引数を使ってデータをフィルター処理し、必要なもののみを返します。\n* **大きなクエリを分割する**: 複雑なクエリを複数の単純なクエリに分割します。\n* **必須フィールドのみを要求する**: 使用できるすべてのフィールドを要求するのではなく、必要なフィールドのみを選びます。\n\nこのような戦略に従うことで、リソース制限に達する可能性を減らし、API 要求のパフォーマンスと信頼性を向上させることができます。"}