URL
Web上のリソースの場所を表す文字列。スキーム・ホスト・パスからなる。
概要
URL（Uniform Resource Locator）は、Web上にあるリソースの「住所」を表す文字列です。https://example.com/search?q=cat#results のような一行の中に、「どうやって（スキーム）」「どこの（ホスト名）」「何を（パス）」「どんな条件で（クエリ）」取りに行くかがすべて詰め込まれています。ブラウザのアドレスバーに毎日入力しているものですが、その一行が通信のどの段階で・誰に使われるのかを分解して見ると、Webの動きが立体的に見えてきます。
日常の開発でも URL は至るところに登場します。リンクを張るとき、API を呼び出すとき、リダイレクトを設計するとき、ページのルーティングを決めるとき——「この情報はパスに載せるべきか、クエリパラメータに載せるべきか」という判断は、Webアプリケーション設計の最初の一歩です。
なお、よく似た言葉に URI（Uniform Resource Identifier）があります。URI は「リソースを識別する文字列」全般を指す広い概念で、URL はそのうち「場所を示して到達できるもの」を指します。実務上はほとんどの場面で URL と呼んで差し支えありません。
なぜ生まれたか
Web以前のインターネットには、FTP・Gopher・ニュースグループなど複数のサービスが並立していて、それぞれ「どのサーバの、どのファイルか」を指定する流儀がバラバラでした。ある文書から別のサービス上の文書を指し示す共通の方法がなく、「世界中の文書をリンクで結ぶ」というハイパーテキストの構想を実現できなかったのです。
ティム・バーナーズ＝リーが Web を設計したとき、この問題を解決するために考案したのが URL です。「プロトコル + ホスト + パス」という統一フォーマットを決めたことで、種類の異なるリソースを一つの記法で指せるようになり、あらゆる文書が相互にリンクし合う Web が成立しました。URL は HTML・HTTP と並ぶ、Webを支える三大発明の一つです。
詳細
構造を分解する
https://user:pass@example.com:443/search?q=cat#results を左から順に見ていきます。
- スキーム（
https）: リソースへの到達方法。http/httpsのほか、mailto:、ftp:などもあります。HTTPS を選べば通信が暗号化されます。 - ホスト名（
example.com）: リソースを持つサーバの名前。DNS によって IPアドレスに解決されます。 - ポート（
:443）: サーバ内のどの窓口に接続するか。ポート番号はスキームごとにデフォルト（http=80、https=443）があるため、通常は省略されます。 - パス（
/search）: サーバ内でのリソースの位置。どのプログラムやファイルが応答するかをサーバ側が決める手がかりです。 - クエリパラメータ（
?q=cat）:キー=値の組を&で連ねる追加条件。検索条件やページ番号など「同じリソースの絞り込み・変化形」を表します。 - フラグメント（
#results）: ページ内の位置。ここだけはサーバに送信されず、ブラウザがページ表示後にスクロール位置などとして解釈します。
各パーツがどこで消費されるかを図にすると、次のようになります。
好きなURLを入力すると、ブラウザ標準の URL API がどう分解するか（日本語のパーセントエンコーディング含む）をその場で確かめられます。
- スキーム
https到達方法（暗号化の有無）- ホスト名
example.comDNSがIPアドレスに解決- ポート
8080省略時はスキームの既定値- パス
/searchサーバ内のリソースの位置- クエリ
?q=%E7%9F%A5%E6%98%9F%E5%9B%B3&page=2絞り込みなどの追加条件- フラグメント
#resultsサーバには送られない
| キー | 値 |
|---|---|
q | 知星図 |
page | 2 |
ブラウザの URL API が正規化した形は https://example.com:8080/search?q=%E7%9F%A5%E6%98%9F%E5%9B%B3&page=2#results です。日本語などURLに使えない文字は、パーセントエンコーディングで自動的に変換されます。
一行のURLが通信で果たす役割
ブラウザにURLを入力してからページが返るまで、URLの各部分は別々の場面で消費されます。
つまりホスト名は「どのサーバに繋ぐか」を決めるためにDNSが使い、パスとクエリは接続確立後に HTTP リクエストラインとしてサーバへ送られ、フラグメントは最後までブラウザの手元に残ります。「URLのどの部分が誰に届くのか」を知っておくと、たとえば「フラグメントに入れた値はサーバのログに残らない」といった挙動が自然に理解できます。
URL設計は API・アプリ設計の入口
REST API の設計では、「リソースをパスで表し、操作は HTTP メソッドで表す」という考え方が基本になります。/users/42 のようにパスが「モノ」を指し、絞り込みや並び替えはクエリパラメータに載せる——この使い分けが崩れると、キャッシュが効かなくなったり、URLを共有・ブックマークしても同じ結果が再現できなくなったりします。「URLだけで状態が再現できるか」は良いWebアプリの目安の一つです。
エンコーディングという落とし穴
URLに使える文字は限られており、日本語やスペース、& や ? などの記号をそのまま含めることはできません。そこで「パーセントエンコーディング」により、猫 は %E7%8C%AB のように変換されます。実務でよくあるバグが「二重エンコード」（すでにエンコード済みの文字列を再度エンコードして %25E7... になる）や、逆にエンコード漏れでクエリが壊れるケースです。URLを組み立てるときは文字列連結ではなく、言語標準の URL 構築 API を使うのが安全です。
現代的な論点
URLは単なる住所以上の意味を持つようになっています。SEOでは読みやすいパス構造が評価に影響し、SPAではブラウザの History API でページ遷移なしにURLを書き換えます。また、クエリパラメータに個人情報やトークンを載せると、アクセスログやリファラ経由で漏洩する恐れがあるため、機密情報はURLに含めないのが原則です。「URLは他人に見られ、記録され、共有されるもの」という前提で設計することが、セキュリティ面でも重要です。