Domain Name System
人が使う名前を、
サービスの接続先へつなぐ
ドメインは、Webサイトやメールで使う「人が覚えやすい名前」です。ただし、URL、DNS、IPアドレス、サーバーとは役割が違います。example.comを分解しながら、取得・費用・SEO・安全な運用まで順番に整理します。
Domain Name System
人が使う名前を、
サービスの接続先へつなぐ
名前をDNSで解決し、接続先へアクセスする流れを図解しています。
結論から言うと、ドメインはインターネット上で使う「名前」です。 DNSがその名前に対応するIPアドレスやメール配送先を調べ、接続先のサーバーがWebページやメール機能を提供します。URL、DNS、IPアドレス、サーバーは一連の処理で連携しますが、同じものではありません。
たとえば https://shop.example.com/products では、example.comが登録するドメイン名、shop.example.comがホスト名、/productsがパスです。ドメインを取得しただけではサイトは表示されず、DNS・サーバー・HTTPSの設定がそろって初めて公開できます。
| 一言でいうと | Webサイトやメールなどで使う、人が覚えやすい階層的な名前 |
|---|---|
| URLとの違い | ドメイン名はURLのホスト部分に使われる要素で、URL全体ではない |
| DNSとの違い | ドメイン名は名前、DNSは名前に対応する情報を問い合わせる仕組み |
| 取得後に必要な設定 | 権威DNS、A・AAAA・CNAME、Webサーバー、TLS証明書、必要に応じてMX・TXT |
| 費用で見る点 | 初年度だけでなく更新、移管、失効回復、オプション、為替・税 |
| 安全な管理 | 会社名義、多要素認証、自動更新、最小権限、変更手順、監視 |
| 確認日 | 2026年7月29日 |
ドメイン名とは、ドットで区切られたラベルを階層として並べ、Webサイト、メール、APIなどの対象を識別するために使う名前です。
数字で表すIPアドレスを毎回覚える代わりに、finitefield.org や example.com のような名前を使えるため、人に伝えやすく、サービスのブランドにもできます。日常会話では「ドメイン」と「ドメイン名」をほぼ同じ意味で使いますが、DNSの技術用語でdomainは、ある位置から下に広がる名前空間全体を指す場合があります。
wwwホストを示すラベルshop用途を分けるラベルexample.com直下で登録する名前comトップレベルドメイン階層は右側のTLDから左へたどります。
.com がトップレベルドメイン(TLD)、その下の example.com が一般に登録する単位、さらに左の shop や www は登録後に管理者が作る下位の名前です。DNSのルートまで明示した完全修飾表記は www.shop.example.com. のように末尾へドットを付けますが、通常の画面では省略します。
Web制作ではexample.comを「ルートドメイン」と呼ぶことがありますが、DNSの本来のルートは名前空間の最上位にある「.」です。誤解を避けるなら、example.comは「登録ドメイン名」または、DNSゾーンの最上部を指す場合は「ゾーン頂点(apex)」と表現すると明確です。
これらは同じWeb表示の流れに登場するため混同されますが、役割が違います。「住所」「電話帳」という比喩だけで覚えるより、何を表し、どこで使われるかを分けると理解しやすくなります。
↔ 表は横方向にスクロールできます
| 用語 | 意味・役割 | 具体例 | 混同しやすい点 |
|---|---|---|---|
| ドメイン名 | DNSの階層的な名前空間にある名前 | example.com | URL全体でも、サーバー本体でもない |
| URL | スキーム、ホスト、パスなどを含み、資源を識別する文字列 | https://example.com/about/ | ドメイン名はURLのホスト部分に含まれる |
| DNS | 名前に対応するIPアドレス、メール配送先などを問い合わせる仕組み | A、AAAA、CNAME、MX、TXT | Webページ本体を配信する仕組みではない |
| IPアドレス | IPネットワークで接続先を扱う数値のアドレス | 192.0.2.1、2001:db8::1 | 同じ名前に複数IP、同じIPに複数サイトを設定できる |
| Webサーバー | HTTP要求を受け、HTML、画像、API応答などを返すソフトウェアや実行環境 | Nginx、Apache、Cloud Runなど | ドメイン登録やDNS管理とは別の層 |
| ホスト名 | ネットワーク上のホストやサービスを識別するために使うドメイン名 | shop.example.com | 登録単位とは限らない |
ブラウザはURLからホスト名を取り出し、必要なA・AAAAなどのレコードを問い合わせます。パス、クエリ、フラグメントをDNSへ送ってページを探すわけではありません。また、#specのようなフラグメントは通常HTTP要求に含まれず、取得後のページ内位置などに使われます。
実際の処理にはキャッシュ、CDN、IPv4・IPv6、プロキシ、HTTP/2・HTTP/3なども関係しますが、基本の責任分界は次の5段階です。
https、ホスト、ポート、パス、クエリ、フラグメントを解析します。省略されたポートはスキームの既定値などから判断されます。
端末やブラウザのキャッシュを確認し、必要ならキャッシュDNSへ問い合わせます。キャッシュDNSは保持済みの値または権威DNSへの問い合わせから応答を得ます。
AレコードならIPv4、AAAAレコードならIPv6の接続先候補を得ます。CNAMEなどで別名をたどる構成もあります。
TLS証明書がアクセス先のホスト名に対応するかを検証し、暗号化された接続を確立します。DNSが正しくても証明書が不一致なら警告になります。
ブラウザはホスト、パス、クエリなどを含むHTTP要求を送り、WebサーバーやアプリがHTML、画像、JSONなどを返します。
登録状態 → 委任 → DNS応答 → ネットワーク → TLS → HTTP → アプリ の順に確認します。「ドメインが反映されない」という一言だけでは、期限切れ、ネームサーバー不一致、A/AAAAの誤り、DNSSEC、証明書、Web設定のどこに問題があるか判断できません。
トップレベルドメインはIANAのRoot Zone Databaseに委任情報が掲載されています。その下で誰が何を登録できるか、必要な資格、文字数、更新や移管の条件は各レジストリの規則で決まります。
.com、.org、.netなど。現在は多様な新gTLDもあります。元の用途イメージと、現行の登録資格が一致するとは限りません。
.jp、.uk、.deなど。国・地域との結びつきがあり、登録資格や必要情報は管理組織ごとに異なります。
日本国内に住所を持つ個人・組織等が対象です。登録数に制限がなく、日本語ドメイン名にも対応します。
CO.JP、OR.JP、AC.JP、GO.JPなど。組織種別ごとの登録資格があり、原則として1組織1ドメイン名などの規則があります。
↔ 表は横方向にスクロールできます
| 区分 | 例 | 向く場面 | 確認事項 |
|---|---|---|---|
| 一般的なgTLD | .com、.org、.net | 国内外を問わず使うブランド・サービス | 更新価格、商標、移管、回復条件 |
| 国別TLD | .jp、.de、.uk | 特定の国・地域を主対象にするサイト | 所在地・資格、公開情報、利用規則 |
| 汎用JP | example.jp | 日本向けの個人・法人・団体サイト | 日本国内住所、文字・形式、指定事業者 |
| 属性型JP | example.co.jp | 日本で登記された会社など | 組織種別、1組織1ドメイン名、名義 |
| 日本語ドメイン | 日本語.jp | 広告、地域名、覚えやすい補助URL | 入力環境、メール対応、似た文字、ASCII互換表現 |
.comなら必ず安全、珍しいTLDなら不利、と一律には判断できません。運営者情報、コンテンツ、HTTPS、更新管理、迷惑行為の履歴、対象地域との整合性を合わせて見ます。
サイトを増やすときは、別の独自ドメイン、サブドメイン、サブディレクトリのどれに置くかを決めます。名称が似ていますが、契約・DNS・サイト構成の単位が異なります。
| 方式 | 例 | 特徴 | よく使う場面 |
|---|---|---|---|
| 独自ドメイン | example.com | レジストラ等を通じて登録し、契約・更新する名前 | 会社、サービス、ブランドの中心サイト |
| サブドメイン | shop.example.com | 登録済みドメインの配下にDNSで作る名前。別サーバーにも接続可能 | ショップ、管理画面、API、国別・製品別サイト |
| サブディレクトリ | example.com/shop/ | 同じホスト内のURLパス。DNSではなくWeb側の構成 | 記事カテゴリ、製品ページ、多言語ディレクトリ |
サブドメインに分ければ自動的に安全な別環境になるわけではありません。CookieのDomain属性、認証、CORS、TLS証明書、検索公開範囲、管理権限を設計します。逆に、サブディレクトリなら必ず同じアプリである必要もなく、リバースプロキシ等で異なるシステムへ振り分けることもできます。
ドメイン名は「商品を永久購入する」のではなく、登録者がレジストラとの契約およびTLDの規則に従い、登録期間中の利用・管理権限を持つ仕組みです。初年度価格だけで決めず、更新・移管・失効まで含めて選びます。
会社名、サービス名、対象国、メール利用、音声で伝えたときの分かりやすさ、誤入力、似た名称を整理します。
空いていることと、商標や名称を安全に使えることは別です。登録資格、商標、既存サービス、類似表記を確認します。
初年度・更新・移管・回復の料金、DNS機能、二要素認証、サポート、名義変更、解約手順を比較します。
法人利用なら、制作会社や担当者個人だけに依存せず、会社が継続管理できる登録者情報・メール・支払方法を使います。
権威DNS、A・AAAA・CNAME、MX・TXT、Webの接続先、TLS証明書を用途別に構成し、外部ネットワークから確認します。
3年間の実質費用 = 初年度登録料 + 2回分の更新料 + 必要なオプション費用 として比較すると、初年度だけ安いプランを見抜きやすくなります。更新価格、税、為替、無料特典の期間は変わるため、申込み直前の表示を確認してください。
同じ事業者にまとめると初期設定は簡単ですが、登録者名義、移管性、障害時の責任分界、解約時の持ち出しやすさも重要です。レジストラ、権威DNS、ホスティングの契約先と管理者を台帳に残します。
SEOのために検索キーワードを詰め込むより、利用者が覚えやすく、長く使える名前を選ぶ方が実務的です。Googleは、ドメイン名内の語を関連性判断の一要素としつつ、完全一致ドメインを過大評価しない仕組みを説明しています。
会社名・サービス名と一致し、検索結果、名刺、メール、SNSで同じ名前を使える方が認知を積み上げやすくなります。
口頭で伝えられ、入力ミスが起きにくい文字列を選びます。数字・ハイフン・似た綴りは必要性を検討します。
Googleは一般的なTLDの違いを通常は大きな順位要因としない一方、ccTLDは特定国向けである強いシグナルになると説明しています。
現在の商品名や地域名に狭く限定しすぎると、サービス追加や海外展開で変更が必要になる場合があります。
どちらもDNSとTLSを成立させ、正規URLを一つに決め、もう一方を301または308で転送します。canonicalだけに依存しません。
ドメイン変更はURL、被リンク、メール、広告、OAuth、Cookie、証明書などに影響します。必要な場合はURL単位の恒久転送と監視を行います。
検索意図を満たす内容、クロール可能な内部リンク、分かりやすいURL、ページ速度、モバイル対応、HTTPS、構造化データ、運営者情報、継続更新が土台です。「キーワード入りドメインを取れば上位表示できる」という期待は持たない方が安全です。
ドメインが失効・乗っ取り・誤変更されると、Webだけでなくメール、ログイン、API、広告、外部サービス連携まで止まる可能性があります。サーバーの一設定ではなく、事業の重要資産として管理します。
DNSSECはDNS応答の真正性検証を支援し、TLSは接続先の認証と通信保護、レジストラ/レジストリロックは登録・移管等の変更統制に関係します。対象TLDと事業者の対応状況を確認し、運用手順とセットで導入します。
登録状態、満了日、請求、回復可能期間を確認します。復旧後もDNS・TLS・メールが同時に戻るとは限りません。
TTLとキャッシュだけでなく、権威サーバー間の差、委任、A/AAAA、DNSSEC、CDN、ブラウザキャッシュも確認します。
両方のDNSとTLSを用意し、正規側へ恒久転送します。内部リンク、canonical、サイトマップも同じURLへ統一します。
Web用Aレコードだけではメールは動きません。MX、送受信サービス、SPF・DKIM・DMARC、旧メール環境の残存を確認します。
確認時は、問い合わせたリゾルバー、対象名、レコード型、応答値、TTL、時刻、IPv4・IPv6、HTTP状態、証明書を残します。権威DNSの応答と、一般のキャッシュDNSから見える応答を分けると原因を絞りやすくなります。
ドメイン名の登録状態、レジストラ、ネームサーバー、作成・更新・満了に関する情報などは、TLDに対応する登録情報検索で確認できます。現在、gTLDではRDAP(Registration Data Access Protocol)が標準的な確認手段です。
ICANNによると、gTLDのレジストリとレジストラはRDAPの提供が必須で、2025年1月28日以降は一部例外を除きWHOISサービスの提供義務が終了しました。RDAPはHTTP(S)と構造化された応答を使い、国際化、認証、権威サービスの発見に対応します。
ただし、公開範囲はTLD、レジストリ、レジストラ、データ保護規則で異なります。検索結果に個人情報が見えないことは、未登録や不正を意味しません。また、ccTLDでは独自の検索方法を採用している場合があるため、管理組織の公式案内を確認します。
同じではありません。ドメイン名はexample.comのような名前です。URLはhttpsなどのスキーム、ホスト、パス、クエリ、フラグメントなどを含む、資源を識別する文字列全体です。
同じではありません。ドメイン名は人が扱いやすい名前、DNSはその名前に対応するIPアドレスやメール配送先などの情報を問い合わせる仕組みです。
必須ではありません。wwwはexample.comの配下に作る慣習的なホスト名です。wwwあり・なしのどちらを正規URLにするかを決め、もう一方から301または308で転送します。
取得だけでは公開できません。権威DNS、A・AAAA・CNAMEなどのDNSレコード、Webサーバーや配信サービス、TLS証明書を設定する必要があります。
永久所有ではありません。登録期間中に利用・管理する契約であり、継続利用には更新が必要です。期限、失効、回復、削除の条件はTLDと事業者によって異なります。
キーワードを入れただけで上位表示できるわけではありません。Googleはドメイン名の語を関連性判断の一要素としつつ、完全一致ドメインを過大評価しない仕組みを説明しています。ブランド性と分かりやすさを優先します。
一律には決められません。TTL、キャッシュ、委任、権威DNS、IPv4・IPv6、DNSSECなどで見え方が変わります。待つだけでなく、問い合わせ先・レコード型・応答値・TTL・確認時刻を記録します。
公開範囲はTLD、登録事業者、データ保護規則によって異なります。gTLDではRDAPが標準的な確認手段になっており、個人情報が非公開または編集済みの場合があります。
定義、階層、URL構文、TLD、登録・更新、RDAP、JPドメイン名、SEOに関する記述は、次の公式資料を基準に確認しました。
ドメイン名はURLそのものでも、DNSそのものでも、サーバーそのものでもありません。名前を登録し、DNSでWebやメールに必要な情報を公開し、接続先でサービスを提供するという三層で考えると、取得・移行・障害対応が整理できます。
選ぶときはブランド性、分かりやすさ、登録資格、更新費用、将来の事業展開を確認します。運用では会社名義、多要素認証、自動更新、権限管理、変更手順、DNS・TLS・メールの監視を整えます。検索順位をドメイン名だけで狙うのではなく、ユーザーに役立つ内容と安定したサイト運用を積み上げることが重要です。
ドメイン取得やDNS設定だけでなく、情報設計、SEO、WordPress・Goでのサイト制作、リニューアル、表示速度改善、公開後の運用まで一体でご相談いただけます。
「作りたいものはあるが、どう進めるべきか分からない」という段階でも大丈夫です。
現状調査、ドメイン・DNS移行、既存URLの整理からお手伝いします。