Lovableで構築したサービスに、カスタムドメインを設定することになりました。

作ったのは、カーシェアとレンタカーを比較できるツールです。すでに運用している tielec.blog とは別に、このサービスを car-sharing-vs-rental-car.tool.tielec.blog というサブドメインで公開したいと考えました。

DNSの設定自体は何度もやってきたので、「たぶん大丈夫だろう」と思っていました。でも、久しぶりの作業だったこともあって、正直ちょっと不安でした。「あれ、これどっちだっけ」となる瞬間が何度かあって、結果的に「知ってるつもり」が曖昧になっていることに気づかされました。

まとめ：Lovableのカスタムドメイン設定手順

Lovableでカスタムドメインを設定する手順をまとめます。この記事では、お名前.comを例に説明しますが、他のDNSプロバイダーでも基本的な流れは同じです。

1. Lovableの管理画面でドメインを追加

  1. Lovableのプロジェクトにログイン
  2. プロジェクトの設定画面を開く
  3. 「Domains」セクションに移動
  4. 「Add custom domain」をクリック
  5. 使いたいドメイン（例: car-sharing-vs-rental-car.tool.tielec.blog）を入力
  6. 「Add domain」をクリック

すると、以下のようなDNSレコード設定情報が表示されます：

RECORD TYPE HOST NAME VALUE
A car-sharing-vs-rental-car.tool 185.158.xxx.xxx
TXT _lovable_verify.car-sharing-vs-rental-car.tool lovable_verify=xxxxxxxx...

この情報を、次のステップでDNS設定に使います。

2. DNSレコードの設定方法

Lovableが指定するDNSレコードは、Aレコード と TXTレコード の2つです。

Aレコード

TXTレコード

注意点:

3. お名前.comでの具体的な設定例

お名前.comの管理画面で、以下の手順で設定します。

手順

  1. お名前.comの管理画面にログイン
  2. 「ドメイン設定」→「DNS設定/転送設定」を選択
  3. 対象ドメインを選択して「次へ」
  4. 「DNSレコード設定を利用する」の「設定する」をクリック

Aレコードの追加

項目 入力内容
ホスト名 car-sharing-vs-rental-car.tool
TYPE A
VALUE 185.158.xxx.xxx（Lovableが表示したIP）
TTL 3600（デフォルトのまま）

TXTレコードの追加

項目 入力内容
ホスト名 _lovable_verify.car-sharing-vs-rental-car.tool
TYPE TXT
VALUE lovable_verify=xxxxxxxx...（Lovableが発行した文字列）
TTL 3600（デフォルトのまま）

設定後:

DNS反映の確認

DNS設定は反映に時間がかかることがあります（通常は数分～数時間）。Lovableの管理画面に戻ると、自動的に検証が行われ、設定が正しければ「Active」または「Verified」と表示されます。

実際にやってみて気づいたこと

ここからは、実際に設定作業をしてみて「知ってるつもりが曖昧になっていた」と気づいたポイントをまとめます。

サブドメインの階層、どっちが正しい？

最初に悩んだのが、サブドメインの設計です。

当初は tool.car-sharing-vs-rental-car.tielec.blog にしようと思っていました。でも、ドメインを入力する直前に「あれ、これで合ってるっけ？」と手が止まりました。

階層の意味を逆に考えていた

よく考えてみると、tool.car-sharing-vs-rental-car.tielec.blog という構造は、こういう意味になります。

tielec.blog
└─ car-sharing-vs-rental-car
    └─ tool

「car-sharing-vs-rental-carというドメインの中に、toolがある」

でも、それって逆ですよね。やりたいことは、「ツール群という役割の中に、個別のサービスがある」 という構造のはずです。

ここで気づきました。階層を逆に考えていた。

正しい構造はこっち

最終的には car-sharing-vs-rental-car.tool.tielec.blog にしました。

tielec.blog
└─ tool（役割）
    └─ car-sharing-vs-rental-car（個別サービス）

