予約エンジンに独自ドメインを接続する方法

サイトはできあがりました。ロゴも正しく、マークアップも設定済み、プラットフォームのサブドメインでテスト予約も通り、社内の誰かがもう三人の顧客にリンクを送っています。そこで当然の疑問が出てきます。なぜアドレスにはまだ他社の名前が入っているのか。このガイドでは、誰かを雇わずに予約エンジンに独自ドメインを接続する方法を説明します。実際に何を変えるのか、関わるレコードは二つか三つ、ブラウザの鍵マークが思ったより遅れて現れる理由、そして触ると会社のメールを静かに壊してしまう設定について。

DNSを深く理解する必要はありません。必要なのはひとつのイメージだけです。ドメイン名は道しるべで、あなたはそれを新しい建物の方へ向け直そうとしている。以下はすべて、そのイメージの細部です。

ドメインは実際どこにあるのか

関わる会社は最大で三つあり、ほとんどの経営者はそのうち一つしか知りません。レジストラはドメイン名を買い、毎年の更新料を払っている会社です。DNSホストはそのドメインのレコードを編集する場所で、レジストラと同じ会社であることが多いものの、違う場合もあります。特に何年も前にウェブ制作会社がドメインを別のDNSサービスへ移していた場合です。ウェブホストは今のサイトが動いている場所です。

これから追加するレコードはDNSホストに入れます。ですから、まずそれがどこかを確かめてください。レジストラにログインし、ドメインに設定されているネームサーバーを見ます。レジストラのものなら、そこでレコードを編集します。別の場所を指していれば、作業場所はそちらです。ここに数分かければ、どこからも参照されない管理画面でレコードをいじって午後を無駄にすることを防げます。

ルートドメインかサブドメインか：触る前に決める

ルートドメイン（apex、ネイキッドドメインとも呼ぶ）は、前に何も付かないyourbrand.jpのことです。サブドメインは前にラベルが付いたもので、www.yourbrand.jp、booking.yourbrand.jp、travel.yourbrand.jpなどです。プラットフォームはどちらにも対応しており、どちらを選ぶかで追加するレコードが変わります。

理由は古い取り決めで、交渉の余地はありません。ルートドメインにはドメインそのものを定義するレコードがすでにあり、DNSではCNAMEがほかのレコードと同じ名前を共有できません。そのためルートドメインはAレコードでIPアドレスを直接指し、サブドメインはCNAMEで別のホスト名を指します。

すでにウェブサイトを持つ旅行会社の多くは、サブドメインから始めるべきです。意見が分かれるのは二行目で、サブドメインは格が落ちて見えると感じる経営者もいます。もっともな見方ですが、顧客の大半がアドレスを打ち込むのではなくLINEやInstagramのリンクから来るなら、その重みは小さくなります。

追加するレコードと、それぞれの役割

管理画面のDNS設定ガイドに、あなたのドメイン用の正確な値が表示されます。値はそこからコピーしてください。どんな記事からも、この記事からもコピーしないでください。以下は各レコードが何のためにあるかの説明で、画面を見たときに意味がわかるようにするためのものです。

• サブドメインにはCNAME。Name：選んだラベル、たとえばbooking。Value：DNSステップが示すプラットフォームのホスト名。「この名前はあの名前の別名」という意味なので、プラットフォームのサーバーが移っても、あなたが触らずにレコードは動き続けます。
• ルートドメインにはAレコード。Name：多くのDNS管理画面でドメインそのものを表す@。Value：DNSステップが示すIPアドレス。「この名前はこの住所にある」という意味です。
• 場合によってはTXT。ホスティング構成によっては確認用のレコードも求められます。DNSステップが指定する名前の下に置く、長いランダムな文字列です。訪問者には何の影響もありません。ドメインを管理する人が接続に同意したことを証明するだけです。ステップに表示されていれば追加し、表示されていなければ足りないものはありません。

失敗の大半は二つのミスから来ます。一つ目は、Name欄にドメイン全体を入力することです。多くの管理画面はドメインを自動で付け足すため、booking.yourbrand.jpと入力するとbooking.yourbrand.jp.yourbrand.jpになり、どこにもつながりません。ラベルだけを入力してください。二つ目は、古いレコードを残したままにすることです。bookingに以前のプロジェクトのAレコードが残っていると、CNAMEはその横に置けず、管理画面によっては黙って古いほうを残します。同じ名前の古いレコードを先に削除してください。

DNSホストがレコードごとにプロキシのスイッチを持っている場合（Cloudflareではオレンジ色の雲で表示）、接続作業中はDNS-onlyに切り替えてください。プロキシはプラットフォームの代わりに訪問者へ応答するので、次に説明する確認からプラットフォームが見えなくなります。

鍵マークが最後に来る理由

