導入：なぜResponse.prototype.statusが重要なのか
フロントエンド開発において、Fetch APIを用いたデータ取得は日常的なタスクです。しかし、「通信が成功した（＝ネットワークエラーが発生しなかった）」ことと、「APIが期待するデータを返した（＝200 OKだった）」ことは別物です。多くの初心者が陥る罠として、404や500エラーが発生しても、Fetch APIはPromiseが解決（resolve）されるため、エラーハンドリングをスルーしてしまうという点があります。この課題を解決し、堅牢な通信処理を実装するために、Response.prototype.statusの理解は不可欠です。
基礎知識：Response.prototype.statusとは
Fetch APIでリクエストを送信すると、戻り値としてResponseオブジェクトが返されます。このオブジェクトのstatusプロパティは、サーバーから返されたHTTPステータスコード（数値）を保持しています。
HTTPステータスコードは大きく分けて「1xx（情報）」「2xx（成功）」「3xx（リダイレクト）」「4xx（クライアントエラー）」「5xx（サーバーエラー）」に分類されます。Fetch APIは、ネットワークが遮断された場合を除き、サーバーがエラーコードを返してもPromiseを拒否（reject）しません。そのため、開発者が明示的にstatusを確認する必要があります。
実装/解決策：ステータスコードを判定するベストプラクティス
Responseオブジェクトには、statusを確認するためのプロパティ以外に、okプロパティという便利な機能も備わっています。これはstatusが200から299の範囲内であればtrueを返すブール値です。現場の実務では、まずokプロパティで成否を判定し、詳細なエラー分岐が必要な場合にstatusプロパティを参照するのが最も効率的です。
サンプルプログラム：実用的なエラーハンドリング実装
以下は、statusを確認して適切に例外をスローする、実務でそのまま使える実装例です。
async function fetchData(url) {
try {
const response = await fetch(url);
// 1. okプロパティで200番台かどうかを判定
if (!response.ok) {
// 2. statusプロパティを使ってエラーの種類に応じた処理を分岐
if (response.status === 404) {
throw new Error('指定されたリソースが見つかりません (404)');
} else if (response.status >= 500) {
throw new Error('サーバー側でエラーが発生しました (5xx)');
} else {
throw new Error(`通信エラー: ${response.status}`);
}
}
// 成功した場合、JSONとして解析
const data = await response.json();
return data;
} catch (error) {
// ネットワークエラーや上記でスローされたエラーをここで補足
console.error('API呼び出し失敗:', error.message);
}
}
応用・注意点：現場で陥りやすいバグの回避策
実務で注意すべき点は、「常にJSONが返ってくるとは限らない」ということです。サーバーが500エラーを返した際、HTML形式のエラーページが返されることがあります。この状態でresponse.json()を呼び出すと、パースエラー（SyntaxError）が発生し、本来のステータスコードに関するエラー情報が隠蔽されてしまいます。
必ずresponse.okを確認してからレスポンスのボディを読み込むようにし、また、APIの仕様に応じて、エラー時にサーバーが返してくるJSON形式のメッセージも考慮するようにしてください。statusコードを適切にハンドリングすることで、デバッグの質が飛躍的に向上します。