UUIDの小ネタ・実務Tips
基本編の補足として、「衝突の直感」「時系列性のあるIDとの比較」「表記や保存の豆知識」などをまとめました。運用や設計の判断材料にどうぞ。
🎯 衝突確率の直感
誕生日のパラドックスを目安に、ビット長と件数でざっくり判断します。
UUIDv4の目安
| 生成件数 | 衝突確率の目安 |
|---|---|
| 10^6 件 | ほぼ 0 |
| 10^9 件 | ほぼ 0（理論上は 10^-18 オーダー） |
| 10^12 件 | 理論上は 10^-12 オーダー。運用ではユニーク制約を併用するのが安全。 |
運用のヒント
- 🧠 UUID単体で100%の一意性を保証するわけではない。DBのユニーク制約や整合性チェックを組み合わせる。
- 🧠 短縮したハッシュやIDを使う場合は、残すビット長に応じて衝突確率が上がる点に注意。
📈 時系列性と類似フォーマット
挿入順やソートのしやすさを重視するときの選択肢です。
比較メモ
| 形式 | 特徴 | 向く用途 |
|---|---|---|
| UUIDv4 | 純乱数。推測されにくいが順序性なし。 | ランダム性重視のID全般。 |
| UUIDv7（ドラフト） | 時刻＋乱数でほぼ時系列順。 | DBインデックスやログで順序性が欲しい場合。 |
| ULID | 時刻＋Base32。ソートしやすい、人が読める。 | URLキーやログなど人目に触れるID。 |
| KSUID | 時刻＋160bit乱数。長期的な重複耐性を強化。 | 時系列性＋高い衝突耐性が欲しい場合。 |
GUIDとの違い
- ℹ️ GUIDは主にMicrosoft文脈の呼び方で、形式はUUIDとほぼ同じ。
- ℹ️ 表記揺れ（大文字/小文字、波括弧付き）に注意し、正規形で扱うと混乱を減らせる。
✍️ 表記とエンコードの豆知識
正規化のルールを決めておくと交換が楽になります。
よくあるバリエーション
- 🔤 ハイフンあり/なし、大文字/小文字。どれかに統一し、I/F仕様に明記する。
- 🔤 URN形式 `urn:uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` で表す場面もある。
- 🔤 短縮したい場合はBase32/BASE64URL/Base58にエンコードするが、エンコード方式を揃えること。
保存形式のヒント
- 💾 DBで速度を重視するならBINARY(16)で保持し、表示時に文字列化する。文字列保存なら小文字＋ハイフン付きに揃えると比較しやすい。
🕶️ プライバシーと乱数品質
情報が漏れたり推測されたりするパターンを避けます。
避けたいこと
- 🚫 v1はMACアドレスや時刻が漏れるため、外部公開IDには不向き。使うならランダムノード対応の実装を選ぶ。
- 🚫 CSPRNGでない乱数でUUIDを作ると推測・逆引きされやすい。信頼できるライブラリを使う。
🧪 バリデーションと運用
入力を受けるときは形式チェックを強めに。
チェック項目
- ✔️ 形式だけでなくバージョン（3桁目ブロック先頭の16進1桁）とバリアントを確認する。
- ✔️ ハイフン有無の揺れは正規化してから保存・比較する。
- ✔️ URLクエリ等で受け取る場合はエンコードミス（%や+）にも注意。
🛠️ 変換・生成の小ネタ
手元で試すと理解が早まります。
コマンド例
- 💻 `uuidgen` でv4生成（環境依存でv1のこともある）
- 💻 `python - <<'PY'\nimport uuid; print(uuid.uuid4())\nPY` で簡易生成
- 💻 `node -e \"console.log(crypto.randomUUID())\"` でv4生成
- 💻 ハイフン除去: `uuidgen | tr -d \"-\"`