422エラー(Unprocessable Content)とは?400との違いとFastAPIでの読み方
先に結論です。422エラーは「言っていることは分かったが、内容が受け付けられない」という意味です。バリデーション(入力チェック)に引っかかった状態だと考えてください。400は「読めなかった」、422は「読めたが駄目だった」です。
422エラーとは
正式名称は 422 Unprocessable Contentです。以前は Unprocessable Entity と呼ばれていました。古い資料では旧名で書かれているので、同じものだと考えて構いません。
| 400 Bad Request | 422 Unprocessable Content | |
|---|---|---|
| サーバーの状態 | 解析できなかった | 解析できた |
| 例 | JSONの構文が壊れている | JSONは正しいが age が -5 |
| たとえると | 日本語になっていない | 日本語だが、内容が条件に合わない |
| 直し方 | リクエストの形を直す | 値を直す |
どのフレームワークが422を返すか
| フレームワーク | 422を返す場面 |
|---|---|
| FastAPI | 型が合わないと自動で422。detail に項目ごとの理由が入る |
| Ruby on Rails | モデルのバリデーション失敗時の定番 |
| Laravel | validate() の失敗時(APIリクエストの場合) |
| Django REST framework | 既定は400。設定で422にもできる |
| Express + express-validator | 実装者が選ぶ(400か422) |
FastAPIの422は型の不一致
FastAPIで422が返ったら、まず型を疑ってください。数値を期待している項目に文字列を送った場合などに自動で返されます。
{
"detail": [
{
"loc": ["body", "age"],
"msg": "Input should be a valid integer",
"type": "int_parsing"
}
]
}
loc がどの項目か、msg が理由です。422が返ったらこの中身を必ず読んでください。原因がそのまま書いてあります。
開発者向け|422を返すときの設計
422を返すなら、どの項目がなぜ駄目なのかを必ず本文に入れてください。コードだけ返しても、呼び出し側は何も直せません。
{
"error": "validation_failed",
"details": [
{"field": "email", "reason": "形式が正しくありません"},
{"field": "age", "reason": "0以上で指定してください"}
]
}
エラーは1件だけ返さず、全部まとめて返してください。1件ずつ返すと、利用者は直して送り直すのを項目の数だけ繰り返すことになります。
400と422、どちらを使うべきか
チームで先に決めて、統一することが最も重要です。実務では次の分け方が扱いやすいと考えています。
| 状況 | 返すコード |
|---|---|
| JSONの構文エラー | 400 |
| 必須項目が無い | 400 |
| 型が違う(数値のはずが文字列) | 400 または 422(どちらでもよい。統一すること) |
| 値の範囲・形式が不正 | 422 |
| 項目間の整合が取れない(開始日>終了日) | 422 |
| 既に同じものが登録済み | 409 |
立場別の確認手順
サイトを見ている側
- 入力内容を見直す。形式や桁数の条件を満たしていますか
- エラーメッセージを読む。画面のどこかに理由が出ていることが多いです
- 全角と半角を確認する。電話番号やメールアドレスでよくある原因です
- 前後の空白を消す。コピペで空白が入っていることがあります
サイトを運営している側
- 入力条件を画面に明記する。422が多い項目は説明が足りていません
- エラーメッセージを具体的にする。「入力内容が正しくありません」では直せません
- 422の発生を項目別に集計する。フォーム改善の材料になります
開発している側
- エラー本文に項目名と理由を入れる。これが無い422は役に立ちません
- 全件まとめて返す。1件ずつは利用者の時間を奪います
- 400との線引きをチームで決める。混在が最も混乱を生みます
- FastAPIなら
detailのlocとmsgを読む
よくある質問
Unprocessable Entity と Unprocessable Content は違いますか?
同じです。名称が変わっただけで、コード(422)も意味も同じです。
422は使わず400で統一してもいいですか?
構いません。422は必須ではありません。重要なのはチーム内で統一されていることと、本文に理由が書いてあることです。
FastAPIで422が出ます
型が合っていません。レスポンスの detail にある loc(項目)と msg(理由)を読んでください。文字列で数値を送っているケースが大半です。
| コード | 名前 | ひとことで言うと |
|---|---|---|
| 400 | Bad Request | リクエストの形が壊れている |
| 401 | Unauthorized | 認証が必要(まだ名乗っていない) |
| 403 | Forbidden | 名乗ったが権限がない |
| 404 | Not Found | その住所に何もない |
| 409 | Conflict | いまの状態と矛盾する |
| 413 | Content Too Large | 送ったデータが大きすぎる |
| 422(このページ) | Unprocessable Content | 形は正しいが内容が不正 |
| 429 | Too Many Requests | 送りすぎ |
| 500 | Internal Server Error | サーバーの中で処理が落ちた |
| 502 | Bad Gateway | 中継役がおかしな応答を受け取った |
| 503 | Service Unavailable | いま受け付けられない |
| 504 | Gateway Timeout | 中継役が待ちくたびれた |
関連記事
形が壊れている場合は400エラー、重複登録は409エラーをご覧ください。
HTTPステータス全体はHTTPステータスコード一覧、HTTPとHTTPSの違いはHTTPとHTTPSの違いにまとめています。
テックジムは月額22,000円の通い放題でプログラミング教室を運営しています。東京本校(永田町)では毎週土曜にゼロから始めるPython入門講座、そしてゼロから始めるClaude Code講座を無料で開いています。どちらも説明会ではなく実際に手を動かす講座です。
まとめ
422エラーは解析はできたが、内容が受け付けられない状態です。400(読めなかった)との違いはここだけです。
開発側で最も大事なのは、どの項目がなぜ駄目なのかを本文に入れること、そして全件まとめて返すことです。FastAPIで422が出たら detail の loc と msg に答えが書いてあります。





