Posts

エラーの概要 GitHub APIの400エラーは「Bad Request」を意味し、クライアント側の送信内容に問題があることを示します。リクエストの形式が不正だったり、必須パラメータが不足していたり、パラメータ値が無効だったりするときに発生します。このエラーが発生した場合、サーバー側に問題があるのではなく、APIへの呼び出し方を見直す必要があります。 実際のエラーメッセージ例 GitHub APIが返す実際の400エラーレスポンスは以下のようなものです。 { "message": "Problems parsing JSON", "documentation_url": "https://docs.github.com/rest" } あるいはバリデーションエラーの場合： { "message": "Validation Failed", "errors": [ { "message": "Required field \"title\" is missing", "field": "title", "code": "missing_field" } ], "documentation_url": "https://docs.github.com/rest/reference/issues#create-an-issue" } よくある原因と解決手順 原因1：JSONの形式が不正である なぜ発生するか リクエストボディをJSON形式で送信する際に、ダブルクォートの閉じ忘れやカンマの不足など、JSON形式として正しくない構文を送ってしまった場合に発生します。 Before（エラーが起きる例） curl -X POST https://api.github.com/repos/<owner>/<repo>/issues \ -H "Authorization: token <your-token>" \ -H "Content-Type: application/json" \ -d '{"title": "New issue" "body": "This is a test"}' 上記の例では、"New issue"と"body"の間にカンマがありません。 After（修正後） curl -X POST https://api.github.com/repos/<owner>/<repo>/issues \ -H "Authorization: token <your-token>" \ -H "Content-Type: application/json" \ -d '{"title": "New issue", "body": "This is a test"}' 原因2：必須パラメータが不足している なぜ発生するか APIエンドポイントが要求する必須パラメータをリクエストに含めていない場合に発生します。例えば、IssueやPull Requestの作成時にtitleが必須なのに省略した場合などです。 ...

エラーの概要 GitHub APIで 401 Unauthorizedエラーが発生するのは、リクエストに対する認証が失敗した場合です。このエラーは、認証情報が完全に欠落している、形式が正しくない、または無効な状態を示しています。GitHub APIを呼び出すときに最も頻繁に遭遇するエラーの一つであり、適切な認証情報を提供することで解決できます。 実際のエラーメッセージ例 curlコマンドで認証情報なしでGitHub APIにアクセスした場合： $ curl https://api.github.com/user { "message": "Requires authentication", "documentation_url": "https://docs.github.com/rest/reference/users#get-the-authenticated-user" } PythonのrequestsライブラリでPersonal Access Token（PAT）が無効な場合： { "message": "Bad credentials", "documentation_url": "https://docs.github.com/rest" } よくある原因と解決手順 原因1：Personal Access Token（PAT）が無効または期限切れ GitHub APIの認証に使用するPATが期限切れになったり、削除されたりすると401エラーが発生します。PATには最大100年の有効期限を設定できますが、明示的に有効期限を設定している場合は有効期限の管理が必要です。 Before（エラーが起きるコード）: # 3年前に作成した期限切れのPATを使用 $ curl -H "Authorization: token ghp_xxxxxxxxxxxxxxxxxxxxxxxxxx" \ https://api.github.com/user # 401 Unauthorized After（修正後）: 新しいPATを生成します。GitHubの設定画面で「Settings > Developer settings > Personal access tokens」に移動し、「Generate new token」をクリックします。必要なscopeを選択（通常はrepoとuser）し、新しいトークンを生成してください。 # 新しく生成したPATを使用 $ curl -H "Authorization: token ghp_yyyyyyyyyyyyyyyyyyyyyyyyyyyy" \ https://api.github.com/user 原因2：Authorizationヘッダーの形式が正しくない GitHub APIは特定の形式でAuthorizationヘッダーを受け取ります。Bearerではなくtokenキーワードを使用する必要があります。また、ヘッダー名や値のスペース配置のミスも401エラーの原因になります。 Before（エラーが起きるコード）: # 間違った形式1：Bearerを使用 curl -H "Authorization: Bearer ghp_xxxxxxxxxxxxxxxxxxxxxxxxxx" \ https://api.github.com/user # 間違った形式2：スペースが足りない curl -H "Authorization:token ghp_xxxxxxxxxxxxxxxxxxxxxxxxxx" \ https://api.github.com/user # 間違った形式3：トークンをクォートで囲んでいる curl -H 'Authorization: token "ghp_xxxxxxxxxxxxxxxxxxxxxxxxxx"' \ https://api.github.com/user After（修正後）: ...