経営者が「何か壊れた」と思うのはこの段階です。レコードは保存され、ドメインも正しく見えるのに、ブラウザは「保護されていない通信」と表示するか、サイト自体が開きません。何も壊れていません。順番が決まっているだけです。

TLS証明書、つまり鍵マークは認証局が発行します。認証局はまず、そのドメインが申請どおりの場所を本当に指しているかを確かめなければなりません。公開DNSで名前を引き、多くの構成ではドメインにリクエストを送ってプラットフォームが応答することまで確認します。あなたのレコードが認証局の使うリゾルバーに届くまで確認は失敗し、何度クリックしても変わりません。レコードが引けるようになれば、プラットフォームが自動で証明書を申請します。証明書を買う必要も、アップロードする必要も、更新する必要もありません。

「引けるようになる」までの時間は、主にそれ以前にあったレコードのTTL、つまりほかのサーバーが古い答えを覚えていてよい時間で決まります。まったく新しい名前なら、たいていすぐに現れます。昨日まで別の場所を指していた名前は、しばらく古いアドレスを返し続けることがあります。既存のレコードを置き換えるとわかっているなら、前日にTTLを下げておくと待ち時間が短くなります。

それ以外は、待ってから確認してください。レコードを何度も編集しないこと。編集するたびに、間違った答えをキャッシュしたサーバーにそれを返し続ける理由をひとつ増やすことになります。公開のDNS確認サイトを使えば、外の世界があなたの名前をどう見ているかがわかります。DNSステップの値が表示されたら、次に起こるのは証明書の発行です。

間違えたときの代償

高くつくミスは予約サイトの中では起きません。ドメインにぶら下がっている、それ以外のすべてで起きます。

最悪なのは、レコードを追加するだけでよいのにネームサーバーを変えてしまうことです。ネームサーバーを移すとドメイン全体が新しいDNSホストに引き渡され、そこで作り直さなかったレコードは消えます。会社のメールを届けるMXレコードも例外ではありません。受信箱が静かになったと誰かが気づくまでに、顧客からのメール、仕入先からの確認、航空会社からのスケジュール変更通知を一日分失うこともあります。予約サイトの接続にネームサーバーの移転はまったく必要ありません。レコードを追加し、ほかには手を付けないでください。

二つ目は、旧サイトにまだ使われているページがあるのにルートドメインを予約サイトへ向けることです。Googleで上位に出ているビザ案内のページや、名刺に印刷した問い合わせページなどです。それらのリンクは、そのページを持たない予約サイトに着地してしまいます。先に旧サイトをサブドメインへ移すか、予約サイトのほうをサブドメインに接続してください。

三つ目は神経をすり減らすだけのミスで、鍵マークが出る前に新しいアドレスを告知することです。宣伝したその日にブラウザが警告で顧客を追い返すのは、ひどい第一印象です。告知はレコードを保存した後ではなく、証明書が有効になった後にしましょう。

プラットフォームのドメインは残す：それが予備の入口

サイトを最初に立ち上げたプラットフォームのサブドメインは、独自ドメインを接続しても消えません。削除はできず、それは意図的なものです。

独自ドメインが落ち着くまでのテスト用アドレスであり、レジストラで更新を忘れたり誰かが誤ってDNSを編集したりしても動き続けるアドレスです。二つのアドレスの裏にある予約エンジンは同じなので、予約も顧客もレポートも、どちらの入口から来たかは気にしません。このアドレスは、独自ドメインが動いているかどうかに左右されない場所に控えておいてください。

新しいサイトの正しい順番もこれで決まります。一日でOTAを立ち上げるときと同じ順番です。まず登録ウィザードがカード不要で用意するサブドメインで公開し、見せられる状態になってから独自ドメインを接続します。アドレスが自分のものになった後、サイトが何をカバーするかはホワイトレーベルの旅行サイトで実際に得られるものにまとめています。

チェックリスト：予約エンジンに独自ドメインを接続する

1. DNSをどこがホストしているかを確認する。ドメインのネームサーバーを見ればわかる。
2. ルートドメインかサブドメインかを決める。残したいサイトがあるならサブドメイン。
3. 何かを変える前に、既存のレコード、特にMXをすべて記録する。スクリーンショットで十分。
4. これから使う名前とまったく同じ名前の古いレコードを削除する。
5. DNSステップのレコードを追加する。サブドメインはCNAME、ルートはA、表示されていればTXTも。Name欄にはラベルだけを入力する。
6. そのレコードのプロキシをDNS-onlyにする。
7. レコードが公開DNSで引けるまで待つ。何度も編集しない。
8. 鍵マークを確認し、新しいアドレスでテスト予約をしてから顧客に知らせる。

このリストのほとんどは待つことです。本当に痛い目にあう可能性がある手順は、リストに入っていないただひとつ、ネームサーバーの移転です。