バイブコーディング入門①｜あなたのWebアプリは「手紙のやりとり」で動いている

冒頭

Cursor や Claude Code を使ってWebアプリを作ってみた。見た目はそれっぽく動いている。でも、いざエラーが出ると何が起きているのか分からない。赤い文字が並ぶ画面を眺めて、AIに「直して」と投げて、別のエラーが出て、また投げて。30分経っても先に進まない。

そんな経験がある方は多いと思う。バイブコーディング（AIにコードを書かせるスタイルの開発）は、コードを書く負担を劇的に減らしてくれる。でも「なぜ動いているのか」が分からないまま進むと、どこかで必ず詰まる。

この記事では、Webアプリが動く最も基本的な仕組みを「手紙のやりとり」にたとえて解説する。リクエスト（手紙を送ること）とレスポンス（返事が届くこと）。この2つの概念が分かるだけで、エラーの原因を自分で特定できる場面が増える。

記事の最後に、バイブコーディングで使える「Webの仕組みチェックシート」を無料配布している。手元に置いておくと、エラーに遭遇したとき何を確認すればいいか迷わなくなる。

Webは「手紙のやりとり」で動いている

Webの基本構造 — 手紙のやりとり
図: Webの基本構造 — 手紙のやりとり

Webアプリの仕組みを一言で言うと、手紙のやりとりだ。

あなたがブラウザ（ChromeやSafari）でWebサイトを開くとき、裏側ではこんなことが起きている。

  1. あなたのブラウザが「このページを見せてほしい」という手紙を送る
  2. 手紙はインターネットを通って、相手のコンピュータ（サーバー）に届く
  3. サーバーが手紙を読んで「はい、このページの内容です」という返事を送り返す
  4. ブラウザが返事の中身を画面に表示する

これだけだ。Webで起きていることの99%は、この「手紙を送る → 返事が届く → 画面に表示する」の繰り返しにすぎない。

この手紙を送る行為を「リクエスト」と呼ぶ。返事を「レスポンス」と呼ぶ。英語だが、Webの世界ではこの2つの言葉が頻繁に出てくるので、このまま覚えてしまうのが早い。

リクエスト = あなたが送る手紙 レスポンス = 相手から届く返事

バイブコーディングで Cursor や Claude Code を使っていると、エラーメッセージに「request」「response」という言葉がよく出てくるはずだ。これは「手紙」と「返事」のことだと分かれば、メッセージの意味が格段に読みやすくなる。

手紙には「宛先」と「用件」がある

普通の手紙に住所と用件を書くように、リクエストにも「どこに送るか」と「何を頼むか」が含まれている。

宛先 = URL

ブラウザのアドレスバーに入力するあの文字列が、手紙の宛先にあたる。たとえば「https://example.com/products」と入力すると、example.com というサーバーの products という場所に手紙が届く。

URLは「住所＋部屋番号」のようなものだ。

  • https://example.com → 建物の住所（どのサーバーか）
  • /products → 部屋番号（サーバーの中のどの情報か）

バイブコーディングでよく遭遇する「404 Not Found」というエラーは「その部屋番号は存在しません」という返事だ。手紙の宛先が間違っていた、ということ。AIにコードを生成してもらったとき、URLの綴りが1文字違っていただけでこのエラーが出ることがある。

用件 = HTTPメソッド

手紙の用件にも種類がある。Webでよく使うのは4つだけだ。

  • GET（ゲット）: 「情報を見せてほしい」→ ページを表示するとき
  • POST（ポスト）: 「新しい情報を送る」→ フォームの送信や会員登録
  • PUT（プット）: 「情報を書き換えてほしい」→ プロフィールの更新
  • DELETE（デリート）: 「情報を消してほしい」→ 投稿の削除

あなたがブラウザでWebサイトを見ているとき、ほとんどの操作はGET（見せて）とPOST（送る）の2つだ。

バイブコーディングでフォームの送信がうまくいかないとき、原因の多くは「GETで送るべきところをPOSTで送っている」か「その逆」だ。手紙の用件の種類が間違っていた、ということ。

返事にも「ステータス」がある

