UUID v4 — 完全ランダム
UUID v4 はもっとも馴染みのある形式です。128 ビットのランダム値をハイフン付き 32 桁の 16 進数で表現します（'550e8400-e29b-41d4-a716-446655440000'）。多数のソースが調整なしにデータを生成するシステムでは最も安全な選択肢で、衝突確率は天文学的に低いです。一方、B-tree インデックスの全域にランダムに新規行が落ちるため、ページ分割と IO 増加で書き込み性能が落ちます。
UUID v7 — 時刻ソート可能
UUID v7（RFC 9562 で標準化）は UUID 形式を保ちつつ、先頭 48 ビットにミリ秒 Unix タイムスタンプを埋め込み、残りをランダムにします。時系列順にソートでき、衝突を防ぐ十分なランダム性も保たれます。新規行はインデックス末尾に追加されるため、書き込み性能が大きく改善します。2024〜2025 年時点で、主要言語に UUID v7 ライブラリが揃っています。
ULID — UUID の親戚、設計的にソート可能
ULID（Universally Unique Lexicographically Sortable Identifier）は UUID v7 より数年早く提案された別仕様です。UUID と同じ 128 ビットを使いますが、26 文字の Crockford Base32（'01ARZ3NDEKTSV4RRFFQ69G5FAV'）で短く URL フレンドリーに表現します。先頭 48 ビットがミリ秒タイムスタンプ、残りがランダム。機能的には UUID v7 と非常に近く、テキスト形式が異なります。
インデックス性能
B-tree は単調挿入を好みます。UUID v4 はインデックス全体にホットなランダムページを生み、ページ分割と高 IO を招きます。UUID v7 と ULID は基本末尾追加になるため、ストレージ層に圧倒的に優しく、数億行規模のテーブルで一括挿入が 2〜5 倍速くなることもあります。
プライバシーと情報漏れ
ソート可能な ID は作成順序を公開的に漏らします。ユーザー ID が連番や時刻ベースなら、誰でもユーザー数を推測したりオンボーディング傾向を逆算できます。UUID v7 / ULID はエンティティ作成のミリ秒を露出させるため、医療データや内部 ID をユーザーに見せる場面では UUID v4 を使うか、表示時にハッシュ化してください。
形式の詳細
- UUID v4: ハイフン込み 36 文字、128 ビット全部ランダム。
- UUID v7: ハイフン込み 36 文字、タイムスタンプ 48 ビット ＋ ランダム 74 ビット ＋ バージョン/バリアントビット。
- ULID: ハイフンなし 26 文字、タイムスタンプ 48 ビット ＋ ランダム 80 ビット、Crockford Base32（I/L/O/U なし）。
移行の考慮点
UUID v4 を使っていてソート可能 ID に移行したい場合、既存行は v4 のまま、新規行を UUID v7 / ULID で発行する形が一般的です。形式の長さが同じなのでカラム変更も不要です。アプリケーションコードからは見えず、ID 生成ライブラリを差し替えるだけで完了します。