Lovable（ラバブル）とは？使い方・Supabase連携・本番化の落とし穴まで【2026年版】

Lovableを使うと、チャットで指示するだけでUIからバックエンドまで動くアプリができる。SupabaseのデータベースとAuthが自動設定されるため、「データが保存されてログインもできるアプリ」を数時間で作れる。

非エンジニアがMVPを作るツールとして、現実的に最もバランスが取れている選択肢だ。

ただし、「本番に出せるか」という問題は別の話だ。Lovableで作ったアプリをそのまま公開すると、セキュリティの穴が空いている可能性が高い。RLS（行レベルセキュリティ）の設定を間違えると、全ユーザーのデータが誰でも閲覧できる状態になる。これはLovableが悪いのではなく、AIが生成するRLSは「動く最短経路」を選ぶため、実際のアクセス制御として機能しないパターンがあるからだ。

使い方と一緒に、本番化の落とし穴を先に知っておくと遠回りせずに済む。Vibe Codingツール全体の選び方はVibe Coding完全ガイドで整理している。

Lovableとは

Lovableは、自然言語の指示だけでフルスタックのWebアプリを生成するAI開発プラットフォームだ。チャットで「備品管理アプリを作って。ログイン機能と、データの登録・一覧・編集ができるようにして」と書くだけで、UIとバックエンドが揃ったアプリが生成される。

他のVibe Codingツールと決定的に違うのは、Supabaseとの自動連携だ。

• 「ユーザー登録機能を付けて」→ Supabase Authが設定される
• 「データを保存できるようにして」→ SupabaseのテーブルとAPIが生成される
• 「自分のデータだけ見えるようにして」→ RLSポリシーが設定される（ただしこれは要確認）

Bolt.newより認証まわりが安定しているのは、Supabaseとの統合が設計段階から組み込まれているからだ。「ログイン機能を作って」と言ったとき、Bolt.newは自前実装を生成して詰まることが多いが、Lovableはsupabase authに乗るため動作が安定しやすい。

始め方

1. lovable.dev でサインアップ（無料枠あり）
2. 「New Project」からプロジェクトを作成
3. チャット欄に作りたいものを入力して生成開始

プロンプトの例：

「社内の備品管理アプリを作って。備品名・カテゴリ・保管場所・担当者を管理できる。一覧画面と登録・編集画面が欲しい。ログイン機能も付けて。ログインしたユーザーだけアクセスできるようにして」

「ログインしたユーザーだけアクセスできるようにして」という一言が重要だ。これを入れないとRLSが設定されないことがある。

生成されたアプリを確認しながら修正を重ねていく。Lovableはチャットの対話に忠実で、「モバイルでも見やすくして」「一覧にフィルターを追加して」といった細かい修正も比較的安定して動く。

料金プラン

「メッセージ数」がLovableのクレジット単位だ。複雑な指示ほどメッセージを消費する。本格的にMVPを作るならLaunchプランが現実的で、途中でクレジット切れになって止まるストレスがない。

Supabase連携で起きる落とし穴

LovableとSupabaseの連携は便利だが、本番化するときに問題が出やすい部分がある。

RLSポリシーが意図通りになっていない

Lovableが自動設定するRLSポリシーは、よく確認しないと「全員がすべてのデータを閲覧できる」状態になっていることがある。

Supabaseの管理画面でTableエディタを開き、「RLS enabled」になっているか確認する。その上で「Policies」タブで実際のポリシーを見てほしい。以下のようなポリシーは危険だ：

-- これは危険：認証なしで全データが読める
CREATE POLICY "anyone can read"
  ON items FOR SELECT
  USING (true);

正しくは：

-- 認証済みユーザーが自分のデータだけ読める
CREATE POLICY "users can read own items"
  ON items FOR SELECT
  USING (auth.uid() = user_id);

Lovableに「RLSポリシーを確認して。ログインユーザーが自分のデータだけ見える設定になっているか確認して」と指示すると、ポリシーを見直してくれる。

