インターネット上の膨大なリソースを管理する際、「どこにあるか」ではなく「それが何であるか」を定義することが重要になります。そこで登場するのがURN（Uniform Resource Name）です。URNは、リソースの場所が変わったり、一時的にアクセス不能になったりしても、そのリソースを一意に識別し続けるための仕組みです。
現代のウェブ技術において、私たちは日常的にURLを利用していますが、技術的な視点ではURNやURIというより広い概念が存在します。本記事では、これらの定義の違いから、URNの具体的な構造、そして実社会でどのように活用されているかを詳しく解説します。
Key Facts
- URNの正体： リソースの「名前」を定義する永続的な識別子であり、場所（ロケーション）に依存しない。
- URIとの関係： URI（Uniform Resource Identifier）という大きな枠組みの中に、URLとURNが含まれる。
- 永続性： リソース自体が消滅したり移動したりしても、識別子としての有効性は維持される。
- 解決不能な特性： URN単体ではリソースへ直接アクセスできず、別途「リゾルバ」などの解析処理が必要。
- 管理体制： 名前空間（NID）の重複を防ぐため、多くはIANAによって管理・登録されている。
URI・URL・URNの概念的な関係性
かつてインターネットの情報アーキテクチャは、URL、URN、そしてメタデータ枠組みであるURC（Uniform Resource Characteristics）の3要素で構成されると考えられていました。しかし、URCは概念段階に留まり、実用化されませんでした。
現在では、W3CとIETFの共同作業により、これらを包括するURI（Uniform Resource Identifier）という用語が標準的に使われています。URIはインターネット上のリソースを識別するための文字列全般を指し、その中に「場所を示す」URL（Uniform Resource Locator）と、「名前を示す」URNが含まれるという構造になっています。
現代的な視点では、URIが「ロケータ（場所特定可能）」であるか「名前（識別のみ）」であるかの境界線は曖昧になっており、技術標準（RFC 3986以降）では個別の区別よりもURIとしての統合的な扱いが優先されています。それでも、特定のプロトコルに縛られない「不透明な識別子」としてのURNの有用性は高く評価されています。
URNの構文と技術的仕様
URNは特定のスキーム（urn:）を用いて記述されます。これはHTTPやFTPなどのプロトコルと同様に、URIの一種として機能します。2017年に更新されたRFC 8141に基づき、その構造は以下のように定義されています。
基本構造
URNは主に「スキーム」「名前空間識別子（NID）」「名前空間固有文字列（NSS）」で構成されます。スキーム部分は大文字小文字を区別しません。NIDには英数字とハイフンが使用でき、その後のNSSには各名前空間で定義された固有のルールに従った文字列が入ります。
最新の仕様変更
近年のアップデートにより、利便性が向上しています。具体的には、他の識別システムとの互換性を高めるためにNSS内でのスラッシュ（/）の使用が許可されました。また、リソースにパラメータを渡すための「q-コンポーネント」や、リゾルバへ指示を出すための「r-コンポーネント」が追加されています（ただし、r-コンポーネントは標準化が進むまで使用が制限されています）。
名前空間（Namespace）の管理
世界中でURNが重複しないようにするため、名前空間識別子（NID）はIANA（Internet Assigned Numbers Authority）への登録が義務付けられています。登録される名前空間は、その性質によって以下のように分類されます。
- フォーマルな名前空間： 公開によるメリットが大きく、厳格な制限（2文字以上の長さ、特定の接頭辞の禁止など）がある登録済みNID。
- インフォーマルな名前空間： IANAによって先着順に番号が割り当てられる形式（例：
urn:number:xxx）の識別子。 - 実験的な名前空間： かつては「X-」で始まる形式がありましたが、現在は廃止され、代わりに
urn:exampleの使用が推奨されています。
URNの具体例と活用シーン
URNは、書籍、映画、学術論文、製品管理など、長期的な保存と識別が必要な分野で幅広く利用されています。
| URNの例 | 識別対象 | 備考 |
|---|---|---|
urn:isbn:0451450523 |
書籍（The Last Unicorn） | ISBN（国際標準書籍番号）を利用 |
urn:isan:0000... |
映画（Spider-Man） | ISAN（国際標準オーディオビジュアル番号）を利用 |
urn:ISSN:0167-6423 |
学術雑誌（Science of Computer Programming） | ISSN（国際標準逐次刊行物番号）を利用 |
urn:ietf:rfc:2648 |
技術文書（RFC 2648） | IETFの標準文書を識別 |
urn:uuid:... |
ユニークなID | 登録機関を必要としないUUID形式 |
urn:epc:id:sgtin:... |
個別の製品 | GS1のEPC（電子商品コード）を利用 |
Frequently Asked Questions
URLとURNの決定的な違いは何ですか？
URLはリソースの「場所（住所）」を示すため、サーバーの移転などでアドレスが変わるとアクセスできなくなります。一方、URNはリソースの「名前（固有のID）」を示すため、場所が変わっても識別子自体は不変であり、永続的にそのリソースを指し示すことができます。
URNだけでウェブサイトのようにページを開くことはできますか？
いいえ、URN単体では直接リソースを特定して表示させる機能（ロケーション機能）を持っていません。URNをURLに変換してアクセスさせるための「リゾルバ」という仕組みを介する必要があります。
URIという言葉はいつ使うべきですか？
URLやURNを総称して呼びたい場合や、それが「場所」なのか「名前」なのかを限定せずに「リソースを識別する文字列」として言及したい場合にURIという用語を使用します。現在の技術標準ではこの包括的な表現が推奨されています。
URNの名前空間は誰でも自由に作れますか？
原則として、グローバルな一意性を保証するためにIANAへの登録が必要です。ただし、urn:uuid:のように、登録機関を介さずに一意なIDを生成できる特殊な名前空間も存在します。
URNは現在も使われている技術ですか？
はい。特にデジタルアーカイブ、図書館システム、物流管理（EPC）、法的な文書管理など、URLのような変動しやすい識別子では不十分な、長期的な信頼性が求められる分野で不可欠な技術として利用され続けています。
References
- .
- .
- .
- .
- .
- .
- .
- .
- .
- .