※購入先、ダウンロードへのリンクにはアフィリエイトタグが含まれており、それらの購入や会員の成約、ダウンロードなどからの収益化を行う場合があります。

client errorとは？HTTP 4xxを30分で切り分ける原因特定と直し方

X、Twitter

client error（HTTP 4xx）が本番で急増すると、現場は一気に混乱します。「クライアントが悪いのか」「サーバ側の設定ミスなのか」「WAFやレート制限の誤作動なのか」。原因候補が多すぎて、ログを眺めるほど時間だけが溶けていきます。

本記事は、4xxの意味を覚えるための解説ではありません。相関IDを起点に、入口ログ→WAF/ゲートウェイ→アプリログを順に突合し、30分で原因の当たりを付けるRunbookとして設計しました。401と403の見分け、404と410の判断、429のRetry-Afterと主体別偏りの見方まで、**「最初に見る証拠」「一次対処」「再発防止」**をセットで整理しています。

読了後には、4xxが出た瞬間に「次に何を確認し、どこへ依頼し、どう復旧と恒久対応を進めるか」が明確になります。運用当番でも、説明責任が求められる場面でも、迷わず動ける状態を目指しましょう。

※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。

目次

client errorが示す範囲と4xxの基本

client errorは多くの場合HTTP 4xxを指す

「client error」という言葉は、現場ではほとんどの場合、HTTPレスポンスの4xx（Client Error）を指して使われます。ブラウザやアプリ、SDKが送ったリクエストに何らかの問題があり、サーバがその要求を受け付けられない状態です。
ただし、4xxは「クライアントが100%悪い」という断定ではありません。サーバ側の設定ミス、ルーティング漏れ、認可判定の不具合、過敏なWAFやレート制限などが、結果として4xxとして現れることもあります。だからこそ、重要なのは“犯人探し”ではなく、証拠ベースで切り分ける手順です。

4xxと5xxを混同しないための考え方

4xxと5xxの違いは単純に見えますが、実務では境界が揺れます。目安としては次の通りです。

  • 4xx：入力、認証、権限、存在、メソッド、制限など「要求の前提が満たされない」

  • 5xx：依存先障害や内部例外など「要求は妥当だがサーバが処理できない」

ただし、たとえば認可判定の実装バグで403が出る、ルーティングの設定漏れで404が出る、誤ったレート制限で429が出るなど、原因はサーバ側でも結果が4xxになるケースがあります。ここを見誤ると、「クライアントに直して」と投げて時間を溶かすことになります。

まず最初に揃える情報セット

4xx対応で一番のムダは、「状況の再現」や「ログの突合」ができないことです。最初に次の情報を揃えるだけで、切り分け速度が上がります。

  • 発生開始時刻（いつから、断続か継続か）

  • 対象環境（本番/ステージング、リージョン、AZ）

  • 対象範囲（どのAPI/画面、特定テナントのみか、全体か）

  • リクエスト情報（URL、メソッド、クエリ、主要ヘッダー、ボディ概要）

  • レスポンス情報（ステータス、レスポンスボディ、主要ヘッダー：Retry-After等）

  • 相関ID（request-id / trace-id / x-correlation-id等）

  • 主体情報（ユーザーID、APIキー、IP、User-Agent、アプリ版、SDK版）

特に相関IDは「ログの世界で同じリクエストを一意に探す鍵」です。相関IDがないと、ログ検索は推測に寄り、復旧が遅れます。後半で、相関IDを前提とした運用設計も扱います。

client errorを30分で切り分けるRunbook

30分Runbookの全体像

ここで扱うのは、知識としての4xx解説ではなく、当番対応でそのまま使える30分Runbookです。目的は「原因を特定しきる」ではなく、まず原因の当たりを付け、一次対処と関係者アクションを決めることです。

  • 0〜5分：事実確定（影響範囲・相関ID・代表例の確保）

  • 5〜15分：観測点の突合（入口ログ→WAF/ゲートウェイ→アプリログ）

  • 15〜25分：4xxタイプ分類（入力／認証認可／存在／仕様不一致／競合／制限）

  • 25〜30分：一次対処の選択（回避・緩和・ロールバック・周知）と恒久対策の論点化

