フロントエンド・バックエンド・データベース — 3層構造を理解する
バイブコーディング入門 — 第2回
前回のおさらいと、今回のテーマ
前回（第1回）では、Webアプリは「手紙のやりとり」で動いていることを解説した。ブラウザがリクエスト（手紙）を送り、サーバーがレスポンス（返事）を返す。この繰り返しだ。
では、その「サーバー」の中では何が起きているのか。ブラウザに表示されるページは、どこで作られているのか。ユーザーが入力した情報は、どこに保存されているのか。
今回は、Webアプリを構成する3つの役割について解説する。フロントエンド、バックエンド、データベース。この3つだ。
バイブコーディングでAIにアプリを作ってもらうと、大量のファイルが生成される。「このファイルは何をしているのか」「エラーはどこで起きているのか」を判断するためには、この3層構造の理解が欠かせない。
レストランに例えると、すべてが分かる
Webアプリの3層構造は、レストランの運営に似ている。
レストランには3つの場所がある。ホール（客席）、キッチン（厨房）、冷蔵庫・食材倉庫だ。お客さん（ブラウザを使っている人）が直接見るのはホールだけ。でも、料理が出てくるまでに、キッチンで調理が行われ、冷蔵庫から食材が取り出されている。
Webアプリも同じだ。
フロントエンド ＝ ホール。あなたがブラウザで見ている画面そのものだ。ボタンの配置、文字の色、アニメーション。見た目と操作に関わるすべてがフロントエンドだ。
バックエンド ＝ キッチン。画面には見えないが、裏側で動いている処理だ。「ログインボタンが押されたら、このユーザーのパスワードが正しいか確認する」「商品一覧のリクエストが来たら、商品データを集めて返す」といった仕事をしている。
データベース ＝ 冷蔵庫・食材倉庫。ユーザー情報、商品データ、注文履歴など、アプリが扱うデータを保管しておく場所だ。バックエンドが必要に応じてデータベースからデータを取り出したり、新しいデータを保存したりする。
3層の間で何が起きているか
前回学んだリクエストとレスポンスの話と、今回の3層構造を組み合わせると、Webアプリの処理の全体像が見えてくる。
たとえば、あなたが作ったアプリで「ユーザー一覧を表示する」場合、こういう流れになる。
- あなたがブラウザでユーザー一覧ページを開く
- フロントエンド（ブラウザ）がバックエンド（サーバー）にリクエストを送る:「ユーザーの一覧をください」
- バックエンドがデータベースに問い合わせる:「ユーザーの一覧を出して」
- データベースがバックエンドにユーザーの一覧を返す
- バックエンドがデータを整理して、フロントエンドにレスポンスとして返す
- フロントエンドが受け取ったデータを画面に表示する
この流れは、レストランの注文と同じだ。お客さん（フロントエンド）が注文する → ホールスタッフがキッチン（バックエンド）に伝える → キッチンが冷蔵庫（データベース）から食材を取り出す → キッチンが料理を作る → ホールスタッフがお客さんに料理を届ける。
CursorやClaude Codeが作るファイル、どれがどの層？
バイブコーディングでAIにアプリを作ってもらうと、たくさんのファイルが生成される。Next.js（Webアプリを作るためのフレームワーク）を使っている場合、生成されるファイルの多くは上のどちらかに分類できる。
フロントエンドのファイルは、名前に page、layout、component といった言葉が含まれていることが多い。画面に何を表示するか、ユーザーがボタンを押したときにどう動くかを定義している。
バックエンドのファイルは、app/api/ フォルダの中や、lib/ フォルダの中にあることが多い。データの取得、保存、計算、外部サービスとの連携など、画面には見えない処理を担当している。
データベースは、Supabase（スーパベース）やPrisma（プリズマ）といったサービス・ツールを通じて操作される。supabase/ フォルダ内のファイルや、データベースへの問い合わせ処理を書いたファイルがこれにあたる。
全部を正確に分類できなくても大丈夫だ。大事なのは「フロントエンドとバックエンドとデータベースは、別の仕事をしている」という感覚を持つことだ。
エラーが起きたとき、3層構造で考える
この3層構造を理解しておくと、エラーが起きたときの対処が変わる。
たとえば、「画面は表示されるが、データが出てこない」という問題が起きたとする。
3層構造で考えると、原因の候補は3つに絞られる。
原因1: フロントエンドの問題。データは裏側で正しく取得できているが、画面への表示処理にバグがある。
原因2: バックエンドの問題。フロントエンドからのリクエストは届いているが、バックエンドの処理でエラーが起きてデータを返せていない。
原因3: データベースの問題。バックエンドの処理自体は正しいが、データベースにデータが存在しない、または接続できない。
この切り分けができると、AIへの指示が格段に具体的になる。
「データが表示されません」→ AIは全体を見回す必要があり、的外れな修正を返しやすい
「/api/usersにリクエストを送ると200 OKが返ってくるが、中身が空配列です。データベースにデータが入っているか確認してほしい」→ AIはデータベース周りだけを確認すればいいので、正確な回答を返しやすい
前回学んだステータスコードと、今回の3層構造を組み合わせると、こういう切り分けができる。
- 画面が真っ白 → フロントエンドの問題の可能性が高い
- 404エラー → バックエンドのURL（リクエストの宛先）が間違っている
- 500エラー → バックエンドまたはデータベースの処理でエラーが起きている
- 200 OKだがデータが空 → データベースにデータがない、またはバックエンドの問い合わせ条件が間違っている
「フルスタック」という言葉の意味
AI関連の記事やツールの説明で「フルスタック」という言葉を見かけることがあるかもしれない。これは「フロントエンドからバックエンド、データベースまで、すべての層を扱える」という意味だ。
CursorやClaude Codeが「フルスタックのWebアプリを生成できる」と言われるのは、3層すべてのコードを自動で書いてくれるからだ。あなたが「ToDoアプリを作って」と頼むと、AIは画面（フロントエンド）、データの処理（バックエンド）、データの保存先（データベース）をまとめて生成する。
これは便利だが、同時にリスクでもある。どの層で何が起きているかを把握していないと、問題が起きたときにすべてが「ブラックボックス（中身が見えない箱）」になる。3層構造を理解しておけば、ブラックボックスの中に光を当てることができる。
実際のフォルダ構造を見てみよう
CursorやClaude Codeで Next.js のプロジェクトを作ると、上のようなフォルダ構造が生成されることが多い。
ここで大事なのは、ファイルを1つ1つ理解することではない。「このファイルはフロントエンドだな」「これはバックエンドの処理だな」と、大まかな分類ができるようになることだ。
目安として覚えておくと便利な法則がある。
- app/ の直下にある page.tsx や layout.tsx → フロントエンド（画面）
- app/api/ の中にあるファイル → バックエンド（データ処理）
- lib/ の中にあるファイル → バックエンドのロジック（計算や外部連携）
- components/ の中にあるファイル → フロントエンド（UI部品）
- supabase/ や prisma/ → データベース関連
AIが生成したファイルの一覧を見たときに、この分類を頭の片隅に置いておくだけで、コードの全体像がつかみやすくなる。
よくある不安と答え
3つの層の境目が曖昧に感じる。厳密に分けられないと意味がないのか？
厳密に分ける必要はない。特にNext.jsのようなフレームワークでは、フロントエンドとバックエンドの境目が曖昧になるケースがある（1つのファイルで両方の処理を書けることがある）。大事なのは「画面の話をしているのか」「データ処理の話をしているのか」「データの保管の話をしているのか」という、大まかな区別ができることだ。
データベースを使わないアプリもあるのか？
ある。たとえば、単純な計算ツールや、データを保存しないランディングページ（商品紹介ページ）は、フロントエンドだけで完結することもある。ただし、ログイン機能やデータの保存が必要なアプリは、ほぼ確実にデータベースが必要になる。
3層構造を知らなくても、AIに全部任せればいいのでは？
任せることはできる。ただし、AIが生成したコードにバグがあったとき、あなたが「どの層の問題か」を伝えられないと、AIも正しく直せない。AIは優秀なシェフ（料理人）だが、「味がおかしい」とだけ言われるより「塩が多い」と言われたほうが、正確に直せる。3層構造の理解は、AIへのフィードバックの精度を上げるための知識だ。
まとめ
Webアプリは3つの層で構成されている。フロントエンド（画面）、バックエンド（裏側の処理）、データベース（データの保管場所）。レストランに例えるなら、ホール、キッチン、冷蔵庫だ。エラーが起きたとき、この3つのどこで問題が起きているかを切り分けるだけで、AIへの指示の精度が大きく変わる。CursorやClaude Codeが生成するファイルも、この3層のどれかに分類できる。全部を詳しく知る必要はないが、「地図」として持っておくと、AIが書いたコードの見え方が変わる。
次回は「Webの歴史を5分で」。なぜ今のWebアプリがこの形になったのか、その経緯を短く振り返る。
参考リファレンス
- MDN Web Docs「Webの仕組み」— Webの基本概念を網羅した公式リファレンス
- 前回: 第1回「あなたのWebアプリは『手紙のやりとり』で動いている」（/articles/vc-001）
- 次回: 第3回「Webの歴史を5分で — なぜ今の形になったのか」（/articles/vc-003）
- バイブコーディング入門 カリキュラム（/vibe-coding）
