Lovableで公開・デプロイするときの確認ポイント

Lovableでアプリを公開するときは、Publishボタンを押す前に「誰が見られるか」「何のdataへ接続するか」「公開後にどのflowを試すか」を決めます。Lovableの公開はprojectをlive URLへdeployし、その時点のversionをsnapshotとして公開する仕組みです。Previewで見た画面がそのまま本番環境の確認になるわけではありません。Lovableの公式案内ではPreviewと公開版は別の画面snapshotでもbackendとdataを共有し、Previewでのdatabase変更は公開側にも影響します。テスト時は専用backendを使うか、既存利用者のdataと明確に分けたtest dataだけを使い、Previewをdata-isolatedな環境と扱わないでください。公開後のURLでlogin、保存、エラー表示をもう一度試し、問題があれば変更を直してPublish changesを行います。

最初に公開するだけなら操作は短くても、公開範囲やbackendの選択を誤るとdata露出や未完成機能につながります。記事のゴールは「ボタンを押せる」ことではなく、公開先・閲覧者・主要操作・戻し方を説明できる状態です。

公開前に決める4つのこと

Publish dialogを開く前に、次の項目をprojectの状態と照合します。

表は横にスクロールできます

判断	先に答える問い	未確定なら
公開URL	LovableのURLかcustom domainか	既存domainへ切替えない
見られる人	誰でも、workspace内、招待者か	Publicにせず設定を確認
公開version	今のprojectのどの状態を出すか	Previewとdiffを再確認
data接続	本番database・Auth・外部APIを使うか	テスト環境から始める

公開範囲はURLを知っている人だけにするつもりでも、リンクを共有すれば第三者へ広がることがあります。business用の機密dataや個人情報が入る場合、公開URLを出す前にAudience設定、Auth、RLS、Storageの境界を確認します。プランによって利用できるアクセス制御に差があるため、選択肢が表示されない場合は現在のworkspace設定を確認してください。

Previewでは主要な作業と失敗経路を通す

Previewで最初の画面だけを見るのではなく、利用者が完了したいflowを最初から最後まで試します。フォームなら入力、validation、送信、成功表示、再読み込み後の状態まで確認します。認証があれば、新規登録、login、logout、protected pageへの直接アクセスを確認します。

最低限の試験表：

表は横にスクロールできます

ケース	操作	公開前に確認する結果
正常な利用	主な入力を入れて送信	dataが一度保存され、結果が画面へ反映
入力ミス	必須欄を空にする、形式を崩す	送信を止め、直す項目を示す
権限なし	未loginで保護URLへ直接移動	dataを見せず、login等の次actionを示す
保存失敗	test環境で失敗条件を作る	成功したように見せず、再試行方法が分かる
狭い画面	mobile幅で主要操作	入力・button・navigationが使える

Previewでbackend接続が確認できないとき、見た目だけの仮dataを成功とみなさないでください。database、メール、決済、外部APIを含む場合は、test用の接続先で実際のrequestと返却を確認します。本番dataや実ユーザーへ副作用が出る試験は、影響を把握するまで避けます。

Security scanは公開判断の一材料

LovableのPublish dialogではQuick scanの結果を確認できます。公式docsによれば、scanはdatabase access rulesやRLS、dependency、MCP server exposureなどを検査します。Deep scanではsecret露出やunsafe input、authorization gapなどの追加確認を行う案内があります。

ただしscan結果が「問題なし」でも、実際の利用者が必要なdataだけを見られることを人の操作で確認してください。特に次を確認します。

• 公開schemaの各tableでRLSと必要なgrantsが整合している

• publishable keyを使うclientから読める行が意図どおり

• secret / service_role credentialがclient bundleやGitへ含まれない

• user Aがuser BのrecordをURLやrequest body変更で取得できない

• Storageのbucket公開設定とobject access policyが意図どおり

• Edge Functionなどserver側処理でもuser認可を行う

