Lovableから一時共有URLへ切り替えるタイミング

できること

Lovableは生成からデプロイまでの時間が短く、試作段階での頻繁な共有に向いている。社内チームとの初期確認では、デプロイURLをSlackに貼るだけで十分な場合がほとんどだ。この段階で認証を細かく設定することは過剰管理になりやすい。

「社外への初稿提出」のタイミングから共有方法を格上げするというルールを決めておくと、判断のブレがなくなる。このタイミングでHTMLまたはスクリーンショットを認証付き共有サービスにアップする習慣にすれば、フェーズが変わるたびに悩む必要がなくなる。

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

できないこと

LovableはReactアプリをそのままデプロイするため、完全な静的HTMLとしての書き出しには対応していない部分がある。カスタムフック・状態管理・API連携を使ったインタラクションはHTMLに書き出した時点で動作しなくなる。「デザインのみ確認してほしい」という用途に限定してHTMLを使うことが前提になる。

Lovableのデプロイ履歴を特定の時点のバージョンとして固定する機能は限定的だ。「Rev.2を後から見直したい」という要求が出た場合、対応が難しい場合がある。重要なバージョンはHTMLを書き出してスナップショットとして保管しておくとよい。

認証と期限の違い

初期フェーズではパスワード認証で十分だ。クライアントに初稿を見せる段階は、まだ詳細なアクセス管理より「スムーズに開いてもらえること」が重要で、シンプルなパスワードで十分な壁が作れる。ここで複雑な認証を要求するとレビュー開始が遅れる。

提案が進んで価格・スコープ・機能仕様が絡んでくる中盤以降は、メール認証でアクセスログを残すことが重要になる。「Aさんがこのバージョンを確認した」という記録が後でのトラブル防止に役立つ。

リリース直前の最終確認では期限を「リリース日の前日23時まで」に設定して、本番公開後に旧プレビューへのアクセスが自動的に遮断されるようにしておく。Lovableのデプロイが残っていても、共有サービス側で期限が切れれば外部からのアクセスを止められる。

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

差し替え・レビュー運用

Lovableの修正はデプロイが速いため、認証付きサービスへのHTMLアップロードが遅れると「LovableのURLでは最新版が見られるが、認証付きURLでは旧版が見えている」という状態が起きやすい。修正と再アップロードをセットで行う手順をチームで決めておくことが重要だ。

差し替え後はレビュアーへ「変更点：ヘッダーデザイン・フォントサイズ修正。期限は〇日まで」というシンプルなメッセージを送ると、レビュアーの確認時間を短縮できる。「全部見てください」という依頼より「ここだけ確認してください」の方が返答が速い。

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

向いているケース早見表

LovableのデプロイURLをそのまま使うのが向いているのは、機能デモの社内確認・技術チームとのコードレビュー・公開前のセルフチェックの3場面だ。これらは閲覧者が信頼できる範囲に収まっており、追加の管理ツールは不要だ。

認証付き共有への切り替えが必要なのは、社外クライアントへの初稿提出・コンペ参加前のUI確認・役員承認フローの3フェーズだ。Lovableの高速イテレーションと認証管理ツールを組み合わせることで、スタートアップから中規模の制作会社まで使えるレビュープロセスが整う。