あなたのWebアプリは「手紙のやりとり」で動いている
バイブコーディング入門 — 第1回
こんな経験はないだろうか
CursorやClaude Codeを使って、Webアプリを作った。見た目はいい感じにできた。ボタンも動く。でも、ある日突然エラーが出る。画面に「404」とか「500」とか表示される。AIに「直して」と頼んでも、的外れな修正が返ってくる。何が起きているのか分からない。
あるいは、AIに「ログイン機能を追加して」と頼んだら、コードがドッと出てきた。動いているように見える。でも「なぜ動いているのか」は説明できない。どこかを触ったら壊れそうで怖い。
これは、あなたのスキルが足りないのではない。Webの仕組みという「地図」を持っていないだけだ。
この連載では、バイブコーディング（AIにコードを書かせる開発スタイル）を実践している人が、最低限知っておくとラクになるWebの仕組みを解説していく。全24回。プログラミングの経験は問わない。CursorやClaude Codeでアプリを作ったことがある人なら、すべて理解できる内容だ。
第1回のテーマは、Webアプリの最も基本的な動作原理。リクエストとレスポンスだ。
Webアプリは「手紙のやりとり」で動いている
Webアプリの仕組みを一言で説明する。手紙のやりとりだ。
あなたがブラウザ（ChromeやSafari）でWebサイトを開くとき、実は裏側でこういうことが起きている。
- あなたのブラウザが、どこかにあるコンピューター（サーバー）に手紙を送る
- サーバーがその手紙を読んで、返事を書いて送り返す
- ブラウザがその返事を受け取って、画面に表示する
これだけだ。どんなに複雑なWebアプリも、この「手紙のやりとり」の繰り返しで動いている。Amazonの商品ページも、Googleの検索結果も、あなたがCursorで作ったToDoアプリも。全部同じ原理だ。
この「手紙を送ること」を、Web の世界ではリクエスト（request＝要求）と呼ぶ。「返事を返すこと」をレスポンス（response＝応答）と呼ぶ。
リクエストとレスポンス。この2つの言葉を覚えるだけで、Webアプリの見え方が変わる。
実際に手紙の中身を見てみよう
手紙のやりとりだと言われても、実感がわかないかもしれない。では、実際にあなたのブラウザが送っている「手紙」の中身を見てみよう。
たとえば、あなたがブラウザのアドレスバーに「https://example.com/products」と入力してEnterを押す。このとき、ブラウザは裏側で次のような手紙を送っている。
GET /products HTTP/1.1 Host: example.com Accept: text/html
少しだけ専門的な表記が出てきたが、怖がる必要はない。これを手紙に例えると、こういうことだ。
- GET /products → 「商品一覧のページを見せてください」（何をしてほしいかという用件）
- Host: example.com → 「example.comさん宛て」（宛先）
- Accept: text/html → 「HTMLという形式で返してください」（返事の形式の希望）
GETは「見せてください」という意味だ。ページを表示するときは、ほぼすべてGETが使われる。名前の通り、情報を「取得する」ための言葉だ。
サーバーからの返事（レスポンス）はこう返ってくる
リクエスト（手紙）を受け取ったサーバーは、返事を書いて送り返す。その返事はこんな形をしている。
HTTP/1.1 200 OK Content-Type: text/html
（ここにHTMLという形式で書かれた商品一覧のページの中身が入っている）
ここで大事なのは先頭の「200 OK」だ。これは「あなたのリクエスト、ちゃんと受け取りました。問題なく処理できました。はい、どうぞ」という意味だ。
200という数字は、ステータスコードと呼ばれるもので、サーバーからの返事の「結果」を示している。正常なら200。この数字が変わると、意味が変わる。
あのエラー番号の正体
Webサイトを見ているときに「404」という数字を見たことがあるはずだ。ページが見つからないときに出るあの画面だ。あるいは、自分で作ったアプリが突然「500」を返すこともある。
これらの数字は、すべてサーバーからの返事（レスポンス）に含まれるステータスコードだ。サーバーが「あなたの手紙にどう応じたか」を3桁の数字で伝えている。
覚えておくと役に立つのは、数字の先頭1桁だ。
- 2xx（200番台）→ 成功。問題なし
- 3xx（300番台）→ 転送。別の場所を見てほしい
- 4xx（400番台）→ あなた（ブラウザ側）の問題。リクエストの内容に間違いがある
- 5xx（500番台）→ サーバー側の問題。サーバーの中で何かおかしいことが起きた
これだけ覚えておけば、エラーが出たときに「自分のコードが悪いのか」「サーバー側の問題なのか」を切り分けられる。
404が出たら、リクエストの宛先（URL）が間違っている可能性が高い。500が出たら、サーバー側のコード（バックエンド）にバグがある可能性が高い。この切り分けができるだけで、AIへの指示の精度が格段に上がる。
バイブコーディングとリクエスト・レスポンスの関係
ここまでの話が、バイブコーディングにどう関係するのか。具体例で説明する。
あなたがCursorで「ユーザー一覧を表示するページを作って」と指示したとする。AIは、ざっくりこういう処理を書く。
- ブラウザが /api/users にGETリクエストを送る
- サーバーが、データベースからユーザー一覧を取り出す
- サーバーが、ユーザー一覧をJSON（データのやりとりに使われる形式）にしてレスポンスとして返す
- ブラウザが、受け取ったJSONを画面に表示する
AIが書いたこのコード、今までは「なんか動いてるっぽい」としか見えなかったかもしれない。でも、リクエストとレスポンスを理解した今なら、処理の流れが見えるはずだ。
そして、もしエラーが起きたとき。たとえば「ユーザー一覧が表示されない」という問題が発生したら、こう考えられるようになる。
- ブラウザはリクエストをちゃんと送っているか？（送り先のURLは正しいか？）
- サーバーはレスポンスを返しているか？（ステータスコードは何か？）
- 200が返ってきているのに表示されないなら、ブラウザ側の表示処理の問題かもしれない
- 500が返ってきているなら、サーバー側のデータ取得処理にバグがあるかもしれない
この切り分けができると、AIへの指示が「ユーザー一覧が表示されないので直して」から「/api/usersにGETリクエストを送ると500エラーが返ってくる。サーバー側のデータ取得処理を確認してほしい」に変わる。後者のほうが、AIは圧倒的に正確な修正を返してくれる。
ブラウザの開発者ツールで「手紙」を見る方法
「リクエストとレスポンスが手紙のやりとりだということは分かった。でも、自分のアプリで実際に何が起きているか確認する方法はあるのか？」
ある。ブラウザに最初から入っている「開発者ツール」（デベロッパーツール）を使えば、すべてのリクエストとレスポンスをリアルタイムで見ることができる。
手順は上の通りだ。Chromeの場合で説明しているが、Safari、Edge、Firefoxにも同じ機能がある。
Networkタブを開いてページを読み込むと、ブラウザが送ったリクエストの一覧が表示される。1つのページを表示するだけでも、画像ファイルやスタイルシート（見た目の設定ファイル）など、数十件のリクエストが飛んでいることがわかるはずだ。
各リクエストをクリックすると、「何を送ったか」（リクエスト）と「何が返ってきたか」（レスポンス）の詳細が見られる。ステータスコード（200、404、500など）もここに表示される。
エラーが起きたとき、まずNetworkタブを確認する。赤く表示されているリクエストがあれば、それが問題の手がかりだ。ステータスコードを見て、4xx（リクエストの問題）か5xx（サーバーの問題）かを切り分ける。これだけで、AIへの指示が一段具体的になる。
よくある不安と答え
この知識がなくてもアプリは作れるのでは？
作れる。CursorやClaude Codeは、リクエストとレスポンスの仕組みを知らなくてもアプリを生成してくれる。ただし、問題が起きたときに「何が起きているか分からない」状態になる。車の運転にエンジンの仕組みは不要だが、警告灯の意味は知っておいたほうがいい。リクエストとレスポンスは、Webアプリの「警告灯」を読むための知識だ。
プログラミングを勉強しないといけないのか？
この連載でプログラミングの勉強は求めない。コードは最小限しか出てこない。目標は「AIが書いたコードの意味がなんとなく分かる」「エラーが出たときに、何が原因かの当たりがつけられる」というレベルだ。プログラマーになる必要はない。
リクエストとレスポンスだけ覚えて、何か変わるのか？
変わる。なぜなら、Webアプリで起きる問題の大半は「リクエストが正しく送られていない」か「レスポンスが期待通りに返ってきていない」かのどちらかだからだ。この2つの概念を知っているだけで、エラーの原因を推測できる確率が上がる。それはつまり、AIに対してより的確な指示が出せるということだ。
まとめ
Webアプリは「手紙のやりとり」で動いている。ブラウザがサーバーに手紙（リクエスト）を送り、サーバーが返事（レスポンス）を返す。この繰り返しだ。エラーが出たときは、ステータスコード（200、404、500）を確認すれば、問題が「自分の指示の間違い」なのか「サーバー側のバグ」なのかを切り分けられる。切り分けができれば、AIへの指示の精度が上がり、的外れな修正を繰り返す時間が減る。次回は「フロントエンド・バックエンド・データベース」という3つの役割分担について解説する。
参考リファレンス
- MDN Web Docs「HTTP の概要」— Mozilla が公開しているWeb技術の公式リファレンス
- バイブコーディング入門 カリキュラム（/vibe-coding）
- 次回: 第2回「フロントエンド・バックエンド・データベース — 3層構造を理解する」（/articles/vc-002）