scanが失敗・未完了なら、その理由を確認してから公開します。指摘件数が少ないことを安全性の点数として扱わず、Critical findingを解決できない場合は公開を止めます。security記事で扱うpolicyの詳細は別途実装とtestが必要です。

まずは使ってみる

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

• 

  Lovable

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

Publish後はlive URLで環境差を確認する

LovableのPublishは公開versionをlive URLへdeployし、HostingとHTTPSを提供すると公式docsに記載されています。初回公開後に変更した内容は、project上で保存されただけでは公開URLへ反映されたと判断できません。Publish dialogからPublish changesを行い、その後のURLで再確認します。

live smoke testでは、Previewと同じ手順を短く繰り返します。

1. URLとtitle、description、iconなどのsite metadataを確認する。

2. Public / Workspace / 招待者など、意図した利用者だけがアクセスできるか見る。

3. login、主要form、data保存、logoutを新しいsessionでも試す。

4. mobileとdesktopで表示・操作を確認する。

5. browser consoleやnetworkでfirst-partyのerrorがないか見る。

6. 修正が必要なら公開変更を行い、もう一度同じflowを確認する。

custom domainを追加する場合は、設定がLiveになる前のURL表示も確認します。DNSやdomainの設定待ちを、アプリのdeploy成功と混同しないでください。domainがまだ利用できないなら、提供されるproject URLでappを確認し、domain設定を別の作業として扱います。

公開後に問題が出たときの戻し方

公開前に、直前の安定versionを識別できるようにしておきます。Git syncを使っているなら、Lovable側のproject versionだけでなく同期branchとrepository commitも記録します。障害時は、まず発生条件・影響する利用者・直前の変更を特定し、公開URLに誤った成功表示やdataを出し続けない状態にします。

表は横にスクロールできます

症状	まず切り分ける	対応
appが開かない	URL、deploy完了、domain状態	project URLとcustom domainを分けて確認
loginできない	Auth設定、callback、公開環境変数	設定値を露出せず構成を照合
保存dataが出ない	project接続先、grant、RLS、request	test環境で再現しpolicyを確認
他人のdataが見える	table / view / function / storage	公開を止め、認可経路を修正
新しい変更が見えない	公開済versionと保存差分	Publish changes後にlive URLを再確認

問題が権限漏れや個人dataの露出なら、UI修正だけでは不十分です。公開範囲を制限またはunpublishし、根本のdatabase/API access ruleを確認します。戻す操作がどのdataへ影響するか分からない場合は、先にdata backupと関係者の運用を確認してください。

閲覧者の立場を変えて確認する

公開範囲は、ownerの画面だけで確かめないでください。ログアウト状態、一般ユーザー、招待されていない人を分けて、同じURLを開いたときの表示を比較します。一般公開ページなら未ログインでも見える情報を限定し、Workspace限定ならworkspace外の別アカウントで拒否されるか確認します。招待者限定なら、招待されていないメールアドレスからのアクセスも試します。

この比較で画面が隠れるだけでなく、data requestも拒否されているかを確認します。権限が想定と違うならPublishを進めず、Audience設定とbackend policyのどちらが原因かを分けて調べます。

AIものさしの判断

静的な試作を共有するだけなら、公開範囲を限定できるかと、外部dataへ接続していないかを中心に見ます。AuthやDatabaseを使うアプリは、Previewで主要flowを通し、RLS・grants・secret・別ユーザー境界を確認してからPublishします。Lovableのscanは見落としを減らす補助であり、利用者ごとのアクセス検証を置き換えません。

公開後に更新する場合は、projectの最新状態、公開snapshot、Live URLを別々に確認します。公開操作を終点にせず、live URL上で想定した利用者が作業を完了できることまで見てから公開完了とします。custom domainや閲覧制御の選択肢が環境にない、または本番dataへの接続を分離できない場合は、無理に公開せず設定を整えるところまでに留めます。