ステップ1 代表リクエストを固定し再現条件を作る

最初にやるべきは、会話の材料（代表例）を作ることです。理想は「成功例」と「失敗例」を並べることです。

  • 同一ユーザーで成功/失敗が分かれるか

  • 同一入力で成功/失敗が分かれるか

  • 特定の端末/ネットワークでのみ起きるか

  • 特定の時間帯、回数、負荷でのみ起きるか

この時点で、たとえば「特定ユーザーだけ403」「特定入力だけ400」「一定回数で429」のように、次に見るべき方向が絞れます。
そして、代表リクエストについては可能な範囲で以下を確保します。

  • 失敗したときの相関ID

  • 入口（CDN/LB/ゲートウェイ）のログ行

  • アプリ側のログ行（認証、認可、バリデーションの痕跡）

ステップ2 観測点マップでログを“上流から下流へ”突合する

4xxの切り分けは、闇雲にアプリログだけを見ると迷子になります。原則は、上流から下流へです。
上流で「そもそもリクエストが届いていない」なら、アプリを見ても答えは出ません。

観測点マップ（どこで何が分かるか）

観測点 代表ログ/データ 相関IDの有無 ここで分かりやすい4xx原因
クライアント 端末ログ、SDKログ、ブラウザDevTools ないことも多い リクエスト生成不備、無限リトライ、誤URL/誤メソッド
CDN アクセスログ、キャッシュ挙動 付与可能 404増加、特定パス集中、エッジ側ブロック
WAF ブロックログ、ルール一致 付与/連携次第 403増加、誤検知、ボット判定
LB アクセスログ、ターゲット振り分け 付与可能 特定AZのみ異常、ヘルスの偏り
API Gateway ルーティング、認証前処理、Rate limit 付与可能 401/403/429、メソッド制限、ヘッダー不備
アプリ アプリログ、例外、認証認可ログ あるべき 400/401/403/422/409、業務ルール違反
IdP/認証基盤 トークン発行/検証ログ 連携次第 401急増（鍵ローテ、期限、設定変更）
DB/外部API クエリ失敗、下流エラー 連携次第 本来5xx寄りだが判定で4xx化されるケース

この表を作っておくと、「次にどこを見るか」が固定化されます。特にWAFやゲートウェイで403/429が出ている場合、アプリを調べても無駄が多いです。

ステップ3 4xxを“タイプ”で分類して最短経路を選ぶ

ステータスコードは多いですが、切り分けの初動では「タイプ」で見るほうが速いです。

  • 入力・形式：400 / 415 / 422

  • 認証・認可：401 / 403

  • 存在・URL：404 / 410

  • 仕様不一致：405 / 406 / 415

  • 競合・整合性：409

  • 制限：429

  • 条件不成立：412（ETag等の前提条件）

  • 大きすぎる：413（アップロード制限）

分類できたら、次に見る“証拠”が決まります。たとえば401/403なら認証ミドルウェアと認可判定ログ、429ならレート制限の主体別メトリクス、400/422ならバリデーション結果と入力差分です。

ステップ4 一次対処を選ぶ（復旧優先の判断軸）

一次対処は「正しさ」よりも「影響を止める」ことが優先されます。判断軸は次の3つです。

  • 重要導線か（ログイン、購入、決済、登録など）

  • 影響範囲は広いか（全体か特定セグメントか）

  • 回避策はあるか（機能フラグ、ロールバック、制限緩和、メッセージ誘導）

一次対処の例：

  • 直近リリースが原因っぽい：ロールバック／機能フラグOFF

  • WAF誤検知っぽい：特定ルールの一時緩和（リスク評価はセット）

  • 429が急増：制限値の一時緩和＋クライアント側の無限リトライ抑止を周知

  • 404急増：想定外のURL変更が疑わしい→301を暫定投入、もしくはルーティング復旧

