UUIDとは?
UUID(Universally Unique Identifier、汎用一意識別子)は、中央機関による調整なしに時空間で一意となるよう設計された128ビットの識別子です。結果は36文字の文字列です:
550e8400-e29b-41d4-a716-446655440000
ハイフンで区切られた5つのグループに32個の16進数字を配置します:8-4-4-4-12。
UUIDバージョン解説
UUID v1 — 時刻ベース + MACアドレス
現在のタイムスタンプとネットワークインターフェースのMACアドレスを組み合わせます。時系列順に並びますが、ホストマシンのMACアドレスと正確な作成タイムスタンプを漏洩させます — プライバシー上の問題です。
UUID v4 — ランダム(最も一般的)
122ビットを暗号学的に安全なランダムデータで埋めます。状態、ネットワーク、調整は不要。ほとんどのユースケースのデフォルト選択肢。
UUID v5 — Namespace + SHA-1
決定論的:同じnamespace + 名前 = 常に同じUUID。v3(MD5は時代遅れ)よりv5を優先してください。
UUID v7 — 時刻順(新標準)
最上位ビットにUnixミリ秒タイムスタンプを使用。UUIDが自然にソート可能になり、データベースのB木インデックスパフォーマンスを大幅に改善します。
UUIDを使う理由
- 中央調整不要:どのクライアントやマイクロサービスも独立してUUIDを生成できます。
- 不透明性によるセキュリティ:連番整数IDはデータ量を露呈します。UUIDは何も明かしません。
- データベースマージ:UUID主キーのテーブルは衝突なしでマージできます。
- オフライン生成:モバイルアプリはオフラインでレコードを作成し、後で同期できます。
- 業界標準:すべての主要なデータベースとフレームワークでネイティブサポート。
UUIDを使わない場合
- ストレージオーバーヘッド:
VARCHAR(36)ではなく、MySQLではBINARY(16)、PostgreSQLではネイティブuuid型を使用してください。 - URLスラッグ:長すぎて覚えにくい。ユーザー向けURLには読みやすいスラッグを使用してください。
- v4によるインデックス断片化:書き込みが多いテーブルにはUUID v7またはULIDを使用してください。
VARCHAR(36)として保存しないでください。UUID_TO_BIN(uuid, 1)でBINARY(16)を使用してください。
コードでUUIDを生成する
JavaScript
const id = crypto.randomUUID(); // v4
Python
import uuid; id = str(uuid.uuid4())
PHP
use Ramsey\Uuid\Uuid;
$v4 = Uuid::uuid4()->toString();
$v7 = Uuid::uuid7()->toString();
SQL
-- MySQL: SELECT UUID();
-- PostgreSQL: SELECT gen_random_uuid();
ベストプラクティス
- バイナリとして保存:
BINARY(16)またはPostgreSQLのネイティブuuid型。 - ほとんどの場合はv4を使用。
- データベースの主キーにはv7を使用。
- プライバシーに敏感なコンテキストではv1を避ける。
- 入力時にUUID形式を検証する。
- 常に小文字を使用する。
よくある質問
2つのUUIDが同じになることはありますか?
理論的には可能です。v4の衝突確率は約5.3×1036分の1です。実際のシステムでは絶対に衝突しません。
データベース主キーにはv4とv7のどちらを使うべき?
データベース主キーにはv7を使用してください。v4はB木インデックスのランダムな位置に挿入し、大規模ではパフォーマンスが低下します。v7のミリ秒精度タイムスタンププレフィックスにより、新しいレコードは常にインデックスの末尾に挿入されます。
UUIDは大文字と小文字を区別しますか?
いいえ。仕様では大文字小文字を区別しません。慣習として常に小文字を使用してください。