Cookie削除でなぜ直る？

ブラウザが送るCookieの破損、古いセッション情報、Cookie全体の肥大化が解消されるためです。まずシークレットウィンドウで確認し、直る場合は該当サイトのCookieだけを削除してください。

特定のサイトだけ400が出るのはなぜ？

そのサイト専用のCookieやセッション情報が破損・肥大化しているか、古いURLを開いている可能性があります。該当サイトのCookie削除と、公式トップページからの再アクセスを試してください。

スマホ(iPhone/Android)での解決方法は？

再読み込み、プライベートブラウズまたはシークレットタブでの確認、該当サイトのWebサイトデータ削除、URLやブックマークの確認の順で試します。全サイトのデータ削除はログイン情報も消えるため最後の手段です。

What does 400 Bad Request mean?

HTTP 400 means the server cannot or will not process a request because the request appears malformed, invalid, or too large. Check the URL and site data as a user, or inspect the request syntax, headers, and validation errors as a developer.

400と422はどう使い分ける？

JSONの構文不正など要求自体を解析できない場合は400、構文は正しいものの値が業務ルールや検証条件を満たさない場合は422とする設計が明確です。ただしAPI全体で一貫した規約を優先してください。

400と401・403の違いは？

400は要求の形式や内容に問題がある状態、401は有効な認証情報がない状態、403は要求を理解したうえでアクセスを拒否する状態です。

400 Bad Request とは？原因と解決方法

最終更新日: 2026-07-26公開日: 2026-07-26執筆: DevToolBox編集部

Webサイトを開いたときに突然 400 Bad Request と表示されても、端末の故障とは限りません。多くはブラウザに保存されたCookieや古いURLが原因です。まず一般利用者が安全に試せる手順を紹介し、その後に開発者向けの調査方法を説明します。

A 400 response means the server could not process the request as sent. For visitors, stale site data is a common cause; for developers, the request itself must be inspected.

HTTP Status Codes

400の定義や、401・403・404・422・431など関連するHTTPステータスコードをすぐに確認できます。

今すぐ試す →

TL;DR

400は、クライアントの要求をサーバーが正しく解釈・処理できないことを示します。
一般利用者は、再読み込み、シークレットウィンドウ、該当サイトだけのCookie削除の順で試します。
特定サイトだけで直らない場合は、URLの打ち間違いや古いブックマークも確認します。
開発者は、JSON、URLエンコード、ヘッダサイズ、Content-Length、入力検証を確認します。

1. 一般利用者向け：400 Bad Requestの解決手順

上から順に試してください。途中で直ったら、それ以降の操作は不要です。最初から全Cookieを消すと関係のないサイトからもログアウトするため、対象サイトだけを切り分けるのがポイントです。

手順1：1回だけ再読み込みする

一時的な通信不良なら、1回の再読み込みで直ります。Chrome・Edgeでは更新ボタン、Windowsでは Ctrl + R、Macでは Command + R を使えます。何度も連打して改善しない場合は次へ進みます。

手順2：シークレットウィンドウで同じページを開く

シークレットウィンドウやプライベートブラウズは、通常ウィンドウのCookieの影響を受けにくいため原因の切り分けに向いています。ここで正常に開ければ、対象サイトのCookieやセッション情報が原因である可能性が高いです。

Chrome：右上のその他アイコンから「新しいシークレットウィンドウ」
Edge：右上の「設定など」から「新しい InPrivate ウィンドウ」
Safari：「ファイル」から「新規プライベートウインドウ」
iPhoneのSafari：タブボタンを押し、タブグループから「プライベート」を選択

シークレットでも同じエラーになる場合は、Cookie以外にURLやサーバー側の障害も考えられます。別の端末でも同じサイトが開けない場合は、利用者側では直せない可能性があります。

手順3：該当サイトのCookieだけを削除する

シークレットで開けた場合は、エラーが出るサイトのCookieだけを削除します。削除後はそのサイトからログアウトされるため、IDやパスワード、二要素認証の手段を確認してから実行してください。ブラウザの版によって配置が少し異なる場合があります。

Chrome（パソコン）

右上のその他アイコンから「設定」を開きます。
「プライバシーとセキュリティ」から「サードパーティ Cookie」を開きます。
「すべてのサイトデータと権限を表示」を開きます。
検索欄に対象サイトのドメインを入力します。
対象サイトの右にある削除アイコンを押し、削除を確認します。

ページを開ける状態なら、アドレスバー左のサイト情報アイコンから「Cookie とサイトデータ」へ進む方法もあります。

Microsoft Edge（パソコン）

