HTTPステータスコード一覧：応答の分類とアプリケーションの成功

執筆：Ai Flowi · 公開日

HTTPステータスコードの一覧にある各コードは、HTTPリクエストがどう処理されたかを示す3桁の応答値です。最初の桁は応答の大まかな分類を示し、個々のコードがより具体的な意味を伝えます。アプリケーションでの成功を判断するには、想定した本文、意図した処理結果、応答で公開される情報を別途確認する必要があります。

呼び出し側が200を受け取っても、返されたレコードが違ったり、データの集合が不完全だったり、非公開フィールドが含まれていたりすることがあります。逆に、エラー応答がリクエストの拒否を正しく説明していても、呼び出し側に見せてはいけない詳細を公開している場合があります。コードは、エンドポイントの仕様を確認するための根拠の1つとして扱います。

まず応答の分類を確認する

分類は、次に何を確認すべきかを判断する助けになります。個々のコードの意味、リクエストメソッド、APIの文書化された応答スキーマを置き換えるものではありません。この記事は読み解くためのガイドであり、すべてのステータスコードを網羅した一覧ではありません。

HTTP応答の5つの大分類
分類一般的な意味呼び出し側が確認すること
1xx：情報リクエスト処理に関する途中経過の情報です。最終応答は届いていますか。
2xx：成功HTTPのレベルでは、リクエストを正常に受信し、理解して受け入れました。この応答だけで、アプリケーションの処理結果を確認できますか。
3xx：リダイレクトリクエストを完了するには追加の対応が必要です。キャッシュに関する処理も含みます。リダイレクト先や、使用すべきキャッシュ済みの表現はありますか。
4xx：クライアントエラー送信された状態のままでは、リクエストを実行できません。リクエスト、認証情報、状態のうち、どの条件に対応が必要ですか。
5xx：サーバーエラーサーバーが、一見有効なリクエストを実行できませんでした。何が失敗し、操作の最終的な結果は判明していますか。

応答がない場合、観測されたHTTPステータスはありません。接続失敗や呼び出し側のタイムアウトは、架空の500を割り当てず、「結果不明」の記録として残します。書き込みがすでに宛先に届いた可能性がある場合、再試行の前にこの不確実性を考慮する必要があります。

代表的なAPI応答コードを区別する

200 OKはHTTPの処理が成功したことを示しますが、本文の意味は操作によって異なります。202 Acceptedは処理を受け付けたことを示し、処理の完了までは示しません。204 No Contentは応答内容を伴わない正常な処理を表します。この応答にJSON本文を要求するのは、確認方法が誤っています。

304 Not Modifiedは、条件付きリクエストと既存の表現の利用に関するものです。データ集合の新しいペイロードではありません。リダイレクト応答も慎重に読み解く必要があります。元の宛先からの応答と、リダイレクトに従った後の応答は、別々の観測結果です。

400は不正なリクエスト、401は認証、403は拒否に関するコードです。複数の段階を持つアプリケーションでは、404だけで内部のどのリソースが見つからなかったかは分かりません。429はリクエストが多すぎることを意味します。サーバー側の例としては、内部エラーの500や、上流からの不正な応答を示す502があります。いずれも、先に試みた書き込みが何も変更しなかったことを示すものではありません。

本文が誤っている架空の200応答では何が起こりますか？

架空の読み取りエンドポイントが、要求した項目について、公開フィールドをitem_idとstateの2つだけ返すと定めているとします。リクエストの対象はsample-Aです。仕様では、完了した結果は同じ項目を識別し、合意した状態値を使う必要があるとされています。

{"http_status":200,"content_type":"application/json","body":{"item_id":"sample-B","state":"ready"}}

これは解釈を練習するために作った観測例であり、記録されたエンドポイントの応答ではありません。HTTPとコンテンツタイプの確認は問題なさそうですが、識別子が違います。呼び出し側はsample-Bをsample-Aに関する根拠として表示せず、アプリケーションの結果を拒否する必要があります。

