何が起きたのか？
400 は「送られてきたリクエストの形がおかしくて、サーバーがそもそも読み解けなかった」というサインです。 教室で言えば、先生に手渡したメモが破れていたり、字がにじんでいて、どんな質問なのかさえ判別できない——そんな状況に近いかもしれません。
JSON のカンマが一つ抜けている、必須のフィールドが入っていない、ヘッダの綴りが違う。サーバーは「中身を見る前の段階」で受け取りを拒否します。だからこそ、まず疑うべきはコードのロジックではなく、リクエストそのものの形です。
黒板からのひとこと
授業で先生に質問するとき、紙に書いた文字が読めなければ、先生は「ごめん、もう一度書き直してくれる？」と返します。怒っているのではなく、読み取れないだけ。400 もそれと同じで、サーバーは中身の正誤を判断する前に、形式の段階でつまずいています。
リクエストは「サーバーへの手紙」です。封筒の宛名が滲んでいたり、便箋がぐちゃぐちゃだったりすれば、中身を読んでもらう前に止まる。整えてから送り直せば、たいてい次は通ります。
解決への歩み
大丈夫、次はこうしてみよう：
- リクエストボディと Content-Type を確認：JSON なのに text/plain で送っていないか、ボディが空ではないか
- 必須パラメータを洗い直す：API ドキュメントを開いて、欠けているフィールドや型違いがないか
- 生のリクエストをログに出して目視：curl や DevTools の Network タブで、実際に飛んでいるバイト列を確認
- バリデーションログを確認（管理者向け）：どのフィールドで弾いているか、エラーメッセージを利用者に返せているか
実際にはこう見える
$ リクエスト
curl -i https://example.com/some/path↓ レスポンス
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=utf-8
<!DOCTYPE html>
<html><body><h1>400 Bad Request</h1></body></html>