400エラーとは？ 10分でわかりやすく解説

UnsplashのSarah Kilianが撮影した写真

Webアプリケーションの開発や運用で「400 Bad Request」が出たときは、まず本当に400なのかを確定し、URL・ヘッダー・Cookie・ボディ（送信データ）のどこで不正と判断されたかを切り分けます。原因の幅が広いため、闇雲に触るより、リクエストの内容と到達経路を順に確認する方が早く絞り込めます。

400エラーとは？

400エラーは、HTTPにおけるステータスコード「400 Bad Request」を指します。これは、クライアント（ブラウザやアプリ）が送信したリクエストを、サーバー（または中継機器）が「クライアントエラーとみなし、処理できない」と判断した場合に返されます。

ここで押さえたいのは、400が示すのは「サーバー障害（5xx）」ではなく、あくまでリクエスト起因のエラー（4xx）だという点です。ただし4xxは一見クライアント起因に見える一方で、サーバー側の実装（入力チェックの厳格化、リクエストサイズ制限、仕様変更）や、中継（リバースプロキシ、CDN、WAF、LB）の制限が引き金になっていることもあります。したがって「クライアントが悪い」と決めつけず、リクエストの内容と到達経路を根拠に確認します。

最初に確認したいこと

400が出たときは、まず表示上の印象ではなく、実際のステータスコードが400なのか、より具体的な413・414・415などではないのかを確定します。そのうえで、アプリに到達しているのか、中継機器で止められているのかを見分けると、調査の順番がぶれにくくなります。

400エラーの概要

400は「Bad Request（不正なリクエスト）」です。実務では、次のような状況で400として扱われることがあります。ただし実装や中継機器によっては、413、414、415など、より具体的な4xxが返る場合もあります。

• URLの形式が不正（エンコード漏れ、禁止文字、パスの解釈不能など）
• クエリパラメータが不正（必須欠落、型不一致、値の範囲外、重複など）
• ヘッダーが不正（不正な値、サイズ過大、期待するヘッダー欠落など）
• Cookieが破損・肥大化し、サーバー（または中継）が解析できない
• ボディ（JSON等）の構文が不正、Content-Length不整合、multipartの境界指定不正

なお、運用現場では「400エラー」とまとめて呼ばれがちですが、HTTPには400以外にもクライアント起因を示す4xxが多数存在します。たとえば「413（Payload Too Large）」「414（URI Too Long）」「415（Unsupported Media Type）」は、同じ4xxであっても意味がより具体的です。トラブルシューティングでは、まずステータスコードを正確に確定し、コードの意味に沿って対処することが近道になります。

400エラーが発生する主な原因

400が返る背景はさまざまですが、実務上よくある原因を「確認しやすい順」に並べると次のとおりです。

1. 中継機器が先に拒否している（WAF、CDN、LB、リバースプロキシが独自に400相当を返す）
2. URL／クエリのエンコード不備（スペース、%の扱い、全角文字、予約文字の混入など）
3. ヘッダー／Cookieの過大・破損（上限超過、形式不正、Cookie乱立で解析不能）
4. ボディの構文エラー（JSONの括弧・カンマ・クォート、文字コード不正）
5. API仕様と実装の不一致（必須項目、型、上限値、enum値、日付形式など）

「なぜ400になったのか」を突き止めるには、サーバーや中継機器が実際に受け取ったリクエストを確認できるかが重要です。アプリのログだけでなく、Webサーバー／プロキシ／WAF／LBのログも確認対象に含めます。

クライアントとサーバーの役割

HTTP通信では、クライアントがリクエストを送り、サーバーがレスポンスを返します。400は「受け取った内容を妥当と判断できなかった」ことを示すため、原因は「クライアントが送った内容」だけでなく「サーバー（や中継）が妥当性をどう判定しているか」にも依存します。

• クライアント側で起きやすい：フォーム入力の未検証、文字コードの混在、古いAPI仕様に基づく送信、Cookie肥大化、二重エンコード
• サーバー側で起きやすい：入力検証の厳格化、ヘッダー・ボディ・URLのサイズ制限、WAFルール追加、仕様変更の周知不足

つまり、400は「どちらが悪いか」を決めるためのコードではなく、どこで不一致が起きたかを探る手掛かりです。

HTTPリクエストとレスポンスの仕組み

HTTPの基本的な流れを、切り分けに使える形でまとめます。400の原因は、リクエストがどの段階で拒否されたかによって当たりを付けやすくなります。

400を短時間で解消するには、「どのステップで不一致が起きたか」を決め打ちせず、ログと実際のリクエストを根拠に切り分けることが重要です。

400 Bad Requestでよくある原因と対処法

ここでは、ステータスコード400 Bad Requestに焦点を当て、現場で頻出する原因と対処をまとめます。確認の順番を意識すると、原因を絞り込みやすくなります。

最初に見る順番

URL・クエリパラメータの不備

URLやクエリは、目視では正しそうに見えても、予約文字やエンコードの扱いで破綻します。特に、検索条件や自由入力をクエリに載せる設計では、400の温床になりやすいです。

