{"meta":{"title":"GraphQL API のレート制限とクエリ制限","intro":"GitHub GraphQL API には、GitHubのサーバーに対する過剰または不正な呼び出しから保護するための制限があります。","product":"GraphQL API","breadcrumbs":[{"href":"/ja/enterprise-server@3.22/graphql","title":"GraphQL API"},{"href":"/ja/enterprise-server@3.22/graphql/overview","title":"概要"},{"href":"/ja/enterprise-server@3.22/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\nGitHub Enterprise Serverでは、レート制限は既定で無効になっています。 インスタンスのレート制限を確認するには、サイト管理者にお問い合わせください。\n\nサイト管理者の場合は、インスタンスのレート制限を設定できます。 詳しくは、「[Configuring rate limits (レート制限を構成する)](/ja/enterprise-server@3.22/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-rate-limits)」をご覧ください。\n\nインスタンスの外部でユーザーまたは組織用のアプリを開発する場合は、標準の GitHub レート制限が適用されます。 詳細については、[](/ja/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api)ドキュメントの GitHub Free を参照してください。\n\n## ノードの制限\n\n[schema](/ja/enterprise-server@3.22/graphql/guides/introduction-to-graphql#schema) 検証に合格するには、すべての GraphQL API [calls](/ja/enterprise-server@3.22/graphql/guides/forming-calls-with-graphql) が次の標準を満たしている必要があります。\n\n* クライアントは、任意の`first`に対して、`last` または [](/ja/enterprise-server@3.22/graphql/guides/introduction-to-graphql#connection) 引数を指定する必要があります。\n* `first` と `last` の値は 1 から 100 である必要があります。\n* 個々の呼び出しでは、合計 500,000 を超える [nodes](/ja/enterprise-server@3.22/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\n* **オブジェクト数を制限する**: `first` または `last` 引数に小さい値を使い、結果を複数ページに分割します。\n* **クエリの深さを減らす**: 必要でない場合は、入れ子構造が深いオブジェクトを要求しないようにします。\n* **結果をフィルター処理する**: 引数を使ってデータをフィルター処理し、必要なもののみを返します。\n* **大きなクエリを分割する**: 複雑なクエリを複数の単純なクエリに分割します。\n* **必須フィールドのみを要求する**: 使用できるすべてのフィールドを要求するのではなく、必要なフィールドのみを選びます。\n\nこのような戦略に従うことで、リソース制限に達する可能性を減らし、API 要求のパフォーマンスと信頼性を向上させることができます。"}