Lovableと認証付きHTML共有サービスの違い｜レビュー用途で選ぶ基準

できること

Lovableで生成したアプリのプレビューURLはデプロイ直後から共有できる。まずシークレットウィンドウでURLを開き、Lovableのセッションを持たない状態でページが表示されるかを確認すること。認証が必要なページを「誰でも見られる」と誤解して送るミスはLovableでも起きやすい。

PCとスマートフォンの両方で表示を確認し、Reactコンポーネントのレスポンシブ設定が正しく効いているかを確かめてから共有する。特にTailwindのブレークポイント設定がLovableのデフォルトで意図した通りになっているか、実機で一度確認することを推奨する。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

できないこと

Lovableのデプロイ先はLovableのサブドメイン上に公開される形が基本で、閲覧者をメールアドレス単位で制限するホワイトリスト機能は標準にない。URLが流出すれば誰でもアクセスできる状態になるため、競合他社に知られたくないUIを確認してもらう用途には向かない。

閲覧期限の自動設定もLovableには存在しない。プロジェクトを削除またはデプロイを停止しない限りURLは有効なままになる。レビュー終了後の失効管理は手動で行う必要がある。

認証と期限の違い

Lovableが生成するReactアプリを静的HTMLとして書き出すには制限があるが、ページのスタティックな表示部分についてはブラウザから保存できる場合がある。デザイン確認に特化するならHTMLを書き出して認証付きサービスで管理する方法が最もシンプルだ。

パスワード認証はLovableのURLを直接共有することに比べて「誰でも見られる」リスクを大幅に下げる。ただし転送には弱く、パスワードを知っている人全員が閲覧可能になる点は同じだ。閲覧者のコントロールを高めたい場合はメール認証に切り替えることを検討する。

期限管理はLovableのデプロイ期間に依存しない管理を実現できる。「このURLはX月X日まで有効」と設定しておけば、Lovableプロジェクト自体がデプロイされ続けていても外部からのアクセスを遮断できる。レビューのタイムラインに合わせた期限設定が柔軟に行える。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

差し替え・レビュー運用

Lovableは修正のたびにデプロイが走り、同じURLで最新版が見られることが多い。これはレビュアーへの再通知が不要な点で便利だが、「さっきと同じURLなのに内容が変わっている」とレビュアーが気づかないリスクもある。修正を加えた際は変更箇所を明示する一言を添えることが重要だ。

認証付き共有サービスにHTMLを移した場合も、同様に差し替えのたびに変更点をメモして連絡する習慣をつけておくとよい。URLが同じであることと、内容が最新であることをレビュアーに理解してもらうことが、効率よいレビューサイクルの前提になる。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける

向いているケース早見表

Lovableのデプロイ先URLをそのまま使うのが向いているのは、社内の技術チームとのUI確認・同じ組織内でのデザインフィードバック・公開を前提とした機能デモの3つだ。これらは閲覧者のコントロールより確認のスピードが優先される場面だ。

認証付きHTML共有サービスへの切り替えが必要なのは、社外クライアントへのUI提案・コンペ参加前のデザイン確認・承認フローとしての役員確認だ。Lovableの生成速度と共有サービスの管理機能を組み合わせると、スピードと安全性を両立できる。