前回との接続——メソッドから、その返事の番号へ
D-05では、要求の種類を表すメソッドの使い分けを見ました。今回はその返事に含まれる3桁の数字、ステータスコードを取り上げます。D-04で名前だけ登場したこの数字を、今回は分類として読めるようにします。番号の先頭一桁を見るだけで、失敗の性質を素早くつかめるようになります。
このスライドのポイント
- D-05: 要求の種類を表すメソッドの使い分けを見た
- 今回: その返事に含まれる3桁の数字＝ステータスコードを分類で読む
- D-04で名前だけ登場したこの数字を、原因の所在まで読めるようにする
先頭一桁で4つに分かれる
ステータスコードは、先頭の数字が大きな分類を表します。2xxは成功、3xxは移動でほかの場所を見よという合図、4xxは依頼した側、つまりクライアントに原因がある状態、5xxは処理する側、つまりサーバーに原因がある状態です。代表例を挙げると、200は成功、301と302は移動、400は依頼の形式が不正、401は本人確認ができていない、403は権限がない、404は場所がない、429は依頼が多すぎる、500はサーバー内部の障害、503は一時的に応答できない状態です。まずは先頭一桁で4つに分ける読み方を身につけてください。
このスライドのポイント
- 先頭の数字が大きな分類を表す
なぜ必要か——無駄な対応を避けるため
この分類を知らないと、エラーが出ましたという報告で止まってしまいます。すると、4xxで依頼側に原因があるのに同じ依頼を何度も繰り返したり、逆に5xxでサーバー側の障害なのに自分のコードばかり疑ったりと、見当違いの対応に時間を使うことになります。先頭一桁で原因の所在が分かれば、直すべき場所と、そもそも待つべきかどうかを最初に切り分けられます。
このスライドのポイント
- 知らないと「エラーが出ました」で止まる
- 4xxなのに同じ依頼を何度も繰り返す／5xxなのに自分のコードばかり疑う、という無駄が起きる
- 先頭一桁で原因の所在が分かれば、直す場所と待つべきかを最初に切り分けられる
原因の所在と再試行の判断
ここでは4つの分類を、原因の所在と再試行の判断という2つの軸で整理します。4xxは依頼側に原因があるため、依頼の中身を直すまでは何度繰り返しても直りません。一方、5xxや429は、少し時間を置いてからの再試行で通ることがあります。再試行とは、失敗した要求を間隔を空けてもう一度送ることです。とくに429は依頼が多すぎるという合図なので、間隔を空けることが解決につながります。
このスライドのポイント
- 4分類を2つの軸で整理: 意味・原因の所在／再試行の判断
- 4xx＝依頼側を直すまで繰り返しても直らない
- 5xx・429＝時間を置いた再試行が有効なことがある（429は間隔を空ける）
- 再試行＝失敗した要求を、間隔を空けてもう一度送ること
ログを1行ずつ読む
次のスライドのログを、1行ずつ読んでみます。同じ宛先に対して、返ってくる番号で原因の所在が変わります。404はパスの打ち間違いで、依頼側を直す対象です。500はサーバー内部の障害で、処理側の問題です。429は依頼の頻度が高すぎる状態で、原因は依頼側にありますが、待てば直るタイプです。番号を見るだけで、直すのか待つのかの方針が決まります。
このスライドのポイント
- 次スライドのログを1行ずつ読む
- 404＝パスの打ち間違い＝依頼側を直す
- 500＝サーバー内部の障害＝処理側
- 429＝依頼の頻度が高い＝依頼側だが「待てば直る」タイプ
- 同じ宛先でも、返る番号で方針（直す/待つ）が決まる
技術サンプル: ステータスコードのログ
サンプルは、4本のリクエストとその結果を並べたログです。同じ宛先でも、返る番号で原因の所在が分かります。2行目の404は場所がないという意味で、パスの綴りを直すまで再試行しても直りません。4行目の429は依頼が多すぎるという合図で、間隔を空ければ通ることがあります。AIへは、このエラーはステータスコードいくつでした、原因は依頼側と処理側のどちらにありそうですか、と聞くと切り分けが進みます。
このスライドのポイント
- 種別: log
- 目的: 同じ宛先への結果から、原因の所在と再試行の要否を読み取る
- サンプル本体:
混同しやすい概念——401と403
混同しやすいのが401と403です。401は、そもそも誰なのかを確認できていない状態です。403は、誰かは分かっているものの、その人には権限がない状態です。対処の方向も違います。401はログインし直す方向で考え、403はA-08で決めた権限設定を見直す方向で考えます。どちらも失敗ですが、直す場所が異なります。
このスライドのポイント
- 401＝そもそも誰なのかを確認できていない
- 403＝誰かは分かっているが、権限がない
- 対処が違う: 401はログインし直す方向／403はA-08で決めた権限設定を見直す方向
バイブコーディングでの確認点
エラーをAIへ報告するときは、何をしたら、どのURLで、何番が返ったか、という3点をそろえて渡します。これはA-07で学んだ、エラーの原文をそのまま渡すという習慣の実践形です。番号を一つ添えるだけで、AIの原因推定の精度は大きく上がります。エラーが出ましたと伝えるだけの報告と比べて、切り分けの速さがまるで変わります。
このスライドのポイント
- エラー報告は「何をしたら・どのURLで・何番が返ったか」の3点セットで渡す（A-07のエラー原文の実践形）
- 番号を伝えるだけで、AIの原因推定の精度が大きく上がる
- 質問例:「このエラーはステータスコード◯◯でした。原因は依頼側と処理側のどちらにありそうですか」
一問一答とまとめ
最後に一問です。404と500、依頼側に原因があるのはどちらでしょうか。……答えは404です。4xxは依頼した側に原因がある分類だからです。30秒でまとめます。ステータスコードは先頭一桁で4つに分かれ、2xxは成功、3xxは移動、4xxは依頼側、5xxは処理側に原因があります。4xxは依頼を直すまで再試行しても直らず、5xxや429は時間を置いた再試行で通ることがあります。次回は、リクエストとレスポンスに付く付加情報、ヘッダーの代表例を見ていきます。関連資料は、エラー文の読み方、エラー解決プロンプト50、API連携ワード100です。
このスライドのポイント
- 一問一答:「404と500、依頼側に原因があるのはどちら？」→ 404（4xxは依頼側）
- 30秒まとめ: 先頭一桁で4分類（2xx成功／3xx移動／4xx依頼側／5xx処理側）。4xxは依頼を直すまで再試行しても直らず、5xx・429は時間を置いた再試行で通ることがある
- 次回: リクエストとレスポンスに付く付加情報＝ヘッダーの代表例へ
- 関連資料: 「エラー文の読み方」「エラー解決プロンプト50」「API連携ワード100」
