UUID v4の衝突確率と安全性（誕生日攻撃・DBインデックス断片化対策）

UUID v4（Universally Unique Identifier version 4）が「なぜ実質的に絶対衝突しないと言えるのか」の数学的根拠と、データベース設計における実務上の注意点です。

1. 衝突確率の数学的試算（誕生日パラドックス）

UUID v4は全体の128ビットのうち、バージョンおよびバリアント識別子を除く 122ビット が暗号学的に安全な乱数（PRNG）です。

総パターン数

2^122 = 5,316,911,983,139,663,491,615,228,246,463,204,482 (約 5.3 × 10^36)

生成数と衝突確率の推定（誕生日攻撃の公式）

生成数に応じた1回以上衝突が発生する概算確率：

生成個数	衝突確率	規模感の例え
100万個 (10^6)	約 10^-25	ゼロに等しい
10億個 (10^9)	約 10^-15	地球全体で1秒間に10億個を何百年生成しても発生しない
1,000兆個 (10^15)	約 10^-7 (0.00001%)	隕石が頭上に落ちる確率より遥かに低い
2.3 × 10^18 個	50%	ここで初めてコイン投げと同等の確率

結論として、システム運用において UUID v4 の重複・衝突を気にする必要は数学的にありません。

---

2. 実務での注意点：RDB（MySQL/PostgreSQL）のB-Tree断片化問題

衝突確率はゼロですが、RDBのプライマリキー（主キー）にUUID v4を使用する場合は性能上の大きな課題 があります。

• 問題点: UUID v4は完全なランダム文字列です。MySQL(InnoDB)などのB-Treeインデックスに挿入する際、インデックスページの全域へ不規則に書き込まれるため、ディスクI/Oの多発とページスプリット（インデックス断片化） を引き起こします。
• 結果: テーブルのレコード数が数百万件を超えると、INSERT 性能が急激に低下します。

---

3. 代替案：UUID v7 または ULID の採用

このB-Tree断片化問題を解消するために、現代のシステム設計では以下の時系列ソート可能なIDが採用されます。

[ 48bit: Unixミリ秒タイムスタンプ ] + [ 74bit: ランダム/シーケンス ]

1. UUID v7 (RFC 9562): 先頭48ビットにミリ秒タイムスタンプを含む新しいUUID標準。時系列順にソートされるためB-Treeインデックスに優しく、UUID v4の相互互換として最優。
2. ULID: 26文字のCrockford Base32表記。ミリ秒タイムスタンプ＋80bit乱数。

---

4. オンラインUUID v4生成