社内で見せるだけなら、共有URLで足ります。問題は、その次です。「取引先にも見せたい」「部門の正式なツールとして案内したい」となった瞬間に、URLの見た目と信頼性が論点になります。自社ドメインでないものを取引先に案内するのは、多くの企業でそのまま通りません。

ところが独自ドメインの設定は、DNSという普段触らない領域に踏み込みます。設定したのに反映されない、旧サイトが表示される、ログインだけできなくなる。ここで詰まって公開が止まるケースは珍しくありません。

この記事では、Lovableで作ったアプリを公開する手順と、独自ドメインの設定、そして公開前に必ず確認すべき項目を、2026年9月1日時点の公式ドキュメントにもとづいて整理します。

そもそも「公開する」とは、何が起きているのか？

手順の前に、仕組みを押さえておくと後の切り分けが速くなります。

公式ドキュメントによれば、公開とはプロジェクトのスナップショットを共有可能なURLへデプロイし、稼働するWebアプリにする操作です。Lovableが公開後のアプリをホストするため、サーバーを用意する必要はなく、HTTPSも含まれます。配信の仕組みはホスティングのドキュメントに整理されています。

ここで重要なのが「スナップショット」という点です。エディタで編集した内容が自動で公開版に反映されるわけではありません。公開操作を行ったその時点の状態が配信されます。編集したのに公開サイトが変わらない、という混乱の多くはここが原因です。

公開先のURLにも階層があります。公式ドキュメントによれば、lovable.appのURLへの公開はすべてのプランで無料です。独自ドメインの利用には有料プランが必要で、ワークスペース独自のブランドURLはBusinessプランとEnterpriseプランで利用できるとされています。

公開の手順は、どうなっているのか？

操作自体は単純です。難しいのは操作ではなく、公開前に何を確認するかのほうです。

公開はダイアログから実行し、完了すると稼働開始が表示されます。失敗した場合は「Publishing failed」が表示されます。公式のトラブルシューティングによれば、チャットで「publish」「deploy」といった指示を出す形でも実行でき、サブドメインを指定する場合は「Publish to my-todos.lovable.app」のような形式で指定します。

公開に失敗する典型的な原因がファイルサイズです。公式ドキュメントによれば、ファイルが10MBを超える場合はCDNアセットへ移行する必要があります。画像や動画をプロジェクトに直接置いている場合に起きやすい症状です。その他の詰まりどころは実践ガイドにも整理されており、解決しない場合は有料プランであればサポートに連絡できます。

Lovableでホストするか、外部でホストするか？

独自ドメインの話に入る前に、そもそもどこで動かすのかという選択があります。既定はLovableのホスティングですが、他の場所に置くこともできます。

公式ドキュメントによれば、Lovableでホストする場合は、独自ドメイン、自動的なSSL、グローバル配信、自動デプロイと環境管理、フルマネージドのバックエンドとデータベース、統合された認証とデータ分離が提供されます。設定すべきインフラがないことが最大の利点です。

一方で、別のドキュメントによれば、Lovableで構築したアプリケーションはどこにでもホストできます。ただし完全に移行した場合、CI/CDパイプラインと本番インフラの運用、データベース・ストレージ・バックアップ、認証やOAuthやAPI連携、そしてセキュリティ監査と法令準拠を自社が管理することになります。

公式の推奨も現実的で、まず単純に始めて段階的に移すこと、コンプライアンスやネットワークの制約といった実際の必要が生じた段階で移行を検討することが効率的だとされています。最初から外部ホスティングを前提にすると、公開までの距離が長くなり、検証の速さという導入目的を損ないます。

公開の権限は、誰に持たせるべきか？

技術的な手順が整っても、運用の設計が抜けていると事故が起きます。とくに外部公開は、一度出てしまうと取り消しが効きません。

基本の考え方は、作る権限と公開する権限を分けることです。作るのは業務部門でよいのですが、外部に出す判断は別の人が行う。この一段を挟むだけで、権限設計の見落としが世に出る確率は大きく下がります。

機能で支える手段もあります。Enterpriseのドキュメントによれば、公開や招待を行える人を制限する機能、放置されたアプリを自動的に退役させる機能が提供されます。セキュリティセンター（Business以上）では、各プロジェクトの最終スキャン日時を表示し、点検されていないプロジェクトを検出できます。

