Webサービスを利用中やAPI開発中に「400 Bad Request」というエラーが表示されて困った経験はないでしょうか。
ステータスコード400はHTTPクライアントエラーの中でも最も基本的なコードであり、クライアントのリクエストに何らかの問題があることを示しています。
本記事では、ステータスコード400の正確な意味と発生原因、そして具体的な対処法について詳しく解説します。
API開発やWebサービス運用でのデバッグに役立てていただける内容ですので、ぜひ最後までご確認ください。
ステータスコード400（Bad Request）とは？基本的な意味と定義
それではまず、ステータスコード400の基本的な意味と、どのような状況で返されるかについて解説していきます。
「400 Bad Request」はHTTPクライアントエラーを示す4xx系コードの一つであり、サーバーがクライアントからのリクエストを理解できなかったか、不正なリクエストと判断した場合に返されます。
エラーの原因はクライアント側にあるため、サーバー側を変更しても解決せず、リクエスト自体を修正する必要があるでしょう。
400 Bad Requestが発生する主な原因
リクエスト構文の誤り：HTTPリクエストの書き方が正しくない
不正なURLエンコード：URLに使用できない文字が含まれている
Content-Typeの不一致：リクエストボディの形式と宣言した形式が異なる
必須パラメータの欠落：APIが要求するパラメータが送信されていない
リクエストサイズ超過：ヘッダーやボディのサイズが制限を超えている
400エラーと他のクライアントエラーの違い
400エラーはリクエストの構文や形式の問題を示す汎用的なエラーコードです。
401は認証情報の不足・失敗、403はアクセス権限の不足、404はリソースの不存在という具体的な原因を示すのに対し、400は「リクエスト自体が不正」という広い意味を持ちます。
400が返される場合は、まずリクエストの内容（ヘッダー・ボディ・パラメータ）を細かく確認することが問題解決への第一歩でしょう。
400エラーが多いAPIエンドポイントへの対処
REST APIを利用中に400エラーが頻発する場合、APIドキュメントとリクエストの内容を照合して必須パラメータの確認を行いましょう。
Content-Typeヘッダーの設定ミス（application/jsonで送るべきところをtext/plainで送っているなど）も400エラーの典型的な原因の一つです。
Postmanなどのツールを使ってリクエストの詳細を確認しながらデバッグすると効率的に問題を特定できるでしょう。
400 Bad Requestの具体的な発生原因と例
続いては、400エラーが発生する具体的な原因とその例を確認していきます。
URLエンコードの問題
URLに日本語や特殊文字（スペース・#・&など）が含まれているにもかかわらず、適切にパーセントエンコードされていない場合に400エラーが発生することがあります。
スペースは「%20」または「+」、日本語はUTF-8でエンコードした値をパーセントエンコードするなど、URLエンコードの規則に従った文字列を使用する必要があります。
ブラウザは自動でエンコード処理を行いますが、APIクライアントやコードからリクエストを送る場合は明示的なエンコード処理が必要でしょう。
リクエストヘッダーの問題
Content-Typeヘッダーとリクエストボディのフォーマットが一致していない場合、サーバーはリクエストを正しく解釈できず400エラーを返すことがあります。
JSONデータを送信する場合は「Content-Type: application/json」を、フォームデータを送信する場合は「Content-Type: application/x-www-form-urlencoded」を正確に指定することが重要です。
また、必須の認証ヘッダー（Authorizationなど）が欠落している場合にも400が返されることがあるでしょう。
| 原因カテゴリ | 具体例 | 対処法 |
|---|---|---|
| URLエンコード | URL内の日本語が未エンコード | パーセントエンコードを適用 |
| Content-Type | JSONなのにtext/plainを宣言 | 正しいContent-Typeを指定 |
| 必須パラメータ | 必要なフィールドが未送信 | APIドキュメントを確認し追加 |
| リクエストサイズ | ヘッダーが8KB超過 | 不要なヘッダーを削除 |
| JSONフォーマット | JSON構文エラー（カンマ漏れなど） | JSONバリデーターで確認 |
JSONボディの構文エラー
APIへのリクエストでJSONボディを送信する際、JSON構文が正しくない（末尾のカンマ・ダブルクォーテーションの欠落・波括弧の対応ミスなど）と400エラーの原因となります。
JSONOnlineやjsonlint.comなどのオンラインJSONバリデーターでリクエストボディを検証してから送信することで、構文エラーを事前に防ぐことができます。
開発環境ではIDEのJSON検証機能を活用するとリアルタイムに構文ミスを検出できるでしょう。
400 Bad Requestの対処法と解決手順
続いては、400エラーが発生した際の具体的な対処法と解決手順を確認していきます。
開発者ツールでのリクエスト内容確認
ブラウザの開発者ツール（F12）のNetworkタブでエラーが発生したリクエストを選択し、RequestヘッダーとPayload（リクエストボディ）の内容を細かく確認します。
サーバーからのエラーレスポンスボディに具体的なエラーメッセージが含まれていることも多いため、Responseタブの内容も必ず確認しましょう。
多くのAPIは400エラー時にどのパラメータに問題があるかを示すエラーメッセージを返すため、その情報を参考に修正方法を判断できるでしょう。
サーバー側でのバリデーション設計と400エラーの適切な返し方
API設計者の観点では、クライアントからのリクエストに問題がある場合に必ず400 Bad Requestを返し、レスポンスボディに具体的なエラー内容を含めることが重要です。
どのフィールドが不正で、なぜ不正なのかを明示したエラーメッセージを返すことで、API利用者がデバッグしやすい設計が実現できます。
バリデーションエラーはさらに具体的な422 Unprocessable Entityを使い分けることで、エラーの種類を明確に伝えることができるでしょう。
クライアント側での400エラーハンドリング
クライアントアプリケーションでは400エラーを受け取った場合、ユーザーに「入力内容に誤りがあります」などの適切なメッセージを表示し、再入力を促す設計が重要です。
エラーレスポンスのボディを解析してフィールドごとのエラーメッセージをUIに表示する実装により、ユーザーエクスペリエンスを大幅に改善できます。
ログにリクエスト内容とエラーレスポンスを記録しておくことで、後からデバッグしやすい環境を整えることが大切でしょう。
まとめ
ステータスコード400（Bad Request）はクライアントのリクエスト自体に問題があることを示すエラーであり、URLエンコード・Content-Type・必須パラメータ・JSON構文エラーなど多様な原因が存在します。
ブラウザの開発者ツールやAPIクライアントツールを活用してリクエストの詳細を確認し、APIドキュメントと照合しながら修正を行うことが解決への近道です。
API設計者はわかりやすいエラーメッセージを返すことで利用者の問題解決を助け、良質なAPIの提供につながるでしょう。
