【完全保存版】URLとFQDNは何が違う？「インターネットの住所」の解剖学

「サーバーのFQDNを教えてください」「URLを共有してください」

ITの現場やWeb制作の打ち合わせで、この2つの言葉が飛び交うことがあります。なんとなく「Webサイトのアドレスのことだろう」と理解していても、「具体的にどこからどこまでがFQDNで、どこからがURLなのか」「なぜ使い分ける必要があるのか」を厳密に説明できる人は意外と少ないかもしれません。

この記事では、URLとFQDNの違いについて、基礎的な定義から、DNSでの名前解決の仕組み、セキュリティ証明書との関係まで、徹底的に深掘りして解説します。これを読めば、ネットワークの基礎知識が一つ上のレベルへ到達するはずです。

Table of Contents

1. 結論：一言で言うと何が違うのか

最初に結論から述べます。両者の最大の違いは「指し示している範囲」と「目的」です。

FQDN (Fully Qualified Domain Name)
- 範囲: インターネット上の「特定のコンピュータ（サーバー）」単体を指す。
- 目的: ネットワーク上でサーバーを特定するため（IPアドレスの代わり）。
- 例: www.google.com
URL (Uniform Resource Locator)
- 範囲: 通信プロトコル、サーバー、そしてその中の「ファイルの場所」まで指す。
- 目的: リソース（データ）にアクセスするための手順書。
- 例: https://www.google.com/search?q=test

関係性としては、「URLという長い命令文の中に、宛先としてFQDNが含まれている」という包含関係になります。

現実世界のアナロジー
- FQDN: 「東京都千代田区〇〇ビル」という建物の絶対住所。
- URL: 「宅急便で（プロトコル）、東京都千代田区〇〇ビルに行き、3階の会議室にある書類（パス）を取ってくる」という指示全体。

2. FQDN（完全修飾ドメイン名）の正体

FQDNは「Fully Qualified Domain Name」の略で、日本語では「完全修飾ドメイン名」と訳されます。

「完全」とはどういう意味か

普段、私たちは社内ネットワークなどで「サーバーA」や「PC-01」といった短い名前（ホスト名）でコンピュータを呼ぶことがあります。しかし、インターネットという広大な世界では、「サーバーA」という名前のコンピュータは世界中に五万と存在します。

これらを区別するために、「〇〇会社の、〇〇部署の、サーバーA」というように、親組織の名前を付けて特定する必要があります。「世界のどこから見ても、絶対にその一台にたどり着けるように、省略せずにすべて記述した名前」だから、「完全（Fully）」であり「修飾（Qualified）」された名前なのです。

構造：ホスト名＋ドメイン名

FQDNは大きく2つのパーツで構成されています。

FQDN = ホスト名 + ドメイン名

例： www.example.co.jp

www: ホスト名（サーバー自体の名前）
example.co.jp: ドメイン名（所属する組織やネットワークの領域）

隠された「ルートドメイン」の秘密

実は、私たちが普段目にしているFQDNは、厳密には最後の一文字が省略されています。

本当のFQDNは、最後にドット（.）がつきます。

普段の表記： www.example.com
厳密な表記： www.example.com.

この最後のドットは「ルート（Root）」と呼ばれ、インターネットのドメイン階層の頂点を意味します。Linuxなどの設定ファイル（BINDなど）や、厳密なDNSの設定では、この最後のドットを忘れると正しく動作しないことがあります。

階層構造による住所の特定

FQDNは、後ろから読むと理解しやすくなります。

. (ルート): インターネットの世界全体
.jp (TLD: トップレベルドメイン): 日本という国
.co (SLD: セカンドレベルドメイン): 企業組織
.example (サードレベルドメイン): exampleという特定の会社
www (ホスト名): その会社にあるWebサーバー

このように、広い範囲から徐々に絞り込んでいくことで、世界で唯一のコンピュータを特定しています。

3. URL（統一資源位置指定子）の解剖

URLは「Uniform Resource Locator」の略です。直訳すると「統一資源位置指定子」ですが、簡単に言えば「インターネット上のリソースの場所」です。

FQDNが「コンピュータ」を指すのに対し、URLは「そのコンピュータの中にある画像、HTMLファイル、動画」などのリソース（資源）を指します。

URLを構成する要素

標準的なWebサイトのURL https://www.example.com:443/dir/page.html?id=1#top を分解してみましょう。

要素	内容	役割
スキーム (プロトコル)	`https`	通信手段の指定（http, ftp, mailtoなど）。「どうやって」通信するか。
オーソリティ	`www.example.com`	通信相手。ここにFQDNが入ります。ユーザー名やパスワードが含まれることもあります。
ポート番号	`:443`	サーバー上の「どの扉」を叩くか。通常は省略されます（http=80, https=443）。
パス	`/dir/page.html`	サーバー内部のディレクトリ構造やファイル名。「どのファイル」が欲しいか。
クエリパラメータ	`?id=1`	プログラムに渡す変数。「どんな条件で」データを処理するか。
フラグメント	`#top`	ページ内の特定の場所。ページを開いた後、どこにスクロールするか。

このように、URLはFQDNを含んだ「全部入りの命令セット」であることがわかります。

