本物のバックエンドとデータベースを持つAIアプリ:完全ガイド(2026年版)

本物のバックエンドを作るAIアプリビルダーはどれか — そして何が「本物」なのか?

短い答え:本物のバックエンドとは、永続的なPostgreSQLデータ、サーバーサイド認証、そしてサーバー上でルールを強制するREST APIのことです — ログインフォームが誰も認証せず、ダッシュボードのチャートがハードコードされたJSONを描画するだけの美しいReactフロントエンドではありません。ほとんどのAIアプリビルダーは後者を生成します。VULK(私たちのプロダクト — 開示は下記)は前者を生成してデプロイします:プロンプトがアカウント、保存データ、管理者ロールを記述すると、本物のバックエンドを自動でプロビジョニングします — PostgreSQLスキーマ、CRUDエンドポイント、ロール付きJWT認証 — フロントエンドと並んで、配線されデプロイされた状態で。LovableとBoltは別の正当な道を取ります:バックエンドをSupabaseに委ねる方式で、うまく機能しますが、2つ目のプラットフォームを運用することになります。フロントエンドファーストのツールは、難しい60%をあなた自身に任せます。

この需要はエッジケースではありません:VULKで生成された全アプリの62%がSQLスキーマを含みます(VULKプラットフォームデータ、2026年7月、生成された11,355アプリ全体)— 「アプリ」をプロンプトする人の大半は、自覚の有無にかかわらず、ユーザーとデータを持つ何かを記述しています。このガイドはすべてをカバーします:本物のバックエンドの4つのテスト、自動プロビジョニングの仕組み、生成されるスキーマと認証の実際、セキュリティパターン、デプロイ、コピペで使える6つの完全なプロンプト、そして — ベンダーが口ごもる部分 — エクスポートと移植性の正直な話、私たち自身のものも含めて。開示:VULKは私たちのプロダクトです。 2026年7月17日更新。

比較表:AIビルダーはバックエンドをどう扱うか

「フルスタックAIビルダー」というラベルの裏には3つのアーキテクチャが隠れています。生成型(VULK、Databutton):AIがスキーマ、エンドポイント、認証をアプリの一部として書きます — 最も統合されており、生成されたサーバーコードを信頼することになります(検査可能です。検査してください)。委任型(Lovable、Bolt → Supabase):ツールがフロントエンドをマネージドBaaSに配線します — 優れたDXときれいなデータ移植性、しかし2つのプラットフォームを運用し、BaaSの形を受け継ぎます。埋め込み型(Base44):セットアップゼロ、出口もゼロ。どれも間違いではありません。成長するにつれ、異なる形で限界が来るのです。料金は2026年7月17日に確認済み。

フロントエンドのみのAIアプリには実際何が欠けているのか?

どんな「AIアプリビルダー」のデモも、4つのテストにかけてみてください:

1. 永続性: データを作成し、再デプロイして、まだ残っていますか? モックデータのアプリはリセットされます。localStorageのアプリはデータを1つのブラウザに人質に取ります。
2. 本物の認証: ログインフォームは資格情報をサーバー上で検証し、セッションを発行しますか? クライアントサイドの「認証」は飾りです — 誰でもDevToolsを開いて素通りできます。
3. サーバーで強制されるルール: ユーザーAはリクエストのIDを変えるだけでユーザーBのレコードを取得できますか? バリデーションがReactの中だけに生きているなら、答えはイエスです。
4. 検査可能なデータ: 自分のデータベースに対してSQLを実行できますか?

これらに落ちれば、あなたが持っているのはプロトタイプです — アイデアの検証には本当に役立ち、v0のようなツールが輝く場所です。しかし、そのプロトタイプとプロダクトの間の隔たりこそがバックエンドです:アカウント、ロール、バリデーション、リレーション、マイグレーション。歴史的にエンジニアリング時間の大半を食ってきた部分であり、VULKの生成の62%が結局必要とする部分です(VULKプラットフォームデータ、2026年7月)。

VULKはどうやってバックエンドを自動プロビジョニングするのか?

「バックエンドを追加して」と言う必要はありません。検出はプロンプトからシグナルを読み取ります:

• 認証シグナル — 「ログイン」「サインアップ」「ユーザーアカウント」「管理画面」「ロール」:認証システムをトリガー。
• 永続化シグナル — 「保存」「格納」「履歴」「レコード」「データベース」:スキーマ + CRUD生成をトリガー。
• APIシグナル — 「エンドポイント」「REST」「webhook」:ルート生成をトリガー。

