404 エラーの記事一覧

冒頭まとめ OpenAI API の 404 は、指定した対象が見つからないことを示します。ただし「何が」見つからないかで、3つの系統に分かれます。 1つ目は**モデルです。code は model_not_found、文言は指定したモデルが存在しないか、アクセス権が無い**、という形になります。 2つ目は経路です。文言は Invalid URL (POST /v1/...) の形で、code は付きません。要求を送った先の経路そのものが存在しない場合です。 3つ目は資源の識別子です。ファイルやアシスタントなど、識別子で指定する対象が見つからない場合が該当します。 この3つには共通の性質があります。文言に、実際に要求された内容がそのまま入ることです。モデル名なら送られたモデル名、経路なら送られた経路。したがって、自分が指定したつもりの値と突き合わせるだけで、原因の大半は確定します。 そしてもう1つ、押さえるべき点があります。モデルの文言は、存在しないのか、権限が無いのかを区別しません。1つの文に両方が併記されています。したがって「モデル名が正しいか」だけを確認しても、原因の半分しか潰せません。 エラーの概要 モデルが見つからない場合の応答です。 { "error": { "message": "The model `gpt-4` does not exist or you do not have access to it.", "type": "invalid_request_error", "param": null, "code": "model_not_found" } } param は null です。どのパラメータが問題かは示されません。示されるのはモデル名そのもので、文言の中に埋め込まれています。 経路が違う場合は、形式がまったく変わります。 404 Invalid URL (POST /v1/chat/completions/) 括弧の中に、実際に要求されたメソッドと経路が入ります。上の例では末尾に余分な区切り文字が付いています。これが原因そのものです。 同じ形で、次のような経路も報告されています。 404 Invalid URL (POST /v1/v1/chat/completions) 404 Invalid URL (POST /v1/chat/completions/chat/completions/) いずれも、基点となる URL と経路の組み立てが二重になった結果です。文言を読めば、何が起きたかがそのまま見えます。 まず最初に：文言に入っている値を自分の指定と突き合わせる 第一に、code があるかを見ます。model_not_found ならモデルの系統、無ければ経路か資源の系統です。 ...

エラーの概要 GitLabの404エラーは、指定したプロジェクト・マージリクエスト・ファイルなどのリソースが見つからないことを意味します。API呼び出しやWebUIでのアクセス時に発生し、プロジェクトの存在確認、アクセス権限、リソースパスの誤入力などが主な原因です。プロジェクトが削除された、URLエンコーディングが正しくない、トークンの権限が不足している場合にも表示されます。 実際のエラーメッセージ例 GitLab API経由でのレスポンス： { "message": "404 Not Found" } curlコマンドでの出力： $ curl -H "PRIVATE-TOKEN: <your-token>" "https://gitlab.com/api/v4/projects/wrong-namespace%2Fproject-name" {"message":"404 Not Found"} WebUIでのブラウザ表示： 404 Not Found The page you're looking for could not be found. Python requests ライブラリでのエラー： import requests response = requests.get( "https://gitlab.com/api/v4/projects/invalid-path", headers={"PRIVATE-TOKEN": "<your-token>"} ) print(response.status_code) # 404 よくある原因と解決手順 原因1：プロジェクトIDまたはパスの誤入力 GitLab APIのプロジェクト指定時に、数字のプロジェクトID、またはURL形式の namespace/project-name を使用します。パスに特殊文字やスペースが含まれる場合は、URLエンコーディングが必須です。スラッシュ（/）は %2F にエンコードする必要があります。 Before（エラーが起きるコード）： # スラッシュがエンコードされていない curl -H "PRIVATE-TOKEN: <your-token>" \ "https://gitlab.com/api/v4/projects/my-group/my-project/repository/commits" # 結果：404 Not Found After（修正後）： # スラッシュをURLエンコードする（%2F） curl -H "PRIVATE-TOKEN: <your-token>" \ "https://gitlab.com/api/v4/projects/my-group%2Fmy-project/repository/commits" # または数字のプロジェクトIDを使用 curl -H "PRIVATE-TOKEN: <your-token>" \ "https://gitlab.com/api/v4/projects/12345/repository/commits" 原因2：トークンの権限不足またはプロジェクトへのアクセス権限がない プライベートプロジェクトへのアクセスには、適切な権限を持つトークンが必要です。トークンが存在しない、有効期限が切れている、または該当プロジェクトへのアクセス権限がないメンバーが使用している場合、404が返されます。GitLabはセキュリティの観点から、権限がないリソースを404で返すため、403（Forbidden）と区別されません。 ...

