Skip to main content
ドキュメントには� �繁に更新が� えられ、その都度公開されています。本ページの翻訳はま� 未完成な部分があることをご了承く� さい。最新の情� �については、英語のドキュメンテーションをご参照く� さい。本ページの翻訳に問題がある� �合はこちらまでご連絡く� さい。

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

リソース制限

GitHubのGraphQL APIは、GitHubのサービスに対する過剰な呼び出し、あるいは悪用の呼び出しに対する保護としてかけられている制限があります。

ノードの制限

スキーマ検証をパスするためには、すべてのGraphQL APIの呼び出しが以下の標準を満す必要があります。

  • クライアントはすべてのコネクションで引数としてfirstもしくはlastを渡さなければなりません。
  • first及びlastの値は1から100の間でなければなりません。
  • 個々の呼び出しは合計500,000以上のノードをリクエストできません。

呼び出し中のノードの計算

以下の2つの例は、呼び出し中の合計ノード数を計算する方法を示しています。

  1. 単純なクエリ:

    query {
      viewer {
        repositories(first: 50) {
          edges {
            repository:node {
              name
    
              issues(first: 10) {
                totalCount
                edges {
                  node {
                    title
                    bodyHTML
                  }
                }
              }
            }
          }
        }
      }
    }

    計算:

    50         = 50 リポジトリ
     +
    50 x 10  = 500 リポジトリのIssue
    
                = 550 総ノード
  2. 複雑なクエリ:

    query {
      viewer {
        repositories(first: 50) {
          edges {
            repository:node {
              name
    
              pullRequests(first: 20) {
                edges {
                  pullRequest:node {
                    title
    
                    comments(first: 10) {
                      edges {
                        comment:node {
                          bodyHTML
                        }
                      }
                    }
                  }
                }
              }
    
              issues(first: 20) {
                totalCount
                edges {
                  issue:node {
                    title
                    bodyHTML
    
                    comments(first: 10) {
                      edges {
                        comment:node {
                          bodyHTML
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
    
        followers(first: 10) {
          edges {
            follower:node {
              login
            }
          }
        }
      }
    }

    計算:

    50              = 50 リポジトリ
     +
    50 x 20       = 1,000 プルリクエスト
     +
    50 x 20 x 10 = 10,000 プルリクエストのコメント
     +
    50 x 20       = 1,000 Issue
     +
    50 x 20 x 10 = 10,000 Issueのコメント
     +
    10              = 10 フォロワー
    
                     = 22,060 総ノード

レート制限

GraphQL APIの制限は、REST APIのレート制限とは異なります。

APIのレート制限が異なっているのはなぜでしょうか? GraphQLでは、一つのGraphQLの呼び出しで複数のRESTの呼び出しを置き換えることができます。 単一の複雑なGraphQLの呼び出しが、数千のRESTリクエストと等価なこともあります。 単一の GraphQL 呼び出しは REST API レート制限を大幅に下回りますが、クエリはGitHub のサーバーが演算するのと同等の� 荷になる可能性があります。

To accurately represent the server cost of a query, the GraphQL API calculates a call's rate limit score based on a normalized scale of points. クエリのスコアは、親のコネクションやその子のfirst及びlast引数を計算に入れます。

  • この式は、MySQLやElasticSearch、GitといったGitHubのシステ� の潜在的な� 荷を事前計算するために、親のコネクション及びその子のfirst及びlast引数を使います。
  • 新しいコネクションはそれぞれ独自のポイント値を持ちます。 ポイントは呼び出しからの他のポイントと組み合わされて、全体としてのレート制限スコアになります。

The GraphQL API rate limit is 5,000 points per hour.

Note that 5,000 points per hour is not the same as 5,000 calls per hour: the GraphQL API and REST API use different rate limits.

Note: The current formula and rate limit are subject to change as we observe how developers use the GraphQL API.

呼び出しのレート制限のステータスを返す

With the REST API, you can check the rate limit status by inspecting the returned HTTP headers.

With the GraphQL API, you can check the rate limit status by querying fields on the rateLimit object:

query {
  viewer {
    login
  }
  rateLimit {
    limit
    cost
    remaining
    resetAt
  }
}
  • limitフィールドは、60分のウィンドウ内でクライアントが消費できる最大のポイント数を返します。

  • costフィールドは、レート制限に対してカウントされる、現在の呼び出しのポイントコストを返します。

  • remainingフィールドは、現在のレート制限ウィンドウ内に残っているポイント数を返します。

  • resetAtは、現在のレート制限ウィンドウがリセットされる時間をUTCエポック秒で返します。

呼び出しの実行前にレート制限スコアを計算する

rateLimitオブジェクトに対してクエリを実行すれば、呼び出しのスコアが返されますが、その呼び出しを実行すると制限に対してカウントされます。 このジレンマを避けるために、呼び出しのスコアを実行前に計算することができます。 以下の計算は、rateLimit { cost }が返すのとおおよそ同じコストを求めます。

  1. 呼び出し中のそれぞれのユニークなコネクションを満たすために必要なリクエスト数を� 算していきます。 すべてのリクエストがfirstもしくはlast引数の制限に達すると仮定します。
  2. その数字を100で割り、その結果を丸めて最終的な総計コストを得ます。 このステップは、大きな数値を正規化します。

Note: The minimum cost of a call to the GraphQL API is 1, representing a single request.

以下は、クエリとスコアの計算の例です。

query {
  viewer {
    login
    repositories(first: 100) {
      edges {
        node {
          id

          issues(first: 50) {
            edges {
              node {
                id

                labels(first: 60) {
                  edges {
                    node {
                      id
                      name
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

このクエリを完了するには、5,101リクエストが必要です。

  • 返しているのは100個のリポジトリですが、APIがリポジトリのリストを取得するために閲覧者のアカウントに接続しなければならないのは一度� けです。 そのため、リポジトリのためのリクエスト = 1
  • 返しているのは50個のIssueですが、APIはIssueのリストを取得するために100個のリポジトリそれぞれに接続しなければなりません。 そのため、Issueのためのリクエスト = 100
  • 返しているのは60個のラベルですが、APIはラベルのリストを取得するために潜在的に合計5,000個のIssueのそれぞれに接続しなければなりません。 そのため、ラベルのためのリクエスト = 5,000
  • 合計 = 5,101

100で割って丸めると、最終的なクエリのスコアは51になります。