検出は意図的に保守的です — ランディングページやポートフォリオは高速な静的フロントエンドのまま。「ユーザーが出品を投稿して出品者にメッセージを送れる」というプロンプトはフルスタックを受け取ります。トリガーされると、1回の生成が4つの連携したレイヤーを生み出します:

1. PostgreSQLスキーマ — テーブル、型、制約、外部キー、インデックス。プロンプト内のエンティティから導出。
2. REST API — エンティティごとの完全なCRUD、バリデーション、ページネーション、正しいステータスコード付き。VULKのAPIエンジンにデプロイ。
3. 認証システム — 登録とログインのエンドポイント、bcryptによるパスワードハッシュ、JWT発行、プライベートルートを守るミドルウェア、プロンプトがロールを示唆すればロールチェック。
4. 配線済みフロントエンド — ReactアプリはこのAPIに対して生成されます:fetch呼び出しは実在のエンドポイントを指し、トークンはリクエストに付き、ローディングとエラーの状態が存在します。ログインフォームで本当にログインできます。この最後のレイヤーこそが、「バックエンドを生成した」と「自分で統合する羽目になる2つの半分を生成した」を分けるものです。

エディタは続いてバックエンドパネルを提供します:テーブルと行のブラウズ、クエリランナーでの生SQL実行、APIテスターでのエンドポイントのテスト、任意のテーブルのCSVエクスポート。あなたのデータは決してカーテンの裏に隠れません。

生成されるSQLスキーマはどんなものか?

スキーマの品質がアプリケーションの品質を決めるため、生成は丁寧なデータベースエンジニアが使うパターンを強制します。「ユーザーがプロジェクトを作りタスクを追加するタスクマネージャー。ユーザーは自分のプロジェクトだけを見られる」に対して:

