401 エラーの記事一覧

冒頭まとめ OpenAI API の 401 は、認証に失敗したことを示します。ただし「キーが間違っている」だけを意味するわけではありません。 公式のエラー一覧を見ると、401 は4種類に分けて説明されています。認証情報が無効な場合、送ったキーが正しくない場合、アカウントが組織に所属していない場合、そして要求元の IP が許可リストに一致しない場合です。 重要なのは、このうち3つはキーを作り直しても直らないことです。認証情報が無効な場合の説明には、失効したキーを使っている、要求先の組織やプロジェクトに割り当てられたものとは別のキーを使っている、そして呼び出しているエンドポイントに必要な権限をキーが持っていない、という3つの原因が挙げられています。キーそのものは有効でも、宛先や権限が合っていなければ 401 です。 もう1つ、切り分けを一気に進める性質があります。「Incorrect API key provided」の文言には、実際に送られたキーが伏字付きで入ります。これを自分のキーと突き合わせて、一致しないなら、調べるべきはキーではなくそのキーを送っている場所です。 したがって最初にやることは、文言がどの種類かを見分けることです。 エラーの概要 キーが正しくない場合の応答は、この形になります。 { "error": { "message": "Incorrect API key provided: sk-Eyftb***************************************99vW. You can find your API key at https://platform.openai.com/account/api-keys.", "type": "invalid_request_error", "param": null, "code": "invalid_api_key" } } message の中の伏字部分に注目してください。先頭と末尾の数文字が見えています。**これはサーバーが受け取ったキー**なので、自分が設定したつもりのキーと照合できます。 プログラムから呼んでいる場合、公式のソフトウェア開発キットでは AuthenticationError として現れます。公式の説明は、キーまたはトークンが無効・期限切れ・失効している、というものです。 文言は主に次の4種類に分かれます。この判別が切り分けの起点になります。 Invalid Authentication → 宛先か権限の不一致 Incorrect API key provided: sk-... → 送られたキーそのものが違う You must be a member of an organization to use the API → 組織への所属が無い IP not authorized → 許可リストとの不一致 まず最初に：文言を4つに振り分ける 第一に、文言に伏字のキーが含まれているかを見ます。含まれていれば、それが実際に送られたキーです。 ...

エラーの概要 GitLab で 401 Unauthorized エラーが発生する場合、クライアントからのリクエストが認証されていない、または認証情報が無効であることを示しています。GitLab API へのアクセス、Git クローン、パイプラインからのリソース取得など、認証が必要な操作全般で発生する可能性があります。このエラーが出た場合、提供されたトークンや認証情報を確認し、それらの有効性と形式を検証する必要があります。 実際のエラーメッセージ例 GitLab API レスポンス： { "message": "401 Unauthorized" } curl コマンドの出力： $ curl -H "Authorization: Bearer invalid-token" https://gitlab.example.com/api/v4/user {"message":"401 Unauthorized"} Git クローン時のエラー： $ git clone https://gitlab.example.com/group/project.git Cloning into 'project'... fatal: Authentication failed for 'https://gitlab.example.com/group/project.git/' よくある原因と解決手順 原因1：パーソナルアクセストークン（PAT）が無効または期限切れになっている GitLab のパーソナルアクセストークンには有効期限が設定でき、期限を過ぎたトークンでリクエストを送信すると 401 エラーが返されます。また、トークンを無効化した場合や、ユーザーアカウント設定で特定のスコープを失った場合も認証に失敗します。特に CI/CD パイプラインやスクリプトで長期間使用するトークンは、期限切れに気づきにくいため注意が必要です。 Before（エラーが起きるコード）： # 2024年1月に作成したトークンを2024年12月に使用しようとしている場合 $ curl -H "PRIVATE-TOKEN: glpat-xxxxxxxxxxxx" \ https://gitlab.example.com/api/v4/user # → 401 Unauthorized が返される After（修正後）： # GitLab UI で新しいパーソナルアクセストークンを生成 # User Settings → Access Tokens → Add new token # スコープ: api, read_user, read_repository などを選択 $ curl -H "PRIVATE-TOKEN: <your-gitlab-token>" \ https://gitlab.example.com/api/v4/user # → 200 OK で成功 原因2：Authorization ヘッダーの形式が誤っている GitLab API にアクセスする際、Authorization ヘッダーの形式が仕様と異なると認証失敗になります。Bearer トークンを使う場合と PRIVATE-TOKEN ヘッダーを使う場合で形式が異なり、特に古いドキュメントを参照している場合に混同しやすいです。また、トークン前後の空白や特殊文字の誤りも 401 の原因になります。 ...