エラーの概要 Terraform の 404 エラーは、設定ファイルで参照しているクラウドリソースが実際には存在しないか、削除されている状態を示します。このエラーが発生すると、terraform plan や terraform apply の実行が中断され、リソース間の依存関係が解決できません。特に data source を使ってリソース情報を取得する場合や、既存リソースを参照する設定で頻出します。 実際のエラーメッセージ例 AWS Provider での例： Error: error reading EC2 Instance: InvalidInstanceID.NotFound on main.tf line 12, in data "aws_instance" "existing": 12: data "aws_instance" "existing" { │ │ InvalidInstanceID.NotFound: The instance ID 'i-0123456789abcdef0' does not exist Google Cloud Provider での例： Error: Error when reading or editing Compute Instance: googleapi: Error 404: The resource 'projects/my-project/zones/us-central1-a/instances/old-instance' was not found よくある原因と解決手順 原因 1：data source で参照しているリソースがまだ作成されていないか削除されている リソースを作成する前に、そのリソース情報を data source で参照しようとするケースがよくあります。また、クラウドコンソールから手動でリソースを削除した場合、Terraform の state ファイルにはまだ存在するとして記録されたままになり、再度参照しようとすると 404 エラーになります。 Before（エラーが起きるコード）： # EC2 インスタンスを作成する前に参照しようとしている data "aws_instance" "existing" { instance_ids = ["i-0123456789abcdef0"] } resource "aws_instance" "new" { ami = data.aws_instance.existing.ami instance_type = "t3.micro" } After（修正後）： ...

エラーの概要 Azureの404エラーは、APIやポータルからアクセスしようとしたリソースが見つからないことを示すHTTPエラーです。このエラーが発生すると、指定したリソース名、リソースID、あるいはAPIエンドポイントが存在しないか、アクセス権限がない状態を意味します。Azure CLIやREST API、Azure Portalを通じてリソースを操作する際に頻繁に遭遇するエラーであり、原因の特定と対処には体系的なアプローチが必要です。 実際のエラーメッセージ例 Azure CLIの出力例： { "error": { "code": "ResourceNotFound", "message": "The Resource 'Microsoft.Compute/virtualMachines/<vm-name>' under resource group '<resource-group-name>' was not found." } } REST APIレスポンス例： { "code": "NotFound", "message": "The specified blob does not exist.", "details": [] } Azure CLI標準エラー出力例： The resource with id /subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Storage/storageAccounts/<account-name> does not exist. (Code: ResourceNotFound) よくある原因と解決手順 原因1：リソース名またはIDの綴りが間違っている Azureのリソース名やリソースIDに入力ミスがあると、404エラーが発生します。特にストレージアカウント名やVirtual Machine名は大文字小文字が区別され、ハイフンやアンダースコアが混在することで綴り間違いが起きやすくなります。また、REST APIで完全修飾リソースID（例：/subscriptions/.../resourceGroups/.../providers/...）を指定する場合、パス内のどこかに誤字があると該当リソースが見つかりません。 Before（エラーが起きるコード）： az vm show --resource-group myResourceGroup --name myVirtualMahine After（修正後）： az vm show --resource-group myResourceGroup --name myVirtualMachine Before（エラーが起きるコード）： curl -X GET \ https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorgeaccount/listKeys?api-version=2023-01-01 \ -H "Authorization: Bearer <access-token>" After（修正後）： ...

エラーの概要 Docker Compose の 404 エラーは、docker-compose.yml（または compose.yml）で指定されたイメージ、サービス、ボリューム、またはネットワークがシステムに見つからないときに発生します。このエラーは、イメージのプル失敗、ビルドコンテキストの誤設定、または依存リソースの不足が原因となることがほとんどです。Docker Compose がコンテナーの起動や構築を試みた際に、参照先が存在しないことを検出すると、このエラーを出力して処理を中断します。 実際のエラーメッセージ例 Error response from daemon: pull access denied for <your-image-name>, repository does not exist or may require 'docker login' または、より明確な 404 表現として： { "message": "manifest not found", "status": 404 } ローカルでのビルド失敗時： ERROR: Service '<your-service-name>' failed to build : [Errno 2] No such file or directory: '<your-build-context-path>' よくある原因と解決手順 原因1：compose.yml 内で指定したイメージが存在しない、またはタグが間違っている Docker Compose がレジストリ（Docker Hub やプライベートレジストリー）からイメージをプルしようとしても、そのイメージが存在しない、あるいはタグが誤っていると 404 エラーが発生します。たとえば、タイポやバージョン番号の誤指定があると、プル対象が見つからなくなります。 Before（エラーが起きるコード）： version: '3.8' services: web: image: nginx:lattest # タイポ: lattest → latest ports: - "80:80" After（修正後）： ...

冒頭まとめ GCP の 404 Not Found は、指定した対象が見つからないことを示します。素直な意味に見えますが、このエラーには「権限が無い場合に、存在を隠すため 404 が返される」という広く知られた説明があり、どこまで本当なのかが調べ方を左右します。 Google が公開しているエラー区分の定義ファイルには、実装する側への注意書きが添えられています。段階的な機能の公開や、公開されていない許可名簿のように、利用者の層ごと拒否する場合には 404 の区分を使ってよい。しかし、利用者単位のアクセス制御のように、層の中の一部の利用者だけを拒否する場合には、403 の区分を使わなければならない。こう書かれています。原則としては、権限の設定による拒否は 403 です。 一方で、運用上の公式文書には別の記述もあります。権限の無い利用者に対象の存在を明かさないために、403 の代わりに 404 が返ることがある、と明記されています。つまり「404 は必ず存在の問題」とまでは言えません。 それでも、調べる順序は変わりません。同じ公式文書が勧めているのは、まず識別子と経路を確認し、対象が実在するかを確かめ、それでも解決しなければ裏に認可の問題がないかを考える、という順序です。名前、プロジェクト、場所の3つを先に確かめれば、たいていの 404 はそこで原因に行き着きます。権限の側を調べるのは、その後です。 なお、403 の側の文言には「あるいは対象が存在しない可能性があります」という但し書きが付きます（GCP の 403 の記事）。403 と 404 は、存在と権限の両面で互いに染み出し得る隣どうしの区分だ、と押さえておくのが正確です。 エラーの概要 応答は他のエラーと共通の形で、status に区分名が入ります。 { "error": { "code": 404, "message": "The resource 'projects/my-project/zones/asia-northeast1-a/instances/my-vm' was not found", "status": "NOT_FOUND" } } 読むべきは message に含まれる対象の名前です。上の例では、どのプロジェクトの、どの場所の、どの対象を探したかが完全な形で書かれています。自分が指定したつもりの内容と、ここに出ている内容を並べれば、食い違いはすぐ見つかります。 特に見落としやすいのが場所の部分です。指定を省略した場合、道具の設定に入っている既定値が使われます。その既定値が意図と違っていると、正しい名前を指定しているのに見つからない、という状態になります。 コマンド行の道具からは、同じ内容が簡潔な形で出ます。 ERROR: (gcloud.compute.instances.describe) Could not fetch resource: - The resource 'projects/my-project/zones/asia-northeast1-a/instances/my-vm' was not found まず最初に：応答に出ている完全な名前と、自分の指定を並べる 第一に、message に出ている対象の完全な名前を読みます。ここには、実際に探しに行った先がそのまま書かれています。 ...

エラーの概要 Kubernetesの404エラーは、APIサーバーが指定したリソース（Pod・Service・Deploymentなど）やアクセスしようとしたエンドポイントが存在しないことを示します。kubectlコマンド実行時やKubernetes APIへのHTTPリクエスト時に発生し、リソースの削除後のアクセスや存在しないNamespaceへのクエリで特に見られます。このエラーはデータ消失を意味しませんが、リソースが実際に動作していない状態を示しているため、早期の対応が必要です。 実際のエラーメッセージ例 $ kubectl get pod my-app -n production Error from server (NotFound): pods "my-app" not found { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "pods \"web-server\" not found", "reason": "NotFound", "details": { "name": "web-server", "kind": "pods" }, "code": 404 } よくある原因と解決手順 原因1：リソースが削除されている なぜ発生するか： Podやサービスが意図せず削除されたり、別のプロセスによって削除された後もアクセスしようとした場合に発生します。Deployment経由でPodを管理している場合、Podは自動的に再作成されることもあります。 Before（エラーが起きるコード）： kubectl delete pod my-app kubectl get pod my-app # Error: pods "my-app" not found After（修正後）： # リソースが本来管理されるべきDeploymentから再作成させる kubectl get deployment kubectl describe deployment my-app-deployment # または新しいPodを作成 kubectl run my-app --image=my-image:latest 原因2：Namespaceの指定ミス なぜ発生するか： リソースがあるNamespaceと異なるNamespaceを指定した場合、APIサーバーはそのNamespace内のリソースを探すため404となります。デフォルトのdefault Namespaceではなく、productionやstagingなどのNamespaceにリソースが存在することを見落とすことが多くあります。 ...

冒頭まとめ Nginx の 404 Not Found は、リクエストされたリソースが見つからないときに返されます。原因はほぼ次の5つのいずれかです。root のパスが実際のファイル配置と合っていない、alias の末尾スラッシュの不一致でパス結合がずれている、try_files の誤設定、意図しない location ブロックがリクエストを処理している、そして proxy_pass 先のアプリケーション自身が 404 を返しているケースです。調査の分かれ道はエラーログです。/var/log/nginx/error.log に No such file or directory の行があれば Nginx 自身のパス解決の問題(原因1〜3)、なければ振り分けか上流の問題(原因4〜5)を疑います。 エラーの概要 404 Not Found は、サーバーがリクエストを受け取ったものの、対応するリソースを見つけられなかった状態です。アクセス自体を拒否された 403 Forbidden とは異なります。この2つはエラーログの文言で区別できます。404 は open() の失敗として (2: No such file or directory) と記録され、403 は (13: Permission denied) や is forbidden と記録されます。ファイルが実在しても読み取り権限がなければ、返るのは 404 ではなく 403 です。 Nginx が自身の既定ページで 404 を返す場合、ブラウザには「404 Not Found」という見出しと nginx の署名だけが表示されます。もし「The requested URL /xxx was not found on this server.」のような説明文が表示されているなら、それは Nginx の既定ページの文言ではありません。上流の別のサーバーやアプリケーションが生成した 404 をそのまま中継している可能性が高く、これ自体が切り分けの手がかりになります(原因5)。 ...

エラーの概要 AWS の 404 エラーは「Not Found」を意味し、指定したリソースが見つからないことを示します。S3 バケット、EC2 インスタンス、API Gateway、Lambda 関数など、あらゆる AWS サービスで発生する可能性があります。このエラーが返される場合、リソースが存在しない、リソース名が誤っている、別のリージョンに存在している、またはアクセス権限がないなどの原因が考えられます。 実際のエラーメッセージ例 S3 へのアクセス時のエラーレスポンス： <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>NoSuchKey</Code> <Message>The specified key does not exist.</Message> <Key>nonexistent-file.txt</Key> <BucketName>my-bucket</BucketName> <RequestId>4TZ432A73F8A1A1A</RequestId> <HostId>SlFydFBhMjMzMzMzL2ZpbGUuanNvbg==</HostId> </Error> AWS CLI でのエラーメッセージ： { "Error": { "Code": "ResourceNotFoundException", "Message": "Could not connect to the endpoint URL: https://dynamodb.<region>.amazonaws.com/" }, "ResponseMetadata": { "RequestId": "12345678-1234-1234-1234-123456789012", "HTTPStatusCode": 404, "HTTPHeaders": { "date": "Thu, 15 Jan 2024 10:30:00 GMT" } } } よくある原因と解決手順 原因 1：リソース名またはリソース ID のスペルが誤っている リソース名に小文字・大文字の違いやハイフンの位置が異なるとエラーが発生します。AWS では大文字小文字を区別するサービスが多いため、タイプミスは高確率で 404 につながります。 Before（エラーが起きる例）： # S3 バケット名が誤っている aws s3 cp myfile.txt s3://my-backet/path/ # Lambda 関数名が誤っている aws lambda invoke --function-name MyLamda output.json After（修正後）： ...

冒頭まとめ Docker の 404 は「指定したものが見つからない」ことを示しますが、探した場所によって原因も対処も変わります。系統は3つです。第一に、手元のデーモンが管理する資源が見つからない場合で、No such container: や No such image: という文言になります。第二に、レジストリ（Docker Hub などのイメージ保管先）にリポジトリはあるがタグが見つからない場合で、manifest for … not found という文言になります。第三に、リポジトリ自体にたどり着けない場合で、pull access denied for …, repository does not exist or may require ‘docker login’ という文言になります。この3つ目の文言が「存在しない」と「権限がない」を並記しているのは意図的な設計で、Docker Hub は非公開リポジトリの存在を外部に確認させないため、両者を区別しないエラーを返します。 つまり Docker の404の調査は、エラー文言を読んで「手元」「タグ」「リポジトリ（または権限）」のどれかを確定するところから始まります。 エラーの概要 docker コマンドのエラーで Error response from daemon: と付くものは、Docker デーモンまで指示が届いたうえで、デーモンが処理を拒否したことを示します。デーモンは、コンテナやイメージなどの資源が見つからない場合、API 上は 404 として応答し、CLI には No such container: <名前> のような文言で表示されます（この対応は Docker のソースコードで確認できます）。一方、docker pull や docker push でレジストリとやり取りする場合の404は、レジストリ側の応答に由来します。レジストリの標準仕様では、リポジトリ名が不明な場合のエラーコードは NAME_UNKNOWN（repository name not known to registry）で、これも HTTP 404 に対応付けられています。 どの場合も、エラーコードの数字より文言のほうが多くを語ります。以下、文言ごとに切り分けます。 まず最初に：エラー文言で3つに分岐する No such container: <名前> や No such image: <名前> なら、手元のデーモンの中に該当する資源がありません（原因1）。 ...