GitHub API

冒頭まとめ GitHub API の 429 Too Many Requests は、呼び出しの量が制限を超えたことを示します。重要なのは、制限が2種類あることです。第一に primary rate limit で、時間あたりの総量の上限です。これに達すると応答ヘッダーの x-ratelimit-remaining が 0 になります。第二に secondary rate limit で、短時間の集中（大量の並列リクエスト、作成系操作の連打など）に対する保護です。こちらは残量が残っていても発動し、message に secondary rate limit という文言が入ります。なお、公式ドキュメントのとおり、同じ制限超過が 429 ではなく 403 で返ることもあります（対処は同じです）。 429 を受け取ったときにやってはいけないのが、待たずに再試行を繰り返すことです。対処の順序は、まずヘッダーの指示どおりに待つ、次に認証を付けて上限を上げる、最後に呼び出しそのものを減らす（直列化・条件付きリクエスト・webhook への転換）、です。いずれも公式の指針が明確に定まっています。 エラーの概要 2種類の 429 は、応答の message で見分けられます。 primary rate limit の超過（時間あたりの総量を使い切った場合）： { "message": "API rate limit exceeded for user ID <user-id>.", "documentation_url": "https://docs.github.com/rest/overview/rate-limits-for-the-rest-api" } secondary rate limit の超過（短時間の集中に対する保護）： { "message": "You have exceeded a secondary rate limit. Please wait a few minutes before you try again.", "documentation_url": "https://docs.github.com/rest/overview/rate-limits-for-the-rest-api" } あわせて読むべきなのが応答ヘッダーです。x-ratelimit-limit が現在の自分の上限、x-ratelimit-remaining が残量、x-ratelimit-reset が残量の回復時刻（UTC の epoch 秒）、x-ratelimit-resource がどの区分（core、search、graphql など）の制限かを示します。retry-after ヘッダーが付いている場合は、その秒数が最優先の待ち時間です。上限の具体的な数値は認証方法などで異なり、変更されることもあるため、この x-ratelimit-limit の実測値と公式のレート制限ドキュメントで確認してください。 ...

冒頭まとめ GitHub API の 500 Internal Server Error は、リクエストの綴りや認証の問題ではなく、GitHub 側の内部で予期しないエラーが起きたことを示すコードです。クライアント側に起因する問題には別のコードが割り当てられており（トークンの不備は 401、レート制限は 403 または 429、不存在や権限不足は 404、入力の検証エラーは 422）、これらが500として返ることはありません。原因は2系統に整理できます。第一に、GitHub 側の一時的な障害や内部エラーで、散発的に発生し、同じリクエストをやり直すと通ります。大半はこちらです。第二に、特定のリクエストが GitHub 側の不具合を毎回踏んでいるケースで、同じ呼び出しだけが何度でも500になります。 対処もこの2系統で決まります。散発なら、稼働状況の確認と、間隔を空けた再試行です。再現するなら、リクエストを最小化して引き金を特定し、応答に必ず含まれる x-github-request-id を添えて報告します。手元のコードの修正で500が直るのは、この引き金を特定して回避できた場合に限られます。500の調査は「散発か、再現か」の見極めから始めます。 エラーの概要 GitHub の API は、クライアント側で対処すべき問題を 4xx 系の各コードに割り当てる設計です。500 は、その割り当てのどれにも該当しない「GitHub 内部の予期しない失敗」を意味します。応答から得られる手がかりは多くありませんが、1つだけ確実なものがあります。GitHub API のすべての応答には x-github-request-id ヘッダーが含まれます（実測で確認できます）。 $ curl -sI https://api.github.com/repos/<owner>/<repo> | grep -i x-github-request-id x-github-request-id: C005:2D15D8:A1B83BD:2375C5CD:6A57385F この値は、GitHub 側のログでそのリクエストを一意に特定するための参照 ID です。500が続く場合の報告と調査の起点になるため、失敗した応答のこのヘッダーを控えておきます。GraphQL API では、参照 ID がエラーメッセージの本文中に埋め込まれて返ることがあり、その扱いは GitHub API の 502 の記事で説明したものと同じです。 まず最初に：散発か再現かを見極める 500を受け取ったら、コードを変更する前に次の3点を確認します。 第一に、GitHub の稼働状況ページ（https://www.githubstatus.com）を確認します。API のインシデントが進行中なら、原因は自分のリクエストではありません（原因1）。掲載が遅れることもあるため、掲載がないことは障害でないことの証明にはなりません。 第二に、同じリクエストを1回だけ再実行します。通れば散発（原因1）、また500なら再現（原因2）の疑いです。ただし作成・更新・削除の操作は、応答が届かなかっただけで処理自体は完了している可能性を排除できないため、再実行の前に対象（Issue やコメントなど）が実際に作られていないかを確認し、二重実行を避けてください。 第三に、失敗した応答の x-github-request-id と発生時刻を控えます。 よくある原因と解決手順 原因1：GitHub 側の一時的な障害・内部エラー GitHub 側のインフラに問題が起きている間は、正しいリクエストでも500が返ります。稼働状況ページに該当のインシデントが掲載されていれば、手元での対処はなく、復旧を待って再試行します。短時間に散発的な500が集中する場合も、まずこの系統を疑います。 再試行の設計には、GitHub 公式の Octokit の retry プラグインの線引きがそのまま使えます。公式の説明のとおり、このプラグインは500を含むサーバー側エラーを再試行の対象とし（500応答なら最大3回）、400・401・403・404・410・422・451 は再試行しません。つまり GitHub 公式のツールにおいても、500は「待ってやり直す価値があるコード」、上記の 4xx は「やり直しても結果が変わらないコード」という扱いです。自前で再試行を書く場合もこの線引きに従います。 ...

