ステータスコードを深掘りする — 404、500、401、403で何が起きているか
バイブコーディング入門 — 第8回
前回までのおさらいと、今回のテーマ
前回（第7回）では、HTTPメソッド（GET・POST・PUT・DELETE）を学んだ。サーバーに送る手紙の「用件」がメソッドだという話だった。GETは「見せてください」、POSTは「新しく作ってください」、PUTは「書き換えてください」、DELETEは「消してください」。
手紙を送ったら、返事が来る。その返事に必ず含まれているのがステータスコードだ。
第6回でDevToolsのNetworkタブを学んだとき、ステータスコードに少し触れた。200は成功、404は見つからない、500はサーバーエラー。この3つだけでもかなり役に立つが、実際にバイブコーディングでアプリを作っていると、もう少し多くのステータスコードに出会う。
401、403、422、429 — これらの数字がDevToolsに表示されたとき、「何が起きているか」を自分で判断できるようになると、AIへのエラー報告の精度がさらに上がる。
今回は、バイブコーディングでよく遭遇するステータスコードを網羅的に解説する。すべてを暗記する必要はない。「こういう番号が出たら、こういう種類の問題だ」というパターンを掴むことが目的だ。
ステータスコードの「百の位」ルール
ステータスコードは3桁の数字だが、最初の1桁（百の位）を見るだけで、返事の種類が分かる。これがステータスコードの最も重要なルールだ。
200番台は「成功」。リクエストが問題なく処理された。
300番台は「転送」。要求されたものは別の場所に移動した。ブラウザが自動的に新しい場所にアクセスし直すので、普段は気にしなくてよい。
400番台は「クライアントエラー」。クライアントとは、リクエストを送った側（ブラウザやアプリ）のことだ。つまり「あなたが送ったリクエストに問題がある」という意味。URLが間違っている、ログインしていない、権限がない、送ったデータの形式がおかしい、などが原因だ。
500番台は「サーバーエラー」。サーバー側で何か問題が起きた。コードにバグがある、データベースに接続できない、サーバーが過負荷状態、などが原因だ。
バイブコーディングでエラーに遭遇したとき、まず百の位を見る。400番台なら「リクエストの送り方に問題がある」、500番台なら「サーバー側のコードに問題がある」。この判断だけで、AIに伝えるべき情報が変わってくる。
200番台 — 成功
200番台はすべて「うまくいった」という意味だ。バイブコーディングでよく見る200番台は3つある。
200 OK
最も基本的な成功コード。リクエストが正常に処理され、データが返ってきた。GETでデータを取得したとき、POSTで新しいデータを作成したとき、PUTでデータを更新したとき — ほとんどの成功レスポンスが200だ。
DevToolsのNetworkタブで、Status列が200の行は問題なく処理された通信だ。緑色で表示されることが多い。
201 Created
POSTリクエストで新しいデータが作成されたときに返されることがある。200と同じ「成功」だが、「新しく何かを作りました」というニュアンスが加わる。
たとえば、新しいユーザーを登録したとき、サーバーが201を返す。「あなたの登録リクエストを受け付けて、新しいアカウントを作成しました」という意味だ。
200と201の違いを気にする必要はほとんどない。どちらも「成功」だ。
204 No Content
前回のDELETEの例で登場した。「成功したが、返すデータはない」という意味だ。データを削除したとき、サーバーは「消しました」とだけ伝えればよく、返すデータがない。そういうときに204が使われる。
DevToolsで204が表示されていたら、「成功したんだな、データは返ってこないけど問題ない」と判断できる。
300番台 — 転送
300番台は「このページは別の場所に移動しました」という意味だ。バイブコーディングで直接目にすることは少ないが、知っておくと混乱しない。
301 Moved Permanently
「このURLは恒久的に別のURLに移動しました」という意味だ。古いURLにアクセスすると、ブラウザが自動的に新しいURLに移動する。
たとえば、サイトのURL構造を変更したとき（/blog/123 を /articles/123 に変えたとき）、古いURLにアクセスした人を新しいURLに転送するために使う。
302 Found（一時的な転送）
「今は別の場所にあるので、そちらを見てください」という意味だ。301が「永久に引っ越し」なのに対して、302は「一時的に別の場所」だ。
ログインが必要なページにログインせずにアクセスすると、ログインページに302で転送されることが多い。
300番台はブラウザが自動的に処理してくれるので、DevToolsに表示されていても問題ないことがほとんどだ。
400番台 — クライアントエラー
400番台は「リクエストを送った側に問題がある」エラーだ。バイブコーディングで最もよく遭遇するカテゴリであり、自分で原因を判断できることが多い。
400 Bad Request
「リクエストの形式がおかしい」という意味だ。サーバーが理解できない形式でデータを送ったときに返される。
よくある原因:
- JSON形式が壊れている（カッコの閉じ忘れ、カンマの付け忘れなど）
- 必須項目が送られていない
- 数値を期待しているところに文字列が送られている
AIへの伝え方: 「POST /api/tasks に送信すると400エラーが返ります。送信データの形式に問題があるかもしれません。Payloadタブの内容は {...} です」
401 Unauthorized
「認証が必要です」という意味だ。ログインしていない状態で、ログインが必要なページやAPIにアクセスしたときに返される。
「Unauthorized」は「認可されていない」と訳されることが多いが、実際の意味は「認証されていない（誰なのか分からない）」だ。
よくある原因:
- ログインしていない
- ログインセッションの有効期限が切れた
- APIキー（サービスを利用するための鍵）が設定されていない、または間違っている
AIへの伝え方: 「GET /api/profile にアクセスすると401が返ります。ログイン状態の確認か、認証トークンの送信処理を見てもらえますか」
403 Forbidden
「アクセスが禁止されている」という意味だ。401との違いは、403は「誰であるかは分かっているが、権限がない」ということだ。
会社で例えると、401は「社員証を持っていないので入れません」、403は「社員証は確認しましたが、この部屋に入る権限がありません」だ。
よくある原因:
- ログインはしているが、その操作を行う権限がない
- 管理者専用のページに一般ユーザーでアクセスした
- データベースのアクセス権限（RLS）が正しく設定されていない
AIへの伝え方: 「DELETE /api/users/5 にリクエストすると403が返ります。ログインはしていますが、この操作の権限設定を確認してもらえますか」
401と403の使い分け早見表
404 Not Found
おそらく最も有名なステータスコードだ。「見つからない」という意味。リクエストしたURLに対応するページやデータが存在しない。
よくある原因:
- URLのスペルミス（/api/taks と打っている。正しくは /api/tasks）
- APIのファイルが正しい場所に置かれていない
- IDが存在しないデータにアクセスした（/api/tasks/999 だが、ID 999のタスクは存在しない）
- ファイル名やフォルダ名が間違っている
AIへの伝え方: 「GET /api/tasks にアクセスすると404が返ります。app/api/tasks/route.ts ファイルが存在するか確認してもらえますか」
バイブコーディングで404が出たときは、まずURLのスペルを確認する。それが正しければ、APIのファイルが正しい場所に作られているかをAIに確認してもらう。
405 Method Not Allowed
「そのHTTPメソッドは使えません」という意味だ。たとえば、GETしか対応していないURLにPOSTリクエストを送ったときに返される。
前回学んだHTTPメソッドの知識と組み合わせると、原因がすぐ分かる。「DELETE /api/tasks/1 で405が返る」なら、APIにDELETE用の関数が定義されていない可能性がある。
AIへの伝え方: 「DELETE /api/tasks/[id] に送ると405が返ります。route.tsにDELETE関数が定義されていないかもしれません」
409 Conflict
「競合が発生した」という意味だ。同じメールアドレスで2回ユーザー登録しようとしたときなどに返される。「そのデータは既に存在します」というニュアンスだ。
422 Unprocessable Entity
「データの形式は正しいが、内容に問題がある」という意味だ。400との違いは微妙だが、422は「形式は合っているがバリデーション（入力チェック）に引っかかった」場合に使われることが多い。
たとえば、メールアドレスのフィールドに「abc」と入力して送信した場合、JSON形式としては正しいが、メールアドレスとしては不正だ。こういうときに422が返される。
AIへの伝え方: 「POST /api/users で422が返ります。バリデーションエラーのようです。Responseタブには 'email must be a valid email address' と出ています」
429 Too Many Requests
「リクエストが多すぎます」という意味だ。短時間に大量のリクエストを送ると、サーバーが制限をかけて429を返す。これをレート制限（rate limiting）と呼ぶ。
外部APIを使っているときに遭遇することが多い。Claude APIやOpenAI APIなど、AIサービスのAPIには利用回数の制限がある。制限を超えると429が返される。
対処法は「少し待ってからやり直す」ことだ。レスポンスヘッダーに「Retry-After」という項目があれば、何秒後にリトライすればよいかが書いてある。
500番台 — サーバーエラー
500番台は「サーバー側で問題が起きた」エラーだ。400番台が「リクエストの送り方が悪い」のに対して、500番台は「サーバー側のコードやインフラに問題がある」。
500 Internal Server Error
最も一般的なサーバーエラー。サーバー側のコードで例外（予期しないエラー）が発生したときに返される。
バイブコーディングで500が出たら、サーバー側のコードにバグがある可能性が高い。DevToolsのResponseタブにエラーメッセージが含まれていることが多いので、そのメッセージをAIに伝えるのが最も効果的だ。
よくある原因:
- データベースのテーブルやカラムが存在しない
- 環境変数（APIキーなど）が設定されていない
- コードの中で null（データなし）に対して操作しようとしている
- 外部サービスへの接続に失敗している
AIへの伝え方: 「POST /api/tasks が500を返します。Responseに 'relation tasks does not exist' と出ています。データベースのテーブルが作成されていないかもしれません」
502 Bad Gateway
「中継サーバーがエラーを受け取った」という意味だ。アプリの前段にあるプロキシサーバー（中継役のサーバー）が、アプリ本体のサーバーからエラーの返事を受け取ったときに出る。
Vercel や Render（レンダー）などのホスティングサービスにアプリを公開しているとき、アプリが起動に失敗すると502が出ることがある。
503 Service Unavailable
「サービスが一時的に利用できない」という意味だ。サーバーがメンテナンス中、または一時的に過負荷状態のときに返される。
自分で作ったアプリで503が出ることは比較的少ない。外部サービス（SupabaseやClaudeのAPIなど）が一時的に停止しているときに見ることがある。
504 Gateway Timeout
「中継サーバーがタイムアウトした」という意味だ。アプリの処理に時間がかかりすぎて、中継サーバーが「もう待てない」と判断したときに返される。
データベースから大量のデータを取得する処理や、外部APIの応答が遅い場合に起きやすい。
AIへの伝え方: 「GET /api/reports が504を返します。レポートデータの取得に時間がかかりすぎているかもしれません。クエリの最適化か、タイムアウト設定の変更を見てもらえますか」
ステータスコード早見表
バイブコーディングでよく遭遇するステータスコードをまとめる。この表を覚える必要はない。DevToolsで見慣れない数字が出たときに、ここに戻って確認すればよい。
200番台（成功）:
- 200 OK — 成功。データが返ってきた
- 201 Created — 成功。新しいデータが作成された
- 204 No Content — 成功。返すデータはない
300番台（転送）:
- 301 — 恒久的な転送。URLが変わった
- 302 — 一時的な転送。ログイン画面への転送など
400番台（クライアントエラー）:
- 400 Bad Request — リクエストの形式が不正
- 401 Unauthorized — 認証が必要（ログインしていない）
- 403 Forbidden — 権限がない（ログイン済みだが禁止）
- 404 Not Found — URLに対応するものが存在しない
- 405 Method Not Allowed — そのHTTPメソッドは非対応
- 409 Conflict — データの競合（既に存在するなど）
- 422 Unprocessable Entity — バリデーションエラー
- 429 Too Many Requests — リクエスト回数制限
500番台（サーバーエラー）:
- 500 Internal Server Error — サーバー側のバグ
- 502 Bad Gateway — 中継サーバーのエラー
- 503 Service Unavailable — サービス一時停止
- 504 Gateway Timeout — 処理のタイムアウト
DevToolsでステータスコードを確認する実践
実際のエラー調査の流れを、ステップバイステップで確認しよう。
ステップ1: DevToolsを開く
F12キー（MacはCommand + Option + I）でDevToolsを開き、Networkタブを選ぶ。「Fetch/XHR」フィルターをかけておく。
ステップ2: 赤い行を探す
エラーのある通信は赤く表示される。赤い行があったら、それがエラーの原因だ。
ステップ3: ステータスコードを確認する
赤い行のStatus列を見る。400番台か500番台かで、問題の所在が分かる。
- 400番台 → リクエストの送り方に問題がある。URLやデータを確認する
- 500番台 → サーバー側のコードに問題がある。サーバーのログを確認する
ステップ4: エラーメッセージを読む
赤い行をクリックして、Responseタブを開く。エラーの詳細メッセージが表示されていることが多い。このメッセージがエラー解決の最大の手がかりだ。
ステップ5: AIに伝える
ステータスコード、URL、HTTPメソッド、エラーメッセージをAIに伝える。
テンプレート: （症状）〇〇の操作をすると△△が起きる。 （DevToolsの情報）[メソッド] [URL] が [ステータスコード] を返している。 （レスポンスの内容）エラーメッセージは「□□□」。
具体例: （症状）ユーザー登録フォームで送信すると、エラーが表示される。 （DevToolsの情報）POST /api/users が422を返している。 （レスポンスの内容）「email must be a valid email address」。
この伝え方をすれば、AIは「フロントエンドのフォームでメールアドレスのバリデーションが足りていない」か「バックエンドのバリデーションが厳しすぎる」かを即座に判断できる。
よくある不安と答え
ステータスコードの番号を全部覚えないといけないか
覚える必要はない。大事なのは「百の位のルール」だけだ。2xxは成功、4xxはリクエスト側の問題、5xxはサーバー側の問題。この3つのパターンを覚えておけば、具体的な番号はこの記事の早見表を見て確認すればよい。
400番台と500番台、どちらが深刻か
一概には言えないが、500番台のほうが深刻なことが多い。400番台は「送り方を直せば解決する」ことが多いのに対して、500番台は「サーバー側のコードにバグがある」ことが多いからだ。ただし、どちらもAIに的確に伝えれば解決できる。
エラーのステータスコードが出ても、アプリが動いているように見えることがあるが
ある。広告や外部の解析ツールの通信がエラーになっていても、アプリ自体は正常に動作していることがある。自分のアプリのURL（/api/ で始まるものなど）の通信に注目すれば、本当に問題のあるエラーを見分けられる。
0や net::ERR_ で始まるエラーはステータスコードではないのか
ステータスコードではない。これはサーバーに手紙が届く前の段階で問題が起きていることを示す。ネットワーク接続の問題、サーバーが起動していない、CORSエラー（クロスオリジンリソースシェアリング、異なるドメイン間のアクセス制限）などが原因だ。これらのエラーが出たときは「サーバーにリクエストが届いていません」とAIに伝えると、適切な調査をしてくれる。
まとめ
ステータスコードは3桁の数字で、サーバーからの返事の種類を教えてくれる。百の位がすべてだ。2xxは成功、3xxは転送、4xxはリクエスト側の問題、5xxはサーバー側の問題。400番台ではURLやデータの送り方を確認し、500番台ではサーバー側のコードを確認する。DevToolsで赤い行を見つけたら、ステータスコードとResponseタブのエラーメッセージをAIに伝える。この2つの情報があれば、ほとんどのエラーは解決の糸口が見つかる。
次回は「HTTPヘッダの基本 — Content-TypeとAuthorizationで何をやりとりしているか」。手紙の封筒に書かれている「差出人情報」や「荷物の種類」にあたるHTTPヘッダについて解説する。
参考リファレンス
- MDN Web Docs「HTTPレスポンスステータスコード」— Mozilla が提供するステータスコードの公式リファレンス
- 前回: 第7回「HTTPメソッドの使い分け — GET・POST・PUT・DELETEで何が変わるか」（/articles/vc-007）
- 次回: 第9回「HTTPヘッダの基本 — Content-TypeとAuthorizationで何をやりとりしているか」（/articles/vc-009）
- バイブコーディング入門 カリキュラム（/vibe-coding）