ステップ5 恒久対策の論点を“宿題”として残す

復旧後に重要なのは、「何を変えれば再発が減るか」を言語化してチケット化することです。ここが弱いと同じ障害が繰り返されます。

  • ログに必要なフィールドが欠けていないか（相関ID、主体、エンドポイント、errorType）

  • エラーレスポンスがバラバラでクライアントが誤動作していないか

  • レート制限の設計（主体、上限、Retry-After、クライアント実装）が不十分ではないか

  • 認証認可の監査・可視化（権限表、スコープ、ロール）が弱くないか

client errorの主要ステータスコード別に原因と対処を整理する

4xx主要コード早見表（原因→確認→一次対処→再発防止）

コード 意味の要点 典型原因 最初に見る証拠 一次対処 再発防止
400 リクエスト不正 JSON壊れ、必須欠落、型不一致 バリデーションログ、受信ボディ、Content-Type 入力修正、サーバ側エラー理由の返却 スキーマ化、契約テスト、RFC7807
401 認証できない トークン無し/期限切れ/署名不正 認証ミドルウェアログ、Authorization有無、exp 再ログイン/更新誘導 トークン更新導線、鍵ローテ手順
403 権限がない スコープ/ロール不足、WAFブロック 認可判定ログ、WAFログ、ルール一致 権限付与/誤検知解除 権限表の整備、監査ログ
404 見つからない URL誤り、ルート未登録、削除 入口ログのパス集中、ルーティング定義 URL修正、ルート復旧、301暫定 変更管理、リンク監視
410 恒久的に消えた 削除済み 対応方針の確認 410に統一/説明ページ 削除フロー、サイトマップ整理
405 メソッド不許可 GET/POST誤り ゲートウェイ設定、Allowヘッダー クライアント修正 OpenAPI/SDK更新
415 Media Type不対応 Content-Type不一致 Content-Type/Accept、ゲートウェイ制約 ヘッダー修正 サンプル・SDK整備
422 意味的に不正 値の制約違反、業務ルール違反 どの項目がNGか（フィールド） 入力修正/エラー文改善 ルール明文化、UIバリデーション
409 競合 二重登録、更新競合 一意制約、同時実行、Idempotency リトライ/重複排除 冪等性キー、楽観ロック
412 前提条件NG ETag不一致 If-Match/ETag、更新競合 再取得→再送 ETag運用、クライアント実装
413 大きすぎる アップロード上限超過 Content-Length、ゲートウェイ制限 上限案内、分割アップロード 上限設計、UX導線
429 リクエスト過多 レート制限、無限リトライ、誤検知 Retry-After、主体別429率、WAF 待機/緩和/遮断 バックオフ、上限、監視

この表のポイントは、「意味」を覚えることではなく、最初に見る証拠を固定することです。次の節で、代表的なコードをさらに掘り下げます。

400を減らすための入力・バリデーション設計

400が増える典型パターン

400は「何でも入れられる箱」になりがちです。増えるときは、だいたい次のどれかです。

  • クライアントが送っているJSONが壊れている（文字列のエスケープ、末尾カンマ等）

  • 必須項目が欠落している（SDKのバージョン差分、仕様変更が追いついていない）

  • 型がズレている（数値/文字列、配列/単体、null許容）

  • Content-Typeが正しくない（application/jsonのはずが別形式）

  • バリデーションエラーが「400だけ」で詳細が返らず、クライアント側が誤ったリトライをする

400の切り分けチェックリスト

  • 失敗リクエストのボディは取得できるか（機密に配慮しつつ）

  • Content-Typeは想定通りか

  • 必須フィールド欠落はないか

  • 型の不一致はないか

  • 失敗が特定クライアント/特定バージョンに偏っていないか

  • 直近の仕様変更（スキーマ変更）はないか

400の再発防止：スキーマと契約の運用