【コラム】URI、URL、URNの違い

よく似た言葉にURI（Uniform Resource Identifier）があります。これらの関係は以下のようになっています。

URI: 総称（親カテゴリー）。リソースを識別するもののすべて。
URL: リソースの「場所」で識別するもの。（住所）
URN: リソースの「名前」で識別するもの。（書籍のISBNコードのようなもの。場所が変わっても名前は変わらない）

すべてのURLはURIですが、すべてのURIがURLではありません。

エンジニアの会話では「このエンドポイントのURI教えて」と言うことが多いですが、これはURLを含んだ広い意味で使われています。

4. インターネット通信における「役割」の違い

ユーザーがブラウザのアドレスバーにURLを入力してから、Webページが表示されるまでの流れを追うと、FQDNとURLの役割分担が明確に見えてきます。

ステップ1：ブラウザがURLを解析する

あなたが https://www.google.com/maps と入力します。

ブラウザはこれを解析し、「httpsで通信するんだな」「相手は www.google.com だな」「欲しいのは /maps だな」と理解します。

ステップ2：FQDNを取り出してDNSに問い合わせる（名前解決）

ブラウザは、通信を行うために相手のIPアドレスを知る必要があります。

しかし、URL全体（https://.../maps）をDNSサーバーに聞いても、DNSは答えられません。DNSは**FQDN（ドメイン名）**しか理解できないからです。

ブラウザはURLからFQDN部分 www.google.com だけを抽出します。
DNSサーバーに「www.google.com のIPアドレスは？」と問い合わせます。
DNSサーバーがIPアドレス（例: 142.250.x.x）を返します。

★ここがポイント

DNSにとっては、後ろのパス（/maps）やプロトコル（https）は関係ありません。DNSが処理するのはあくまでFQDNだけです。

ステップ3：IPアドレスに対してURLの命令を送る

IPアドレスが判明したら、ブラウザはそのサーバーに対して実際のアクセスを行います。

ここで初めて、URLの残りの情報が使われます。

プロトコル: HTTPSの手順で接続を開始。
パス: サーバーに対して GET /maps というリクエストを送る。

サーバーは「/maps というリクエストが来たから、地図のデータを返そう」と処理を行います。

5. エンジニア視点での重要ポイント

実務レベルでは、この違いを理解していないとハマるポイントがいくつかあります。

SSL/TLS証明書はFQDNに紐づく

WebサイトをHTTPS化する際に必要な「サーバー証明書（SSL証明書）」は、基本的にFQDN単位で発行されます。

www.example.com 用の証明書は、blog.example.com では使えません（エラーになります）。
URLのパス部分（/company や /products）は証明書に関係ありません。

ワイルドカード証明書（*.example.com）などもありますが、証明書における「本人確認」の単位はあくまでドメイン（FQDN）であることを覚えておきましょう。

バーチャルホストとHTTPヘッダー

1つのWebサーバー（1つのIPアドレス）で、複数のWebサイト（site-a.com と site-b.com）を運営する技術を「バーチャルホスト」と呼びます。

この時、サーバーは送られてきたリクエストが「どのFQDN宛てのものか」を判断するために、HTTPリクエストヘッダー内の Host: という項目を見ます。

URLを入力してアクセスする際、ブラウザは自動的にFQDNをこの Host ヘッダーにセットして送信しています。これにより、サーバーは正しいWebサイトを表示できるのです。

トラブルシューティング（pingとcurlの使い分け）

サーバーに繋がらない時、エンジニアは黒い画面（ターミナル）でコマンドを打ちます。

ping コマンド
- 対象: FQDN (またはIPアドレス)
- 例: ping www.google.com
- 理由: サーバーそのものが生きているか、ネットワークが繋がっているかを確認するため。URL（パス含む）を指定するとエラーになります。
- ping https://www.google.com/ ← これは間違い！
curl コマンド
- 対象: URL
- 例: curl -I https://www.google.com
- 理由: Webサーバーとして正常にページを返してくるか、HTTPステータスコード（200 OKなど）を確認するため。

「サーバーは生きている（pingは通る）が、Webページが見られない（curl/ブラウザがエラー）」という切り分けを行うためにも、この2つの違いの理解は必須です。

6. まとめ

URLとFQDNの違いについて、長旅にお付き合いいただきありがとうございました。

最後に要点を整理します。

FQDNは「インターネット上のコンピュータの絶対的な名前（住所）」。
URLは「リソースへのアクセス手順と場所（指示書）」。
URLの中にFQDNが含まれている。
DNSはFQDNを使ってIPアドレスを調べる。
WebサーバーはURL（パス）を見て具体的なデータを返す。

「URL」は日常会話でも使われる一般的な言葉ですが、「FQDN」はインフラエンジニアやサーバー管理者が意識する専門的な概念です。

しかし、Webサイトがどのように表示されるのか、その裏側の仕組みを理解するためには、この2つの区別が欠かせません。もし今後、サーバーの設定やトラブルシューティングに関わることがあれば、ぜひ「今はFQDNの話をしているのか、URL全体の話をしているのか」を意識してみてください。それだけで、問題解決のスピードが格段に上がるはずです。