エラーの概要 GitHub APIの403エラーは、認証には成功したものの、その操作を実行する権限がないことを示します。リポジトリへのアクセス、プルリクエストの作成、シークレットの管理など、特定の操作に必要なスコープやロールが不足している場合に発生します。認証と権限は別の概念であり、この違いを理解することが解決の鍵となります。 実際のエラーメッセージ例 { "message": "Resource not accessible by integration", "documentation_url": "https://docs.github.com/rest/reference/repos#get-a-repository" } curl -H "Authorization: token <your-token>" \ https://api.github.com/repos/<owner>/<repo>/secret_scanning/alerts # Response: # HTTP/1.1 403 Forbidden # { # "message": "API rate limit exceeded", # "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting" # } よくある原因と解決手順 原因1：トークンに必要なスコープが付与されていない GitHub APIトークンは「スコープ」という単位で権限が管理されます。例えば、プライベートリポジトリへのアクセスには repo スコープが、リポジトリシークレットの読み書きには admin:repo_hook スコープが必要です。スコープ不足のトークンでAPI呼び出しを行うと403が返されます。 修正前（スコープ不足）： # 権限なし（public_repo スコープのみ）のトークンでプライベートリポジトリにアクセス curl -H "Authorization: token ghp_xxxxxxxxxxxx" \ https://api.github.com/repos/<owner>/<private-repo> # → 403 Resource not accessible by integration 修正後（必要なスコープを追加）： # トークンを再生成時に repo（フルアクセス）スコープを選択 # または以下のスコープを組み合わせる # - repo (プライベートリポジトリへのフルアクセス) # - workflow (GitHub Actions ワークフロー管理) # - admin:repo_hook (Webhook管理) # 権限をもつトークンで再度実行 curl -H "Authorization: token ghp_yyyyyyyyyyyy" \ https://api.github.com/repos/<owner>/<private-repo> # → 200 OK スコープの確認方法： ...

エラーの概要 GitHub APIで404エラーが返される場合、リクエストで指定したリソース（リポジトリ、ユーザー、プルリクエストなど）がサーバー上に存在しないことを示します。このエラーはGitHub APIの認証が成功している場合でも発生し、エンドポイントのURLやパラメータの誤りが主な原因となります。 実際のエラーメッセージ例 { "message": "Not Found", "documentation_url": "https://docs.github.com/rest/reference/repos#get-a-repository", "status": 404 } { "message": "Validation Failed", "errors": [ { "message": "The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.", "resource": "Search", "field": "q", "code": "invalid" } ], "documentation_url": "https://docs.github.com/rest/reference/search" } よくある原因と解決手順 原因1：リポジトリ名またはオーナー名のスペルミス APIエンドポイントで指定したリポジトリ名やオーナー名に誤りがあると、サーバーがそのリソースを検索できず404が返されます。 Before（エラーが起きるコード）: curl -H "Authorization: token <your-github-token>" \ https://api.github.com/repos/microsoft/vscode/contents/LICENCE.md この例は、実際のLICENSE.mdファイルをLICENCE.md（英国式スペル）と誤って指定しているため、404が返されます。 After（修正後）: curl -H "Authorization: token <your-github-token>" \ https://api.github.com/repos/microsoft/vscode/contents/LICENSE.md 原因2：プライベートリポジトリへのアクセス権限不足 プライベートリポジトリにアクセスする際、認証トークンが不足していたり、有効期限が切れていたり、そのリポジトリへのアクセス権限がないと404が返されます。GitHub APIは権限がない場合、存在しないふりをする設計になっています。 ...

