UUID

UUIDとは何か？

UUIDは、日本語で「汎用的に一意な識別子」と訳され、ソフトウェアが管理する情報オブジェクトを一意に識別するための128ビットの数値です。通常、xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx のように、8-4-4-4-12桁の16進数で表現されます（合計32桁の16進数）。

UUIDの主な目的は、中央集権的な管理機関なしに、分散システム環境下でIDが重複する確率を極めて低く抑えながら一意なIDを生成することです。これにより、異なる場所や時間に生成されたIDが偶然一致してしまうことを防ぎます。

UUIDの構造において、特定のビットはバージョン情報（Mで示される部分の先頭4ビット）とバリアント情報（Nで示される部分の先頭1～3ビット）を表しており、これによりUUIDの生成方法やフォーマットが識別できるようになっています。

UUIDの歴史と標準化

UUIDの概念は、1980年代にアポロコンピュータ社のネットワークコンピューティングシステム（NCS）で生まれ、その後、Open Software Foundation（OSF）の分散コンピューティング環境（DCE）で採用されたことで広く知られるようになりました。

DCE UUIDの仕様は、後にIETF（Internet Engineering Task Force）によって標準化され、RFC 4122として公開されました。このRFC 4122は長らくUUIDの主要な標準仕様とされてきましたが、技術の進展や新たなニーズに対応するため、2024年5月にRFC 9562によって改訂・廃止（obsolete）され、新しいバージョンや改善が盛り込まれました。

UUIDのバージョン

UUIDにはいくつかのバージョンがあり、それぞれ生成方法や特性が異なります。

バージョン1 (Version 1: タイムスタンプベース)

生成方法:
60ビットのタイムスタンプ（グレゴリオ暦1582年10月15日0時0分0秒からの100ナノ秒単位）
14ビットのクロックシーケンス（同一時刻に複数のUUIDを生成する場合や、システムクロックが変更された場合に値を変更）
48ビットのノードID（通常はコンピュータのMACアドレス）
特徴:
時間的順序性がある程度期待できます（ただし、完全にソート可能とは限りません）。
生成元のノード（MACアドレス）を特定できる可能性があります。
課題:
MACアドレスが含まれるため、プライバシーに関する懸念がありました。
システムクロックの正確性や同期に依存します。

バージョン2 (Version 2: DCEセキュリティ)

生成方法: バージョン1のタイムスタンプの一部を、POSIXのUID/GID情報やローカルドメイン番号で置き換えたものです。
特徴: DCEのセキュリティ機能のために定義されましたが、一般的にはほとんど使用されていません。RFC 4122でも詳細な定義は省略されています。

バージョン3 (Version 3: 名前ベース、MD5ハッシュ)

生成方法:
名前空間識別子（Namespace ID、それ自体もUUID）
その名前空間内で一意な名前（文字列）
これらを連結し、MD5ハッシュアルゴリズムでハッシュ値を計算して生成します。
特徴:
同じ名前空間と同じ名前からは、常に同じUUIDが生成されます（決定論的）。
入力が同じであれば出力も同じになるため、冪等性を確保したい場合に有用です。
課題:
MD5ハッシュの衝突可能性が指摘されています（ただし、UUID生成における実用上の問題となるケースは稀です）。

バージョン4 (Version 4: ランダム)

生成方法: バージョンとバリアントを示す数ビットを除き、残りの122ビットを完全にランダムな値または疑似ランダムな値で生成します。
特徴:
生成が非常に容易で、外部情報（MACアドレスや時刻）に依存しません。
プライバシーに関する懸念が最も少ないバージョンの一つです。
最も広く利用されているバージョンの一つです。
課題:
衝突確率が完全にゼロではありませんが、122ビットのランダム空間を持つため、実用上問題となることは極めて稀です（例えば、数兆個のUUIDを生成しても衝突する確率は非常に小さい）。
時間的な順序性はありません。

バージョン5 (Version 5: 名前ベース、SHA-1ハッシュ)

生成方法: バージョン3と同様に名前空間識別子と名前から生成しますが、ハッシュアルゴリズムとしてSHA-1を使用します。
特徴:
バージョン3と同様に決定論的です。
SHA-1はMD5よりもハッシュ衝突耐性が高いとされています。
課題:
SHA-1も将来的には脆弱性が懸念されており、より強固なハッシュアルゴリズムへの移行が議論されることがあります。
新しいバージョン (RFC 9562で提案)
RFC 9562では、既存のバージョンに加えて、新たなUUIDバージョンが提案・定義されました。これらは、既存バージョンの課題解決や新たなユースケースへの対応を目的としています。

バージョン6 (Version 6: 再順序化タイムスタンプベース)

バージョン1を改良し、タイムスタンプのビット順序を並べ替えることで、ソート可能性を大幅に向上させています。
バージョン1のMACアドレスの代わりに、ランダムなビット列やハッシュ値を使用することでプライバシー懸念を軽減するオプションも提供します。

