[バイブコーダー #1] AI生成アプリを解剖する：フロントエンド・バックエンド・DBの役割

AIに言葉で指示してアプリを作る人が急増しています。CursorやClaude Code、v0などに「こんなサービスを作って」と頼めば、本当に動くアプリが出てきます。しかし完成後、多くの人が同じ壁にぶつかります。アプリは動くのに、AIが何を作ったのか分からない。エラー時にどこを見て、AIへ何を聞けばよいかも分かりません。

この壁を越える第一歩は、コードを読む力ではありません。アプリを構成する部品と、それぞれがどこで何をするかを知り、構造の地図を持つことです。開発者がフロントエンド、バックエンド、DBと呼ぶ三つの部品です。この記事では、この三つを非開発者にも分かるように解説します。この地図があれば、次回以降のAPIキー、Git、デプロイ、料金の問題も整理できます。

アプリはレストランと同じ構造です

Webアプリでもモバイルアプリでも、ユーザー向けサービスの多くは三つの部分で構成されます。レストランにたとえると、ぴったり理解できます。

**ホール（フロントエンド）**は、お客さまが座る場所です。メニュー、テーブル、内装など、直接見たり触れたりするものすべてです。アプリではボタン、入力欄、画面遷移など、目に見えるものが該当します。

**厨房（バックエンド）**は、お客さまから見えない場所です。注文を受けて料理を作り、レシピや食材管理などの営業秘密もここにあります。アプリではログイン、決済、権限確認など重要な処理を担います。

**倉庫（データベース、DB）**は、食材を保管する場所です。厨房が火事で閉まっても、倉庫の食材は残ります。アプリでは会員情報、記事、注文履歴などのデータが実際に保存されます。

お客さま（ユーザー）がメニューから注文すると（フロントエンド）、注文票が厨房へ届き（バックエンド）、厨房が倉庫から食材を取り出して調理し（DB照会）、ホールへ出します。Instagramを更新するたび、この往復が起きています。

フロントエンドはユーザーの端末で実行されます

フロントエンドの最重要ポイントは「どこで実行されるか」です。フロントエンドのコードはサーバーではなく、**ユーザーのブラウザ（またはスマートフォン）**で実行されます。サイトにアクセスするとコードが端末へ送られ、端末が実行して画面を描画します。

ここで、バイブコーダーが必ず知るべき結論があります。**フロントエンドのコードは誰でも閲覧できます。**ブラウザで右クリックして「検証」を選べば、表示中サイトのフロントエンドコードがそのまま見えます。NaverでもTossでも例外はありません。そう設計されているため、完全に防ぐ方法もありません。

したがって、フロントエンドに秘密を置いてはいけません。APIキー、管理者パスワード、決済検証ロジックなどを入れるのは、全世界に公開するのと同じです。AIにコーディングさせると、便宜上こうした値をフロントエンドへ入れてしまうことがあり、知らずにデプロイしてAPIキーを盗用され、高額請求を受ける事故も珍しくありません。この話は第2回で詳しく扱います。

バックエンドは自分のサーバーで実行されます

バックエンドは反対に、自分が管理するサーバーで実行されます。ユーザーはコードを見られず、バックエンドへ「リクエスト」を送り「レスポンス」を受け取るだけです。レストランの客が厨房に入れず、注文票だけを渡すのと同じです。

重要な処理はすべてバックエンドで行う必要があります。

• 秘密の保管：APIキーやDB接続情報などの秘密は、バックエンドだけに置きます。
• 権限確認：「このユーザーに記事を削除する資格があるか」という検査は必ずバックエンドで行います。フロントエンドで削除ボタンを隠すだけでは飾りにすぎません。ボタンが見えなくても、リクエストは誰でも送れるからです。
• 決済と計算：価格計算をフロントエンドで行い、その結果を信じると、リクエストを改ざんして1ウォンで決済される可能性があります。

まとめると、**フロントエンドは見せる場所、バックエンドは決める場所です。**フロントエンドの検査はユーザー向けの案内であり、実際のセキュリティと判断はすべてバックエンドの役割です。

DBはデータが実際に住む場所です

「アプリを削除して再デプロイしたのに会員情報が残っている」と感じたなら、データがアプリではなくDBに保存されているからです。アプリ（フロントエンド＋バックエンド）は作業員、DBは金庫です。作業員を全員替えても、金庫の中身は変わりません。

バイブコーディングでよく使うSupabaseやFirebaseは、このDBを代わりに運用するサービスです。ここから次の区別が生まれます。

• コードをいくら修正して再デプロイしても、データは安全です。
• 一方、DBを初期化すると、コードが正常でもデータはすべて消えます。

「何かを元に戻したい」とき、コードのロールバックとデータ復旧がまったく別問題なのはこのためです。コードはGitで戻し（第3回で扱います）、データはDBバックアップから戻します。一方を戻しても、もう一方は戻りません。

自分のプロジェクトでは、どれがどこか

概念を理解したら、プロジェクトフォルダーに当てはめてみましょう。AIが作ったプロジェクトには多数のフォルダーがありますが、名前に規則があり、おおよその区別ができます。バイブコーディングで最も一般的なNext.jsプロジェクトなら、次のとおりです。

• app/またはpages/、components/→画面を描画するフロントエンドです。ボタンの文言を変えたいときはここを見ます。
• app/api/フォルダー、またはファイル先頭に"use server"と書かれたファイル→バックエンドです。同じプロジェクト内でも、サーバーで実行されるコードです。
• .envファイル→バックエンドが使う秘密の値の保管場所です。APIキーやDB接続情報が入ります。
• DBは通常、プロジェクトフォルダー内にありません。SupabaseやFirebaseのWebサイト（ダッシュボード）へログインして初めて見える、別の空間です。

注意点が一つあります。Next.jsのような最新ツールでは、フロントエンドとバックエンドが一つのプロジェクトフォルダー内に混在しています。フォルダーが一つでも、すべてが同じ場所で実行されるわけではありません。ユーザーブラウザへ送られるファイルもあれば、サーバーだけに残るファイルもあります。迷ったらAIに「このファイルはユーザーブラウザとサーバーのどちらで実行される？」と聞きましょう。この質問で、秘密を置く場所が決まります。

この地図があると変わること

構造を知ると、すぐに三つのことが変わります。

**第一に、エラー時にどこを見るか分かります。**画面がおかしければブラウザの開発者ツールのコンソール（フロントエンドの悲鳴）、保存やログインができなければサーバーログ（バックエンドの悲鳴）を見ます。AIに聞くときも「ブラウザコンソールにこのエラーが出る」と「サーバーログにこのエラーが出る」は全く別の手掛かりで、この区別だけで診断精度が大きく上がります。

**第二に、セキュリティ事故の半分を防げます。**秘密はバックエンドに、権限確認もバックエンドで。この原則だけで、バイブコーディング由来の事故の多くを避けられます。

第三に、AIへの指示が正確になります。「保存ボタンを押すとエラーになる」より「ボタンを押すとバックエンドAPIの呼び出しに失敗するようだ。サーバー側のコードを確認して」と言うほうが、はるかに早く解決します。地図を持つ人の質問は違います。

まとめ

• アプリは、ホール（フロントエンド）・厨房（バックエンド）・倉庫（DB）で構成されるレストランです。
• フロントエンドはユーザー端末で実行され、誰でもコードを見られるため、秘密を置いてはいけません。
• バックエンドは自分のサーバーで実行され、秘密の保管・権限確認・決済などの判断をすべて担います。
• DBはアプリとは別の空間なので、コードを作り直してもデータは残り、DBを削除するとコードが正常でもデータは消えます。
• 迷ったらAIに「このコードはブラウザとサーバーのどちらで実行される？」と聞いてください。

次回は、この構造で事故が最も起きやすいAPIとAPIキーを扱います。なぜキーを隠すのか、公開されると何が起きるのか、プロジェクトのキーが安全か確認する方法までまとめます。