エラーの概要 422 Unprocessable Entity は、HTTPリクエストの形式は正しいものの、送信されたデータが GitHub API の検証ルールに違反している場合に返されるステータスコードです。GitHub API では、リクエストボディのフィールド値が不正、重複、無効な状態、または不足している時に発生します。このエラーは 400 系の汎用的なクライアントエラーとは異なり、データの意味的な問題を指摘します。 実際のエラーメッセージ例 GitHub API が返す 422 エラーレスポンスの典型例を以下に示します。 { "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing" } ], "documentation_url": "https://docs.github.com/rest/issues/issues?apiVersion=2022-11-28#create-an-issue" } 別の例として、ブランチ作成時に既存のブランチ名を指定した場合： { "message": "Validation Failed", "errors": [ { "message": "Reference already exists", "documentation_url": "https://docs.github.com/rest/git/refs?apiVersion=2022-11-28#create-a-reference", "resource": "GitRef", "field": "ref", "code": "already_exists" } ] } よくある原因と解決手順 原因 1: 必須フィールドが不足している なぜ発生するか Issue や Pull Request 作成時に、title など必須パラメータを省略するとこのエラーが発生します。GitHub API の各エンドポイントには、リクエストボディに含める必須フィールドが定義されており、これらが欠けていると検証に失敗します。 Before（エラーが起きるコード） curl -X POST https://api.github.com/repos/<owner>/<repo>/issues \ -H "Authorization: token <your-token>" \ -H "Content-Type: application/json" \ -d '{ "body": "This is the issue description" }' After（修正後） ...

エラーの概要 GitHub APIの429エラーは「Too Many Requests」を意味し、レート制限に達したことを示します。GitHubは不正アクセスやDDoS攻撃から保護するため、APIリクエスト数に制限を設けており、この上限を超えると429が返されます。認証の有無やエンドポイント、時間窓によって制限値が異なるため、適切な対策が必須です。 実際のエラーメッセージ例 { "message": "API rate limit exceeded for user ID <user-id>.", "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting" } curl -i https://api.github.com/user HTTP/1.1 429 Too Many Requests X-RateLimit-Limit: 60 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 1234567890 よくある原因と解決手順 原因1：認証なしでAPIを呼び出している なぜ発生するか： 認証なし（匿名）でのリクエストは時間当たり60回に制限されます。スクリプトやアプリが複数回実行されると、すぐに上限に達してしまいます。 Before（エラーが起きる状態）： # 認証なしでリクエスト curl https://api.github.com/user/repos After（修正後）： # Personal Access Token(PAT)を使用して認証 curl -H "Authorization: token <your-personal-access-token>" \ https://api.github.com/user/repos 原因2：ポーリング間隔が短すぎる なぜ発生するか： 定期的にAPIを監視する際に、十分な間隔を設けずにリクエストを送り続けると、あっという間に制限に達します。認証済みでも時間当たり5,000リクエストが上限です。 Before（エラーが起きる状態）： import requests import time token = "<your-personal-access-token>" headers = {"Authorization": f"token {token}"} # 1秒ごとにポーリング（60秒で60リクエスト = 上限到達） while True: response = requests.get( "https://api.github.com/repos/<owner>/<repo>/pulls", headers=headers ) print(response.status_code) time.sleep(1) # 間隔が短すぎる After（修正後）： ...

エラーの概要 GitHub APIで500エラーが発生する場合、GitHub側のサーバーで予期しない内部エラーが発生していることを示します。クライアント側の設定ミスではなく、サーバー側の障害またはAPIの不具合が原因です。ただし、不正なリクエスト形式やタイムアウト、レート制限を超えた状態でも500が返されることがあり、実際には利用者側で対応可能な原因も含まれます。 実際のエラーメッセージ例 { "message": "Internal Server Error", "documentation_url": "https://docs.github.com/rest" } curlコマンドでの表示例： $ curl -H "Authorization: token <your-token>" https://api.github.com/repos/<owner>/<repo>/issues HTTP/1.1 500 Internal Server Error Server: GitHub.com Content-Type: application/json; charset=utf-8 よくある原因と解決手順 原因1：不正なJSONペイロード形式またはエンコーディングエラー GitHubのAPIサーバーがリクエストボディを解析できない場合、500エラーで応答することがあります。特にJSONの形式が微妙に間違っていたり、文字エンコーディングが指定されていない場合に発生します。 Before（エラーが起きる例）： import requests payload = { "title": "バグ報告", "body": "テスト\n改行" # バイナリデータが含まれる } # Content-Type指定なしでPOST response = requests.post( "https://api.github.com/repos/<owner>/<repo>/issues", headers={"Authorization": "token <your-token>"}, data=payload # json=ではなくdataを使用 ) After（修正後）： import requests import json payload = { "title": "バグ報告", "body": "テスト\n改行" } response = requests.post( "https://api.github.com/repos/<owner>/<repo>/issues", headers={ "Authorization": "token <your-token>", "Accept": "application/vnd.github.v3+json", "Content-Type": "application/json; charset=utf-8" }, json=payload # 自動的にJSONエンコード ) print(response.status_code) 原因2：APIバージョン指定の不適切またはヘッダーの不足 GitHubはREST APIのバージョンを指定するため、AcceptヘッダーやX-GitHub-Api-Versionヘッダーが必須です。これが正しく指定されないと、古いバージョンのエンドポイントにルーティングされ、予期しない形式のリクエストとして処理される結果500になります。 ...

