ステータスコード確認を一言でいうと
fetch で API を叩くときの「ステータスコード確認」は、
「サーバーが今どんな気持ちで返事してきているか」をちゃんと見ること です。
- 200「OK、うまくいったよ」
- 404「そのページ(データ)は見つからないよ」
- 401「あなたはまだログインしていないよ」
- 500「サーバー側でトラブルが起きてるよ」
こういった「HTTP ステータスコード」を見ないまま response.json() だけしようとすると、
「エラーなのに成功扱い」「原因が分からない」といった地獄にハマります。
ここが重要です。
fetch は“HTTP エラーでも”基本的にエラーを投げません。
だからこそ、response.status や response.ok を自分でチェックすることが、非同期通信ではほぼ必須スキルになります。
fetch とステータスコードの基本関係
fetch は「通信の成功」だけ見ている
まず大前提として、fetch 自体が見ているのは、「HTTP リクエストがサーバーに届いて、レスポンスが返ってきたかどうか」 です。
const response = await fetch("https://example.com/api/users");
JavaScriptこの await fetch(...) が reject(throw)されるのは、主にこんなときです。
- ネットワークが切れていてサーバーに届かない
- CORS 制限などでブラウザがブロックした
- URL が完全におかしい(プロトコル不正など)
逆に言うと、
- 404 Not Found
- 500 Internal Server Error
でも、「サーバーから何かしらレスポンスは返ってきている」ので、
fetch 的には「ひとまず成功」として response を返してしまいます。
つまり、
const response = await fetch(...);
// ここまでは 404 でも 500 でも普通に通る
JavaScriptのです。
ステータスコードは response.status と response.ok で見る
response オブジェクトには、ステータスを見るためのプロパティが用意されています。
console.log(response.status); // 200, 404, 500 などの数字
console.log(response.ok); // 200〜299 のとき true、それ以外 false
JavaScriptstatusは素の数字okは「成功系(200番台)かどうか」を true/false で簡易的に教えてくれます
ここが重要です。
fetch の「成功/失敗」と、HTTP 的な「成功/失敗」は別物です。
fetch が成功しても、サーバーが失敗していることは普通にあります。
だからこそ、response.status / response.ok を必ず自分で確認する必要があります。
一番基本のパターン:ステータスコード確認付きの GET
最低限これは書きたい標準形
async function loadUsers() {
try {
const response = await fetch("https://example.com/api/users");
if (!response.ok) {
console.error("HTTPエラー:", response.status);
return;
}
const data = await response.json();
console.log("ユーザー一覧:", data);
} catch (err) {
console.error("通信エラー:", err);
}
}
JavaScript動きと意味を順番に整理します。
const response = await fetch(...)
→ 通信自体は成功したか?(サーバーまで届いたか?)だけを見ている。
→ 404 や 500 でもここは通る。
if (!response.ok) { ... }
→ ステータスコードが 200〜299 以外なら「HTTP 的にはエラー」とみなす。
→ status をログなどに出して、早めに return する。
const data = await response.json();
→ ここに来るのは「HTTP 的にも成功した」と判断したときだけ。
→ JSON を安心してパースする。
catch (err)
→ ネットワーク断など、fetch 自体がエラーになったときに来る。
ここが重要です。
「通信に成功したか?」と「API が正常に処理できたか?」は別レイヤーの話。fetch は前者しか見ていないので、後者は status / ok を使って自分で見る、という役割分担を頭の中で分けてください。
HTTP ステータスコードのざっくり分類(よく使うものだけ)
大まかな分類
全て暗記する必要はありませんが、「ざっくり意味」と「よく見る代表」だけ」は押さえておくと楽になります。
200番台(成功)
- 200 OK … リクエスト成功。期待通り。
- 201 Created … 新規作成に成功(POST など)。
→ response.ok === true になる範囲。
→ 基本的にこのときだけ「成功扱い」にすることが多いです。
300番台(リダイレクト)
- 301 / 302 … 別の URL に移動した、など。
→ fetch では多くの場合ブラウザがよしなに追従してくれるので、
初心者のうちはあまり意識しなくてOK。
400番台(クライアント側のエラー)
- 400 Bad Request … リクエストがおかしい(パラメータ不正など)。
- 401 Unauthorized … 認証が必要(ログインしていない、トークン間違い)。
- 403 Forbidden … 権限が足りない(見てはいけないものを見ようとしている)。
- 404 Not Found … URL やリソースが見つからない。
→ 「フロント側のリクエストが悪い」ことが多いゾーン。
→ パラメータ間違い、ログイン漏れ、URL ミスなど、自分の書いたコードを疑う。
500番台(サーバー側のエラー)
- 500 Internal Server Error … サーバー内部のバグ的なもの。
- 503 Service Unavailable … サービス一時停止中、など。
→ サーバー側の問題なので、フロントからはどうしようもないことが多い。
→ ユーザーには「時間を置いて再度お試しください」などのメッセージを出す。
ここが重要です。
すべて覚える必要はありません。
まずは「200番台=成功」「400番台=こっち(クライアント)側の入力がおかしい」「500番台=サーバーでトラブル」が分かれば十分。
あとは必要に応じて 404 / 401 / 500 など、よく遭遇するコードだけ少しずつ意味を足していけばOKです。
ステータスコードごとに分岐したいときの書き方
例:ステータスによってメッセージを変える
例えば、ユーザー情報を取得する API で、ステータスごとに違うメッセージを出したいとします。
async function loadProfile() {
try {
const response = await fetch("https://example.com/api/profile");
if (response.status === 200) {
const data = await response.json();
console.log("プロフィール:", data);
return;
}
if (response.status === 401) {
console.log("ログインが必要です");
return;
}
if (response.status === 404) {
console.log("プロフィールが見つかりません");
return;
}
console.log("想定外のエラー:", response.status);
} catch (err) {
console.error("通信エラー:", err);
}
}
JavaScriptポイント:
- 「成功時(200)」だけ
response.json()している
→ エラー時は JSON でないこともあるので、むやみにjson()しないほうが安全な場合もある - 他のステータスごとに、人間に見せるメッセージを変えている
ここが重要です。response.ok で「成功かどうか」をざっくりチェックしつつ、
必要に応じて response.status で、「どの種類の失敗か」を細かく分ける。
ビジネスロジックとして意味のあるステータスだけ if で拾う、というスタイルが王道です。
例外を投げて catch に集約する書き方(おすすめパターン)
if で分岐しつつも、エラー処理は一箇所に集めたい
ステータスごとに分岐するのは良いのですが、
あちこちで console.log や UI 更新を書くと散らかりがちです。
少し整理された型はこうです。
async function loadUsers() {
try {
const response = await fetch("https://example.com/api/users");
if (!response.ok) {
// ステータスごとに例外メッセージを変える
if (response.status === 404) {
throw new Error("ユーザーが見つかりません (404)");
}
if (response.status === 401) {
throw new Error("認証が必要です (401)");
}
throw new Error("未知のエラー: " + response.status);
}
const data = await response.json();
console.log("ユーザー一覧:", data);
} catch (err) {
console.error("APIエラー:", err.message);
// ここで一括して「ユーザーにエラーを見せる」処理を書ける
}
}
JavaScript流れ:
!response.okで「成功かどうか」を判断- 失敗なら、
statusを見て 「意味のある Error オブジェクト」を投げる - 例外はすべて
catchに集まる catchの中で、エラーメッセージを UI に表示するなどの処理を一括で書ける
ここが重要です。
ステータスコードを見て「なぜ失敗したのか」を人間に分かる形(Error オブジェクトのメッセージ)に変換し、
実際のエラー表示は catch で一箇所にまとめる。
この形を覚えておくと、「処理の流れ」と「エラー対応」を綺麗に分離しやすくなります。
初心者として「ステータスコード確認」で本当に押さえてほしいこと
fetch がエラーを投げるのは「通信そのものに失敗したとき」であって、
HTTP ステータスが 404 や 500 のときでも普通に response は返ってくる。
HTTP 的な成功かどうかは response.ok と response.status で自分でチェックする。
基本は if (!response.ok) { ... } を挟んでから response.json() する。
200番台=成功、400番台=クライアント(自分)の入力や権限の問題、500番台=サーバーの問題。
まずはこのくらいのザックリ分類が頭に入っていれば十分。
ステータスごとのメッセージ分岐が必要なら、response.status === 404 などで if を書き、
必要に応じて throw new Error("意味のあるメッセージ") を投げて catch に集約する。
ここが重要です。
ステータスコードの確認は、「ただ数字を見る作業」ではありません。
「サーバーが今、こちらに何を伝えようとしているのか」を受け取る作業です。
コードを書くときは、200 なら何をする?404 ならユーザーにどう伝える?500 ならどうリトライや問い合わせの案内を出す?
と、自分に問いかけながら response.status を扱ってみてください。
その感覚が身につくと、API 通信のエラーは“怖いもの”ではなく、“対話の一部”として扱えるようになります。