400の根本対策は「人間の記憶」ではなく「仕組み」です。

  • スキーマ定義（OpenAPI等）を単なるドキュメントではなく、検証・生成に使う

  • 契約テストで、サーバ変更がクライアントを壊さないようにする

  • バリデーションエラーは、クライアントが直せる粒度で返す（ただし内部情報は出さない）

このとき、エラー形式の統一は後述のRFC7807が効きます。「どのフィールドが、なぜダメか」を機械可読に返せると、クライアント側のUXも改善します。

401と403を“証拠ベース”で切り分ける

401と403が混ざる理由

401と403の混同は、運用現場で特に多い落とし穴です。理由はシンプルで、どちらも「アクセスできない」からです。しかし原因と対処はまったく異なります。

  • 401：認証が成立していない（欠落、期限切れ、署名不正、aud/iss不一致）

  • 403：認証は成立したが、権限が足りない（ロール、スコープ、ACL、WAFブロック含む）

401/403判断表（証拠付き）

観点 401で疑う 403で疑う
まず見る証拠 認証ミドルウェアの検証結果、exp、署名検証 deletionではなく認可判定ログ、WAFログ、ルール一致
発生の偏り 特定クライアント版、期限境界、鍵ローテ直後 特定ロール/テナント、特定IP/UA、特定エンドポイント
一次対処 再ログイン誘導、トークン更新 権限付与/誤検知解除/アクセス設計見直し
再発防止 鍵ローテRunbook、期限/時刻ずれ対策 権限表、監査ログ、ポリシー可視化

401が急増したときに見るべき典型原因

  • トークン期限（exp）が短すぎる、更新導線が壊れた

  • 署名鍵のローテーションで検証側が追従していない

  • クライアントがAuthorizationヘッダーを送っていない（CORSやプロキシ、実装差分）

  • 時刻ずれ（特にサーバ側の時刻、もしくは検証基盤の時刻）で期限判定がズレる

一次対処としては「再ログイン誘導」だけでなく、アプリの更新導線を緊急で整える、期限を暫定延長する（リスク評価は必須）などの選択肢もあります。

403が増えたときに見るべき典型原因

  • 権限モデル変更（ロール/スコープの変更）が周知されていない

  • 認可判定の条件が実装バグで厳しくなった

  • WAFが誤検知している（特定のパラメータやUser-Agentでブロック）

  • ゲートウェイ側のIP制限・国制限・ACLが意図せず効いている

403は「セキュリティ上の意図」が絡むため、一次対処の緩和はリスクを伴います。だからこそ、WAFログやルール一致を確認し、どの制御で落ちているか（認可か防御か）を必ず分けます。

404と410を運用とUXの両面で扱う

404が増えたときの基本パターン

404は「存在しない」だけでなく、次のような“サーバ側都合”で出ます。

  • ルーティング設定の漏れ（デプロイ漏れ、環境差分）

  • URL変更後の301未整備

  • CDNキャッシュやRewriteの不整合

ここで重要なのは、404を「放置」するか「直す」かを、目的別に判断することです。

404/410/301の判断表（サイト運営者にも使える）

状況 推奨 ねらい
URLが移動した 301 旧URL利用者とクローラを新URLへ誘導
恒久的に削除した 410 「もう戻らない」ことを明確にし整理を早める
一時的に欠落（不具合） 404→復旧 ルーティングやデプロイを直し復旧
釣り/スキャン/不要アクセス 404維持＋監視 無用な情報を増やさず、傾向を把握

404の再発防止：変更管理とリンク監視

URL変更が多いプロダクトほど、次が効きます。

  • 変更前にリダイレクト計画を作る（最低限、主要導線）

  • リリース後に404の上位パスを監視し、想定外の増加を検知

  • 内部リンクの自動テスト（主要ページのリンク切れ検出）

405/415/422で起きる“仕様不一致”をつぶす

405は「メソッドの契約違反」

