400 エラーの記事一覧

冒頭まとめ OpenAI API の 400 Bad Request は、送った要求の内容が受け付けられなかったことを示します。公式の説明では、要求の形式が壊れているか、必須のパラメータが欠けている場合とされ、エラー文言がどこが問題かを教えてくれるはずだと書かれています。 実際、応答には機械が読める形で場所と種類が入ります。param に問題のあるパラメータの名前、code に種類の識別子です。この2つを読めば、直す場所と直し方がほぼ決まります。 よく見る code は3つです。unsupported_parameter は、そのパラメータ自体がそのモデルでは使えない、という意味です。unsupported_value は、パラメータは使えるがその値が使えない、という意味です。context_length_exceeded は、入力と出力の合計が上限を超えた場合です。 もう1つ、境界として押さえておくべき点があります。モデル名の誤りは 400 ではありません。存在しないモデルや権限の無いモデルを指定した場合、返るのは 404 で、code は model_not_found です。400 の原因としてモデル名を探し始めると遠回りになります。 エラーの概要 最も多く見る形は、使えないパラメータを送った場合です。 { "error": { "message": "Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.", "type": "invalid_request_error", "param": "max_tokens", "code": "unsupported_parameter" } } param に max_tokens と名指しされ、message には代わりに使うべき名前まで書かれています。推測の余地がありません。 値だけが問題の場合は、code が変わります。 { "error": { "message": "Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.", "type": "invalid_request_error", "param": "temperature", "code": "unsupported_value" } } 上限超過の場合は、内訳まで示されます。 ...

エラーの概要 GitLab の 400 エラーは、「Bad Request」を意味し、GitLab API またはウェブインターフェースへのリクエストの形式や内容に誤りがある場合に発生します。これは、サーバーがリクエストを正しく解析できない、または必須情報が不足していることを示します。CI/CD パイプラインの実行時やプロジェクト管理操作の際に頻出するエラーです。 実際のエラーメッセージ例 API リクエストの場合： { "message": "400 Bad Request", "error": "Invalid JSON body", "error_description": "The request body could not be parsed as JSON" } CI/CD パイプライン実行時： ERROR: (ci::pipeline:creation) This project does not have CI enabled 400 Bad Request - The request body contains invalid fields よくある原因と解決手順 原因1：JSON リクエストボディの形式エラーまたは必須フィールドの欠落 GitLab API への POST/PUT リクエストで、JSON の形式が壊れているか、API が必須とするフィールドが含まれていません。特に issue 作成や merge request の更新時に頻発します。 Before（エラーが起きるコード）： curl -X POST "https://gitlab.example.com/api/v4/projects/<project_id>/issues" \ -H "PRIVATE-TOKEN: <token>" \ -H "Content-Type: application/json" \ -d '{ "title": "New Issue" "description": "Missing comma and required labels field" }' After（修正後）： ...