こうすることで、将来的に他のツールが増えても、こんな風に拡張できます。

tool.tielec.blog
├─ car-sharing-vs-rental-car
├─ cloud-cost-simulator
└─ pricing-compare

意外とこういうの、実際に手を動かす直前まで気づかないんですよね。

「まあこれでいいか」と進めてしまいそうでしたが、一度手を止めて考えてよかったと思います。

CNAMEだと思っていたら、A+TXTで「え？」となった

設計が決まったので、Lovable側でドメインを追加しました。

一般的なホスティングサービスでは、カスタムドメイン設定というと CNAMEレコード が出てくることが多いです。なので、「たぶんCNAMEが表示されるだろう」と思っていました。

実際に表示されたのは、これ

ところが、画面に表示されたのはこれでした。

RECORD TYPE HOST NAME VALUE
A car-sharing-vs-rental-car.tool 185.158.xxx.xxx
TXT _lovable_verify.car-sharing-vs-rental-car.tool lovable_verify=xxxxxxxx...

え、CNAMEじゃないの？

正直、一瞬「自分の理解が間違ってるのかな」と思いました。でも、設定方法自体は理解しているので、「まあ、とりあえず言われた通りに設定すればいいか」と進めました。

ただ、気になったので調べてみました。

Aレコード=1サービス1IP...じゃないよね？

ここで疑問が湧きました。

「Lovableで一つサービスを作るたびにAレコードで追加するということは、一つのサービスに対して一つのIPアドレスが割り当てられているのか？」

でも、そんなわけないですよね。IPv4なんてとっくに枯渇してるのに、サービスごとにIPを割り当てるなんて無理です。

実際の仕組みはこうだった

調べてみたら、同じIPアドレスを、複数のサービスで共有している ことがわかりました。

car-sharing-vs-rental-car.tool.tielec.blog
            ↓
      185.158.xxx.xxx   ← Lovableのエッジ（入口）
            ↓
   HTTPのHostヘッダで振り分け
            ↓
     該当するプロジェクト

つまり、DNSは「入口」を決めるだけで、実際のプロジェクトへの振り分けは HTTPのHostヘッダやTLSのSNI によって行われます。

あ、そういうことか。

Cloudflare、Vercel、Netlifyも同じ仕組みです。考えてみれば当たり前なんですが、久しぶりすぎて「あれ、どうだったっけ？」となりました。

TXTレコードは「なりすまし防止」

では、TXTレコードは何のためにあるのか？

これは 「このドメインが、このLovableプロジェクトに紐づいていることを証明する」 ためのものです。

Lovableが発行した固有の文字列をDNSに設定させることで、「なりすまし」を防いでいます。これがないと、誰でも他人のドメインを勝手に設定できてしまいます。

「知ってるつもり」が曖昧になっていた

今回、久しぶりにDNS設定をやってみて、「知ってるつもり」が意外と曖昧になっていること に気づきました。

知識としては持っているはずなのに、実際に手を動かそうとすると「あれ、どうだっけ？」となる。

これ、エンジニアあるあるだと思うんですよね。普段やらない作業って、知識が曖昧になります。

でも、手を動かしながら確認することで、改めて理解が深まる こともあります。今回も、「CNAMEじゃなくてA+TXT」という違いを調べたことで、DNSの仕組みを改めて整理できました。

「確認しながら進む」のは悪いことじゃない

「久しぶりだから不安」「あれ、どうだっけ？」と思うことは、別に恥ずかしいことじゃないと思います。

むしろ、「知ってるつもり」のまま進めてしまう方が危ない。

今回も、サブドメインの階層を逆に考えていたことに、入力直前で気づきました。もし「まあこれでいいか」と進めていたら、後で修正する手間がかかっていたはずです。

「あれ、これで合ってるっけ？」と一度立ち止まること。

意外とこれが、エンジニアとして大切なんじゃないかと思います。

[📦 商品リンク: moshimo-book-dns-textbook]