4xx と 5xx — エラーが出たらどこを見るか

当てもの問答はこうして始まる

AI にウェブアプリを任せたことがある人には見慣れた光景がある。画面に赤い文字が出て、それをキャプチャして AI に投げ、AI がコードを直し、まだ動かず、また投げる。何周かすると原因も分からないままコードがあちこち書き換わっている。

原因は腕前ではなく情報だ。どこが壊れているか分からないまま直せと言えば、AI も推測で直すしかない。逆に壊れた区間を一箇所に絞って渡せば、同じ AI が一度で直すことが多い。

絞り込みにプログラミングの実力は要らない。ブラウザがすでに答えの半分を画面に出しており、それを読む規則は二つだけだ。先頭一桁を見ること、そして境界をたどること。

ステータスコードはどこで見るか

ブラウザには開発者ツールが標準で入っている。Windows は F12、Mac は Command + Option + I を押すと画面の横か下にパネルが開く。Chrome も Edge も Safari も備えており、入れるものは何もない。Safari だけは設定で「開発」メニューを一度有効にする必要がある。

タブは二つ分かれば足りる。Console はフロントエンドのコード（JavaScript）が残したメッセージが溜まる場所、Network は画面が外部とやり取りしたリクエストが一行ずつ積まれる場所だ。エラーが出たときはまず Network を開く。

Network タブを開いたまま、問題のボタンをもう一度押す。すると一覧に新しい行が増える。赤く表示された行、あるいは Status 列の数字が 400 番台・500 番台の行が犯人だ。その行をクリックすると、右側に送った内容（Request）と返ってきた内容（Response）が出る。

ここで大事なのは画面のエラー文言ではなくこの数字だ。文言はサービスごとにばらばらだが、数字は世界共通の約束である。

先頭一桁で責任の所在が分かれる

ステータスコードは三桁で、後ろ二桁が細かい理由、先頭が大分類だ。先頭だけ見ればどちら側を見るかが決まる。

実戦では 4 と 5 の差が最も大きい。4 は送った側の問題なので自分の画面・入力値・アドレスを見る。5 は受け取った側の問題なので、自分のコードをいくら直しても意味がない。

よく出会うコードだけ拾うと

数字を全部覚える必要はない。実際にぶつかるのは十ほどで、それぞれが何を確認しろという合図なのかだけ分かればいい。

401 と 403 の違いは押さえておく価値がある。401 は「あなたが誰か分からない」でログインの問題、403 は「誰かは分かるがその権限がない」で権限設定の問題だ。開発では前者を認証、後者を認可と呼ぶ。

529 は自分のせいではない

Claude Code や API を使っていると 529 によく出会う。先頭が 5 なので、これは自分側ではなく相手のサーバー側の状況だ。リクエストが集中して捌ききれていないという意味で、よく「サーバーが落ちた」と言う。

これを知らないと、問題のないコードを延々と直し続けることになる。実際、ここが最もよくある無駄だ。5 で始まるコードが見えたら手を止め、少し待ってから再試行するのが正解である。

ただし同じ 5xx でも、自分で作ったバックエンドが返した 500 なら自分のサーバーの問題だ。自社サービスが出した 500 か、外部サービスが出した 5xx かをまず分ける。それは Network タブでそのリクエストがどのアドレスへ行ったかを見れば分かる。

リクエストが通る五つの区間

先頭一桁で方向が定まったら、次は位置を絞る。そのためにはメモを一つ保存するとき裏で何が起きているかを知る必要がある。ウェブサービスは一塊ではなく、次の五区間がつながった構造だ。

1）フロントエンド。ユーザーに見える画面。ユーザーから見て最も前にあるのでフロントと呼ぶ。HTML が中身を担い、CSS が見た目を整え、JavaScript がクリックなどの動作を扱う。ブラウザの中で動くため、ここで使える言語は事実上 JavaScript だけだ。

2）HTTP と API。画面とサーバーが会話する規格。アドレス（URL）へリクエストを送り応答を受け取る。やり取りするデータ形式はたいてい JSON だ。この通信区間をまとめて API と呼ぶ。

