LovableとSupabaseでWebアプリを作るときの進め方

LovableでWebアプリを作るときは、画面を増やす前にバックエンドの管理先を決めます。Lovable CloudはLovable側で管理するbuilt-in backendで、自分のSupabase projectを接続する方法もあります。自前のSupabaseを選ぶと、database、auth、storage、functions、billingや運用の管理主体はSupabase側になります。どちらが優れているかではなく、誰が運用し、どの画面から監査・請求・復旧するかで選んでください。

現行のLovable Docsでは、Cloudと自分のSupabaseの切替は自動のone-click migrationではないと説明されています。後から移ることはできますが、schemaとdataを別途移す計画が必要です。将来の移行可能性を考えるなら、Auth、Storage、Secrets、Functionsをどこに置くかも含めて初期設計します。

運用責任からbackendを選ぶ

Lovable Cloudは、別のSupabase projectを用意せずにbackend機能を使い始めたい場合に向きます。管理画面、認証設定、storage、logsをLovableのCloud viewから扱い、Lovable workspace側の運用・billingに寄せられます。自分のSupabase projectは、既存organizationやdashboard、監査手順、billing、環境分離、databaseを使いたい場合に向きます。同じSupabaseの基盤を使う部分があっても、projectの所有や管理アクセスは同一ではありません。

選択の目安：

・要件が揺れているprototype：まず小さなdataでCloudを試し、実ユーザー情報を入れる前にownershipと移行条件を確認。

・会社のSupabase organizationがあり、管理者が明確：自分のprojectへ接続し、owner、billing、backup責任を確認。

・既存userやproduction dataがある：接続前に環境分離、Auth、Storage、migration、復旧手順を計画。

・複数Lovable projectで一つのSupabaseを共有：意図的な共有か確認し、schema、RLS、Edge Function secretsの競合を点検。

「いつか使うかも」だけで自前環境を選ばず、すでに組織で運用している仕組みを見落としてCloudへ固定することも避けます。

接続前にprojectの正体を確認する

自分のSupabaseを接続する場合、workspace adminがSupabase organizationをLovable workspaceへリンクし、その後Lovable projectを編集できる人が接続先projectを選ぶ流れです。organizationを使える状態にする作業と、個別projectを接続する作業は別です。接続メニューが見えない場合、project editor権限だけでなくworkspace owner/adminの設定も確認します。

接続前にはproject名、region、用途、development/staging/production区分、owner、請求先、backup方針を記録します。候補が複数あるときはproject名だけで選ばず、管理者と用途を照合します。Lovable公式Docsは、同じSupabase projectを複数のLovable projectで使うと、project secretsの一部が上書きされることがあると警告しています。意図した共有でなければ、実験用と本番用を分けます。

LovableからSupabaseへつなぐ手順

現行の公式手順では、workspaceへSupabase organizationをリンクし、Lovable projectのCloud viewから既存Supabase projectを選びます。接続後、Cloud viewにproject名と状態が表示され、Supabase dashboardへのlinkが出ることを確認します。つながったように見えても、別projectが選ばれていれば、生成したtableやuserは想定場所にありません。

接続後に確認すること：

1. Lovableのproject名とSupabaseの接続先project名が一致する。

2. Supabase dashboardで同じprojectを開ける。

3. ownerと請求先が想定どおり。

4. development dataだけで試せる環境である。

5. schema変更がmigrationとして追跡される。

6. Edge Functionとsecretの所在が分かる。

画面ラベルは更新されるため、操作名を固定暗記せず、接続先の名前、所有者、状態を照合します。

schemaはdata ownershipから小さく作る

tableを生成する前に、データの所有者と読み書き条件を定義します。たとえばprojectsにはowner user IDがあり、tasksはproject IDに属し、profilesは認証userと紐づきます。画面に必要なfieldだけを足すのでなく、user Aがuser Bのrowを読めないか、projectを削除したら関連taskをどうするか、招待ユーザーのroleをどう分けるかを先に決めます。

初期schemaメモの例：