エラーの概要 502 Bad Gateway は、GitHub API がリクエストを処理するサーバー間の通信に障害が発生したときに返されるエラーです。クライアントからのリクエストそのものは正しくても、GitHub の内部インフラストラクチャでゲートウェイ層が上位サーバーから不正な応答を受け取った状態を示します。このエラーが発生すると、API呼び出しは失敗し、データの取得や更新ができなくなります。 実際のエラーメッセージ例 { "message": "Bad Gateway", "documentation_url": "https://docs.github.com/rest" } HTTP/1.1 502 Bad Gateway Content-Type: application/json { "message": "502", "status": 502 } よくある原因と解決手順 原因1：GitHub 側のメンテナンスやインシデント なぜ発生するか GitHub は定期的にインフラメンテナンスを実施します。メンテナンス中は API サーバーが一時的に不安定になり、リクエストがゲートウェイで処理できず 502 が返されます。 Before（エラーが起きる状態） curl -H "Authorization: token <your-github-token>" \ https://api.github.com/user HTTP/1.1 502 Bad Gateway After（解決方法） GitHub の Status ページ（https://www.githubstatus.com）を確認し、メンテナンスやインシデントが報告されているかチェックします。メンテナンス中の場合は復旧を待ちます。 # ステータスを確認してから数分待機後にリトライ curl -H "Authorization: token <your-github-token>" \ https://api.github.com/user 原因2：無効な Authorization ヘッダーまたは認証エラー なぜ発生するか トークンの形式が不正、有効期限が切れている、またはスコープが不足している場合、認証層で処理できずゲートウェイエラーとして返されることがあります。 Before（エラーが起きるコード） import requests token = "ghp_invalidtoken" # 形式が不正 headers = {"Authorization": f"token {token}"} response = requests.get("https://api.github.com/user", headers=headers) print(response.status_code) # 502 が返される After（修正後） ...

エラーの概要 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", "errors": [ { "message": "Server overloaded", "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api" } ] } HTTPヘッダーには以下のような情報が含まれます。 HTTP/1.1 503 Service Unavailable Retry-After: 60 Content-Type: application/json よくある原因と解決手順 原因1：GitHub側のメンテナンスまたは障害 GitHubは定期的なメンテナンスや予期しない障害によってAPIが一時的に利用できなくなることがあります。この場合、Retry-Afterヘッダーで指定された時間待機することが重要です。 Before（エラーが起きる例）： import requests response = requests.get( 'https://api.github.com/user/repos', headers={'Authorization': 'token <your-github-token>'} ) if response.status_code != 200: print(response.json()) # メンテナンス中は503が返される After（改善後）： import requests import time def fetch_with_retry(url, token, max_retries=3): for attempt in range(max_retries): response = requests.get( url, headers={'Authorization': f'token {token}'} ) if response.status_code == 503: retry_after = int(response.headers.get('Retry-After', 60)) print(f"Service unavailable. Retrying in {retry_after} seconds...") time.sleep(retry_after) continue return response raise Exception("Failed after maximum retries") response = fetch_with_retry( 'https://api.github.com/user/repos', '<your-github-token>' ) 原因2：APIレート制限に達した場合の不適切なハンドリング GitHub APIはユーザーごとにレート制限を設定しており、制限を超過すると一時的に503エラーが返される場合があります。特に認証なしのリクエストでは制限が厳しいため注意が必要です。 ...