バージョン7 (Version 7: Unixエポックタイムベース)

Unixエポック（1970年1月1日0時0分0秒UTC）からのミリ秒単位のタイムスタンプと、より多くのランダムビットで構成されます。
高い衝突耐性を持ちつつ、時間的なソートが可能であるため、データベースの主キーなどでの利用が期待されています。生成時刻がUUIDの先頭部分に来るため、インデックス効率が良いとされています。
バージョン8 (Version 8: カスタム/実験的)
特定のアプリケーションや実験的な目的のために、ベンダーや組織が独自に定義できる形式です。UUIDのフォーマットは維持しつつ、一部のビットの割り当てを自由に設定できます。
UUIDが現在の体系になった理由
UUIDがこれほど多様なバージョンを持つ体系になった背景には、以下のような技術的な要求や課題への対応がありました。

一意性の確保（Universally Unique）

分散システムが普及するにつれ、中央集権的な採番システムなしに、世界中のどこで生成してもIDが衝突しない仕組みが求められました。128ビットという広大な空間と、各バージョンの工夫により、この一意性を極めて高い確率で保証しています。

多様なユースケースへの対応

時間的順序性: ログやイベントの記録など、生成された順序が重要となるケースがあります。バージョン1や、より改善されたバージョン6、バージョン7はこれに応えます。
内容ベースの識別: 特定のデータやリソースに対して、その内容から一意かつ決定論的なIDを生成したい場合があります。バージョン3やバージョン5がこれに適しています。例えば、同じURLからは常に同じUUIDを生成するといった使い方が可能です。
単純な一意性: MACアドレスなどの環境情報に依存せず、簡単に衝突の少ないIDが欲しいというニーズにはバージョン4が応えます。
プライバシー: 初期バージョン1のMACアドレス利用はプライバシー上の懸念を生みましたが、バージョン4やバージョン6以降ではこの点が考慮されています。

パフォーマンスと実装の容易さ

バージョン4は乱数生成に依存するため、比較的実装が容易で生成コストも低く抑えられます。
バージョン1やバージョン6、7は時刻情報へのアクセスや処理が必要になります。
データベースのインデックス効率も考慮されるようになり、バージョン7のようなソート可能なUUIDが注目されています。ランダムなUUID（特にバージョン4）は、B-Treeインデックスなどでは書き込み時に断片化を引き起こしやすく、パフォーマンスに影響を与える可能性が指摘されていました。

標準化による相互運用性

RFCによって仕様が標準化されることで、異なるシステムやプログラミング言語間でもUUIDを共通の識別子として利用できるようになりました。RFC 9562による改訂は、これまでの運用で明らかになった課題や新たな要求を取り込み、UUIDの有用性をさらに高めるものです。

衝突耐性の向上とセキュリティ

名前ベースのUUIDでは、ハッシュアルゴリズムの強度が重要になります。MD5（バージョン3）からSHA-1（バージョン5）への移行は、より高い衝突耐性を求める動きの現れです。将来的にはさらに強力なハッシュアルゴリズムに基づくバージョンが登場する可能性もあります。

技術者がUUIDを扱う上での注意点

バージョンの適切な選択: ユースケースに応じて最適なバージョンを選択することが重要です。例えば、単純な一意性が必要ならバージョン4、時間順序性が必要でデータベースのキーとして使いたいならバージョン7、特定の情報から決定論的にIDを生成したいならバージョン5（または3）といった具合です。
衝突確率の理解: 特にバージョン4では、理論上は衝突の可能性があります（ただし、実用上は無視できるほど低い）。この確率を理解し、許容できる範囲か評価する必要があります。
データベースでのパフォーマンス: ランダム性の高いUUID（特にバージョン4）をデータベースの主キーとして使用する場合、インデックスの断片化によるパフォーマンス低下に注意が必要です。バージョン7のような時間順序性のあるUUIDは、この問題を軽減するのに役立ちます。
セキュリティとプライバシー:
バージョン1のUUIDを外部に公開する場合、MACアドレスが含まれる可能性に留意が必要です（ただし、最近の実装ではプライバシー保護のためランダムなノードIDが使われることもあります）。
名前ベースのUUID（バージョン3、5）を使用する場合、入力となる「名前」が推測可能な場合、生成されるUUIDも推測可能になる点に注意が必要です。
生成ライブラリの品質と準拠性: 使用するプログラミング言語やライブラリが、RFCに準拠したUUIDを正しく生成できるか確認することが重要です。特に新しいバージョン（6, 7, 8）に対応しているかはライブラリによって異なります。
将来性: RFC 9562で新しいバージョンが定義されたように、UUIDの仕様も進化しています。最新の動向を把握し、必要に応じて新しいバージョンへの移行を検討することも重要です。