profiles：認証userごとに一行。公開情報とprivate設定を分ける。

projects：owner_user_idを持つ。複数人で使うならmembership relationを設ける。

tasks：project_idと作成者を持つ。project memberへ見せる範囲を定義。

uploads：storage path、owner、visibility、削除状態を紐づける。

これは固定schemaではなく、Reader Jobとアプリのdataに必要なentityだけを選ぶための例です。

Lovableはschema変更をSQL migrationとして表示し、承認後に実行する流れを案内しています。実行前にtable、column、constraint、index、権限、既存dataへの影響をreviewします。生成された差分が機能に必要か、data lossがないか、rollbackや再適用が可能かを確認します。migration fileがrepositoryに残るか、更新後のtypeが同期されるかも見ます。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Lovable

  公式サイトを見るTool詳細を見る

AuthとRLSを早い段階で試す

Supabase tableをfrontendから利用する設計では、Row Level Security（RLS）を有効にし、row単位のread/write policyを設定します。Supabase公式Docsはpublishable keyを使う場合でもRLSとleast privilegeが必要だと説明しています。keyが見えるかどうかだけで安全性を判定しません。user Aでログインし、user Bのrowを読み書きできないことを直接試します。

permission test：

・未ログイン：公開data以外は読めないか。

・一般user A：自分のrowを読めるが、他userのrowは拒否されるか。

・一般user B：Aのrecord IDを指定しても取得できないか。

・編集権限：許可されていないfieldを更新できないか。

・削除権限：owner以外がrowを消せないか。

・Edge Function：認証、input validation、secretをserver側で扱うか。

testには架空のdataを使い、顧客情報を試験用に入れません。画面でbuttonを隠すだけでは、APIへの直接アクセスは防げません。

secretと公開keyを取り違えない

Supabaseのpublishable keyはbrowserで使うpublic keyですが、secret/service role keyはRLSを迂回するためbackendに限定します。Lovableの現行integrationでは、secretをsecure inputから登録し、Edge Function等のserver-sideで使う方法が案内されています。Stripe、メール配信、外部AIのsecretをUI componentやclient-side environmentへ埋め込まないでください。

生成されたcodeとbuildの内容も確認します。browserへ送られるJavaScriptやnetwork responseにsecretが現れないか、repositoryへ.envがcommitされていないか、logsへ値を書いていないかを調べます。流出の疑いがあればsecret valueを表示せず、rotationと影響範囲の確認を行います。

Cloudと自前Supabaseの運用差

Lovable Cloud backendはLovableがmanaged serviceとして扱い、projectによってはSupabase dashboard上に自分のprojectとして見えません。自分のSupabaseを接続した場合は、dashboard、billing、backup、instance運用を自分たちで行います。どちらがつながっているかは、Cloud viewの実表示とSupabase dashboardを照合して確認してください。project名や生成時の会話から推測しません。

自前Supabaseへ切り替えると、Cloud内蔵の管理画面・機能の一部が同じ形で使えないことがあります。自動migrationがない条件を踏まえ、data export、schema再作成、Auth user、Storage file、Functions、secretを棚卸しします。「あとで移せる」という予定だけでは計画になりません。

公開前のchecklist

・接続先projectとownerが一致する。

・開発と本番のdata、環境を分ける。

・schema変更とmigrationをreviewした。

・各tableのRLSとpermission testを実施した。

・secret keyをbrowserへ送っていない。

・Edge Functionに必要なsecretが設定されている。

・Auth、Storage、backup、logsの責任者が決まっている。

・障害時の停止・復旧手順を確認した。

未確認が残るなら、UIが整っていてもproduction readinessは完了していません。AI生成schemaやpolicyは、data ownershipを理解する担当者が再読します。

AIものさしの判断として、最初に作る速さだけでなく「問題が起きたとき誰がdataを見て、止めて、戻せるか」でbackendを選びます。自分のSupabaseを接続しても、認証、権限、backup、billingの運用責任は消えません。prototypeは小さく試し、顧客dataを入れる前にowner、RLS、secret、migration、復旧計画を確定してください。