UUID v1、v4、v5: どのバージョンを使用する必要がありますか?
簡単な回答
デフォルトでは UUID v4 (ランダム) を使用します。調整は必要なく、衝突のリスクは無視できます。 v1 (時間ベース) は、時間順序指定可能な ID が必要で、ノード ID を保護できる場合にのみ使用してください。名前から派生した決定的な ID が必要な場合は、v5 (名前空間 + 名前) を使用します。無料の UUID ジェネレーターを使用して任意のバージョンを生成します。
導入
UUID (Universally Unique Identifier) は、8-4-4-4-12 の 16 進グループの 36 文字としてレンダリングされる 128 ビットの識別子です。 123e4567-e89b-12d3-a456-426614174000。 RFC 9562 ではいくつかのバージョンが定義されています。最も頻繁に発生する 3 つは、v1 (時間 + MAC)、v4 (ランダム)、および v5 (名前空間 + 名前、SHA-1) です。それぞれが一意性の保証、並べ替え可能性、決定性の間で異なるトレードオフを行います。
ステップバイステップ
-
UUID v1 — 時間とノードベース
v1 は、現在の 60 ビットのタイムスタンプ (1582-10-15 からの 100 ns 間隔) と 48 ビットのノード ID (通常は MAC アドレス) をエンコードします。同じノード上で生成された ID は単調増加し、時間順にソート可能です。リスク: MAC アドレスによってハードウェア ID が漏洩し、ノード間のクロック スキューにより順序が崩れる可能性があります。
-
UUID v4 —ランダム
v4 は 122 のランダム ビットを使用します (6 ビットはバージョン/バリアントに固定されています)。 122 のランダム ビットを使用すると、2 兆 7,100 億の ID 間で衝突が発生する確率は 50% になります。現実的なワークロードでは、確率は事実上ゼロです。 v4 は調整を必要とせず、ホスト情報を公開しないため、最も安全なデフォルトになります。
-
UUID v5 — 名前空間と名前 (SHA-1)
v5 は、名前空間 UUID と名前文字列を SHA-1 でハッシュし、決定的な 128 ビット ID を生成します。同じ (名前空間、名前) ペアは常に同じ UUID を生成します。これは重複排除と自然キーから派生した安定した ID に最適です。 v3 も同じアイデアですが、MD5 を使用します (これは避けてください)。
-
トレードオフを比較する
v1 はソート可能ですが、MAC リークがあり、クロック同期が必要です。 v4 はランダムでプライベートですが、並べ替えることはできません。 v5 は決定的で重複排除されますが、ランダムではありません。名前を推測すると、攻撃者は UUID を再現できます。順序付け、ランダム性、または決定性が必要かどうかに基づいて選択してください。
-
あなたのケースに適したバージョンを選択してください
データベースの主キー: v4 (または、新しいシステムでは時間順序付けを可能にする v7)。調整のない分散システム: v4。自然キーからの決定的 ID (例: URL → UUID): v5。時間順の利点を活用する監査ログ: 安全なランダム ノード ID を持つ v1。
例
UUID v1 (時間ベース、並べ替え可能)
入力: ノード 00:11:22:33:44:55 で 2026-08-28T12:00:00Z に生成されました
出力: 1ef7c1d0-2d3b-11f0-8000-001122334455 (バージョン桁「1」、時間ソート可能)
UUID v4 (ランダム)
入力: Random generation
出力: f47ac10b-58cc-4372-a567-0e02b2c3d479 (バージョン桁「4」、ランダムビット)
UUID v5 (名前空間+名前から決定的)
入力: 名前空間 DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8) + 名前 'freeonlinetoolsgo.com'
出力: 74738ff5-5367-5958-9aeb-0c1f1f1f1f1f (同じ入力は常に同じ出力を生成します)
よくある問題
- UUID をネイティブ 16 バイト BINARY/UUID 型ではなく VARCHAR(36) として保存すると、2 倍のストレージが無駄になり、インデックスのパフォーマンスが低下します。可能な場合は、ネイティブの UUID 列タイプを使用します。
- ノード ID を保護せずに v1 を使用すると、デフォルトの MAC アドレスによりハードウェア ID が漏洩し、プライバシーの問題になります。これを、ノードごとに暗号的にランダムな 48 ビット値に置き換えます。
- v4 の衝突は不可能であると仮定すると、実際にはそうではありません。単に天文学的に発生する可能性が低いだけです。 122 のランダム ビットを使用すると、50% の確率で約 2 兆 7,100 億の ID が必要になります。 10 億 ID の場合、確率は ~0.0000000000000001 です。
- v5 (SHA-1 ベース) の代わりに v3 (MD5 ベース) を使用する: MD5 は壊れているため、v5 が推奨されます。どちらも決定論的ですが、v5 の方が衝突耐性が強いです。
ヒント
- ほぼすべてのユースケースでデフォルトは v4 です。これはランダム、プライベート、調整なしで衝突安全です。
- 時間でソート可能なランダム ID が必要な場合は、Unix タイムスタンプとランダム ビットを組み合わせた UUID v7 (RFC 9562, 2024) を参照してください。これは、最新のデータベースでは v1 よりも優れています。
- v5 を使用してナチュラル キー (URLs、電子メール アドレス) から安定した ID を生成すると、同じ入力が常に同じ UUID にマップされます。これは重複排除と冪等の APIs に役立ちます。
- サーバーとの往復を避けるために、可能な場合はクライアント上で UUID を生成します。UUID ジェネレーターは、crypto.getRandomValues() を使用してブラウザ内で完全に実行されます。