規模が小さいうちは、機能ではなくルールで足ります。「外部公開は情報システム部門の承認後」と決め、承認者と標準の所要日数を明示してください。所要日数を書かないルールは、現場に回避されます。プラン別に利用できる統制機能はプラン一覧で確認できます。

独自ドメインは、どう設定するのか？

ここからが本題です。手順は2通りあり、既にドメインを持っているかどうかで分かれます。

公式ドキュメントによれば、Lovable上で新規にドメインを購入する場合は、Project → Settings → Domains から「Buy new domain」を選び、ドメイン名を検索し、購入期間（1〜10年）、自動更新の設定、登録情報を入力して決済します。

すでに他社で取得したドメインを接続する場合は「Connect domain」を選び、ドメインを入力したうえで、自動設定に対応するサービスを使うか、手動でDNSレコードを設定します。検証が完了するまで待つ形になります。

接続できる範囲も明記されています。ルートドメイン（yourdomain.com）とサブドメイン（blog.yourdomain.com など）の両方に対応し、複数のサブドメインを個別に接続できます。ただし同一のドメインを複数のプロジェクトに接続することはできません。異なるサブドメインであれば可能です。

必要なDNSレコードは何か？

設定を情報システム部門に依頼する場合、必要なレコードを正確に伝えられるかどうかで所要日数が変わります。曖昧な依頼は往復を生みます。

公式ドキュメントによれば、必要なのはドメインを向けるためのAレコード（値は 185.158.133.1）と、所有権を検証するためのTXTレコード（lovable_verify= で始まる値）です。あわせて、IPv6のAAAAレコードはドメインの設定を妨げる可能性があるため削除が必要とされています。

SSLについては、Lovableが証明書を自動で発行しインストールします。TLS 1.2以上に対応し、PCI DSSのような一般的なコンプライアンス要件を満たすとされています。自社で証明書を用意する必要はありません。

反映されないときは、何を疑えばよいのか？

設定直後に見えないのは、多くの場合は異常ではありません。公式ドキュメントによれば、DNSの変更は反映に最大72時間かかる可能性がありますが、多くは数時間以内に反映されるとされています。SSL証明書が未発行の場合も同じく72時間が目安です。

それでも解決しない場合、原因は限られています。旧サイトが表示されるなら、古いA・AAAA・CNAMEレコードが残っています。Cloudflareを使っていて1001や1003のエラーが出る場合は、プロキシが有効になっていることが原因で、DNS設定を「DNS only」に変更します。検証中の状態が続く場合も、プロキシを無効化してLovableのIPへ直接向ける必要があります。

そしてもうひとつ、独自ドメイン特有の症状があります。サイトは表示されるのにサインインだけできない、というものです。公式ドキュメントによれば、これは認証のリダイレクトURLに新しいドメインがまだ含まれていないことが原因で、Cloudのユーザー・認証設定に追加することで解決します。移行時に見落としやすい項目です。

なぜ業務で使うなら、独自ドメインが必要なのか？

「見た目の問題だから、まずは無料のURLでいい」という判断は、実は規約上の推奨と食い違います。ここは知らないと後で困る論点です。

Lovableの利用規約（最終更新2026年8月28日）には、特定のサブドメインが恒久的に利用できることに依拠すべきではなく、ミッションクリティカルなアプリケーションには独自ドメインを使うべきである旨が記載されています。つまり lovable.app のURLは、業務の基盤として案内し続ける前提のものではありません。

実務上の意味は明確です。取引先に案内する、社内のポータルからリンクする、資料に印刷する——といった「後から変えにくい場所」にURLを載せるなら、独自ドメインを先に設定してください。後から変更すると、案内済みのリンクがすべて無効になります。

もうひとつ、独自ドメインには実利があります。公式ドキュメントは、ブランドの一貫性、検索エンジンでの見つけやすさ、覚えやすさを利点として挙げています。外部公開のLPや申込フォームでは、この3点がそのまま成果に効きます。

逆に、社内の一時的な検証や、数週間で役目を終える用途であれば、無料のURLで十分です。判断の分かれ目は機能ではなく、そのURLをどこに載せるかです。

公開する前に、何を確認すべきか？

ここが本記事で最も重要な部分です。技術的に公開できることと、公開してよい状態であることは別だからです。

確認は自動と手動に分かれます。公式ドキュメントによれば、公開ダイアログを開くとBasic Scanがバックグラウンドで自動実行され、行レベルセキュリティ（RLS）ポリシーのリンティング、データベースの設定確認、依存パッケージの脆弱性が対象になります。より詳細なエージェント型のコードレビューであるDeep Scanは自動実行されず、手動で起動します。手動実行はいずれも無料です。