冒頭まとめ GitHub API の 502 Bad Gateway は、リクエストの綴りや認証の問題ではなく、GitHub 側が時間内に応答を作れなかったことを示すコードです。原因は2系統に整理できます。第一に、GitHub 側の一時的な障害やインシデントです。この場合、手元でできることは稼働状況の確認と、時間をおいた再試行しかありません。第二に、リクエストの処理が重すぎて時間切れになるケースで、特に GraphQL API で複雑なクエリや大量のデータを一度に要求したときに頻発します。こちらは、取得件数を減らす・クエリを分割するという自衛策が有効です。 逆に、トークンの不備は 401、レート制限の超過は 403 または 429、リソースの不存在や権限不足は 404 として返るのが GitHub の仕様であり、これらが502の原因になることはありません。502の調査は、稼働状況と「操作の重さ」の2点から始めます。 エラーの概要 502 Bad Gateway は、GitHub の内部で応答の生成に失敗した、または間に合わなかったことを示します。GraphQL API の場合、実際の報告例に共通する特徴的な応答本文があります。 { "data": "null", "errors": [ { "message": "Something went wrong while executing your query. This may be the result of a timeout, or it could be a GitHub bug. Please include `XXXX:XXXX:XXXXXXX:XXXXXXX:XXXXXXXX` when reporting this issue." } ] } message 内のバッククォートで囲まれた文字列は、そのリクエストを特定するための参照 ID です。GitHub サポートやコミュニティへ報告する際に必要になるため、502が続く場合は控えておきます。文言にあるとおり、この応答は時間切れ（timeout）の可能性を GitHub 自身が示しています。なお、ブラウザの GitHub 上で同種の問題が起きた場合は「We couldn’t respond to your request in time.」という表示になり、これも「時間内に応答できなかった」という同じ状態を指します。 ...

