永続的な URI（ユニーク・リソース・アイデンティファイア）の設計と重要性

1. URI の変更が頻発する理由

理論上、ドメイン名の所有者は自身の管理下のすべての URI を制御する権利を持ち、ドキュメントが消える唯一の正当な理由は「企業の廃業」や「サーバー維持費の不足」のみであるはずですが、現実には以下のような人為的な要因により「枯れたリンク（dangling link）」が多数発生しています。

• 不適切なサイト再編成
  • 旧 URI の維持を無視したリデザインを行うのは不適切です。
  • 対策： 新しいリデザイン計画において、既存の URI をどう扱うかを事前に検討し、運用継続性を確保する設計が必要です。
• 管理負荷の増大と誤判断
  • 資料が多すぎて機密情報や古くなったものを区別できず、「無効化」を選択したケース。
  • 対策： 「先を見据えた対応」が必要です。各ドキュメントに対して配布範囲、作成日、有効期限などのメタデータを記録・維持しましょう。
• 実装構造と URI の分離不足
  • 「ファイルを移動させなければならない」という考えは弱気な言い訳です。
  • サーバー（Apache など）は、URI とファイルシステムの場所を柔軟にマッピングできます。
  • 対策： URI スペースを抽象的な空間として扱い、サーバー構成スクリプトやデータベースを活用して実装構造と分離させます。
• 人的管理の依存
  • URI に担当者名（例：

    john/...

    ）を含めるのは非推奨です。担当者が変わるだけでリンクが切れます。
• 技術スタックの変更による影響
  • 「CGI スクリプト」から「バイナリプログラム」へ変更した場合、URI を

    cgi-bin

    から移動させるなどの対応がなされることがありますが、これはサーバーの実装詳細を URI に暴露しており避けるべきです。
  • 対策： サーバー側の仕組みを変えても、コンテンツ自体（およびその URI）は変更しないようにします。

事例：国立科学財団（NSF）

• 不適切な URI 例：

  http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

  • 「cgi-bin」「.pl」といった表現は、現在のサーバー構成やスクリプト実装を直接指しており、将来のアーキテクチャ変更でリンク切れの原因になります。
• 適切な URI 例：

  http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

  • 「pubs/1998」というヘッダーにより、「古い分類スキームが進行中である」というアーカイブ情報が明記されています。将来ドキュメント番号が変わっても、この URI 構造は安定性を保証します。

2. URN（ユニーク・リソース・ネーム）への依存は危険

「URI に永続性を求めるべきではなく、役割は URN にある」という意見がありますが、これは有害な誤解です。

• 多くの既存の URN スキームは「組織 ID + 日付 + 文字列」のような形式で、HTTP URI と同様に組織の事情によって不安定になりがちです。
• もし組織が永続的な URN を提供できるなら、直ちに HTTP URI として実装し始めてください。
• 本質： HTTP の仕組み自体に欠陥があるのではなく、組織側の設計思想に問題があります。
  • ドキュメントの URN から現在のファイル名へのマッピングテーブルをデータベース化し、サーバーがそれに基づいてコンテンツを取得する仕組みを作りましょう。

3. なぜ URI の永続性が重要なのか？

サーバー上で URI を変更すると、以下のリスクが発生します。

• 外部リンクの把握不能
  • 通常のウェブサイト、ブックマーク、友人への手書きメモなど、どこでリンクが張られているかを完全に把握できません。
• 信頼失墜と挫折感
  • リンク切れに気づいた利用者はサーバー所有者への信頼を失い、目的達成に対する挫敗感を抱きます（精神的・実用的な両面）。
• 評判の毀損
  • 枯れたリンク苦情は避けられない事実ですが、それによるサーバー管理者の評判被害も明白です。

4. URI の設計原則：何を省くべきか？

Web マスターには、20 年後や 2000 年後でも有効な URI を割り当てる責任があります。「設計」とは、情報を省き、変化する要素から切り離すことです。

✅ 含めるべき情報

• 作成日（発行日付）：
  • これ以外の変化しない情報です。新しいシステムと古いシステムの区別や、アーカイブ分類に有用です。
  • 例：

    http://www.w3.org/1998/12/01/chairs

    （W3C 議長会議議事録）

❌ 省くべき情報（トラブルの元）

• 著者名： 著作権関係の変化や、担当者の退職に伴う引き継ぎリスクがあるため。
• 主題： 当時の文脈に合っていたとしても、時間の経過とともに意味が変化するため。
• ステータス：

  old

  ,

  draft

  ,

  latest

  など。ドキュメントの状態は常に変化するものであり、永続的な識別子には含めるべきではありません。
• アクセス制限： チーム限定、会員限定などの表記。公開範囲の拡大に伴いリンク切れを引き起こします（現在は日付コードで管理するのが標準です）。
• ファイル名拡張子：

  .html

  ,

  .pl

  など。技術フォーマットは時代とともに変わります。将来の HTML 未使用時でも現在のリンクが有効であるべきです。
• ソフトウェア機構： 「cgi」や「exec」といった実装詳細を表す語句。サーバーの実装変更に対応できなくなります。
• ディスク名： サーバー上の物理的なディレクトリ名を URI に含めるのは冗談めかしていますが、実際にリスクがあります。

例：トピックと分類の扱いについて

• 階層ツリー型構造は危険
  • 「MarkUp」→「Markup」→「HTML」といった名前変更は頻繁に発生します。
  • 言語の意味論（解釈の多様性）や、組織の再編による領域名の変更により、URI が破損するリスクがあります。
  • URI をトピック分類に縛ることは避けるべきです。
• ドメイン名の慎重さ
  • サーバー管理を容易にするため（例：

    secure

    ,

    cgi.pathfinder.com

    ）にドメイン名を分けることは、リンク破壊の原因になります。
  • リダイレクトやプロキシ技術を用いて、複数のサーバーを一つの論理的な Web サーバーとして見せる設計が推奨されます。

5. 実装上の工夫と注意点

拡張子の扱いについて（ファイルベースのサーバー向け）

Apache などでコンテンツネゴシエーションを設定することで、URI から拡張子を省きつつ形式を選択できます。

• 手順：
  1. サーバーをコンテンツネゴシエーション実行モードへ設定。
  2. URI に拡張子（例：

     .png

     ）を含まず参照する。
• メリット： HTML や PNG が主流から JavaScript や動画に変わる場合でも、ベースURI

  mydog

  は永続的に関係付けられます。
• 注意： データベースによるマッピングは有効ですが、無制限な成長には注意が必要です。

具体的な失敗事例（炎の殿堂）

物語 1：Channel 7 の雪閉鎖情報

• 状況：

  http://www.whdh.com/stormforce/closings.shtml

  で雪閉鎖情報を公開していたが、システム変更によりリンク切れ。
• 解決： URI を変更せず、新しいシステムに対応させることで解決可能でした。URI 自体の固定化は重要です。

物語 2：Microsoft Netmeeting のリンク切れ

• 状況： アプリケーション内埋め込みのリンク（Help/Microsoft on the Web/Free stuff など）が「Error 404」になり、その後修正されるまでに時間がかかったケース。
• 教訓： メーカーサイトへの埋め込みリンクでも、URL は変更しないよう厳格に管理すべきです。

結論 URI は変化せず、コンテンツとシステムのみが進化するべきものです。「現時点で最も優れたサイトを表示する」という任務が、将来的なリンク切れを招く原因になっているケースが多いです。設計段階から「200 年後も有効であるか」を考慮し、適切なツールの導入と保守体制の構築が必要です。