ステータスコード204とは？意味や使い方は？（No Content：レスポンス：意味など）

ステータスコード204とは？意味や使い方は？（No Content：レスポンス：意味など）

WebサイトやAPIの開発、ブラウザの通信確認をしていると、HTTPステータスコード204という表示を見かけることがあります。

エラーのように見えて不安になるかもしれませんが、204は多くの場合、処理が適切に完了したことを伝える正常なステータスコードです。

ただし、画面に何も表示されない理由や、200との使い分け、キャッシュとの関係まで理解していないと、実装時や障害調査時に判断を誤るおそれがあります。

この記事では、No Contentの意味、HTTPレスポンスの構造、APIでの具体的な使い方、注意点を初心者にも分かりやすく解説します。

ステータスコード204の意味と基本的な役割

それではまず、ステータスコード204の意味と基本的な役割について解説していきます。

204 No Contentの定義

HTTPステータスコード204は、リクエストの処理が成功した一方で、クライアントへ返す本文がないことを示す成功レスポンスです。

正式な名称はNo Contentであり、直訳するとコンテンツなしという意味になります。

ここでいうコンテンツとは、HTML、JSON、画像、テキストなど、レスポンスボディに含まれるデータを指します。

サーバーが何も処理していない、あるいは通信が失敗したという意味ではありません。

むしろ、削除や更新などの指示をサーバーが受け取り、必要な処理を終えたことを簡潔に知らせる用途で使われます。

HTTPではステータスコードの先頭が2である場合、基本的にはリクエスト成功を表します。

204も200や201と同じ2xx系に分類されるため、通信結果としては正常と判断できます。

ブラウザの開発者ツールでは、Networkタブに204と表示され、Response欄が空になっていることがあります。

この状態は、サーバーが意図どおりに空のレスポンスを返した結果である可能性が高いでしょう。

ただし、期待していたJSONが返らない場面では、フロントエンド側の仕様とバックエンド側の実装に食い違いがないか確認することが大切です。

レスポンスボディを持たない仕組み

HTTPレスポンスは、ステータスライン、ヘッダー、ボディという要素で構成されます。

204ではヘッダーを返せますが、レスポンスボディを含めることはできません。

たとえば削除APIに対してDELETEリクエストを送信し、対象データが正常に削除された場合、サーバーは204を返すことがあります。

利用者に返すべき追加情報がなければ、JSONを組み立てずに通信を完了できるためです。

要素	204の扱い	確認時のポイント
ステータスコード	204	成功の2xx系に属するか確認します
ステータス文言	No Content	本文なしを示す補足です
レスポンスヘッダー	送信可能	Cache ControlやETagなどを設定できます
レスポンスボディ	送信しない	JSONやHTMLを含めないことが原則です
Content Length	通常は不要	本文を送る前提の値を設定しないよう注意します

204のレスポンスに本文を付けないというルールは、単なる慣習ではありません。

クライアントが本文なしとして処理する前提を持つため、サーバー側でJSONなどを出力すると、環境によって予期しない挙動につながる場合があります。

特にフレームワークの設定で自動的にメッセージを付与していないか、実装を確認しておくと安心です。

利用者の画面に起こる変化

204を受け取ったブラウザは、一般に現在の表示ページをそのまま維持します。

200で空のHTMLを返した場合とは異なり、通常はページ内容を空の画面に置き換えません。

フォームの自動保存、通知設定の更新、いいねボタンの状態変更など、ページ遷移が不要な操作と相性がよい理由です。

JavaScriptからfetchを利用する場合、レスポンス自体は成功として扱えます。

一方で、response.jsonをそのまま実行すると、本文が存在しないため解析エラーになることがあります。

画面に変化がないため、ユーザーには処理が実行されたのか伝わりにくい場合もあります。

保存完了のトースト通知、ボタンの文言変更、更新日時の表示といったUIを用意すると、操作の結果を理解しやすくなるでしょう。

HTTPの成功と、利用者にとって分かりやすい体験は別の観点です。

200や201や202との使い分け

続いては、200や201や202との使い分けを確認していきます。

200 OKとの違い

200 OKは、リクエストが成功し、通常は何らかのレスポンス本文を返すときに使用されます。

検索結果のJSON、取得したユーザー情報、表示用のHTMLなどを返すAPIでは200がよく選ばれます。

対して204は、成功したことだけを返せば十分で、本文が不要なときの選択肢です。

たとえば設定値を更新したあとに、更新後の設定情報を返すなら200が自然です。