右上の「設定など」から「設定」を開きます。
「Cookie とサイトのアクセス許可」を選びます。
「Cookie とサイトデータの管理と削除」を開きます。
「すべての Cookie とサイトデータを表示する」を選びます。
対象サイトを検索し、表示されたサイトデータだけを削除します。

Safari（Mac）

メニューバーの「Safari」から「設定」を開きます。
「プライバシー」を選びます。
「Webサイトデータを管理」を押します。
対象サイトを検索して選択し、「削除」を押します。
「完了」を押して、ページを開き直します。

iPhone・iPad（Safari）

「設定」アプリを開きます。
「アプリ」から「Safari」を選びます。
「詳細」から「Webサイトデータ」を開きます。
対象サイトを検索し、項目を左へスワイプして「削除」を押します。

古いiOSでは「設定」の一覧に「Safari」が直接表示される場合があります。「履歴とWebサイトデータを消去」は広範囲のデータを消す操作なので、対象サイトだけを消したいときは「詳細」の画面を使います。

Android（Chrome）

Chromeで対象サイトを開きます。
アドレスバー左のサイト情報アイコンを押します。
「Cookie とサイトデータ」を開きます。
削除アイコンを押し、対象サイトのデータを削除します。

表示が異なる場合は、Chromeの「設定」から「サイトの設定」、「すべてのサイト」の順に開き、対象サイトを選んで「データを削除してリセット」を実行します。

手順4：URLとブックマークを確認する

URLに余計な記号や空白が入っていないか確認します。コピーしたURLは末尾の句読点まで含んでいることがあります。公式トップページを検索して入り直し、サイト内のメニューから目的のページへ移動するほうが安全です。

古いブックマークには、期限切れのセッションIDや現在は使われていないパラメータが残る場合があります。トップページから開けたら、古いブックマークを削除して新しく登録し直してください。

全サイトのCookie削除は最後の手段

対象サイトだけの削除で直らず、複数サイトに同じ問題が出る場合に限って、ブラウザ全体のCookie削除を検討します。実行すると多くのサイトからログアウトし、カートの内容や一部の設定も失われる可能性があります。再ログインできることを先に確認してください。

2. 特定のサイトだけ400が出る理由

Cookieはサイトごとに保存され、同じサイトへアクセスするたびに要求ヘッダとして送信されます。そのため、1サイトのCookieだけが破損・肥大化すると、ほかのサイトは正常なのに特定サイトだけ400になります。

症状	原因	対処
シークレットなら開ける	Cookieの破損・肥大化	該当サイトのCookieだけ削除
ログイン後だけ400になる	古いセッション情報	サイトデータを削除して再ログイン
ブックマークからだけ失敗	古いURL・期限切れパラメータ	トップページから移動して再登録
別端末でも同じサイトだけ失敗	サイト側の設定・障害	時間を置くか運営へ問い合わせ

3. 400 Bad Requestの意味

400は4xx系、つまりクライアント側の要求に関係するステータスコードです。要求の構文不正、Cookieを含むヘッダの過大、不正なパラメータ、API本文の形式違いなどで返されます。ただし原因がサーバー実装やプロキシ設定にある場合もあり、表示だけで利用者の責任とは断定できません。

The status describes the request outcome, not who is to blame. A proxy limit or server-side parser can also produce a 400 response.

コード	意味	典型例
400	要求を解釈・処理できない	不正なJSON、壊れたCookie
401	有効な認証情報がない	未ログイン、期限切れトークン
403	要求を理解したが拒否	認証済みだが権限不足
404	対象が見つからない	URLに対応するページがない

認証・認可との違いは401と403の使い分けガイドで詳しく解説しています。

4. 開発者向け：400の原因一覧

原因	確認ポイント	対処
不正なJSON	括弧、カンマ、Content-Type	送信前にJSONとして検証
Cookie・ヘッダ過大	Cookie、JWT、プロキシ上限	不要なCookie削除と設計見直し
URLエンコード漏れ	空白、記号、日本語	URL APIでクエリを構築
Content-Length不整合	本文のバイト数と宣言値	HTTPライブラリに計算を任せる
バリデーション失敗	必須項目、型、範囲	フィールド別の理由を返す

nginxでCookieやヘッダが大きすぎる場合

nginxでは要求ヘッダの読み取りに使うバッファを large_client_header_buffers で設定できます。Cookieや長いURLが上限を超えると、アプリケーションへ渡す前に400を返す場合があります。まずアクセスログとエラーログを確認し、どのヘッダが増えたかを特定してください。

上限を大きくするだけでは、Cookieが増え続ける設計や巨大な認証トークンを温存します。不要なCookieの廃止や、セッション情報をサーバー側へ置く設計を先に検討します。設定変更時は公式ドキュメントと現在のnginxの版を照合してください。

