Lovable AI で作るSaaS MVP 完全テンプレート2026

この記事でわかること

Lovable で SaaS の MVP を最短で立ち上げるためのテンプレ手順
ランディング・認証・課金・管理画面を分割して指示する設計術
検証フェーズで捨てやすいコード構造の作り方

結論

Lovable は「自然言語ベースで UI とフロントロジックを高速に作る」用途に特化しているため、SaaS MVP のフロント部分とランディングを 1〜2 日でまとめて作るのに向きます。逆にバックエンドの複雑なロジックは Supabase Edge Functions など外部に逃がす設計のほうが手戻りが少なくなります。

本題

Lovable で MVP を作る際の構成図

中級者向けに、最初に頭に置いておく構成は次の4ブロックです。

公開ランディング: 機能紹介・料金・お問い合わせ
認証: メール+パスワード or Magic Link
ダッシュボード: ユーザーが日々触る本体機能
課金: Stripe Checkout への誘導と Webhook ハンドラ

Lovable は1〜3を得意としますが、4 の Webhook 処理は Supabase Edge Functions または Vercel Serverless に切り出すのが無難です。

ステップ1: ランディングを先に作る

SaaS は「売れるかどうか」を最初に検証するのが目的なので、ランディングを最初に出します。プロンプト例:

B2B 向けの議事録自動要約 SaaS のランディングページを作ってください。
セクション: ヒーロー / 課題 / 機能3つ / 料金プラン3つ / FAQ / CTA
トーン: 落ち着いた紺＋アクセントオレンジ、スクショ風モックを2枚配置
CTA: 「無料で試す」ボタンで /signup へ遷移

ランディング段階では認証も DB も不要なので、純粋にコピーとデザインの調整だけに集中できます。

ステップ2: 認証フローを Supabase で組む

Lovable の AI チャットに「Supabase Auth でメール+パスワードのサインアップ・ログイン・パスワード再設定の3画面を作って」と頼むと、テンプレ的な画面が出ます。

ポイントは2つ。 - メール確認リンク先を本番ドメインに合わせて Supabase 側で設定する - パスワード再設定の遷移は同一ドメイン内で完結させる（クロスドメインだと Cookie が消える）

ステップ3: ダッシュボードは「画面1つずつ」追加

中級開発者ほど一気に作りたくなりますが、Lovable の場合は画面を1つずつ追加するほうがトラブルシュートが楽です。

ダッシュボード /app/dashboard を追加してください。
左サイドバーに「議事録一覧」「アップロード」「設定」の3メニュー。
メイン領域は議事録一覧（テーブル: タイトル / 作成日 / 文字数 / 操作）。
データは supabase.from('minutes') から取得し、自分のものだけ表示。

機能を追加するたびに動作確認 → コミット → 次の機能、というリズムを守ります。

ステップ4: 課金はテンプレで割り切る

MVP段階では Stripe Checkout のテンプレに乗るのが最速です。Lovable 内部では「Stripe Checkout のリンクを生成する関数」と「成功後リダイレクトページ」だけ作り、Webhook (checkout.session.completed) は Supabase Edge Functions で実装します。

擬似コード:

// supabase/functions/stripe-webhook/index.ts
serve(async (req) => {
  const sig = req.headers.get("stripe-signature")!;
  const event = stripe.webhooks.constructEvent(await req.text(), sig, WEBHOOK_SECRET);
  if (event.type === "checkout.session.completed") {
    const userId = event.data.object.metadata?.user_id;
    await supabase.from("subscriptions").insert({ user_id: userId, plan: "pro" });
  }
  return new Response("ok");
});

ステップ5: 捨てやすい構造を意識する

MVP は捨てる前提で作ります。Lovable で生成されるコードは比較的素直な React/Next.js なので、ロジックを lib/ 以下に集中させ、画面ファイル側は薄くしておくと、後から別フレームワークへの引っ越しが楽です。

よくある質問（FAQ）

Q1: Lovable と Bolt.new はどう使い分けますか？

A1: UI の作り込みやコピーライティング寄りの調整は Lovable、フルスタックでバックエンドまで一括生成したい場合は Bolt.new、というのが2026年時点の感覚的な目安です。

Q2: Stripe ではなく Paddle や Lemon Squeezy でも作れますか？

A2: 可能です。Webhook シークレットとイベント名を読み替えるだけで、フロント側の Checkout 誘導とリダイレクト処理はほぼ同じ構造で動きます。

Q3: 開発を途中で Lovable から離脱できますか？

A3: できます。生成されたコードは GitHub 連携でエクスポートできるので、以後はローカルで通常の Next.js プロジェクトとして開発を続けられます。

まとめ

Lovable で SaaS MVP を作る際は「ランディング先行 → 認証 → ダッシュボード分割 → 課金は外部委譲」の順で進めると、1〜2日で検証用の有償β版まで到達できます。中級開発者は最初の構成図を意識し、捨てやすいコード配置で素早く検証サイクルを回しましょう。