一方、自動検査では判定できない項目があります。以下は人が確認する必要があります。表の右列にあるとおり、いずれも「動作するかどうか」では発見できません。

最下段は軽視されがちですが、外部に見せる場面では効きます。日本語で指示していても、エラーメッセージや空状態の文言は指示から漏れやすく、そこだけ英語で残ることがあります。取引先に案内する画面では、この種の粗さが信頼を損ないます。

公開した後、何が発生し続けるのか？

公開は終わりではなく、運用の始まりです。ここを見積もっていないと、翌月に想定外の費用が出ます。

公式ドキュメントによれば、公開後はCloud usageとして、データベースサーバーの稼働、保存容量、ネットワーク、ストレージ、バックエンドの処理、リアルタイム更新のメッセージがクレジットを消費します。AI機能を組み込んでいる場合は、実行時の呼び出しがAI gateway usageとして別に計上されます。つまり利用者が増えるほど消費します。

さらに重要なのが、残高がゼロになったときの挙動です。ビルドが止まるだけでなく、公開済みアプリのAI機能が動作しなくなり、組み込みバックエンドに依存するアプリは一時停止することがあります。データは保持されますが、利用者から見ればアプリは止まっています。取引先に案内した後にこれが起きると、信頼の問題になります。稼働の前提となる構成はCloudのドキュメントで確認できます。

対策は単純です。プロジェクト単位の利用状況を定期的に確認し、残高の下限と補充の担当者を決めておくことです。公開の承認と同時に、この運用ルールも決めてください。

よくある質問（FAQ）

編集したのに公開サイトが変わりません。

公開は操作した時点のスナップショットを配信する仕組みです。編集後に改めて公開操作を行う必要があります。自動では反映されません。

独自ドメインは無料プランでも使えますか？

公式ドキュメントによれば、独自ドメインの利用には有料プランが必要です。lovable.appのURLへの公開はすべてのプランで無料です。なお有料プランから無料プランへ変更した後は、新規のドメイン接続ができないとされています。

DNSの設定は情シスに依頼する必要がありますか？

自社のドメインを扱う以上、通常は管理部門への依頼になります。依頼時にはAレコードの値、TXTレコードによる検証、AAAAレコードの削除が必要である点を明記すると、往復が減ります。

1つのドメインで複数のアプリを公開できますか？

同一のドメインを複数プロジェクトに接続することはできませんが、サブドメインを分ければ可能です。app.example.com と form.example.com のように用途で分けるのが一般的です。

公開を取り消すことはできますか？

公開したアプリを非公開に戻す操作自体は可能ですが、その間に共有されたURLや取得された情報は戻せません。外部公開の判断は、取り消せる前提で軽く行わないでください。

社内限定で公開したい場合はどうしますか？

認証を設けたうえで、招待した利用者のみがログインできる構成にします。ワークスペース独自のURLはBusinessプランとEnterpriseプランで利用でき、Enterpriseでは公開や招待を行える人を制限する統制も提供されます。

公開前チェックは誰が担当すべきですか？

作った本人以外が望ましいといえます。作った人は「そう動くはず」という前提で見るため、権限の抜けに気づきにくいためです。作る人と点検する人を分ける運用にしてください。

まとめ：公開できることと、公開してよいことは別

Lovableでの公開は、その時点のスナップショットをLovableのホスティングへ配信する操作です。lovable.appへの公開は全プラン無料、独自ドメインは有料プラン、ワークスペース独自のブランドURLはBusiness以上という段階があります。

独自ドメインの設定で必要なのは、Aレコード（185.158.133.1）とTXTレコードによる検証、そしてAAAAレコードの削除です。反映には最大72時間かかることがあり、旧サイトの表示は古いDNSレコード、CloudflareのエラーはプロキシをDNS onlyにしていないこと、サインイン不可は認証のリダイレクトURL未更新が原因です。

そして最も重要なのは、公開前の確認を工程として組み込むことです。自動スキャンはRLSや依存関係の問題を拾いますが、未ログインの訪問者に何が見えるか、他人のデータが見えないかといった業務判断は人が行います。公開後はCloud usageが継続的に発生し、残高がゼロになるとアプリが止まる点も、運用ルールとして先に決めておいてください。

Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、公開前チェックの標準化や運用設計のご相談は株式会社100の問い合わせ窓口をご利用ください。