更新が完了した事実だけでよいなら、204を返す設計が簡潔になります。

どちらが絶対に正しいという話ではなく、クライアントが次に必要とする情報から選ぶことが重要です。

ステータスコード	主な意味	本文	代表的な利用場面
200 OK	処理成功	必要に応じて返します	データ取得、更新後の情報返却
201 Created	新しいリソースの作成成功	作成結果を返すことがあります	会員登録、投稿作成、注文作成
202 Accepted	受付完了、処理は継続中	進捗情報を返すことがあります	動画変換、大量データ処理
204 No Content	処理成功、本文なし	返しません	削除、単純な更新、状態変更

API設計書には、成功時に何を返すのかを明記しておくことが欠かせません。

ステータスだけを見る実装と、JSONを必ず受け取る実装が混在すると、保守時に不具合を生みやすくなります。

201 Createdとの違い

201 Createdは、新規リソースが作成されたことを示すステータスコードです。

POSTリクエストによって新しい商品、記事、ユーザー、予約情報などを作成した場面で用いられます。

作成先を示すLocationヘッダーを付けたり、生成されたIDを本文のJSONで返したりするケースもあります。

新規作成後に返す情報が不要という事情はあり得ますが、作成操作では利用者やクライアントがIDを必要とすることも少なくありません。

そのため、作成の成功を表すなら201、すでにあるリソースの削除や結果不要の更新なら204という整理が分かりやすいでしょう。

リソースの新規作成か、既存状態の変更かを判断軸にすると選びやすくなります。

202 Acceptedとの違い

202 Acceptedは、サーバーがリクエストを受け付けたものの、処理がまだ完了していないことを示します。

すぐに終わらない非同期処理で使われる点が、完了済みを表す204との大きな違いです。

たとえば数万件のCSVを取り込む処理、メールを一括送信する処理、AIによる画像生成の依頼などは、受付直後に最終結果を返せないことがあります。

このような場合に204を返すと、クライアントは処理が完全に終わったと誤解するかもしれません。

202を返し、進捗確認用のURLやジョブIDを示すほうが、状態を正確に伝えられます。

成功コードはすべて同じではなく、処理がいつ完了したかまで表現する点がHTTP設計の要点です。

APIにおける204の実装場面

続いては、APIにおける204の実装場面を確認していきます。

DELETEリクエストでの活用

204が最もよく使われる場面の一つが、DELETEリクエストによる削除です。

たとえば削除対象の商品IDが存在し、データベースから正常に削除できたなら、本文を返さず204で終了できます。

削除後に一覧画面へ戻る、画面上から対象行を消すといった処理は、フロントエンド側で実行可能です。

削除結果の詳細や更新後の一覧を返したい場合には200を使う設計もあります。

重要なのは、利用するAPI全体で考え方を揃えることです。

一部の削除APIだけが200で空JSONを返し、別のAPIが204を返す状態では、呼び出す側が余計な分岐を抱えます。

また、すでに削除済みのリソースに対するDELETEをどう扱うかは、APIの方針によって異なります。

冪等性を重視し、最終的に削除済みであれば204を返す設計もあります。

一方で存在しないリソースとして404を返す設計もあるため、仕様書とクライアント側の期待値を一致させましょう。

PUTとPATCHによる更新

PUTやPATCHは、既存リソースの更新に使われるHTTPメソッドです。

プロフィールの表示名、通知設定、公開状態、並び順などを変更し、更新後のデータを返す必要がなければ204が候補になります。

通信量を抑えられる点はメリットですが、節約できるデータ量が小さい場合もあります。

更新後の値をサーバー側で補正する仕組みがあるなら、200で最新データを返すほうが実装しやすい場合もあるでしょう。

たとえば入力された日時をサーバーのタイムゾーンで変換する、表示名の前後空白を削除する、権限により設定可能な値を制限するといった処理です。

こうした場合、クライアントはサーバー確定後の状態を受け取る必要があります。

反対に、単純なフラグ更新なら204による軽量な応答が扱いやすくなります。

OPTIONSとCORS周辺の扱い

204は、OPTIONSリクエストへの応答で見かけることもあります。

OPTIONSは、対象URLで利用できるHTTPメソッドや、クロスオリジン通信に関する条件を確認するために使われます。

ブラウザが送るCORSのプリフライトリクエストに対し、サーバーが必要なAccess Control Allow OriginやAccess Control Allow Methodsなどのヘッダーを返し、204で応答する構成です。