エラーの概要 Terraform の 401 エラーは、クラウドプロバイダー（AWS・Azure・GCP等）または Terraform Cloud/Enterprise への認証に失敗したときに発生します。認証情報の不足・期限切れ・形式エラーなどが原因で、リソースの操作やプランの実行が中断されます。 実際のエラーメッセージ例 Error: error configuring Terraform AWS Provider: error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid on main.tf line 1, in provider "aws": 1: provider "aws" { Error: Failed to retrieve available provider versions from Terraform Registry (registry.terraform.io). This may be caused by network connectivity issues, or an incorrect API token. HTTP status code: 401 Unauthorized よくある原因と解決手順 原因1：AWS アクセスキーの認証情報が不正または期限切れ AWS のアクセスキーが間違っているか、IAM（AWS Identity and Access Management）ユーザーの権限が削除されている場合に発生します。特に複数の AWS アカウントを扱う環境では、設定ミスが起こりやすくなります。 Before（エラーが起きるコード）： # 期限切れまたは不正なキーを使用 export AWS_ACCESS_KEY_ID=<your-access-key-id> export AWS_SECRET_ACCESS_KEY=<your-secret-access-key> terraform plan After（修正後）： # 最新の認証情報を取得・確認 aws sts get-caller-identity # 有効なキーを再設定 export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7NEWKEY export AWS_SECRET_ACCESS_KEY=<your-secret-access-key> # または ~/.aws/credentials ファイルで管理 cat ~/.aws/credentials terraform plan 原因2：環境変数が設定されていない Terraform が認証情報を探すとき、環境変数（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY など）が未設定の場合、プロバイダー認証に失敗します。特に CI/CD パイプラインやサーバーレス環境では見落としやすい原因です。 ...

エラーの概要 Azure への API リクエストやコマンド実行時に 401 Unauthorized エラーが返される場合、認証情報が無効であるか期限切れになっていることを示しています。このエラーが発生すると、Azure リソースへのアクセスが完全にブロックされ、デプロイやリソース管理の操作が実行できなくなります。Azure CLI、SDK、マネージド ID など複数の認証方式で発生する可能性があります。 実際のエラーメッセージ例 Azure CLI での出力例： $ az group list ERROR: The command failed with an unexpected status code: 401 (Unauthorized). The command failed with an error. (AuthenticationFailed) Authentication failed. The `Credentials` object was not initialized. Please call `Credentials.Initialize()` before making any requests. REST API レスポンス例： { "error": { "code": "AuthenticationFailed", "message": "Authentication failed. The user or application is not authorized to access the resource.", "details": [ { "code": "Unauthorized", "message": "The request requires authentication information." } ] } } よくある原因と解決手順 原因1：az login のセッションが期限切れになっている Azure CLI の認証セッションには有効期限があります。特に長時間セッションを保持していたり、PC のスリープ後に再度コマンドを実行したりする場合、自動的にセッションが無効化されることがあります。 ...

エラーの概要 Docker Composeで401エラーが発生する場合、コンテナレジストリーへの認証に失敗しています。このエラーはプライベートイメージをpullしようとする際に最も頻繁に発生し、レジストリー側が「認証情報が不正または未提供」と判定した状態です。Docker Hubやプライベートレジストリー（ECR、GCR、プライベートDockerレジストリーなど）の両方で起こりえます。 実際のエラーメッセージ例 ERROR: for <service-name> UnexpectedStatusError(401): 401 Client Error: Unauthorized for url: https://index.docker.io/v2/<image-name>/manifests/latest { "message": "unauthorized: authentication required", "details": "https://docs.docker.com/docker-hub/access-tokens/" } ERROR: for myapp pull access denied for myregistry.azurecr.io/myimage, repository does not exist or may require 'docker login': denied: authentication required よくある原因と解決手順 原因1：docker loginを実行していない Docker Composeでプライベートイメージをpullする前に、docker loginコマンドで認証を済ませていない状況です。認証情報が~/.docker/config.jsonに保存されていないため、レジストリー側は401で応答します。 Before（エラーが起きるコード）： # 認証なしで直接実行 $ docker-compose up ERROR: for webapp UnexpectedStatusError(401): 401 Client Error: Unauthorized After（修正後）： # 1. 先に認証を完了させる $ docker login Username: <your-username> Password: <your-password> Login Succeeded # 2. その後にdocker-composeを実行 $ docker-compose up 原因2：compose.ymlで正しい認証情報が参照されていない compose.ymlにレジストリー認証情報を含めるとき、x-aws-cred-helperやcredHelpers設定が不正な場合や、設定ファイル自体が存在しない場合に401が発生します。 ...

冒頭まとめ GCP の 401 Unauthorized は、「あなたが誰なのか分からない」という意味です。「あなたにその操作をする資格がない」ではありません。この2つは似て見えますが、GCP では明確に区別されています。 Google が公開しているエラー区分の定義ファイルを読むと、その区別が仕様として書かれています。401 に対応する区分の説明は「その操作に対する有効な認証情報を持っていない」という一文だけです。一方、403 に対応する区分の説明には、呼び出し元を特定できない場合にこれを使ってはならず、代わりに 401 の区分を使うこと、と明記されています。 つまり、認証情報が届いていない、あるいは読めない段階が 401 です。誰であるかは分かったが、その人にはその操作が許されていない段階が 403 です。この境界は、対処の方向を決めます。401 に対して権限の役割を追加しても、何も変わりません。 もう1つ、実務で誤解されやすい点があります。サービスアカウントの鍵は、既定では期限切れになりません。公式文書に、利用者が作成した鍵は既定では期限が無い、と明記されています。組織の方針で期限を設定した場合にのみ期限が発生します。したがって「鍵の期限切れ」を最初に疑うのは、多くの環境で見当違いです。 期限があるのは、短命の認証情報のほうです。こちらは既定で1時間、組織の設定を変えれば最大12時間まで延ばせます。長時間動く処理で 401 に当たるなら、疑うべきはこちらです。 エラーの概要 応答の形は他のエラーと共通で、status に区分名が入ります。 { "error": { "code": 401, "message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential.", "status": "UNAUTHENTICATED" } } status が UNAUTHENTICATED であることが、このエラーの性質を示しています。認証されていない、という区分です。 details 配列には、機械が読める識別子が入ります。設計の指針では、すべてのエラー応答が識別子を含むべきとされているため、reason の値で原因を分岐できます。 コマンド行の道具からは、認証情報が見つからない旨の文言が出ます。この場合、要求は送られてすらいないことがあります。手元で認証情報を探す段階で失敗しているためです。応答としての 401 なのか、手元での失敗なのかは、文言で区別できます。 まず最初に：誰として認証されているかを確認する 第一に、いま自分がどの身元で操作しているかを確認します。 gcloud auth list 第二に、実際に使われる認証情報が何かを確認します。ここが意図と違っていることが、このエラーの大半です。 gcloud auth application-default print-access-token > /dev/null && echo "既定の認証情報あり" || echo "既定の認証情報なし" 第三に、status が UNAUTHENTICATED か PERMISSION_DENIED かを見ます。後者であれば、認証は通っており、問題は権限の側です。調べる先が変わります（GCP の 403 の記事）。 ...

エラーの概要 Kubernetesで401エラーが発生するのは、APIサーバーへのリクエストに対して認証に失敗した状態を示します。認証トークンの有効期限切れ、認証情報の不足、または権限がないServiceAccountの使用が典型的な原因です。このエラーが出ると、kubectlコマンドの実行やPodからAPIサーバーへのアクセスが拒否されます。 実際のエラーメッセージ例 error: You must be logged in to the server (Unauthorized) { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "Unauthorized", "reason": "Unauthorized", "code": 401 } kubectl logs pod-name -n default Error from server (Unauthorized): pods "pod-name" is forbidden: User "system:serviceaccount:default:default" cannot get resource "pods" in API group "" in the namespace "default" よくある原因と解決手順 原因1：kubeconfig設定の無効化または存在しない認証情報 kubeconfig内の証明書やトークンが無効になっている、または参照しているファイルが削除されている場合に401エラーが発生します。クラスタをセットアップした時点での認証情報が失われたり、パスが誤っていたりすることが多いです。 Before（エラーが起きるコード）： # ~/.kube/config apiVersion: v1 clusters: - cluster: certificate-authority: /etc/kubernetes/pki/ca.crt # ファイルが削除済み server: https://10.0.0.1:6443 name: my-cluster contexts: - context: cluster: my-cluster user: admin-user name: my-context current-context: my-context users: - name: admin-user user: client-certificate: /home/user/.certs/client.crt # パスが誤っている client-key: /home/user/.certs/client.key After（修正後）： ...

エラーの概要 AWSで401エラーが返される場合、リクエストに含まれる認証情報が無効であることを示しています。AWS API、SDK、CLIのいずれかを使用する際に、アクセスキー、シークレットアクセスキー、セッショントークン、またはIAMロールの認証情報が不正または期限切れの状態で送信されると発生します。このエラーは認証層での問題であり、比較的簡単に解決できるケースがほとんどです。 実際のエラーメッセージ例 AWS CLIを使用した場合： $ aws s3 ls An error occurred (InvalidAccessKeyId.NotFound) when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records. AWS SDK（Python）でのJSONレスポンス例： { "Error": { "Code": "UnrecognizedClientException", "Message": "The security token included in the request is invalid" } } API Gateway経由での呼び出しでのエラー： HTTP/1.1 401 Unauthorized { "message": "Unauthorized" } よくある原因と解決手順 原因1：アクセスキーが無効または存在しない AWS IAMユーザーのアクセスキーが削除されたり、誤入力されたりしている場合に発生します。特に手動で環境変数やConfigファイルに設定した場合は打ち間違いが多いです。 Before（エラーが起きるコマンド）： export AWS_ACCESS_KEY_ID="<your-access-key-id>" export AWS_SECRET_ACCESS_KEY="<your-secret-access-key>" aws ec2 describe-instances After（修正後）： # IAMコンソールで現在のアクセスキーを確認 # または新しいアクセスキーを生成してから設定 export AWS_ACCESS_KEY_ID="<your-access-key-id>" export AWS_SECRET_ACCESS_KEY="<your-secret-access-key>" aws ec2 describe-instances 確認手順は以下の通りです。AWSマネジメントコンソールでIAM→ユーザー→セキュリティ認証情報タブを開き、アクセスキーが有効（Active）な状態であることを確認してください。無効な場合は新しいアクセスキーを生成する必要があります。 ...

エラーの概要 Dockerで401エラーが発生するのは、レジストリ（Docker Hub、ECR、プライベートレジストリなど）への認証に失敗したときです。認証情報が提供されていない、または提供されていても無効・期限切れの場合に表示されます。特に docker pull、docker push、docker login の実行時によく見られます。 なお、2020年11月以降、Docker Hubの匿名（ログインなし）でのイメージダウンロード数に制限が導入されたため、以前はログインなしで利用できていたパブリックイメージでも、現在は認証が必須になるケースが増えています。 実際のエラーメッセージ例 Error response from daemon: unauthorized: incorrect username or password { "errors": [ { "code": "UNAUTHORIZED", "message": "authentication required", "detail": null } ] } Error response from daemon: Get "https://registry-1.docker.io/v2/": unauthorized: authentication required, 401 よくある原因と解決手順 原因1：Docker Hubへのログインが完了していない Docker Hubのパブリックイメージであっても、ダウンロード数制限により認証が必須になるケースがあります。また、プライベートイメージにアクセスする場合は必ず認証が必要です。 Before（エラーが起きるコード）： # ログインなしで直接pullを実行 docker pull <your-username>/<image-name>:latest After（修正後）： # 最初にDocker Hubにログイン docker login # プロンプトにユーザー名とパスワード（またはPersonal Access Token）を入力 # その後でpullを実行 docker pull <your-username>/<image-name>:latest 原因2：AWS ECRの認証トークンが期限切れ ECRの認証トークンは12時間の有効期限があります。Docker daemonに保存されたトークンが期限切れになると401エラーが発生します。 ...

冒頭まとめ GitHub API の 401 Unauthorized は、認証そのものの失敗です。権限の不足ではありません（権限不足は GitHub では 404 または 403 として返ります）。401 の応答の message は2種類しかなく、これが調査の分岐点になります。Requires authentication なら、認証情報がそもそも GitHub に届いていません（原因1）。Bad credentials なら、認証情報は届いたものの、その値が正しくありません（原因2・3）。 Bad credentials の正体は、トークンの誤記や期限切れ・失効のほか、「有効なトークンを設定し直したのに、別の場所（環境変数など）に残った古いトークンが優先され続けている」という取り違えが定番です。どの文言か、そして実際にどのトークンが送られているかを確かめることから始めます。 エラーの概要 401 の応答は次の2種類です（いずれも実際の応答をそのまま確認したものです）。 認証情報なしで認証必須のエンドポイントにアクセスした場合： { "message": "Requires authentication", "documentation_url": "https://docs.github.com/rest", "status": "401" } 認証情報は送ったが、値が正しくない場合： { "message": "Bad credentials", "documentation_url": "https://docs.github.com/rest", "status": "401" } ヘッダーの形式について、公式ドキュメントは、ほとんどの場合 Authorization: Bearer と Authorization: token のどちらでもトークンを渡せる（JSON Web Token を渡す場合のみ Bearer が必須）としています。どちらの形式かが401の原因になることは基本的にありません。また、github.com の API はユーザー名とパスワードによる認証に対応していないため、パスワードでの認証を試みる古いコードは動きません。トークンによる認証が前提です。 まず最初に：message を読み、最小のリクエストで再現する まず message の文言で、認証情報が「届いていない」のか「届いたが不正」なのかを確定します。次に、問題を最小の形で再現します。認証済みユーザー自身の情報を返す /user エンドポイントが最適です。 curl -i -H "Authorization: Bearer <your-github-token>" https://api.github.com/user これが 200 なら、トークン自体は有効です。アプリケーション側で401が出ているなら、アプリケーションが実際に送っているトークンがこれと同じものではない、という取り違え（原因3）に的が絞られます。これが 401 Bad credentials なら、トークンの値そのものの問題です（原因2）。 ...