CREATE TABLE users (
  id            SERIAL PRIMARY KEY,
  email         VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  name          VARCHAR(120) NOT NULL,
  role          VARCHAR(20) NOT NULL DEFAULT 'member',
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE projects (
  id         SERIAL PRIMARY KEY,
  user_id    INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  name       VARCHAR(160) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE tasks (
  id          SERIAL PRIMARY KEY,
  project_id  INTEGER NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  title       VARCHAR(200) NOT NULL,
  description TEXT,
  priority    VARCHAR(10) NOT NULL DEFAULT 'medium'
              CHECK (priority IN ('low','medium','high')),
  status      VARCHAR(12) NOT NULL DEFAULT 'open'
              CHECK (status IN ('open','in_progress','done')),
  due_date    DATE,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_projects_user_id ON projects(user_id);
CREATE INDEX idx_tasks_project_id ON tasks(project_id);
CREATE INDEX idx_users_email ON users(email);

意図的な選択であり、それぞれが素朴な生成コードによくある失敗です:

• password_hash、決してpasswordではない。 カラム名そのものが、平文保存をうっかり書くことを不可能にします — プロンプトエンジニアリングのレベルで強制されるルールです。
• 意図的な削除挙動を持つ外部キー — 子が親より生き残るべきでない場所にはON DELETE CASCADE、孤児が生き残るべき場所にはSET NULL(削除されたカテゴリより長生きする商品)。
• 有界値へのCHECK制約 — タスクのステータスが静かに"donee"になることはできません。
• クエリパターンに合わせたインデックス — 外部キー、ログイン検索用のメール、ソート列。
• すべてのテーブルにタイムスタンプ。 必要になるまでは退屈。必要になれば決定的です。

なぜMongoDBやFirebaseではなくPostgreSQLなのか? 人々がプロンプトするアプリは圧倒的にリレーショナルだからです — 注文は品目を含み、タスクはプロジェクトに属し、プロジェクトはユーザーに属します — そして制約付き外部キーは、ドキュメントには不可能な整合性保証でそれを表現します。さらに、サードパーティのBaaSへの依存は「1つのプロンプトで動くデプロイ済みアプリ」を、2つ目のプラットフォームでのアカウント作成で壊してしまうからです。Postgresは本番のために手で選ぶものであり、だから生成されるのです。

生成される認証はどう機能するのか?

認証は生成された近道が侵害になるレイヤーだからこそ、あるべき姿で構築された完全な認証フロー:

• POST /api/auth/register — 入力を検証し、パスワードをbcryptでハッシュ化(決して平文ではなく、決して可逆ではない)、password_hashに保存し、JWTを返します。
• POST /api/auth/login — bcryptハッシュを比較し、成功時に署名付きJWTを発行。メール違いとパスワード違いで同じエラー(アカウント列挙の防止)。
• すべての保護されたルートのミドルウェアがJWTをサーバーサイドで検証。フロントエンドは自動的に付与します。
• クエリでの行レベル所有権 — 検証済みトークンからのWHERE user_id = $1。URLのIDを変えても他人の行は読めません。
• ロールはプロンプトで求められたとき(「管理者は商品を管理できる」)— ミドルウェアでチェックされるroleカラム、管理者専用エンドポイント、対応する条件付きUI。

認証の傍らには、選択の余地のないセキュリティのデフォルト:あらゆる場所でのパラメータ化クエリ(文字列連結のSQLなし)、すべてのエンドポイントでのサーバーサイド入力検証、アプリのオリジンに限定されたCORS、認証エンドポイントのレート制限。生成された認可ロジックは、速いジュニア開発者の仕事をレビューするのと同じように、ローンチ前にレビューしてください — パターンは正しい。あなたのアプリ固有の「誰が誰のデータを見られるか」のルールには人間の目が必要です。

フルスタックアプリのための完全なコピペ用プロンプト6選

それぞれが完全で、意図的にバックエンド生成を働かせます — アカウント、リレーション、ロール、集計。そのまま貼り付けてください。

1. チーム付きSaaSタスクマネージャー:

Taskframeというタスク管理アプリを作って。ユーザーはサインアップし、プロジェクトを作り、タイトル、説明、優先度(低/中/高)、期限、ステータス(未着手/進行中/完了)を持つタスクを追加する。ユーザーはメールでチームメイトをプロジェクトに招待できる。メンバーは共有プロジェクトを見られるが、プロジェクトの削除やメンバーの除外はオーナーだけができる。ビュー:カラム間ドラッグ対応のステータス別ボードと、ソートとフィルター付きのリストビュー。ダッシュボードは全プロジェクト横断の自分の未完了タスクを期限順に表示し、期限切れは赤で。クリーンなライトUI、インディゴのアクセント。

2. 管理画面付きECストア:

Kiln & Co.というハンドメイド陶器のオンラインストアを作って。顧客はカテゴリフィルター付きの商品グリッドを見て回り、商品詳細ページを見て、カートに入れ、チェックアウトする(配送先住所フォーム + モック決済)。注文はアカウントに履歴として保存される。管理者ロール:別の/adminエリアに商品管理(名前、価格、在庫、カテゴリ、説明を持つ商品の作成、編集、アーカイブ)、ステータス更新付き注文リスト(未処理/発送済み/配達済み)、月別売上サマリー。注文で在庫が減る。在庫ゼロの商品は売り切れ表示になり注文できない。温かみのあるミニマルデザイン、テラコッタのアクセント。

3. 予約プラットフォーム:

ヨガスタジオの予約アプリを作って。公開部分:今週のクラススケジュール(名前、講師、時間、残席)、サインアップとログイン。会員はクラスの席を予約する — 定員はサーバーサイドで強制され、満席のクラスは追加予約を拒否する — 開始2時間前までキャンセル可能。マイ予約ページは今後と過去のクラスを表示。スタッフロール:クラスの作成と編集(名前、講師、曜日、時間、定員)、クラスごとの名簿の確認、出席の記録。同じ会員の同じクラスへの二重予約を防ぐこと。落ち着いたセージとクリームのデザイン。

4. 顧客フィードバックボード:

ミニマルなプロダクトロードマップツールのような公開フィードバックボードを作って。ログイン済みなら誰でもアイデアを投稿でき(タイトル、説明、カテゴリ)、他のアイデアにupvoteできる — ユーザーごとアイデアごとに1票、切り替え可能。アイデアは票数か新しさでソート。それぞれにコメントスレッド。管理者ロール:アイデアのステータス変更(検討中/計画済み/進行中/リリース済み)、アイデアのピン留め、スパムの削除。公開ロードマップページはアイデアをステータス別のカラムにまとめる。ステータス変更はアイデアのアクティビティフィードに現れる。ダークテーマ、エレクトリックブルーのアクセント。

5. 請求書アプリ:

フリーランサー向けの請求書アプリを作って。ユーザーは顧客(会社、担当者名、メール、住所)を管理し、請求書を作成する:顧客、明細行(説明、数量、単価)、税率、支払期限、ユーザーごとに自動生成される連番の請求書番号。請求書のステータス:下書き、送付済み、支払済み、期限超過 — 期限超過は支払期限から自動計算。ダッシュボード:未回収合計、今月の入金、期限超過の件数、6か月の売上棒グラフ。共有リンクでアクセスできる印刷向けレイアウトの公開閲覧専用請求書ページ。プロフェッショナルなスレートと白のデザイン。

6. コミュニティレシピプラットフォーム:

コミュニティのレシピ共有プラットフォームを作って。ユーザーは登録し、レシピを公開し(タイトル、写真プレースホルダー、材料リスト、番号付き手順、調理時間、難易度、タグ)、自分のものだけを編集・削除できる。みんながタグやタイトル・材料の全文検索で閲覧できる。各レシピには星評価(ユーザーごとに1つ、編集可能)があり平均評価順にソート、さらにコメント。ユーザープロフィールは自分のレシピと保存したお気に入りを表示。ホームページ:今週の高評価と最新。モデレーターロールはレシピとコメントを削除できる。フレッシュなグリーンとクリームのデザイン、セリフの見出し。

パターンの読み方:エンティティとそのフィールドを名指しし、誰が何をできるかを述べ(「削除できるのはオーナーだけ」)、守られるべきルールに言及する(「定員はサーバーサイドで強制」「ユーザーごとに1票」)。それらの文が外部キー、ミドルウェア、制約になります。

フルスタックアプリのデプロイとプレビューはどう機能するのか?

生成中、フロントエンドはホットリロード付きのライブプレビューmicroVMで動き、すでに生成された本物のAPIと通信しています — プレビューでテストしたサインアップは実際の行を書き込み、バックエンドパネルのテーブルブラウザですぐに確認でき、生SQLでクエリもできます。デプロイはフロントエンドをCloudflareのエッジへ、バックエンド + PostgreSQLをVULKのインフラへ送り出します。ワンクリック、ライブURL、カスタムドメイン対応。バックエンド + PostgreSQLのデプロイはBuilderプラン($19.99/月)以上に含まれます。デプロイ後の反復は同じフォローアッププロンプトのループで、スキーマ変更はデータを破壊するリビルドではなくマイグレーションとして扱われます。

すべてをエクスポートして離れられるか?(正直な答え)

ユーザーが10,000人になる前に、どのプラットフォームにも聞くべき質問です。VULKの答えには強い半分と限定的な半分があります — 両方を正確に:

きれいにエクスポートできるもの:

• フロントエンドの完全なソース — ZIPダウンロードまたはGitHubプッシュ。プロプライエタリな依存のない標準的なReact + Vite + TypeScriptプロジェクト。
• 完全なスキーマ — schema.sqlがソースエクスポートに同梱。
• すべてのデータ — バックエンドパネルからテーブルごとのCSVエクスポート(表示中のページだけでなくテーブル全体)、加えてクエリランナー経由の生SQLアクセス。

できないもの: バックエンドのランタイム。生成されたCRUDエンドポイントと認証を提供するAPIエンジンはVULKのホスト型インフラであり、エクスポートされたフロントエンドはそのホスト先URLを呼びます。フルスタックアプリをエクスポートすればフロントエンドはどこでも動きます — が、VULKのAPIと話し続けます。全体をセルフホストするにはAPI層の再実装が必要です(エクスポートしたスキーマとデータが完全な仕様書になります — Expressでも何でも、範囲の限られた再構築ですが、本物の作業です)。

市場の他社が同じ質問にどう答えるかの文脈:Lovable/Boltは最もきれいなデータ移植性を持ちます — Supabaseプロジェクトはあなたのもの、pg_dumpして終わり(エッジファンクションとRLSポリシーのバックエンドロジックの移行は別途必要)。Replitはコードへの完全アクセスを与えます。あなたのVMです。Base44にはバックエンドのエクスポートが一切ありません。フロントエンドのみのツールは、そもそもデータを持たないことでこの質問をかわします。どのツールを選ぶにせよ:エクスポートの道は12か月目ではなく、1週目にテストしてください。