405は「そのURLは存在するが、そのメソッドは受け付けない」という状態です。API Gatewayやルーティングで弾いている場合もあれば、アプリが明示的に拒否している場合もあります。
よくある原因は、クライアント側が古い仕様で実装されていることです。一次対処はクライアント修正ですが、緊急時はゲートウェイ側で暫定的に許可する（リスク評価は必要）などの判断もあり得ます。

415は「Content-Type/Acceptのズレ」

415は、送ってきたボディの形式をサーバが理解できない状態です。多いのは以下です。

  • application/jsonを想定しているのに別のContent-Type

  • ファイルアップロードでmultipart/form-dataが崩れている

  • Acceptヘッダーの指定で想定外のレスポンス形式を要求している

再発防止は、SDK・サンプル・ドキュメントの整合をとり、テストで形式のズレを検知できるようにすることです。

422は「形式は正しいが意味がNG」

422は「JSONとしては正しいが、値の制約が破れている」場合に相性が良いコードです。
ここで大事なのは、クライアントが直せる粒度で「どの項目が、なぜダメか」を返すことです。
ただし内部ルールの出しすぎは危険なので、表示するのは「入力として満たすべき条件」に留め、権限構造などは露出しない方針が安全です。

409と412で起きる競合を“冪等性”で潰す

409が出る典型シナリオ

  • 二重登録（ユーザーがボタン連打、ネットワーク遅延で二重送信）

  • 参照していた状態が古いまま更新しようとして衝突（同時更新）

  • 一意制約に引っかかる（メールアドレス等）

一次対処は、クライアント側の多重送信抑止と、サーバ側の冪等性（Idempotency-Key）で再現を止めるのが有効です。

412（前提条件NG）を使うと更新競合が扱いやすい

ETag/If-Matchを使う更新は、競合を「仕様」として扱えます。
412を正しく運用できると、「競合したので再取得してから再送して」という導線を作れます。これにより409の泥沼（どちらが勝つか）を回避しやすくなります。

429を“運用設計＋クライアント実装”で安定させる

429が増える原因は3種類に分かれる

429は「レート制限」と一言で片付けられますが、実際は原因が3系統あります。

  • 正常なレート制限（想定通りの保護）

  • クライアント実装の不具合（無限リトライ、重複送信、バッチ暴走）

  • 防御系の誤作動（WAF/ボット判定、共有IPの巻き込み）

429の一次対処：まずRetry-Afterと主体別偏りを見る

  • Retry-Afterが返っているか（返っていないとクライアントは適切に待てない）

  • 主体（APIキー/IP/ユーザー）別に偏っていないか（特定の暴走を見つける）

  • どのエンドポイントに集中しているか（高コストAPIやログイン周りが多い）

429の再発防止：クライアント側の“守る実装”

429を減らすうえで、サーバ側の制限だけでは不十分です。クライアント側に次が揃って初めて安定します。

  • 最大リトライ回数

  • 指数バックオフ（待機時間の増加）

  • ジッター（待機のばらつき）

  • 同一リクエストの重複送信を抑止（冪等性キーやキュー制御）

  • 429以外（401/403/400）にはリトライしない（誤った再試行を止める）

エラーレスポンス設計でclient errorを“直しやすく”する

エラーで返すべき情報と返してはいけない情報

ユーザーやクライアントに「直せる情報」を返すことは重要ですが、内部情報の出しすぎは情報漏えいにつながります。設計の基本は次です。

返すべき：

  • 何が問題か（短いtitle）

  • 何を直すべきか（detailを短く）

  • どこで起きたか（instance）

  • 問い合わせ用の相関ID（traceIdなど）

返さない：

  • スタックトレース、SQL、内部例外名、詳細な権限構造

  • アカウント存在が推測できる情報（ログインIDの存在可否など）

RFC 7807でエラー形式を統一する