HTTPには、要求ヘッダが大きすぎることを明示する 431 Request Header Fields Too Large もあります。自分で制御できるAPIなら431のほうが原因を伝えやすい一方、手前のプロキシが400へ変換することもあります。

5. API設計での400 Bad Request

APIが400を返すときは、クライアントが次の要求を修正できる情報を含めます。エラーコードだけでなく、問題のあるフィールド名と理由を安定した形式で返すと、画面表示、ログ分析、テストが容易になります。

{
  "error": {
    "code": "invalid_request",
    "message": "Request validation failed",
    "fields": [
      { "name": "email", "reason": "must be a valid email address" },
      { "name": "quantity", "reason": "must be between 1 and 99" }
    ]
  }
}

利用者が入力した値をそのままエラーメッセージへ埋め込まず、ログにも必要以上に残さないようにします。パスワード、トークン、Cookie、個人情報はエラーレスポンスへ含めません。

400と422の使い分け

JSONの構文が壊れていて本文を読めない場合を400、JSONとしては読めるものの意味上の検証に失敗した場合を 422 Unprocessable Content とすると区別が明確です。

すべての入力エラーを400に統一する既存APIもあります。最重要なのはAPI全体の一貫性と、クライアントが機械的に判定できるエラーコードです。途中から方針を変える場合は互換性とAPI仕様書も更新します。

6. アンチパターン

すべての検証エラーを理由なしの400にする

本文が空でも型が違っても業務ルール違反でも、単に400だけを返すとクライアント開発者は推測するしかありません。少なくとも安定したエラーコード、対象フィールド、修正可能な理由を返します。

内部情報を詳しく出しすぎる

データベース名、SQL、ファイルパス、スタックトレース、内部サービス名を含めると、攻撃者に構成を推測される恐れがあります。利用者には安全で具体的な理由を返し、詳細はアクセス制御されたサーバーログへ記録します。

7. よくある質問 / FAQ

Cookieを削除すると、保存したパスワードも消えますか？

通常、Cookieとブラウザのパスワード管理は別です。ただし対象サイトからはログアウトします。削除前にログイン情報と二要素認証の方法を確認してください。

特定サイトだけ400なら、サイト側の障害ですか？

必ずしもそうではありません。シークレットウィンドウで開けるなら、そのサイトのCookieが原因の可能性が高いです。別端末や別回線でも失敗するならサイト側の障害も疑います。

Cookie削除でも直らない場合はどうすればよいですか？

URLとブックマークを確認し、公式トップページから入り直します。それでも直らなければ、発生時刻、ページURL、追跡IDを控えて運営へ問い合わせてください。パスワードやCookieの値は送らないでください。

8. English summary

400 Bad Request means the server could not process the request as sent. Visitors should reload once, test the page in a private window, remove data for the affected site only, and check the URL or an old bookmark. Clearing all cookies should be a last resort because it signs you out of other sites. Developers should inspect malformed JSON, URL encoding, header and cookie size, Content-Length, and validation failures. Use 422 consistently when valid syntax fails semantic validation, and never expose secrets or internal stack traces.

よくある質問 / FAQ

Cookie削除でなぜ直る？: ブラウザが送るCookieの破損、古いセッション情報、Cookie全体の肥大化が解消されるためです。まずシークレットウィンドウで確認し、直る場合は該当サイトのCookieだけを削除してください。
特定のサイトだけ400が出るのはなぜ？: そのサイト専用のCookieやセッション情報が破損・肥大化しているか、古いURLを開いている可能性があります。該当サイトのCookie削除と、公式トップページからの再アクセスを試してください。
スマホ(iPhone/Android)での解決方法は？: 再読み込み、プライベートブラウズまたはシークレットタブでの確認、該当サイトのWebサイトデータ削除、URLやブックマークの確認の順で試します。全サイトのデータ削除はログイン情報も消えるため最後の手段です。
What does 400 Bad Request mean?: HTTP 400 means the server cannot or will not process a request because the request appears malformed, invalid, or too large. Check the URL and site data as a user, or inspect the request syntax, headers, and validation errors as a developer.
400と422はどう使い分ける？: JSONの構文不正など要求自体を解析できない場合は400、構文は正しいものの値が業務ルールや検証条件を満たさない場合は422とする設計が明確です。ただしAPI全体で一貫した規約を優先してください。
400と401・403の違いは？: 400は要求の形式や内容に問題がある状態、401は有効な認証情報がない状態、403は要求を理解したうえでアクセスを拒否する状態です。