監視ダッシュボードやアクセスログで4xxが増えているのを見つけた瞬間、「ユーザーの操作ミスだろう」と片付けたくなる一方で、実はアプリの実装変更、認証設定、WAFやCDNのルール、URL設計の不整合など“こちら側の問題”が潜んでいることも少なくありません。しかも4xxは種類が多く、400・401・403・404・429が混ざると、どこから手を付けるべきか判断が難しくなります。
本記事では、client error（4xx）の基本を押さえつつ、30分で原因に当たりを付ける切り分けフローを軸に、代表コードごとの原因と対策を具体的に整理します。さらにSearch Consoleで見える404・ソフト404の「直す／放置」の判断基準、CloudFrontやIISなど環境別の見方、再発防止の監視設計までまとめました。読み終えたときには、目の前の4xxに対して「何を確認し、どこを直し、どう防ぐか」を迷わず決められるはずです。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
client errorの意味と4xxの全体像
4xxが示す範囲と5xxとの違い
client errorはHTTPステータスコードのうち、主に4xxを指します。ざっくり言えば「クライアントのリクエストに問題があり、サーバーがそのまま処理できない」状態です。ただし、ここでいう“クライアント”はブラウザだけではなく、モバイルアプリ、APIクライアント、クローラ、CDNやプロキシ経由のアクセスなど、サーバーに対してリクエストを投げるすべてを含みます。
一方の5xxは「サーバー側がリクエストを処理しようとしたが、内部で失敗した」状態です。データベース障害、アプリ例外、オリジン到達不可、タイムアウト、設定の不整合などが典型です。
現場で重要なのは、4xx＝利用者のミス、5xx＝サーバーのミスと単純化しないことです。たとえば「403（Forbidden）」は権限不足のように見えますが、実際にはWAFの誤検知や、CDNの国別ブロック設定、アプリ側のアクセス制御の誤りなど“運用・設定”起因で大量発生することが珍しくありません。「404（Not Found）」も、ユーザーの打ち間違いより、内部リンク・サイトマップ・アプリのルーティング・リダイレクトの設計ミスで発生することが多いです。
つまり4xxを見たら、次の問いを立てるのが近道です。
どの層（アプリ／Webサーバー／CDN／WAF／認証基盤）が4xxを返しているか
誰が（ユーザー／ボット／社内システム／外部連携）そのリクエストを投げているか
仕様として正しい4xxか、事故としての4xxか
この3点が整理できると、復旧までの距離が一気に縮まります。
代表的な4xx一覧と「まず見るべき観点」
4xxは種類が多いですが、運用でよく見かけるものは限られます。まずは代表的なコードを“原因カテゴリ”で把握すると混乱しません。
400（Bad Request）
リクエストが不正。必須パラメータ不足、型不一致、JSON不正、URLエンコード不備、サイズ超過など。401（Unauthorized）
認証が必要だが認証情報がない、または不正。トークン期限切れ、Authorizationヘッダ欠落、署名不一致など。403（Forbidden）
認証はできた／あるいはリクエストは理解できたが、アクセスを許可しない。権限不足、IP制限、WAF、地域制限、ディレクトリ保護など。404（Not Found）
リソースが存在しない。URL誤り、リンク切れ、削除済み、ルーティング不備。410（Gone）
恒久的に削除した。将来復活しないことを明確に伝えたい場合に使う。429（Too Many Requests）
レート制限により拒否。過剰アクセス、ボット、連携の暴走、クライアントのリトライ設計不備など。
ここでの「まず見るべき観点」は、コードの意味そのものよりも診断に必要な情報です。具体的には次の4つを最初に押さえます。
発生しているURL／エンドポイント（特定の1本か、広範囲か）
発生している主体（ユーザーのブラウザなのか、アプリなのか、クローラなのか）
発生頻度とタイミング（急増なのか、一定なのか、リリース直後なのか）
ログに残っている“拒否理由”（アプリが返したのか、WAFなのか、CDNなのか）
この段階で「重要導線で起きている401/403/429は高優先」「ボット由来の404は中〜低優先」など、初動の優先順位も決めやすくなります。
client errorを30分で切り分ける手順
手順1 再現と影響範囲の確定
最短で解決するには、いきなり設定を触らず、まず状況を言語化します。再現できるかどうかは非常に重要です。再現できれば原因が絞れますし、再現できない場合でも「どの条件で発生するか」を推定できます。
確認項目は次の順序がおすすめです。
どのステータスコードが増えているか
4xxの合計だけを見ると、404のノイズに埋もれて本当に深刻な401/403/429を見落としがちです。まずはコード別に分解します。影響範囲（URL・機能・ユーザー層）
特定URLだけ：ルーティング、公開範囲、リダイレクト、パーミッションを疑う
特定機能だけ：API仕様変更、認証・権限、バリデーションを疑う
特定UAだけ：アプリ旧版、クローラ、bot対策、ブラウザ互換を疑う
特定国・IP帯だけ：CDN/WAFの地理制限、IPレピュテーションを疑う
発生開始時刻と直前イベント
リリース、WAFルール更新、証明書更新、DNS変更、CDN設定変更、ログイン方式変更など、運用上のイベントと紐づくことが多いです。ユーザー影響（売上・主要導線・SLO）
監視上のスパイクでも、ボット由来なら実害は小さい一方、ログインや購入の401/403は即影響します。
再現する際は、同じURLでも「ログイン状態」「Cookie」「Authorization」「User-Agent」「リファラ」「IP（社内/VPN）」で結果が変わることがあるため、条件を揃えて確認します。
手順2 ログで「誰が」「何を」要求したか見る
原因切り分けは、結局ログがものを言います。最低限、次の情報が取れれば診断の精度が上がります。
リクエストライン：メソッド、パス、クエリ
ステータスコード：4xxの種類
リファラ：どこからリンクされたか（内部遷移・外部参照が分かる）
User-Agent：ブラウザ/アプリ/クローラ判別
認証情報の有無：Authorization、Cookie、セッションID（値そのものは扱いに注意）
クライアント識別：IP、ユーザーID、トークンの種別、X-Forwarded-For 等
処理時間：遅延が絡む場合の手がかり
拒否理由のログ：WAFのルールID、認可失敗の理由、バリデーションエラー内容など
CDNやWAFが挟まる環境では、どこで拒否されたかが最重要です。
CDNが返しているのか（エッジでブロック、キャッシュされたエラー応答）
オリジンが返しているのか（アプリやWebサーバーの設定）
認証基盤が返しているのか（認証サーバーやIDaaS）
この“責任境界”が曖昧だと、原因箇所の推測がぶれます。ログの突き合わせ（CDNログとオリジンログの同時刻・同一リクエストの照合）を意識してください。
手順3 原因カテゴリに当てはめる
ログから見えてきた現象を、カテゴリに落とすと対処がスムーズです。おすすめの分類は次の5つです。
URL・ルーティング起因
404/410中心。内部リンクのミス、サイトマップの誤掲載、リダイレクトミス、アプリルーティング不備、削除の影響など。認証起因
401中心。トークン期限切れ、署名不一致、ヘッダ未付与、Cookie属性変更（SameSite等）、認証方式変更など。認可（権限）起因
403中心。ロール設定、ACL、IP制限、WAF誤検知、管理画面保護など。入力・仕様不整合起因
400中心。必須項目、型、フォーマット、サイズ、エンコード、バージョン差異など。制限・防御起因
429や403中心。レート制限、bot対策、国別ブロック、セキュリティ製品の判定など。
ここで大切なのは「同じコードでも原因が違う」ことです。たとえば403は権限不足だけでなく、WAF誤検知や国別制限でも出ます。ログの“拒否理由”が取れない場合は、発生条件（特定IP帯、特定UA、特定パス）から推定します。
手順4 応急対応と恒久対応を分ける
緊急時にありがちな失敗は、応急対応と恒久対応が混ざり、結果として再発することです。まずは「止血」を優先し、その後に原因を潰す流れに分けます。
応急対応の例
404が主要ページで多発：いったんページを復元、または暫定的に正しいページへ301
401/403が主要APIで多発：直近の認証・権限変更をロールバック
429でサービスが実質停止：制限値を一時緩和しつつ、攻撃兆候がないか監視強化
WAF誤検知：最小範囲で例外ルールを入れ、影響を観測
恒久対応の例
内部リンク・サイトマップ生成ロジックの修正
認証トークン更新設計、失効と更新の例外処理、クライアント側バックオフの実装
権限・ロール設計の見直し、監査ログ整備
レート制限のキー設計（IPのみ→ユーザーIDも併用等）、誤検知時の救済導線
応急対応は「影響を止める」ことが目的なので、将来の拡張性よりも速度を優先してよい場面があります。ただし、応急対応の内容は必ず記録し、恒久対応のタスクに落とし込むのが再発防止の要です。
client errorの代表コード別の原因と対策
400の原因と直し方
400は「リクエストが不正」の総称で、APIやフォーム送信、Webhookなどで頻出します。原因が多岐にわたるため、エラーレスポンスの設計がそのまま運用難易度を左右します。
典型的な原因
必須パラメータ不足（例：idが空、tokenがない）
型不一致（数値が必要なのに文字列、配列が必要なのにオブジェクト）
JSON構文不正（カンマ、クォート、エスケープ）
文字コード・エンコーディング不備（URLエンコード漏れ、二重エンコード）
サイズ超過（ヘッダやボディが大きすぎる）
仕様変更による旧クライアントの送信形式不一致
対策の進め方
サーバー側ログに“どの検証で落ちたか”を残す
400が増えたときに最短で原因が分かるのは、「必須項目Xが欠落」「フォーマット不正」「サイズ超過」のような機械可読な理由です。個人情報を出しすぎない範囲で、失敗理由を構造化して残します。クライアント側のバリデーションと整合させる
サーバーだけが厳しいと、ユーザー体験は悪化します。可能ならクライアント側でも同じ制約を実装し、送信前に弾きます。仕様変更は段階的移行にする
旧アプリや外部連携が残っていると、突然400が増えます。バージョニング、互換期間、警告ログの期間を設けると安全です。
運用のコツ
400の“総数”だけでなく、原因コード別（missing_field / invalid_format など）で集計できると、対応が早くなります。
401の原因と直し方
401は認証の問題です。ログイン機能やAPI認証（Bearerトークン、署名付きリクエスト、セッションCookieなど）で発生します。
典型的な原因
Authorizationヘッダが付与されていない（クライアントの実装バグ、プロキシでヘッダが落ちる）
トークン期限切れ（更新処理が走っていない、端末時刻ずれ）
署名不一致（鍵の更新、環境変数の差し替えミス）
Cookie属性変更（SameSite/secure/httpOnly）により送られない
認証サーバー側の設定変更（クライアントIDの無効化、リダイレクトURLの不整合）
対策の進め方
401の発生元を分解する
どのエンドポイントで401が出ているか。ログイン直後なのか、一定時間後なのか。更新APIだけなのか。これで原因がかなり絞れます。トークンのライフサイクルを見直す
期限切れ前に更新する
更新失敗時の再認証導線を用意する
連続失敗時は無限リトライしない（サーバー負荷を増やしやすい）
クライアント差分を疑う
UAやアプリバージョン別に401率を見れば、特定バージョンのバグや互換性問題を発見しやすいです。
ユーザー体験の注意点
401を返す場合、可能であれば「再ログインが必要」「トークン更新が必要」など、次の行動が分かる情報を返すと問い合わせが減ります（返しすぎはセキュリティ上注意）。
403の原因と直し方
403は「許可されていない」状態です。認証は通っていても、権限がない、あるいはセキュリティ機構が拒否しているケースがあります。
典型的な原因
ロール・権限設定のミス（管理者だけアクセス可能なAPIに一般ユーザーがアクセス）
公開範囲の設定（社内IPのみ許可、特定パスのBasic認証）
WAF/bot対策による遮断（特定パターンのクエリ、特定UA、攻撃判定）
国別・地域別ブロック（CDNやWAFで設定）
ファイル/ディレクトリのアクセス制御（Webサーバー設定）
対策の進め方
どの層が403を返しているかを確定する
アプリログに到達していないならWAF/CDN側が疑わしいです。到達しているならアプリの認可ロジックや設定を見ます。直近の変更履歴を洗う
WAFルール更新、権限テーブル変更、管理画面の保護設定など、変更が原因になりやすいです。誤検知の切り分けをする
特定国、特定UA、特定パスに偏るなら誤検知の可能性があります。ルールIDや該当条件をログに残せると修正が速いです。例外は最小範囲で適用する
403の例外ルールは広げすぎるとリスクが上がります。まずは影響範囲を限定し、ログで監視しながら調整します。
404と410の使い分け
404は「存在しない」、410は「恒久的に削除した」です。SEOや運用を考えると、どちらが正しいかは“意図”で決めるのが基本です。
404が向くケース
単に存在しない（誤URL、打ち間違い、古いリンク）
将来復活の可能性がある（期間限定ページ等）
削除したが、状況により復活もあり得る
410が向くケース
完全廃止し、今後復活しない
検索エンジンにも「戻らない」ことを明確に伝えたい
大量の廃止URLを整理したい（移行時など）
代替ページがある場合
近い代替があるなら301リダイレクトが選択肢です。ただし、何でもかんでもトップページに飛ばすのはユーザー体験を損ね、検索エンジン評価上も望ましくないことがあります。できるだけ意味的に近いページへ誘導します。
注意：200でエラーページを返さない
404相当なのに200を返すと、後述のソフト404扱いになりやすく、インデックスの品質を下げる要因になります。
429の原因と直し方
429はレート制限です。正当な防御として機能している場合もありますが、設定が厳しすぎると正規ユーザーの利用を妨げます。
典型的な原因
同一IPから短時間に大量アクセス（企業ネットワーク、モバイルキャリアNATなどで“同一IPに見える”）
クライアントの無限リトライ（失敗時に即時再送を繰り返す）
外部連携の暴走（Webhookの再送、バッチの同時実行）
bot/スクレイピング（特定パスへの集中アクセス）
制限キー設計の不備（IPだけで判定してしまい、正規ユーザーも巻き込む）
対策の進め方
発生元を特定する（IP/UA/ユーザーID）
正規ユーザーか、攻撃か、連携かを見極めます。制限のキーと閾値を再設計する
IPだけでは巻き込みが起きやすいので、ユーザーIDやAPIキー単位、トークン単位を併用するなど工夫します。クライアント側でバックオフを実装する
429を受けたら待ち時間を伸ばし、同時リクエスト数も抑える。これだけでサーバー負荷と429率が大幅に改善することがあります。例外と監視をセットで運用する
特定連携は上限を緩める、ただし異常増加は検知する、というバランスが必要です。
Search Consoleで見るclient errorの判断基準
404は直すべき場合と放置でよい場合
Search Consoleで「404（ページが見つかりません）」が出ると焦りがちですが、404自体は“存在しないなら存在しないと返している”だけで、必ずしも悪ではありません。重要なのは意図したURLなのに404になっていないかです。
直すべきかの判断は、次の2軸で考えると迷いません。
あなたが“そのURLを存在させたい”のか
Googleに“そのURLを存在すると伝えてしまっている”のか（例：サイトマップ、内部リンク）
直すべき代表例
サイトマップに載せているURLが404
→ サイトマップ生成ロジックが誤っているか、公開・非公開の切替で不整合がある可能性が高いです。内部リンクやナビゲーションから404に行けてしまう
→ ユーザー体験として明確な損失なので優先度は高めです。重要ページ（購入、ログイン、問い合わせ）で404
→ 直ちに復旧と原因究明が必要です。
放置でよい（または優先度が下がる）代表例
ボットが無関係なURLにアクセスしているだけ
→ 404を正しく返しつつ、必要に応じてWAFやレート制限で負荷を下げます。削除済みで代替もないURL
→ 404（または410）を返し続けること自体は自然です。
ここでのポイントは、Search Consoleのレポートは“サイト改善のヒント”であって、すべてをゼロにすることが目的ではない、という点です。内部品質（サイトマップや内部リンク）に関わる404を優先し、外部要因やノイズは落ち着いて扱うのが現実的です。
ソフト404が起きる理由と直し方
ソフト404は、ステータスコードとしては200（成功）などを返しているのに、ページの中身が「存在しない」「エラー表示」「極端に薄い」と判断され、Search Consoleで“404相当”として扱われる状態です。
よくある原因
存在しないページでも共通テンプレで200を返している
（例：「お探しのページは見つかりません」と表示しているのに200）検索結果ゼロのページや、内容がほぼないページを量産している
パラメータで無限にURLが増え、薄いページが大量にできている
認証が必要なのに、200でログイン画面を返してしまう（本来は401/403が適切な場合がある）
直し方の基本
存在しないなら、404または410を正しく返す
表示内容とステータスコードを一致させます。代替導線を用意する
404ページ自体は問題ありませんが、ユーザーが次に進めるように「検索ボックス」「カテゴリ一覧」「人気ページ」などを用意すると離脱を減らせます。薄いページを作らない設計にする
検索条件ページやタグページの生成ルールを見直し、index/noindexや正規化も含めて整理します（サイト全体の設計論点）。
ソフト404は“コードの修正”だけでなく、“コンテンツ設計”の見直しが必要になることもあります。まずは「本当に存在しないのか」「存在するが薄いのか」を分けて考えると、打ち手が見えます。
サイトマップ送信URLの「間違い」を潰す
Search Consoleでの4xx問題を最速で減らすなら、サイトマップと内部リンクに集中するのが効率的です。ここが正しければ、検索エンジンに対して「存在するURL」を正しく伝えられている状態になります。
チェックポイントは次のとおりです。
URL正規化の統一
末尾スラッシュ有無、http/https、www有無、大文字小文字、URLエンコードの一貫性。公開制御との整合
会員限定・非公開ページがサイトマップに混ざっていないか。公開切替の際にサイトマップ更新が追随しているか。リダイレクトチェーンの排除
サイトマップには最終到達URLを掲載し、301→302→404のような事故を避けます。更新のタイミング
大規模リニューアル時は、旧URLをサイトマップに残さない、更新漏れを監視する、といった運用が重要です。
サイトマップが正しくても、内部リンクが古いままだとユーザー体験が崩れます。サイトマップと内部リンクの両方を“同じ正規URL”に揃えるのが理想です。
CDN・サーバー別に見るclient error
CloudFrontで4xx/5xxが出るときの見方
CDN配下では、4xxがどこで発生しているかが見えづらくなります。そこで意識したいのが「エッジで返したのか、オリジンが返したのか」です。CloudFrontのような構成では、オリジンが返したステータスがそのままビューアへ返るケースが多く、原因がアプリやオリジン設定にあることも少なくありません。
確認の基本手順
同一リクエストをエッジログとオリジンログで突合する
同時刻、同一パス、同一クエリ、同一UA、同一IP（X-Forwarded-For含む）を照合し、どこで拒否されたかを確定します。キャッシュが絡むか確認する
一時的な設定ミスで返した403や404が、一定時間キャッシュされて“直したのに治らない”ように見えることがあります。キャッシュポリシーやエラーキャッシュの扱いを把握すると、復旧判断が早くなります。WAFやセキュリティ設定の影響を疑う
特定パスだけ403、特定国だけ403、特定UAだけ403など、偏りがある場合はWAF/制御ルールが疑わしいです。
よくある落とし穴
オリジンのルーティングが変わったのに、CDN側の設定やビヘイビアが追随していない
認証が必要なパスをキャッシュしてしまい、想定外の401/403が増える
リダイレクトや正規化が二重化し、意図せず404が増える
CDNは便利ですが、原因箇所が増える分、ログの突合と責任境界の整理が重要になります。
IISで4xxが出るときの基本切り分け
IIS環境では、認証・アクセス制御・URL Rewrite・ディレクトリ権限などの設定が4xxに直結しやすいです。特に403はIIS設定やWindowsの権限設定が絡むことがあります。
切り分けの基本
発生するパスと条件を確定
特定ディレクトリだけなら、Web.configやIISの機能単位設定が疑わしいです。認証設定の確認
Windows認証、匿名認証、Basic認証などの変更で401/403が出やすくなります。アクセス権限の確認
アプリプールの実行ユーザーが対象ファイル/ディレクトリにアクセスできないと、403や関連エラーが出ることがあります。Rewriteやリダイレクトの影響確認
ルールの順序や条件が変わると、意図しないURLに誘導され404が出ることがあります。
IISでは「いつから起きたか」と「どの設定が変わったか」が重要な手がかりになるため、変更履歴とセットで追うと原因に到達しやすいです。
再発防止チェックリストと監視の設計
リンク・ルーティング・リダイレクトの点検
404を減らす最も確実な方法は、ユーザーが踏む導線（内部リンク）と検索エンジンに伝える導線（サイトマップ）を整えることです。以下のチェックリストを定期点検に組み込みます。
内部リンクに404がない（主要導線は自動テストやクローリングで確認）
末尾スラッシュ、www有無、http/httpsなどURL正規化が統一されている
リダイレクトは最短（チェーンになっていない）
代替がない削除URLは404/410を返し、200で誤魔化していない
サイトマップは存在するURLのみを載せ、更新が公開状態に追随している
パラメータ付きURLの取り扱いが整理され、無限生成を防いでいる
特に大規模改修やCMS移行では、旧URLがどこかに残りやすいので、内部リンクの自動検査（定期クローラ、E2Eテスト）を用意しておくと効果的です。
認証・権限・レート制限の運用ルール
401/403/429は、セキュリティとユーザー体験のバランスが難しい領域です。運用ルールが曖昧だと、どこかのタイミングで一気にスパイクします。
トークンの期限、更新、失効、再認証の動線が明確
401増加は「ログイン不全の兆候」として監視される
403増加は「権限設定/WAF誤検知の兆候」として監視される
レート制限はキー設計（IPのみ/ユーザーID併用）と閾値が文書化されている
429時のクライアント動作（バックオフ、同時実行制御）が統一されている
セキュリティ例外は最小範囲で、期限と監視がセットになっている
“強くしすぎてユーザーが使えない”状態と、“緩くしすぎて攻撃に弱い”状態の中間を保つには、監視と継続的な調整が必要です。
監視指標とアラートの最小セット
4xx監視は、総数だけだとノイズが多く、重要な異常を見落とします。最小セットとして次の構成にすると、運用負荷と検知精度のバランスが取りやすいです。
コード別の4xx率（特に401/403/429）
404はノイズになりやすい一方、401/403/429はユーザー影響が直結しやすいので、別扱いで監視します。重要エンドポイント別の4xx
ログイン、購入、決済、会員登録、主要APIなどは個別に監視します。発生主体の偏り監視
UA、IP帯、国別の偏りを見れば、bot増加やWAF誤検知、特定アプリ版の不具合に早く気づけます。リリースイベントとの紐づけ
デプロイ直後の4xx変動を追えるようにし、「いつから」「何が変わった」をすぐ言える状態にします。
最後に、監視は“検知して終わり”ではありません。アラートが鳴ったら、この記事で紹介した切り分け手順（再現→ログ→分類→対応）に沿って動けるよう、当番手順やRunbookに落としておくと、復旧速度が安定します。