エラーの概要 Terraform で 400 エラーが発生する場合、これはクラウドプロバイダーの API が「不正なリクエスト」と判定したことを意味します。HCL の構文自体は正しくても、リソース定義のパラメーター型や値がプロバイダーの期待形式と一致していない場合に起こります。terraform apply 実行時に最も頻繁に遭遇するエラーで、本来なら terraform plan で事前に検出すべき問題です。 実際のエラーメッセージ例 Error: error creating DB Instance: BadRequest: 400 Bad Request on main.tf line 15, in resource "aws_db_instance" "example": 15: resource "aws_db_instance" "example" { with aws_db_instance.example, on main.tf line 15, in resource "aws_db_instance" "example": 15: resource "aws_db_instance" "example" { Error: Error making API call: status code 400, message: invalid parameter value $ terraform apply Error: error creating resource: BadRequest: The request body is malformed │ │ with module.vpc.aws_security_group.allow_ssh: │ on vpc/main.tf line 42, in resource "aws_security_group" "allow_ssh": │ 42: resource "aws_security_group" "allow_ssh" { よくある原因と解決手順 原因 1：リソースパラメーターの型が不正 Terraform のプロバイダーが期待する型（文字列、数値、リスト等）と異なる型で値を指定すると、API リクエスト生成時に 400 エラーが発生します。特に、数値として指定すべきポート番号を文字列で渡したり、ブール値を文字列で指定したりするケースが多く見られます。 Before（エラーが起きるコード）： resource "aws_security_group" "example" { name = "example-sg" description = "Example security group" ingress { from_port = "80" # 型エラー：文字列ではなく数値であるべき to_port = "443" # 型エラー protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } depends_on = true # 型エラー：ブール値ではなく string の list } After（修正後）： ...

エラーの概要 Azure 400エラーは「Bad Request」を意味し、Azure APIへのリクエストに含まれるパラメータや値に誤りがある場合に発生します。これは認証エラーではなく、リクエストの内容そのものが仕様に違反していることを示す重要な信号です。Azure PortalやAzure CLI、REST APIを通じてリソースを作成・更新する際に頻繁に遭遇するエラーであり、適切な対応により確実に解決できます。 実際のエラーメッセージ例 Azure REST APIのレスポンス例： { "error": { "code": "BadRequest", "message": "The value of parameter 'vmName' is invalid.", "details": [ { "code": "InvalidParameterValue", "message": "The name 'my-vm-123456789-toolongname' is longer than the maximum allowed length of 15 characters." } ] } } Azure CLIの出力例： $ az vm create --resource-group myRG --name "invalid@vm#name" --image UbuntuLTS (BadRequest) The name 'invalid@vm#name' does not match the allowed pattern. よくある原因と解決手順 原因1：必須パラメータの不足または型の不正 リクエストに必須のパラメータが含まれていないか、指定した値がAPIが期待するデータ型と異なっている場合に発生します。例えば、リソースIDは文字列型で指定が必須であるのに対し、数値型で送信された場合などが該当します。Azure APIの仕様では厳密な型チェックが行われるため、JSONペイロードの構造確認は必須です。 Before（エラーが起きるコード）： import requests payload = { "properties": { "adminUsername": "azureuser", # adminPassword が不足している "osProfile": { "computerName": "myvm" } } } response = requests.put( "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2021-07-01", headers={"Authorization": f"Bearer {token}"}, json=payload ) After（修正後）： ...

エラーの概要 Docker Composeで400エラーが発生する場合、compose.yml（またはdocker-compose.yml）の設定に問題があるか、コマンドのオプション指定が誤っている可能性があります。このエラーはCompose自体が設定ファイルを正しくパースできないことを示しており、設定ファイルの検証とコマンド構文の確認により、ほぼすべてのケースで解決します。 実際のエラーメッセージ例 ERROR: The Compose file './docker-compose.yml' is invalid because: service 'web' has unsupported config option: 'cointainer_name' { "error": "Invalid service configuration", "message": "service 'db' config has unsupported option: 'envrionment'", "code": 400 } Error response from daemon: Ports must be expressed as "port" (a number) or "port/protocol" (a string). よくある原因と解決手順 原因1：compose.ymlのYAML構文エラー（インデント・タブ混在） YAML形式の構文ミスが最も多い原因です。インデント（スペース）の不一致、タブ文字の混在、コロンの後の空白忘れなどが該当します。YAMLはインデントに非常に敏感であり、2文字か4文字のスペースで統一する必要があります。タブ文字を使用するとパーサーが正しく解釈できず、400エラーが発生します。 Before（エラーが起きるコード）： version: '3.8' services: web: image: nginx:latest ports: # タブ文字が混在している - "80:80" db: image: postgres:13 # インデントが統一されていない（スペース数が異なる） environment: POSTGRES_PASSWORD: secret After（修正後）： version: '3.8' services: web: image: nginx:latest ports: - "80:80" db: image: postgres:13 environment: POSTGRES_PASSWORD: secret 原因2：サービス定義の必須キー不足または値の型エラー serviceセクション内で必須キーが欠けている、または値の型が仕様と異なる場合も400エラーになります。例えば、portsに文字列を指定すべきところに数値を指定したり、environmentをリスト形式で記述すべきところにオブジェクト形式で書いたりすると発生します。また、キー名のタイプミス（cointainer_nameなど）も認識されずエラーとなります。 ...

冒頭まとめ GCP の 400 Bad Request は、1つの意味を持つエラーではありません。Google が公開しているエラー区分の定義ファイルを見ると、400 に対応する区分は3つあります。引数が不正な場合、対象の状態がその操作を許さない場合、そして値が有効な範囲の外にある場合です。 この3つは、対処が根本的に違います。定義の説明文が、その違いをはっきり述べています。1つ目は「系の状態に関係なく問題のある引数」を指し、例として形式の壊れたファイル名が挙げられています。何度送っても結果は変わりません。2つ目は「系がその操作に必要な状態にない」ことを指し、例として空でないディレクトリの削除が挙げられています。状態を直せば同じ要求が通ります。3つ目は「有効な範囲を越えた操作」で、ファイルの終端を越えて読もうとした場合が例です。 したがって、GCP で 400 を受け取ったときに最初に読むべきは、状態コードではなく応答の status の値です。ここを読まずに要求の書式を疑うと、2つ目や3つ目の場合に見当違いの調査を続けることになります。 さらに、応答には details という配列が付きます。設計の指針には、すべてのエラー応答は機械が読める識別子を含まなければならない、と定められています。どの項目が悪いかを名指しする構造もこの中に入るため、原因の特定はここでほぼ完了します。 エラーの概要 実際の応答は、基本の4項目と details 配列で構成されます。 { "error": { "code": 400, "message": "There was a problem with the request.", "status": "INVALID_ARGUMENT", "details": [ { "@type": "type.googleapis.com/google.rpc.ErrorInfo", "reason": "INVALID_ARGUMENT", "domain": "example.googleapis.com", "metadata": { "requestId": "t-a8896317-069f-4198-afed-182a3872a660" } }, { "@type": "type.googleapis.com/google.rpc.BadRequest", "fieldViolations": [ { "field": "destinations[0].login_account.account_id", "description": "String is not a valid number.", "reason": "INVALID_NUMBER_FORMAT" } ] } ] } } details の中身は @type で種類が分かれます。ErrorInfo は機械が読める識別子で、reason に大文字と下線だけの短い語が入ります。設計の指針では、この語は63文字以内で、大文字・数字・下線の形式に従うと定められています。domain には、どのサービスが出したエラーかが入ります。 ...

エラーの概要 Kubernetes APIサーバーへのリクエストが不正な形式や内容であることを示すHTTP 400エラーです。マニフェストファイルの構文エラー、API仕様に違反するフィールド値、または不完全なリクエストボディが原因となります。このエラーはクラスタとの通信に成功した後、サーバー側でリクエストの妥当性検証に失敗したときに発生する重要な診断シグナルです。 実際のエラーメッセージ例 { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "error validating data: ValidationError(Pod.spec.containers[0].resources.limits): invalid type for io.k8s.api.core.v1.ResourceList: got \"string\", expected \"object\"", "reason": "BadRequest", "code": 400 } error: error validating "deployment.yaml": error validating data: [ValidationError(Deployment.spec.template.spec.containers[0].ports[0].containerPort): invalid type for io.k8s.api.core.v1.ContainerPort: got "string", expected "integer", ValidationError(Deployment.spec.template.spec.containers[0].image): string length must be non-empty] よくある原因と解決手順 原因1: YAML構文エラーまたはフィールド型の不一致 なぜ発生するか： Kubernetesマニフェストファイルで、数値型フィールドを文字列で指定したり、オブジェクト型フィールドにスカラー値を渡したりするときに発生します。特にポート番号やリソース制限でこの問題が頻発します。 Before（エラーが起きるコード）： apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx image: nginx:latest ports: - containerPort: "8080" # 文字列型で指定 resources: limits: memory: 512Mi # オブジェクト型だが不正 cpu: "1" # 数値型だが文字列 After（修正後）： apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 8080 # 整数型で指定 resources: limits: memory: 512Mi cpu: "1" # CPU値は文字列でも有効 requests: memory: 256Mi cpu: "500m" 原因2: 必須フィールドの欠落 なぜ発生するか： Kubernetesリソースの必須フィールド（例：metadata.name、コンテナのimage）が定義されていない場合に発生します。APIサーバーは最小限のリソース定義すら受け付けません。 ...

エラーの概要 Nginx における 400 エラーは、クライアントから送信されたリクエストが HTTP 仕様に違反していることを示します。リクエストヘッダーの形式が不正、サイズ超過、または URI の不正な文字エンコーディングなどが原因となり、サーバー側で処理できない状態を意味します。本エラーはクライアント側の問題であるため、サーバー設定とリクエスト内容の両面から原因特定が必要です。 実際のエラーメッセージ例 Nginx のアクセスログに記録される 400 エラーの典型的な出力は以下の通りです。 192.168.1.100 - - [15/Nov/2024:10:23:45 +0900] "GET /api/v1/users?name=<invalid_char> HTTP/1.1" 400 157 "-" "Mozilla/5.0" また、Nginx のエラーログには以下のように記録されることがあります。 2024/11/15 10:23:45 [info] 12345#12345: *1 client sent invalid request line: "GET /search?q=あああ HTTP/1.1" よくある原因と解決手順 原因1：リクエストヘッダーサイズの超過 なぜ発生するか Nginx は large_client_header_buffers で設定されたサイズ制限を超えるヘッダーを受け取ると、400 エラーを返します。これはメモリ消費やバッファオーバーフロー攻撃を防ぐための保護機構です。特に Cookie やカスタムヘッダーが多い場合に発生しやすくなります。 Before（デフォルト設定での問題） # Nginx デフォルト設定 # large_client_header_buffers 4 8k; # 4個のバッファ、各8KB # このサイズでクライアントが 32KB 以上のヘッダーを送信するとエラー server { listen 80; server_name example.com; location / { proxy_pass http://backend; } } After（ヘッダーバッファサイズの拡大） ...

エラーの概要 AWS の HTTP 400 エラーは「Bad Request（不正なリクエスト）」を意味し、AWS API に送信されたリクエストに構文的な誤りや不正なパラメータが含まれている場合に返されます。AWS では API Gateway、S3、DynamoDB、Lambda、IAM など複数のサービスで発生する可能性があり、クライアント側の設定ミスやリクエスト形式の誤りが主な原因となります。 実際のエラーメッセージ例 AWS SDK を使用した場合、以下のようなエラーが出力されます。 { "Error": { "Code": "BadRequest", "Message": "1 validation error detected: Value null at 'instanceIds' failed to satisfy constraint: Member must not be null" } } AWS CLI での例： $ aws s3api put-object --bucket <your-bucket-name> --key test.txt An error occurred (InvalidArgument) when calling the PutObject operation: The authorization header is malformed; the Credential is mal-formed; expecting 'AWS4-HMAC-SHA256 Credential=...' よくある原因と解決手順 原因1：必須パラメータの欠落またはデータ型の誤り なぜ発生するか AWS API は厳密なパラメータ検証を行います。必須パラメータが指定されていない、または文字列型で数値を渡すなどデータ型が異なる場合、400 エラーが返されます。特に DynamoDB や EC2 API では顕著です。 ...

冒頭まとめ Docker の 400 Bad Request は、デーモンまで届いたリクエストの形式や値が不正で、デーモンが処理を始められなかったことを示します。実際の環境で最も多いのは、クライアントとデーモンの API バージョン不一致です。エラー文言が client version <番号> is too new（クライアントが新しすぎる）または too old（古すぎる）なら、これに該当します。新しい CLI やツールと古いデーモンの組み合わせ、CI の Docker-in-Docker 構成、DOCKER_API_VERSION 環境変数の固定ミスが典型です。そのほか、デーモンの API を直接呼び出す場合の壊れた JSON や、設定値の検証で弾かれるケースが400になります。 逆に、400と誤解されやすいが400ではないものも押さえておくと迷いません。Dockerfile の構文エラーはビルド時の解析エラー、compose ファイルの YAML 不正はクライアント側の読み込みエラー、イメージ名の形式違反は invalid reference format としてデーモンに送る前に拒否されます。いずれもデーモンの400応答ではなく、調査の場所が異なります。 エラーの概要 docker コマンドは、裏側で Docker デーモンの API に HTTP リクエストを送るクライアントです。Error response from daemon: で始まるエラーは、リクエストがデーモンまで届いたことを意味します。デーモンは、不正なパラメータに分類されるエラーを 400 として応答する実装になっており（Docker のソースコードで確認できます）、API バージョンの範囲外もこの分類に含まれます。実際の報告に共通する文言は次の2種です。 Error response from daemon: client version 1.52 is too new. Maximum supported API version is 1.43 Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44 too new はクライアントの要求する API バージョンがデーモンの上限を超えている状態、too old は逆に、デーモンが受け付ける下限より古い状態です。後者は、Docker Engine のバージョン29が受け付ける最小 API バージョンを引き上げたことに伴い、古いクライアントやツールを使う環境で報告が増えています。 ...