データベースの主キーやAPIのリクエストIDなどで「550e8400-e29b-41d4-a716-446655440000」のような文字列を見かけたことがある方は多いと思います。これはUUID（Universally Unique Identifier）と呼ばれる識別子で、世界中のどこで生成しても重複しないように設計されています。この記事ではUUIDの仕組みと、v1〜v7と呼ばれる主なバージョンの違い、実際の使われ方を解説します。
1. UUIDとは何か
UUIDは128bit（16バイト）の値で、8-4-4-4-12桁の16進数をハイフンで区切った文字列として表記されます。中央集権的な管理者がいなくても、各端末やサーバーが独立してIDを生成でき、それでも他のどこかで生成されたIDと衝突しない確率が極めて低くなるように設計されているのが最大の特徴です。
手元で確認したい場合はUUID生成ツールで実際に生成してみると、文字列の形式がイメージしやすくなります。
2. なぜ「重複しない」と言えるのか
UUIDが重複しないと言われる根拠は、128bitという非常に大きな値の空間にあります。例えば後述するv4（ランダム生成）の場合、実際にランダムな値として使えるビット数はバージョン情報などを除いて122bitほどになりますが、それでも組み合わせの数は2の122乗という天文学的な数になります。
これは「絶対に重複しない」という数学的な保証ではなく、「現実的な規模でシステムを運用する限り、偶然同じ値が生成される可能性は無視できるほど小さい」という確率的な話です。同じ仕組みで毎秒大量のUUIDを生成し続けるような極端な状況でない限り、実用上は重複しないものとして扱って問題ないとされています。
3. v1・v4・v7など主なバージョンの違い
UUIDには生成方法の違いによっていくつかのバージョンがあり、文字列の3つ目のブロックの先頭1文字（1、4、7など）でバージョンを判別できます。代表的なものを整理すると次のようになります。
| バージョン | 生成方法 | 特徴 |
|---|---|---|
| v1 | タイムスタンプ＋MACアドレスなど | 生成時刻や生成元の端末情報が値から推測されうる |
| v4 | 完全にランダムな値 | 最も広く使われる。生成元の情報は含まれない |
| v5 | 名前空間＋名前をハッシュ化 | 同じ入力からは常に同じUUIDが生成される |
| v7 | タイムスタンプ＋ランダム値 | 生成順に並べ替えやすい。2024年のRFC 9562で標準化 |
v1はMACアドレスなど端末を特定しうる情報を含むためプライバシー上の懸念が指摘されることがあり、現在はランダム性の高いv4が最も一般的に使われています。v7はタイムスタンプを先頭に持つことで生成順にソートしやすく、データベースのインデックス効率が良いという理由で近年採用が増えてきているバージョンです。
4. UUIDが使われている場面
UUIDは「複数の場所で同時にIDを発行しても衝突しない」という性質が必要な場面で広く使われています。
- •データベースの主キー：複数のサーバーやアプリから同時にレコードを追加しても、IDの重複を心配せずに済む
- •APIのリクエストID：1件1件のリクエストに一意なIDを振り、ログの追跡やエラー調査に使う
- •ファイル名の一意化：アップロードされた画像やファイルの名前が衝突しないようにする
- •分散システムにおけるセッションIDやトランザクションID
5. 連番ID（オートインクリメント）との比較
データベースの主キーとしては、1、2、3…と増えていく連番ID（オートインクリメント）も古くから使われてきました。UUIDと比べると、それぞれにメリット・デメリットがあります。
| 観点 | 連番ID | UUID |
|---|---|---|
| 分散環境での衝突 | 複数のDBで同時発行すると衝突しやすい | 衝突をほぼ気にしなくてよい |
| 値の推測しやすさ | 次のIDが推測しやすく、件数も推測されうる | ランダム性が高く推測されにくい（v4の場合） |
| ソート性・並び順 | 発行順にきれいに並ぶ | v1・v7以外は生成順との対応が弱い |
| データサイズ | 小さい（4〜8バイト程度） | 大きい（16バイト、文字列では36文字） |
連番IDは他人にIDを推測されやすく、件数や成長スピードが外部から分かってしまうリスクがありますが、ソートのしやすさやデータサイズの面では有利です。逆にUUIDはランダム性が高く分散システムに向く一方、v1・v7以外は生成順での並び替えがしにくいという弱点があります。サービスの規模や要件に応じて使い分けるのが基本です。
6. ULIDという比較的新しい選択肢
UUIDのソート性の弱さを補う目的で、近年「ULID（Universally Unique Lexicographically Sortable Identifier）」という識別子も使われるようになっています。ULIDはタイムスタンプ部分とランダム部分を組み合わせた構造を持ち、UUID v7と似た発想で、生成順に文字列としてソートしやすいという特徴があります。
UUIDより新しい仕組みのため対応しているライブラリやデータベースがUUIDほど普及していない場合もありますが、生成順のソートが重要なシステムでは選択肢の一つとして検討されることがあります。
7. データベースに保存する際の注意点
UUIDは「00000000-0000-0000-0000-000000000000」のようにすべて0の「NIL UUID」を特別な意味（未設定・空値など）で使う設計もあるため、システムによっては通常のUUIDと区別する処理が必要です。また、UUIDを文字列（36文字）のままデータベースに保存するとインデックスが大きくなりやすいため、パフォーマンスを重視する場合はバイナリ形式（16バイト）で保存し、表示時だけ文字列に変換する設計が採られることもあります。どちらの形式で保存するかは、扱うデータの規模やアクセス頻度、使用するデータベースの種類に応じて検討するとよいでしょう。
まとめ
UUIDは128bitの値によって、中央管理者なしで世界中のどこで生成しても重複しにくいことを実現した識別子です。v1・v4・v7などバージョンごとに生成方法と特徴が異なり、用途に応じて選ぶことができます。まずはUUID生成ツールで実際にUUIDを生成し、形式や使い方を確かめてみてください。