エラーの概要 GitHub APIにおける503エラーは、GitHubのサービスが一時的に利用不可の状態にあることを示します。このエラーはGitHub側のメンテナンス、インフラストラクチャの過負荷、またはAPI呼び出しの集中に達した場合に発生します。503エラーが返される際には、通常Retry-Afterヘッダーが含まれており、どのくらい待つべきかの秒数目安が提示されます。 実際のエラーメッセージ例 GitHub APIから返される実際の503レスポンスの例を以下に示します。 { "message": "Service Unavailable", "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api" } cURLやPythonのrequestsライブラリを使用した場合のコンソール出力例： curl -H "Authorization: token <your-github-token>" \ https://api.github.com/user/repos # レスポンス HTTP/1.1 503 Service Unavailable Retry-After: 60 Content-Type: application/json {"message":"Service Unavailable"} よくある原因と解決手順 原因1：GitHub側のメンテナンスまたはシステム障害 GitHubが定期メンテナンスやシステム障害の最中にAPI呼び出しを行うと503エラーが発生します。この場合、ユーザー側では対応できず、GitHub側の復旧を待つ必要があります。 Before（エラーが起きるコード）： import requests response = requests.get( 'https://api.github.com/user/repos', headers={'Authorization': f'token <your-github-token>'} ) print(response.json()) # 503エラーで処理が停止 After（修正後）： import requests import time def fetch_with_retry(url, token, max_retries=3): headers = {'Authorization': f'token {token}'} retry_count = 0 while retry_count < max_retries: response = requests.get(url, headers=headers) if response.status_code == 503: retry_after = int(response.headers.get('Retry-After', 60)) print(f"503エラー。{retry_after}秒後に再試行します") time.sleep(retry_after) retry_count += 1 elif response.status_code == 200: return response.json() else: raise Exception(f"エラー: {response.status_code}") raise Exception("最大再試行回数に達しました") result = fetch_with_retry('https://api.github.com/user/repos', '<your-github-token>') print(result) 原因2：APIレート制限への抵触 GitHub APIには時間ごとの呼び出し回数制限があります。認証ユーザーは1時間あたり5,000リクエスト、未認証ユーザーは60リクエストに制限されています。この制限に達すると429エラーが返されますが、その直後の集中アクセスによって503エラーが発生する可能性があります。 ...

冒頭まとめ GitHub API の 504 Gateway Timeout は、GitHub が制限時間内に応答を作り終えられず、リクエストを処理の途中で打ち切ったことを示すコードです。これは公式に明文化された挙動で、GitHub の公式文書（Troubleshooting the REST API）は、処理が10秒を超えるリクエストを打ち切ってタイムアウトの応答と Server Error のメッセージを返すこと、そしてこの制限時間は API の速度と信頼性を守るために予告なく変更されうることを明記しています。原因は2系統に整理できます。第一に、GitHub 側の障害や混雑で、普段は通るリクエストが散発的に時間切れになるケースです。第二に、リクエスト自体が重すぎて、平常時でも制限時間に収まらないケースです。 対処もこの公式文書がそのまま示しています。稼働状況を確認すること、要求を簡素化すること（1ページに100件を要求しているなら件数を減らす）、時間をおいて再試行することの3つです。逆に、トークンの不備は 401、レート制限は 403 または 429、不存在や権限不足は 404 として返るのが GitHub の仕様であり、これらが504の原因になることはありません。また、手元の HTTP クライアントに設定したタイムアウトの発火は、GitHub からコードが返る前に手元で接続を打ち切る動きなので、504とは別の事象です。504の調査は、コードが本当に GitHub から返っているかの確認と、「散発か、重さ由来か」の見極めから始めます。 エラーの概要 GitHub は API リクエストの処理時間に上限を設けており、超過したリクエストを自らの判断で打ち切ります。打ち切られたリクエストへの応答は次のような形になります。 $ curl -i -H "Authorization: Bearer <your-github-token>" \ "https://api.github.com/repos/<owner>/<repo>/commits?per_page=100" HTTP/2 504 ... { "message": "Server Error", "documentation_url": "https://docs.github.com/rest" } この Server Error という文言は、公式文書がタイムアウト応答に伴うと明記しているメッセージです。なお、同じ「時間内に応答を作れなかった」状態は、経路や API の種類によって 502 として現れることもあります。特に GraphQL API の重いクエリの時間切れは、参照 ID 入りのエラーメッセージを伴う 502 の形の報告が多く、その扱いは GitHub API の 502 の記事で説明しています。コードが502でも504でも、時間切れである限り、原因の見極め方と対処（縮小・分割・再試行）は共通です。 まず最初に：3点を確認する 504を受け取ったら、コードを変更する前に次の3点を確認します。 第一に、そのコードが本当に GitHub から返っているかを確認します。手元のクライアントのタイムアウト（curl の –max-time、requests の timeout= など）が先に発火した場合、ステータスコードは受け取れず、例外や接続打ち切りとして現れます。この場合の調査対象は GitHub ではなく、手元の設定と経路です。 第二に、GitHub の稼働状況ページ（https://www.githubstatus.com）を確認します。公式文書も、時間切れが API 側の問題によるものかをこのページで確認するよう案内しています。インシデントが進行中なら原因は自分のリクエストではありません（原因1）。掲載が遅れることもあるため、掲載がないことは障害でないことの証明にはなりません。 ...