• よくある原因：スペースや日本語の未エンコード、%の二重エンコード、&や=の混入、同名パラメータの重複、日付形式の揺れ
• 対処：クライアント側でURLエンコードの方針を統一し、サーバー側では許容する文字・形式を仕様として明文化する

入力をそのままURLに入れるのではなく、入力の正規化→エンコード→送信の順序を固定すると事故が減ります。たとえばスペースは「+」ではなく「%20」を採用する、UTF-8を前提にする、予約文字を許容しない場合はサーバー側で明確に弾く、といったルールを決めておきます。

ヘッダーやCookieの破損・肥大化

400の原因として見落とされがちなのが、ヘッダーやCookieです。Cookieは便利な反面、運用が長いほど増えやすく、ドメイン配下の複数サービスがそれぞれCookieを発行すると、総量が膨らみます。一定量を超えると、サーバーや中継機器が解析できず、400になることがあります。

• よくある原因：Cookieの総量が大きい、同一ドメインでCookieが乱立、値が壊れてパース不能、独自ヘッダーが肥大化
• 対処：対象ドメインのCookieを削除して再現確認、不要Cookieの見直し、上限値を前提に設計する

ユーザー環境でのみ再現する場合は、まずCookie削除や別ブラウザでの再現性を確認すると、原因が一気に絞れます。運用としては、認証情報や状態管理をCookieに詰め込みすぎず、セッションIDに寄せるなど、肥大化しにくい構造にしておくことが重要です。

ボディの構文不正と仕様不一致

APIでは、ボディの問題が400の代表要因です。ここには2種類あります。ひとつはJSONとしてパースできない構文エラー、もうひとつはパースはできるが仕様を満たさない検証エラーです。どちらも400として返されることがあり、ログが薄いと切り分けが難しくなります。

• よくある原因：JSONの括弧・カンマ・クォートミス、UTF-8不正、型の違い（数値/文字列）、必須項目欠落、想定外のキー、enum外の値
• 対処：送信前にJSON生成をライブラリに任せる、サーバー側は検証エラーをログに残し、クライアントへは要点を返す

実装面では、JSONの組み立てを手作業で行わず、必ずシリアライザに任せます。サーバー側は、検証失敗の理由を最低限ログに残す設計が重要です。たとえば「どの項目が、どのルール（required、type、maxLength、pattern、enum）に違反したか」を記録できると、推測ではなく事実で対応できます。

中継機器が返す400

アプリが返した400に見えて、実は中継機器が先に400を返していることがあります。この場合、アプリログには何も残りません。WAFがルールに該当した、CDNが仕様外のリクエストを拒否した、LBやリバプロがヘッダー上限に達した、といったケースです。

• よくある原因：WAFの検知ルール、ヘッダーサイズ制限、特定文字列のブロック、転送設定の不整合、multipart境界の不整合
• 対処：アプリに到達したかをログで確認し、到達していない場合はWAF/LB/CDN側のログを確認する

切り分けの第一歩は「アプリに到達しているか」です。到達していないなら、アプリ改修より先に経路の制限やルールを確認します。

混同されやすい代表的な4xx

運用現場では「400エラー」とひとまとめに呼ばれることがありますが、実際には別のステータスコードが返っている場合があります。ここでは混同が多いものをまとめます。いずれも4xxですが、意味がより具体的なため、コードに沿って対応すると解決が早まります。

415 Unsupported Media Type

415は、送信したContent-Typeがサーバーの想定と一致しない場合などに返されます。たとえばJSONを期待しているのにtext/plainで送っている、あるいはmultipart/form-dataの指定が不適切、といったケースです。

1. クライアントが送るContent-Type（例：application/json）を仕様通りに設定する
2. サーバー側で受け入れ可能なContent-Typeを明確化し、必要なら受け入れ範囲を調整する

413 Payload Too Large

413は、リクエストボディがサーバーや中継機器の許容サイズを超えた場合に返されます。ファイルアップロードや大量データ送信で起こりやすいエラーです。環境によっては、アプリに届く前にリバースプロキシが返すこともあります。

1. 送信するデータ量を減らす（分割送信、圧縮、差分送信など）
2. サーバー／プロキシの上限値を確認し、運用方針に沿って必要な範囲で引き上げる

414 URI Too Long

414は、URL（パス＋クエリ）が長すぎて処理できない場合に返されます。検索条件を大量にクエリへ載せる設計、複雑なフィルタ条件をURLに詰め込む実装で発生しがちです。

1. URLに載せる情報を絞る（条件を短縮、ID化）
2. 多数条件はPOSTでボディ送信へ設計変更する（検索APIなど）

ステータスコードが400ではなく415/413/414なら、原因はより具体的に示されています。まず「本当に400か」を確認し、コードに合わせて対処することが最短ルートです。

400系を減らすためのベストプラクティス

400系は、起きてから直すより、起きにくい設計にしておく方が有効です。ここでは、開発・運用の両面で再発を減らすための実践ポイントを紹介します。

