※この記事にはプロモーション（広告）が含まれています。
UUID（Universally Unique Identifier）とは、分散システムにおいて事前の調整なしに、世界中で重複しない識別子を生成するための128ビットの数値規格である。
UUIDの基本構造
UUIDは、単なるランダムな数字の羅列ではない。RFC 4122（現在はRFC 9562へアップデート）によって定義された厳格なフォーマットに基づいている。
- 128ビットのバイナリデータと32桁の16進数表記UUIDの本体は128ビットの数値だが、人間が読みやすいように「8-4-4-4-12」の形式でハイフン区切りされた32桁の16進数で記述されるのが通例である（例：550e8400-e29b-411d-a516-446655440000）。
- 「Variant」と「Version」による種別判定データ内には特定のビット位置に「バリアント（Variant）」と「バージョン（Version）」を示すフィールドが埋め込まれている。これにより、そのUUIDがどの仕様に基づき、どのようなアルゴリズムで生成されたかを判別できる仕組みになっている。
- 時空間的、あるいは統計的な一意性の確保構造内には生成時の時刻、MACアドレス、あるいは高度な疑似乱数が組み込まれる。これらを特定のルールで混合することで、天文学的な確率で「衝突（重複）」を回避する構造となっている。
UUIDのバージョン
UUIDには、生成のロジックによって複数のバージョンが存在する。用途に応じて最適なものを選択する必要がある。
- 時系列に基づくVersion 1とVersion 6/7V1はMACアドレスと現在の時刻を組み合わせて作成される。V6はV1の時刻情報を並べ替えてDB検索しやすくしたもの、V7はUnix Epoch（Unix時間）をベースにした現代的な標準である。
- ハッシュ値を利用するVersion 3とVersion 5特定のドメイン名やURLといった「名前」を元に生成される。V3はMD5、V5はSHA-1アルゴリズムを用いる。入力が同じであれば常に同じUUIDが出力されるため、再現性が求められる場面で重宝する。
- 完全なランダム性を追求するVersion 4128ビットのうち、バージョンとバリアントを示すビットを除く122ビットを乱数で埋める。現在、Web開発やアプリケーションの実装において最も広く利用されているタイプである。
UUIDの生成方法
UUIDの生成は、使用する言語やライブラリによって抽象化されているが、内部では以下のようなプロセスが実行されている。
- 暗号学的に安全な乱数生成器（CSPRNG）の利用特にVersion 4においては、予測不可能な乱数ソースが鍵となる。OSが提供するエントロピー（/dev/urandomなど）を利用し、推測困難なビット列を確保することで、他者との重複を実質的にゼロに抑え込んでいる。
- 時刻情報とナノ秒精度のカウンタ合成Version 1や7では、システムクロックを取得して上位ビットに配置する。同じ瞬間に複数のUUIDが要求された場合に備え、シーケンス番号（カウンタ）をインクリメントして付与することで、同一マシン内での衝突も防いでいる。
- 名前空間（Namespace）とハッシュ演算の紐付けVersion 5などでは、まず「DNS」や「URL」といった名前空間を定義し、対象となる文字列と結合してSHA-1ハッシュを計算する。この結果を128ビットに切り出し、所定のビット操作を施すことでIDを導き出す。
UUIDとGUIDの違い
エンジニアの間で混同されやすい言葉に「GUID（Globally Unique Identifier）」があるが、これらは背景が異なる。
- Microsoftによる呼称か、国際標準による呼称かGUIDは、もともとMicrosoftがCOM（Component Object Model）などで利用するために採用した用語である。本質的にはUUIDの一種であり、現代においては「UUIDのMicrosoft実装」と捉えて差し支えない。
- 仕様の範囲と互換性UUIDはIETFやISOによって標準化された広範な規格を指す。GUIDは歴史的に特定のアルゴリズムを指すこともあったが、現在のWindows環境やSQL Serverで生成されるGUIDは、UUID Version 4などの標準規格に準拠している。
- レジストリやインターフェースでの利用Windows OSの内部処理や、Active Directoryのオブジェクト識別においては「GUID」という言葉が定着している。一方、Java、Python、Goなどのオープンソース界隈やRFCをベースとした文脈では「UUID」と呼ぶのが一般的である。
メリット
UUIDを採用することで、システムの設計における制約が大幅に緩和される。
- オフライン環境や分散環境での採番が可能データベースのオートインクリメント（連番）とは異なり、中央サーバーに問い合わせる必要がない。クライアント側や各マイクロサービスが自律的にIDを発行しても、結合時にIDがぶつかる心配を排除できる。
- セキュリティの向上と情報の隠蔽連番のIDを使用すると「URLの数字を変えるだけで他人のデータにアクセスできる」といった脆弱性を生みやすい。UUID（特にV4）は推測が不可能なため、外部にIDが露出してもデータの全件探索や総当たり攻撃を防ぐ壁となる。
- データベース移行やマージの容易さ異なるシステム間でデータを統合する際、連番IDだと必ず重複が発生し、再採番の手間が生じる。UUIDであれば、世界中で唯一無二であることが保証されているため、テーブルをそのままガッチャンコ（統合）しても識別の一貫性が保たれる。
まとめ
UUIDは、現代のITインフラや分散システムを支える「名前のない共通言語」のような立ち位置にある。単にランダムな文字列を作っているのではなく、背景にある数学的な裏付けと標準化されたルールによって、巨大なデジタル世界の秩序を維持しているのだ。
エンジニアとしては、単にライブラリを叩いて生成するだけでなく、各バージョンの特性を理解し、格納効率や検索速度（インデックスの断片化）まで考慮した選定が求められる。特に近年のトレンドであるVersion 7などは、時系列順のソート性能とランダム性を両立させており、今後のデファクトスタンダードになる可能性が高い。