APIが増えるほど、「エラーの形」がバラバラだと運用とUXが崩れます。RFC 7807（Problem Details）に寄せておくと、クライアントが一貫して扱えます。

  • type：問題種別のURI（分類）

  • title：短い要約

  • status：HTTPステータス

  • detail：人間向け詳細（短く）

  • instance：発生場所（URI）

  • 拡張：traceId、fieldErrorsなど

fieldErrorsを入れると400/422が劇的に直しやすくなる

400/422は特に「どの項目がダメか」が重要です。次のように最小限の配列を返すと、クライアント側がUIに落とし込みやすくなります。

  • field：項目名

  • reason：理由（短く）

  • expected：期待（必要なら）

ただし、内部ルールやセキュリティに関わる理由は出しすぎないように注意します。

監視とアラート設計：4xxは“総数”より“内訳と導線”で見る

監視の基本：重要導線×コード×主体

4xxはノイズが多いため、総数だけを見ても誤検知が増えます。次の粒度が有効です。

  • 重要エンドポイント別（ログイン、購入、決済、登録）

  • コード別（401/403/429は特に）

  • 主体別（ユーザー、APIキー、IP帯、User-Agent、アプリ版）

アラート設計の例

  • 401率が急上昇：認証基盤の変更や鍵ローテ、期限設定の問題を疑う

  • 403が特定パスで増加：WAF誤検知、認可判定の変更を疑う

  • 429が主体偏りで増加：特定クライアントの暴走、ボット集中を疑う

  • 404が特定パスで増加：URL変更・ルーティング漏れ・リンク切れを疑う

当番が迷わないチェックリスト（緊急時）

  • 直近リリース/設定変更はあるか（ゲートウェイ/WAF/認証/ルーティング）

  • 影響は重要導線か、どのユーザー層か

  • 相関IDで入口ログ→ゲートウェイ→アプリを突合できるか

  • 401/403/429の主体偏りはあるか

  • 404の上位パスは何か（移動/削除/不具合のどれか）

  • 一次対処（ロールバック、緩和、遮断、周知）の候補は何か

サイト運営者向け：Search Consoleの4xxをどう扱うか

Search Consoleの4xxは“意図”で仕分ける

サイト運営の文脈では、「4xxが出ている」こと自体よりも、それが意図した状態なのか、不具合なのかが重要です。

  • 意図した404：存在しないページへのアクセス（放置＋監視）

  • 意図した410：削除を明示（整理が早い）

  • 不具合の404：移動したのに301がない、デプロイ漏れ、ルーティング漏れ（修正対象）

対応方針の最短決定フロー

  • ページは移動したか？ → はい：301

  • 恒久削除したか？ → はい：410

  • 本当は存在するのに404か？ → はい：復旧（ルーティング/デプロイ/リンク修正）

  • 保護ページか？ → 公開方針に従い、noindexや認証制御を検討

client errorに関するよくある質問

4xxでもサーバ側が悪いケースはありますか

あります。WAF誤検知で403、ゲートウェイの設定で405、ルーティング漏れで404、過敏な制限で429など、原因はサーバ側でも結果は4xxになり得ます。重要なのは「誰が悪いか」ではなく、観測点と証拠を揃えて切り分けることです。

400と422はどう使い分ければよいですか

運用方針として一貫していればどちらでも回りますが、一般には次の整理がしやすいです。

  • 400：形式や前提が不正（壊れたJSON、必須欠落、型不一致など）

  • 422：形式は正しいが、値の制約や業務ルールで受け付けられない

重要なのは、クライアントが修正できる情報を返し、誤リトライを防ぐことです。

429のときにやってはいけないことはありますか

「無限リトライ」「429以外にも機械的にリトライ」「待機なしの再試行」は状況を悪化させます。Retry-Afterの尊重、指数バックオフ、上限回数、冪等性がセットで必要です。

エラー文言はどこまで詳しく書くべきですか

ユーザーが直せる情報は必要ですが、内部実装や権限構造などは出しすぎない方が安全です。問い合わせ用の相関IDを付け、詳細はログで追える設計が現実的です。

参考情報源

X、Twitterの最新記事4件