この場合も、本文を返す必要は通常ありません。

開発者ツールでOPTIONSが204になっているなら、CORS設定が正常に通過している可能性があります。

ただし、そのあとに送られる本来のGETやPOSTが失敗していないかは別途確認が必要です。

204だけを見て通信全体が成功したと判断せず、リクエストの流れを追うことが大切でしょう。

レスポンスヘッダーとキャッシュの注意点

続いては、レスポンスヘッダーとキャッシュの注意点を確認していきます。

キャッシュ可能性の考え方

204は本文を持ちませんが、キャッシュに関する扱いを意識する必要があります。

HTTPキャッシュでは、レスポンスのヘッダー情報や仕様に基づいて、ブラウザや中継サーバーが応答を再利用する場合があります。

単に本文がないからといって、キャッシュの影響を受けないわけではありません。

状態変更後に古い情報を表示させたくない画面では、Cache Controlの設定を検討しましょう。

特にユーザーごとに異なる設定情報、認証に関わる応答、管理画面の操作結果では、意図しない共有キャッシュを避けることが重要です。

204でもヘッダー設計は必要という点を忘れないようにしてください。

ヘッダー	主な役割	204での考え方
Cache Control	キャッシュの可否や期間を指定	更新結果を再利用させたくない場合に設定します
ETag	リソースのバージョン識別	更新後の状態識別に利用できる場合があります
Location	関連するURLを示す	新規作成では201と組み合わせることが一般的です
Allow	許可するHTTPメソッドを示す	OPTIONS応答で利用されることがあります
Access Control Allow Origin	CORSの許可元を示す	プリフライト応答で重要になります

キャッシュの設定は、性能と鮮度のバランスを取る作業です。

すべてを無効にすると安全に見えますが、必要以上に通信が増える可能性もあります。

反対に長期間のキャッシュを許可すると、更新直後の表示に古い状態が残るかもしれません。

Content TypeとContent Lengthの確認

204ではレスポンスボディがないため、通常はContent Typeを指定する意味もほとんどありません。

JSONを返さないにもかかわらずapplication/jsonを付けると、呼び出し側がJSONを期待する原因になり得ます。

フレームワークが自動付与する場合もあるため、実際のHTTPレスポンスを確認しておくとよいでしょう。

Content Lengthについても同様で、本文のサイズを表すヘッダーを不適切に設定しないことが必要です。

204は空文字列を返すこととは異なります。

空のJSONオブジェクトや空の配列を返すなら、それは本文を含む200レスポンスとして設計するほうが意味が明確になります。

本文なしと空データは別物として扱う姿勢が、APIの理解をそろえる助けになります。

リダイレクトやCookieとの関係

204はリダイレクトを指示するステータスコードではありません。

別ページへ移動させたい場合には、301、302、303、307、308などの用途を検討します。

フォーム送信後に画面を更新したいのに204を返すと、期待した画面遷移が起こらず、利用者が戸惑うことがあります。

一方で、レスポンスヘッダーにSet Cookieを付けてCookieを更新することは可能です。

たとえば設定変更に伴ってセッション情報を更新するケースでは、本文なしでヘッダーだけを返す構成も考えられます。

ただし認証やCookieはセキュリティに直結するため、Secure、HttpOnly、SameSiteなどの属性も併せて確認しましょう。

204という成功コードだけで安全性が保証されるわけではありません。

フロントエンドとバックエンドの対応方法

続いては、フロントエンドとバックエンドの対応方法を確認していきます。

JavaScriptでの受信処理

JavaScriptでAPIを呼び出すときは、204を明示的に扱う分岐を入れるとトラブルを防ぎやすくなります。

fetchはネットワークレベルの失敗ではない限りPromiseを返しますが、HTTPエラーかどうか、本文があるかどうかはアプリケーション側で確認します。

response.okは2xx系で真になるため、204でも成功と判定されます。

その後にJSONを読み込む処理を無条件で実行すると、空の本文を解析しようとして問題になることがあります。

AxiosなどのHTTPクライアントでも、レスポンスデータが空になる点は同じです。

成功時の共通処理でdataの存在を前提にしていないか、型定義や例外処理を見直すとよいでしょう。

TypeScriptを使う場合は、レスポンスがvoidになるエンドポイントを明確にし、返却データありのAPIと区別すると保守性が上がります。

204専用の成功パターンをチームで共有することも有効です。

サーバーサイド実装の確認

バックエンドでは、処理成功後に204を返すだけでなく、出力が混ざらないことを確認する必要があります。