入力バリデーションを設計として分離する

入力チェックを「その場しのぎ」で足すと、どこで何を検証しているかが分からなくなります。クライアントとサーバーのそれぞれで役割を分け、検証の粒度を揃えるのが基本です。

• クライアント側：必須入力、桁数、形式（メール等）、明らかな範囲外を事前に止める
• サーバー側：最終的な妥当性（権限、整合性、依存関係）、不正値の拒否を必ず実施する

バリデーションは、セキュリティだけでなく、障害時の切り分けにも関わります。検証ルールがそろっているほど、400が出たときに原因を追いやすくなります。

API仕様を実装と同じ精度で明文化する

仕様が曖昧だと、クライアントは推測で送り、サーバーは推測で拒否します。結果として400が増えます。仕様書には次の要素を含めます。

• URL、メソッド、Content-Type
• 必須／任意、型、最大長、許容値（enum）、日付形式
• エラー時の返却形式（エラーコード、メッセージ、項目名、リクエストIDなど）

仕様が明確だと、実装ミスだけでなく「想定外の使われ方」も早期に発見できます。

エラーレスポンスを直せる形で返し、詳細はログに寄せる

ユーザー向けの文言だけでは、開発者が原因を追えません。一方で、内部情報を過剰に返すとセキュリティ上のリスクになります。現実的には、次の設計がよく使われます。

• クライアントには「何が不正か」を最小限で返す（例：invalid_parameter、missing_field）
• サーバー側ログには詳細（どの項目がどのルールに違反したか、受信値の要約、リクエストID）を残す

このとき、リクエストIDをレスポンスにも含めると、問い合わせ対応やログ突合がしやすくなります。

サイズ制限を仕様として扱う

ヘッダー／Cookie／ボディ／URLの上限は、アプリだけでなく中継機器にも影響されます。環境によって上限が異なることも多いため、運用上の上限値を決め、仕様に反映します。

• ボディ上限：アップロード設計、分割送信、圧縮の採用
• URL上限：クエリの設計方針（多数条件はPOSTへ）
• Cookie上限：用途を限定し、肥大化を防ぐ
• ヘッダー上限：独自ヘッダーの乱用を避け、必要性と上限を明確にする

「たまたま通っていた」を放置すると、環境変更（WAF導入、LB更改、CDN設定変更）で突然4xxが増えることがあります。制限は最初から前提条件として固定するのが安全です。

400系のトラブルシューティング手順

400系が発生したら、推測ではなく、確認できる事実から切り分けます。次の順序で進めると、原因を追いやすくなります。

1. ステータスコードを確定する

目的は、対応の方向を誤らないことです。ブラウザの表示だけで判断せず、開発者ツールのNetworkタブやAPIツールでレスポンスを確認し、400/413/414/415などのどれかを確定させます。

2. 再現させ、最小ケースに落とす

目的は、原因を一つずつ潰せる状態を作ることです。パラメータを減らし、ヘッダーを最小限にし、ボディを最小の正しい形にして、どこでエラーが出るかを探ります。

• ブラウザ：開発者ツールでリクエスト内容を確認し、差分を把握する
• APIツール：同じURLで段階的に条件を増やし、境界を特定する

3. アプリに到達したかをログで確認する

目的は、発生レイヤを確定することです。アプリログにリクエストが残っていない場合、中継機器が返している可能性があります。次のログを確認します。

• アプリケーションログ（リクエストID、検証エラー、例外の有無）
• Webサーバー／リバースプロキシログ（受信したか、どこで拒否したか）
• WAF/LB/CDNログ（ブロック・制限・ルール該当の有無）

4. 再発条件と恒久対策をまとめる

目的は、同種の障害を減らすことです。暫定対応で直っても、同じ種類の400が再発すると運用コストが増えます。次の観点でまとめます。

• どの入力／条件で発生したか（値、文字種、サイズ、特定のヘッダー）
• どのレイヤで拒否されたか（アプリ、リバプロ、WAF、CDN）
• 恒久対策は何か（仕様明確化、バリデーション、サイズ設計、ログ改善、ルール調整）

400系は「仕様のズレ」が原因であることが多いため、恒久対策まで含めて決めると、同じトラブルが減っていきます。

まとめ

400エラー（400 Bad Request）は、サーバー（または中継機器）がリクエストを不正と判断して処理できなかったときに返されるステータスコードです。原因はURL・ヘッダー・Cookie・ボディなど幅広く、さらにWAFやプロキシが400相当を返すケースもあります。まずはステータスコードを正確に確定し、次にリクエストの内容を最小化して再現条件を絞り、その後にどのレイヤで拒否されたかをログで切り分けるのが近道です。

また、運用上は「400系」として扱われがちな415（Content-Type不一致）、413（ボディ過大）、414（URL過長）なども、コードが示す意味に沿って対処することで解決が早まります。入力バリデーションの設計、API仕様の明文化、エラーレスポンスとログの整備、サイズ制限の前提化といったベストプラクティスを取り入れることで、400系の発生頻度を下げ、運用を安定させやすくなります。