「Webサイトを作るなら、まずドメインを取る」と言われても、何を登録し、その後に何が必要なのか分かりにくいものです。ドメインは、人が覚えて利用するための名前です。Webサイトのファイルやメールの中身、その保存先とは役割が違います。
この記事では、名前の読み方から、登録・更新・管理を続けるための確認までを説明します。例は仕組みを学ぶためのもので、ドメインの空きや接続成功を確認した実例ではありません。
30秒で要点
- ドメインは名前、URLは場所の指定。 URLにはドメイン以外に通信方法やページへのパスなどが含まれます。
- 名前は右から階層を読む。 TLDと実際に登録できる単位は同じとは限りません。
.co.jpのTLDはjpです。 - 登録してもサイトやメールは自動完成しない。 DNSと配信先・メール先の設定や契約を別に確認します。
- 初年度の価格だけで決めない。 登録者、更新、連絡先、支払情報、移管や復旧の条件を残します。
1. ドメイン・URL・ホスティングの関係
たとえば、文書用の例示名を使った次のURLを考えます。
https://www.example.com/services/?plan=basic#contact
表が収まらない場合は、横にスクロールできます
| 部分 | この例 | 役割 |
|---|---|---|
| 通信方法 | https | この例ではHTTPSで利用する |
| ホスト名 | www.example.com | 接続先を表す名前 |
| パス | /services/ | サイト内の場所を示す部分 |
| クエリ | ?plan=basic | 追加の情報を渡すための部分 |
| フラグメント | #contact | 文書内の位置などを示す部分 |
各部分の呼び方はMDNのURLリファレンスで確認できます。ここでは文字列を分ける練習として扱います。
example.comがドメイン名、www.example.comもその下の階層を含むドメイン名です。日常的に「取得したドメイン」と言う場合は、契約で登録した単位を指していることが多いため、ホスト名全体と区別すると混乱を減らせます。
この例で使うexample.comは、IANAが文書用に予約する例示ドメインです。登録・移管の対象ではなく、そのHTTPサービスを実アプリの依存先にしないよう案内されています。上のURLも文字列の説明であり、そのページの存在を主張していません。
名前があっても、届ける内容は別に必要
ドメインを住所名に、ホスティングを提供場所にたとえると、同じ住所名を案内しながら提供場所を移すこともある、と理解できます。ただし実際の変更にはDNSなどの設定や契約が関わり、切替が即時・無停止とは限りません。
MDNのドメイン解説では、DNSが名前に関連する接続先を調べる仕組みと、キャッシュした情報が更新されるまで時間がかかる場合を説明しています。DNSの情報、Webの配信先、メールの配送先を一つの設定だと思わないことが大切です。info@example.comのようなメールアドレスは、@より右側にドメインを使います。名前を登録しただけで、そのメールアドレスの受信箱までできるわけではありません。メールサービスと必要な設定を確認します。サイトの置き場所はホスティングの基礎で扱います。
2. 右から読む名前の階層と、登録できる単位
ドメインは、点で区切られた部分を右から順に読むと構造が分かります。点で区切る部分を「ラベル」と呼びます。
表が収まらない場合は、横にスクロールできます
| 例・形式 | 右端のTLD | その左の階層 | 確認すること |
|---|---|---|---|
example.com | com | exampleが第2階層 | この文字列は文書用の予約例 |
www.example.com | com | exampleの下にwww | 登録した名前の下で使うサブドメインの例 |
任意の名前＋.jp | jp | 登録する名前の部分 | 汎用JPなどの登録条件 |
組織の名前＋.co.jp | jp | coが第2階層、組織名はその左 | 属性型JPの区分と資格条件 |
.co.jp全体を一つのTLDと呼ぶのは正確ではありません。また「第2階層なら自由に登録できる部分」とも限りません。実際にどの単位を登録できるかは、そのTLDや区分の規則に従います。
サブドメインは必ず三つのラベルになるという意味ではありません。すでにある名前の下に作る名前で、さらに階層が続くこともあります。自社で管理する範囲とサービス提供者が設定する範囲を確認します。
.jpの区分を確認する
JPRSの説明では、汎用JP、都道府県型JP、属性型・地域型JPなどが区別されています。日本の住所という条件や、企業向けの.co.jpなど区分ごとの条件があります。
「日本の事業だからすべて同じJP名を登録できる」とは考えず、指定事業者の案内と現在の登録規則を確認してください。この記事は例外や組織変更時の資格を網羅するものではありません。また、紹介ページにある過去の登録比率や安全性の順位を、現在の統計として使っていません。
3. 名前を選ぶときは、伝わりやすさと管理を優先する
短さだけでなく、読み上げても伝わるか、似た名前と間違えにくいか、事業が変わっても使い続けられるかを考えます。名前の候補を複数用意し、利用条件と登録できるかを確かめる順序が現実的です。
表が収まらない場合は、横にスクロールできます
| 観点 | 自社で確認する問い |
|---|---|
| 読みやすさ | 口頭・名刺・案内文から入力するときに迷わないか |
| 誤認のしにくさ | 文字や区切りが似た別の名前と混同しないか |
| 継続性 | 一時的な商品名や担当者名に寄りすぎていないか |
| 利用条件 | 組織や所在地の条件に合うか。権利上の確認が必要か |
| 運用 | 誰が登録・更新・問い合わせに対応できるか |
商標などの権利関係は、空き状況だけでは判断できません。必要なら専門家へ確認します。取得できたこと自体を、他者の権利を侵害しない証明とは考えないでください。
キーワードを入れればSEOに有利、とは決めない
Googleのランキングシステムの説明では、ドメイン内の語は関連性を判断する多くの要因の一つとされる一方、検索語に完全一致させた名前を過大評価しない仕組みが示されています。そのため、名前にキーワードを入れるだけで順位が上がる、ハイフンを含むだけで不利になる、といった一般則にはしません。名前を変えるためにURLやメールを移す負担もあるため、SEOだけを理由に急いで変更しないようにします。
4. 登録は「誰の名義で、誰が管理するか」まで決める
登録の窓口と、サイト制作会社、ホスティング会社は同じ場合も別の場合もあります。担当者が変わっても調べられるよう、役割を記録します。
表が収まらない場合は、横にスクロールできます
| 役割・情報 | 残しておく内容 |
|---|---|
| 登録者 | 登録の権利を持つ組織・個人と、正しい登録情報 |
| 登録の窓口 | 契約している事業者、契約・問い合わせの連絡先 |
| 管理アカウントの責任者 | 自社で確認できる担当、引継ぎ先 |
| DNSの管理先 | 名前に関する設定を変更するサービスと担当 |
| Web・メールの提供先 | 配信、メール、関連機能の契約先と担当 |
| 更新情報 | 有効期限、通知先、支払方法、更新の確認方法 |
JPでは、JPRSの指定事業者を通して登録する仕組みが案内されています。登録情報を扱う組織と、利用者の契約窓口の関係は、実際の契約と公式案内で確認してください。
制作会社へ取得を依頼する場合も、自社の継続利用に必要な名義・管理権限・更新連絡・引継ぎを決めます。個人の記憶や、退職した担当者のメールだけに依存しないようにします。
旧Google Domainsの案内に注意する
以前の記事や手順にあるGoogle Domainsを、現在もGoogleが提供する新規登録サービスとして案内しないようにします。Squarespaceの公式移行案内は、Google Domainsの登録と関連する顧客アカウントを取得したことと、その後の管理方法を説明しています。
既存利用者は自分の現在の管理先を確認してください。管理の移行と、Webサイトやメールの設定がすべて変わることは同義ではありません。この記事では実アカウントの移行・操作は行っていません。
5. 初年度料金ではなく、更新を含む費用で比べる
ICANNの更新・失効に関するFAQは、登録事業者の条件、更新料金、期限、連絡先や支払情報を確認するよう案内しています。初年度の割引と更新時の価格は分けて見ます。次は仕組みを説明する架空の料金です。実際の事業者の見積や、現在の相場ではありません。
表が収まらない場合は、横にスクロールできます
| 架空の案 | 初年度 | 2年目 | 3年目 | 3年間の合計 |
|---|---|---|---|---|
| A | 1,000円 | 2,500円 | 2,500円 | 6,000円 |
| B | 2,000円 | 2,000円 | 2,000円 | 6,000円 |
Aは1,000＋2,500×2、Bは2,000＋2,000×2で、どちらも6,000円です。初年度が安い案だけを見ても、継続した総額は判断できません。この例には税、オプション、移管、失効後の復旧などの費用を含めていません。
価格が同じでも、必要な設定、支援範囲、更新通知、支払方法、取り出せる情報が違う場合があります。料金と機能を合わせて比較しましょう。
自動更新でも、確認する担当は必要
自動更新を使う場合も、支払方法の期限、通知先、更新後の状態を確認します。有効期限と社内の確認日を別に残しておくと、更新通知を見落としたときの確認につながります。
失効した後の回復手順や費用は、TLDや登録事業者、現在の状態で違います。ICANNの典型的なgTLDの説明を、そのままJPを含む全ドメインへ当てはめないでください。「一定期間なら必ず取り戻せる」と待つのではなく、契約先へ速やかに確認します。
6. WHOIS・RDAPは、登録情報を確認する仕組み
登録情報を調べる仕組みとして、WHOISやRDAPという名前が出てきます。ICANNの告知では、2025年1月28日からgTLD登録情報の提供基盤をRDAPへ移行すると説明されています。
これはJPなど、すべての国別TLDでWHOISが廃止されたという意味ではありません。また、登録者の個人情報がいつも全て公開されるわけではなく、非公開情報の取扱いは別です。
検索結果で名前が見つからないことだけを、登録できるという最終判断にも使いません。利用条件と最新の登録可否は、実際の登録窓口で確認します。この記事では実際の登録情報検索は行っていません。
7. 移管とサイト・メールの引越しを分ける
登録の窓口を移すこと、DNSの管理先を変えること、Webやメールの提供先を変えることは、別の変更です。同じ時期に行うことはあっても、まとめて一つの作業だと考えると確認漏れが起こりやすくなります。
まず現在の契約、DNSの設定、Web・メールの担当、更新期限を一覧にします。次に何を変えるのかを特定し、認証や契約条件、必要な停止、切替後の確認、戻せる範囲を担当者と確かめます。元の契約を先に解約して、データや連絡手段を失わないようにしてください。
DNSはキャッシュがあるため、変更直後に全利用者へ同じ状態が見えるとは限りません。この記事は移管や切替の実施手順書ではなく、影響を調べるための入口です。具体的な切替は利用する各サービスの現行手順に従って計画します。
8. 最小の確認：名前と担当を一枚に書けるか
ドメインを一つ取り上げ、登録窓口、登録者、DNS、Web、メール、有効期限、更新の担当を記入してください。新規サイトなら空欄が契約前の質問になり、既存サイトなら担当不明の箇所が引継ぎの課題になります。
URLを見分ける練習では、最初の例のホスト名・パス・クエリ・フラグメントを分けます。実在の契約やDNSを変更する必要はありません。名前の仕組みを理解する練習と、本番の設定操作を混ぜないようにします。
サイト制作全体の順序はWebサイト制作の入門、公開する環境はホスティングの選び方へ進めます。覚えやすい名前を選ぶことに加えて、その名前を自社で管理し続けられることを判断の中心に置きましょう。