開発用と本番用のSupabaseが同じ

Lovable内で使っているSupabaseプロジェクトは開発用だ。本番公開するときは、本番用のSupabaseプロジェクトを別途作成し、テーブル構造をマイグレーションする必要がある。開発中に入れたテストデータと本番データは分離しておかないといけない。

Supabaseの無料枠の制限

ユーザーが増えてくると無料枠では対応できなくなる。本番運用を見据えているならProプランへの移行を前提にしておく。

エクスポート後に何が必要か

LovableはGitHubへのエクスポートに対応している。「Connect to GitHub」からリポジトリを作成できる。

エクスポートした後に直面する問題を知っておく。

環境変数の再設定

Lovable内で自動設定されていたSupabaseの接続情報は、エクスポート先では未設定の状態だ。Vercel・Netlify等のデプロイ先の管理画面で、以下を手動設定する必要がある：

NEXT_PUBLIC_SUPABASE_URL=your-project-url
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

これを忘れると、アプリは表示されてもデータの保存と取得ができない。白画面ではなく「動いているように見えてデータだけ失われる」状態になるため、気づくのに時間がかかることもある。

コードの整理

Lovableが生成するコードは、修正を重ねると重複やデッドコードが増える傾向がある。本番化の前にコードを整理しておくと、後から修正しやすくなる。

本番公開までの現実的な流れ

実際に本番化するとき、どのくらいかかるか。経験上の目安を書く。

• プロトタイプ完成（Lovableで）： 1〜3日
• GitHubエクスポートと環境整備： 半日〜1日
• RLSポリシーの確認・修正： 数時間〜1日（問題が多い場合はそれ以上）
• 本番Supabaseの設定とデータ移行： 半日〜1日
• Vercel/Netlifyへの本番デプロイ・ドメイン設定： 数時間
• エラー監視・バックアップ設定： 半日

合計すると、プロトタイプができた状態から本番公開まで、エンジニアが関与する場合は1〜2週間が現実的な目安だ。自力でやる場合は、セキュリティ知識が必要な部分で詰まることが多く、数週間〜1ヶ月になることもある。

よくある質問

LovableとBolt.newはどちらを選べばいいですか？

認証とデータ保存が必要なアプリを非エンジニアが作るならLovable。速さを最優先にするならBolt.new。Lovableの方がSupabaseとの連携が安定しているため、認証まわりで詰まるリスクが低い。「動くものを1日で作りたい」ならBolt.new、「ちゃんとしたMVPを作りたい」ならLovableという選び方がわかりやすい。

プログラミング経験がゼロでも使えますか？

UIを作る部分は使える。ただし、本番化の工程（RLS確認、環境変数設定、デプロイ）では技術的な知識が必要になる場面がある。「Lovableで作ったけど、本番に出せるか自信がない」という状態になったときに、専門家のレビューを受けるのが最も時間効率がいい。

生成されたコードは自分のものですか？

Lovableの利用規約では、生成されたコードの知的財産権はユーザーに帰属するとされている。ただし商用利用の詳細は利用規約を直接確認することを推奨する。

Lovableで決済機能（Stripe連携）は作れますか？

Stripe連携を指示すれば生成してくれるが、決済フローのセキュリティ確認が必要だ。Stripeのwebhookの検証、エラー時のロールバック処理など、決済特有の実装は自動生成のコードだけでは不十分なことが多い。

LovableでMVPのプロトタイプができた後、「セキュリティ的に本番に出せるか確認したい」「RLSが正しく設定されているか見てほしい」——そういう相談が多い。

→ エクスポート後のコードをCursorで拡張したり、Claude Codeでリファクタリングする流れも定番だ

AIのあとしまつは、Lovableで作ったプロダクトのセキュリティ確認・RLS設定・本番インフラ構築を担当する。まずは無料相談でプロジェクトの状態を確認してほしい。