3）バックエンド。目に見えない処理側。リクエストが来たら誰かを確かめ（認証）、その資格があるかを見て（認可）、値が正常かを検査し（検証）、実際のルールを適用する。

4）データベース。サービスの記憶を担う。バックエンドが処理した結果を表の形で保存し、後で取り出す。

5）デプロイとインフラ。これらが実際に動く場所だ。自分のパソコンでしか開かない localhost を出て、他の人もアクセスできる場所へ載せる工程である。

紛らわしい用語が一つある。「サーバー」はバックエンドのプログラムだけを指す言葉ではない。インフラの観点ではそのプログラムが動くコンピュータを意味することもある。バックエンドはそのコンピュータの上でロジックを処理するプログラムだと捉えればよい。

不具合は区間のあいだで起きる

実務で問題が出る場所は、たいてい区間の内側ではなく区間と区間をつなぐ矢印の上だ。遅くなったならどれかの矢印で遅延しており、保存できなかったならどれかの矢印で切れている。

だからデバッグは矢印を順にたどる作業になる。次の四段階をそのまま進めれば犯人は一区間に絞られる。

第一段階。問題の動作を再現する。Network タブを開いたまま、そのボタンをもう一度押す。

第二段階。リクエストが実際に出たかを見る。新しい行が増えなければフロントエンドの時点で止まっている。この場合 Console タブに JavaScript のエラーが出ていることが多い。

第三段階。出ていればステータスコードを見る。4xx なら送った値・アドレス・ログイン状態を、5xx ならバックエンドのログを見る。

第四段階。バックエンドまで正常なら、値が本当にデータベースに入ったかを確認する。応答は成功なのにデータがなければ保存ロジックかトランザクション側だ。

この順序を一度身につければ、次のエラーからはキャプチャを投げる前にどの区間かが分かった状態で始められる。

AI にはこの質問を先にする

多くの人はエラー画面を貼り付けて「直して」と言う。すると AI は見えている症状に合わせてコードを変える。原因が別の区間にあれば、その修正は新しい問題を生む。

代わりに位置を尋ねる質問を先に入れる。下の文はそのまま写して使ってよい。

この質問はエラーだけのものではない。初めて聞く技術用語に出会ったときも同じ枠で聞けば、その技術が全体の流れのどこに位置するかがつかめる。位置が分かれば、残りの説明が付く場所ができる。

ユーザーのリクエストが フロントエンド → API → バックエンド → データベース と流れるとして、
今回のエラーがどの区間で発生したのかをまず判断してください。
判断の根拠になったステータスコードとログも一緒に示し、
まだ確認が要るなら、私が何をキャプチャして持ってくればよいか教えてください。

ユーザーのリクエストが フロントエンド → API → バックエンド → データベース と流れるとして、
いま出てきたこの技術はどの区間に影響する技術か説明してください。
あわせて、それを理解する前に知っておくべき概念があれば教えてください。

分からない用語が出たら地図を見る

区間が分かっても、その中の用語は次々に出てくる。そのとき使いやすいのが roadmap.sh だ。フロントエンド開発者、バックエンド開発者といった役割ごとに「この順で学べばよい」という地図を一枚の図にまとめたサイトである。

使い方は簡単だ。該当のロードマップを開き、今つまずいている技術がその地図のどの段階にあるかを探す。紫で示された項目は作者の推奨、つまり実務でよく使われるものだ。英語だが、図をそのまま AI に渡して説明させればよい。

こうすると用語がばらばらに積み上がらず、地図上の座標として積まれる。それが後で検索するときも、AI に聞くときもずっと速い。

バグはゼロにならない

最後に期待値を一つ調整しておくとよい。どれだけ熟練した開発者が作ってもバグはゼロにならない。AI が作っても同じで、むしろ増えることさえある。

だから実際の開発で最も時間がかかるのは、コードを初めて書く瞬間ではなく作った後だ。確認して、出して、エラーが出たらまた直す。その繰り返しが大半を占める。

結局必要なのはバグのないコードではなく、問題が起きたときに素早く位置を見つける方法だ。先頭一桁を読む、境界をたどる、まず位置を聞く。この三つで大半の当てもの問答は終わる。