レスポンスのステータスコード — 手紙のたとえ
図: レスポンスのステータスコード — 手紙のたとえ

サーバーから届く返事（レスポンス）には、必ず「番号」が付いている。これをステータスコードと呼ぶ。3桁の数字で、返事の意味を教えてくれる。

全部覚える必要はない。バイブコーディングで特によく見る4つだけ押さえておけば十分だ。

200 — 成功。問題なくデータが返ってきた。正常な状態。

404 — 見つからない。URLの綴りが間違っているか、そのページが削除されている。AIが生成したコードのURLパスを確認してみる。

500 — サーバー内部エラー。サーバー側のプログラムに問題がある。バイブコーディングでは、AIが生成したサーバー側のコード（API Route や Server Action と呼ばれる部分）にバグがある可能性が高い。

403 — アクセス拒否。ログインしていない、または権限がない。Supabase（スーパーベース: データベースサービス）を使っている場合、RLS（行レベルセキュリティ: 誰がどのデータにアクセスできるかを制御する仕組み）の設定が原因であることが多い。

エラーが出たとき、まずこの番号を見る。番号が分かれば「手紙の宛先が間違っていたのか」「返事を作る側の問題なのか」「権限の問題なのか」が一瞬で判断できる。

実際に手紙のやりとりを見てみよう

理屈だけでは実感が湧かないと思う。ここで、実際にブラウザの中で手紙のやりとりを「見る」方法を紹介する。

少しだけ画面操作が出てくるが、そのまま真似すれば動く。意味は分からなくてOKだ。

ステップ1: ブラウザの「開発者ツール」を開く

Chromeを使っている場合、キーボードで以下を押す。

  • Mac: Command + Option + I
  • Windows: F12 または Ctrl + Shift + I

画面の右側や下側に、英語が並んだパネルが開く。これが開発者ツール（DevTools: ブラウザに内蔵されている検査機能）だ。怖がらなくて大丈夫。何かを壊す操作ではない。ただ「裏側を見る窓」が開いただけだ。

ステップ2: Network（ネットワーク）タブを開く

パネルの上部にタブが並んでいる。「Network」と書かれたタブを押す。日本語設定の場合は「ネットワーク」と表示されていることもある。

ステップ3: ページを再読み込みする

そのまま、ページを再読み込みする（F5 キーまたは Command + R）。

すると、Networkタブにズラッと行が並ぶ。これが「手紙のやりとりの記録」だ。1行が1通の手紙（リクエスト）に対応している。

ステップ4: 1行を押して中身を見る

どれか1行を押すと、右側に詳細が表示される。ここで確認できるのは:

  • Request URL: 手紙の宛先（URL）
  • Request Method: 用件の種類（GET、POSTなど）
  • Status Code: 返事の番号（200、404など）

この3つが読めれば、エラーが出たときに「どこに送った手紙が、どんな返事で返ってきたか」を自分の目で確認できる。

バイブコーディングで「これを知っていると助かる」3つの場面

エラー発生時の確認フロー
図: エラー発生時の確認フロー

場面1: AIが生成したコードで画面が真っ白になった

画面が真っ白になったとき、多くの人は「コードが間違っている」と思ってAIに「直して」と投げる。でも、その前にNetworkタブを開いてみてほしい。

もし赤い行があって、ステータスコードが500なら、サーバー側のコードに問題がある。404なら、URLの設定が間違っている。エラーがないのに画面が白いなら、画面を描画するコード（フロントエンド）の問題だ。

この切り分けができるだけで、AIへの質問が「画面が真っ白です。直してください」から「/api/products にGETリクエストを送ると500エラーが返ってきます。サーバー側のコードを確認してください」に変わる。

後者の質問のほうが、AIは圧倒的に正確な答えを返してくれる。

場面2: フォームを送信しても何も起きない

お問い合わせフォームや会員登録フォームを送信しても、画面が変わらない。これもNetworkタブで確認する。

フォームの送信ボタンを押したとき、Networkタブに新しいリクエストが追加されたか。追加されていなければ、そもそもリクエストが送られていない。ボタンとフォームの接続がされていないということだ。