PHP、Node.js、Python、Java、Rubyなど、どの言語でもデバッグ出力や例外メッセージが紛れ込むと、204の前提が崩れることがあります。

HTTPヘッダーを送信したあとに不要な本文を出力していないか、ミドルウェアが共通JSONを追加していないかを確認しましょう。

REST APIのルーティングでは、削除や更新のエンドポイントごとに、成功時と失敗時のステータスコードを定義します。

認証失敗なら401、権限不足なら403、対象なしなら404、入力不備なら400や422といったように、状況を区別する設計が必要です。

204はあくまで処理成功かつ返却本文不要という条件に当てはまる場合に使用します。

テストとログの確認方法

204を実装したら、ブラウザの開発者ツール、curl、APIテストツール、サーバーログなどで実際の応答を確認します。

確認時には、ステータスコードが204になっていること、ボディが送られていないこと、必要なヘッダーが付いていることを見ます。

フロントエンドでは、成功後の画面状態が想定どおり変化するかも重要です。

削除ボタンを押したのに項目が残る、保存後に古い値が表示される、成功通知が出ないといった問題は、HTTP通信自体が成功していても起こり得ます。

自動テストでは、statusが204であることに加え、レスポンスボディが空であることを検証するとよいでしょう。

契約テストを導入している場合は、API仕様書に204と本文なしの条件を記載し、クライアントとサーバーの認識差を抑えられます。

204で発生しやすいトラブルと対処法

続いては、204で発生しやすいトラブルと対処法を確認していきます。

JSON解析エラーの原因

204に関する代表的なトラブルは、クライアントが空のレスポンスをJSONとして解析しようとすることです。

エラー文にはUnexpected end of JSON inputなどが表示される場合があります。

これはサーバーの処理失敗ではなく、本文がない204に対してjson処理を実行したことが原因であるケースが多いでしょう。

対処としては、ステータスコードを判定して204では本文解析を行わないようにします。

あるいは、クライアントが常にJSONを必要とする設計なら、サーバー側を200とJSONレスポンスへ変更する方法もあります。

どちらを選ぶかは、エンドポイントの役割とプロジェクトのAPI方針で決めるとよいでしょう。

仕様と実装の前提をそろえることが根本的な解決につながります。

画面が更新されない問題

204を返したあとに画面が更新されないという相談もよくあります。

これは204がブラウザに新しいページ内容を表示させる応答ではないことから起こります。

フォーム送信後に一覧を更新したい場合、JavaScriptで再取得する、画面上のデータを更新する、リダイレクトを返すといった処理が別途必要です。

従来のフォーム送信では、成功後に画面遷移させるため303 See Otherを活用する設計もあります。

非同期通信では、204を受け取った後にUIを更新する処理を実装する方法が一般的です。

通信ログだけではなく、ユーザーが何を見て次に何を操作するのかまで考えると、適切な応答を選びやすくなります。

意図しない204と障害調査

本来はデータを返すはずのAPIが204になる場合、ルーティング、条件分岐、データ取得処理、例外処理を順に確認します。

データが存在しないときに204を返す実装もありますが、検索結果が空であることを表すなら、空配列を本文に含めた200のほうが分かりやすいことがあります。

たとえば商品検索で該当件数が0件の場合、クライアントは検索自体の成功と結果0件を区別したいはずです。

そのため、200と空配列を返す設計がよく採用されます。

204が返る条件をログに記録し、リクエストURL、HTTPメソッド、認証ユーザー、処理件数、分岐条件を確認すると調査が進みます。

ただし個人情報や認証トークンをログに残さないよう、情報の取り扱いには十分注意してください。

ステータスコード204のまとめ

最後に、ステータスコード204の要点をまとめます。

204 No Contentは、HTTPリクエストが正常に完了し、レスポンスボディを返す必要がないことを示す成功ステータスコードです。

DELETEによる削除、PUTやPATCHによる単純な更新、OPTIONSやCORSのプリフライト応答などで活用されます。

200は本文を返す成功、201は新規作成、202は処理受付後の継続中、204は成功済みで本文なしという違いを押さえると、APIの設計意図を理解しやすくなります。

実装では、204にJSONやHTMLを付けず、フロントエンドで無条件にJSON解析しないことが重要です。

また、画面を更新したい場合は、204だけでは表示が変わらないため、UI更新や再取得の処理を用意する必要があります。

成功の意味と返す情報の有無を分けて考えれば、204を適切な場面で使えるようになるでしょう。