1つの成功表示にまとめず、応答の根拠を分ける
架空の観測例HTTPの分類本文の判定処理結果の根拠情報公開の判定
sample-Aの読み取りでsample-Bを返す200：成功の分類要求した項目との一致に失敗書き込みは不要この例では余分なフィールドなし
書き込みが「記録済み」と返すが、宛先に一致するレコードがない200：成功の分類提案された応答の構造に一致この例の即時反映の前提では、完全な読み戻しによる確認に失敗漏えいは示されていない
ジョブの送信でジョブ参照を返す202：受け付け済み送信の仕様に一致完了はまだ確認できない公開を許可されたフィールドを確認
拒否されたリクエストの応答に、非公開の内部参照が含まれる4xx：クライアントエラーの分類拒否を正しく説明している可能性がある書き込みを試みた場合は別途確認公開応答の仕様に違反

書き込みでは、宛先の読み取りによって、いつ、どのように処理結果を確認できるかを仕様で定める必要があります。不完全な読み取り、反映の遅延、異なる宛先の読み取りでは、書き込みが行われていないとは判断できません。「本文が正しい」と「処理結果を確認済み」は別々の結論として保持します。

提示されたSheet JSON APIテストが実際に示すこと

ステータス：テスト済み。SheetをJSON APIとして使う手順には、AI Flowi Workflow 1.9.2で2026年10月9日にテストし、26件中25件が合格したと記録されています。これは読み取り専用のGoogle Sheetエンドポイントであり、APIの信頼性全般のベンチマークではありません。

想定どおりの404応答に含まれていた非公開識別子の漏えいについては、その手順のT20の記録を確認してください。プラットフォームでの失敗の範囲については、Webhookのエラー処理をご覧ください。コードの解釈から得られる教訓は、エンドポイントの承認より限定的です。正しく分類された拒否であっても、情報公開の判定が必要です。

したがって、上の架空の表の拒否されたリクエストには、拒否がリクエスト仕様に一致したか、返されたフィールドが許可されていたかという2つの所見が必要です。前者の合格で、後者の不合格を取り消すことはできません。想定したステータスを示す1つの成功表示にまとめず、両方の所見を記録します。

AI Flowi Workflowにおけるステータス解釈の位置付け

ステータス：文書化済み。外部へのリクエストを行うコンポーネントの仕様は、API Requestリファレンスに記載されています。このインターフェースは、カタログに記載されていますが、Ai Flowiによる本番環境でのテストは行われていません。

HTTPの判定を記録する際は、どの応答に対する判定かを特定します。ゲートウェイでの拒否、元のエンドポイントのリダイレクト、リダイレクト後の宛先の応答は別々のイベントです。呼び出し側が最終的な200を観測しても、同じ要求項目に関するイベントだからという理由で、その値を先の拒否に結び付けてはいけません。

sample-Aの演習では、要求した項目を、観測されたコードと本文の判定とともに保持します。後の応答がsample-Aを正しく示していた場合も、先のsample-Bとの不一致は失敗した観測結果として残し、後の応答を独立して評価します。これにより、最終的に正しい結果が得られたことで、すでに呼び出し側に渡された誤った応答が隠れるのを防げます。

よくある解釈の誤り

  • ジョブを受け付けただけの段階でも、すべての2xx応答を「業務処理完了」と呼ぶこと。
  • JSONの構文だけを確認し、要求した識別子、許可されたフィールド、完全性を見落とすこと。
  • ワークフロー内部の404を、公開エンドポイントのアドレスが存在しない証拠として扱うこと。
  • 想定したステータスコードだからという理由で、エラーの詳細をそのまま表示すること。
  • 成功応答が届かなかったという理由だけで、結果が不明な書き込みを繰り返すこと。

応答と処理結果を検証する、実際に実行できる手順については、APIテストをご覧ください。関連用語として、クォータの解釈はAPIレート制限を、データ集合の応答の完全性を確認する方法はAPIページネーションをご覧ください。