リクエストが送られているのに画面が変わらないなら、レスポンスのステータスコードを確認する。200なのに画面が変わらないなら、レスポンスの内容は正しく届いているが画面の更新処理がない。500なら、送信先のサーバー側のコードに問題がある。

このように「リクエストが送られたのか」「レスポンスは何が返ってきたのか」を見るだけで、原因の方向性が分かる。

場面3: ログイン後のページで「権限がない」と言われる

Supabase を使ったアプリで、ログインしたはずなのにデータが表示されない。403 Forbidden が返ってきている。

これは「ログインはできたが、データへのアクセス権限がない」という状態だ。Supabaseを使っている場合、RLSポリシー（誰がどのデータを見られるかのルール）が設定されていないか、設定が間違っている可能性が高い。

AIへの質問は「Supabaseの products テーブルにGETリクエストを送ると403が返ってきます。RLSポリシーを確認してください」となる。「データが表示されません」よりも、はるかに的確な修正が返ってくる。

リクエストとレスポンスの「中身」をもう少しだけ

手紙のたとえをもう1段階だけ掘り下げる。実際のリクエストとレスポンスには、手紙の封筒にあたる部分と、中に入っている便箋にあたる部分がある。

封筒にあたるのが「ヘッダー」。手紙の差出人、日時、手紙の形式（日本語か英語か）などが書いてある。

便箋にあたるのが「ボディ」。実際のデータ、つまりページのHTML（画面の構造を書いたファイル）やJSON（ジェイソン: データをやりとりするための書式）が入っている。

バイブコーディングで特に重要なのはボディだ。APIを使うアプリでは、レスポンスのボディにJSONという形式でデータが入っている。開発者ツールのNetworkタブでレスポンスの「Response」や「Preview」を開くと、実際のデータを見ることができる。

ここで「APIから返ってきたデータにユーザー名が入っていない」と気づけば、AIに「APIのレスポンスにusernameフィールドが含まれていません。サーバー側のSELECT文を確認してください」と的確に伝えられる。

よくある不安と答え

開発者ツールを開くと何か壊れないか？

壊れない。開発者ツールは「見る」ための機能であって、何かを変更する機能ではない。プロのエンジニアも毎日使っている道具だ。閉じれば元の画面に戻る。

ステータスコードを全部覚える必要があるか？

必要ない。200（成功）、404（見つからない）、500（サーバーエラー）、403（権限なし）の4つだけ覚えれば、実務の9割はカバーできる。残りは遭遇したときに調べれば十分だ。

リクエストやレスポンスが英語で読めない

全部読む必要はない。見るべきは3つだけ。URL（宛先）、Method（GET/POST）、Status Code（番号）。この3つは英単語というより「記号」として見ればいい。数字と単語の組み合わせだけで意味が分かるようになっている。

これを知らなくてもバイブコーディングはできるのでは？

動くものを作るだけなら、知らなくても進められることはある。でも「動かなくなったとき」に詰まる。エラーの原因が分からないまま何度もAIに投げ直して、結局30分以上かかるパターンは多い。リクエストとレスポンスの概念を知っているだけで、エラー解決の時間が半分以下になる。

まとめ

Webアプリは「手紙のやりとり」で動いている。ブラウザがリクエスト（手紙）を送り、サーバーがレスポンス（返事）を返す。返事には番号（ステータスコード）が付いていて、200は成功、404は宛先不明、500はサーバーの問題、403は権限不足。ブラウザの開発者ツールを開けば、この手紙のやりとりを自分の目で見ることができる。バイブコーディングでエラーに遭遇したとき、まずNetworkタブを開いてステータスコードを確認する。それだけで「何が起きているか」が分かり、AIへの質問の精度が上がり、解決が早くなる。

🎁 特典

この記事で解説したリクエストとレスポンスの仕組みを、1枚のチェックシートにまとめた。エラーが出たときに見るべきポイント、ステータスコードの早見表、開発者ツールの開き方が書いてある。バイブコーディング中に手元に置いておくと、エラーの切り分けに迷わなくなる。

→ バイブコーディング Webの仕組みチェックシート（PDF）を無料ダウンロード /resources

📚 参考リファレンス