UUID：完全ガイド
UUID（汎用一意識別子）は、分散システムとデータベースにおいて、中央の調整なしに一意の識別子を作成するための基盤です。データベースレコードからAPIトークン、セッション識別子まで、UUIDは一意性が重要な場所で使用されます。このガイドでは、UUIDとは何か、さまざまなバージョン、そしていつそれぞれを使用するかについて説明します。
UUIDとは？
UUID（汎用一意識別子）は、重複の可能性が実質的にゼロである128ビットの数値です。標準形式では、5つのグループに分かれた32文字の16進数で、ハイフンで区切られた形で表示されます：550e8400-e29b-41d4-a716-446655440000。この形式は、8-4-4-4-12の文字を表しています。 UUIDの美しさは、その一意性保証にあります。適切に生成されたUUIDは、誰がいつどこで生成したかに関係なく、実質的に一意であることが保証されます。これにより、データベースの自動インクリメントIDとは異なり、UUIDは複数のシステムやデータベース間で安全に生成および結合できます。 UUIDには複数のバージョンがあり、それぞれ異なる生成方法と使用例があります。最も一般的なのはv4（ランダム）とv1（タイムスタンプベース）です。v5（名前ベース）とv3（古いMD5ベース）もありますが、あまり使用されません。最新のv6とv7は、タイムスタンプベースでソート可能な改善を提供します。 UUIDは技術的に一意性が保証されていませんが、衝突の確率は天文学的に小さいです。年間10億のv4 UUIDを生成すると、重複の確率は約100年後に50%に達します。実際には、これは一意性が保証されているのと同じくらい良いことを意味します。 UUIDは、分散システム、データベースの主キー、セッション識別子、ファイル名、APIトークン、メッセージ識別子など、さまざまなアプリケーションで使用されます。中央のカウンターや調整を必要とせずに一意の識別子が必要な場合は、UUIDが優れた選択肢です。
UUIDバージョンの理解
UUID v4はランダムUUIDで、最も一般的に使用されているバージョンです。暗号的に安全な乱数ジェネレーターを使用して、122ランダムビット（6ビットはバージョンとバリアントに予約されています）を生成します。v4 UUIDには、生成時刻やマシンに関する情報は含まれていません—純粋にランダムです。これにより、プライバシーに優れ、ほとんどの用途に適しています。ランダムな性質により、ソートできませんが、ほとんどのアプリケーションではこれは問題ではありません。 UUID v1はタイムスタンプとMACアドレスベースのUUIDです。現在の時刻（100ナノ秒単位）とマシンのネットワークアダプターのMACアドレスを組み合わせます。これにより、v1 UUIDは時間順にソート可能になります—同じマシンで生成されたUUIDは、生成時刻順に並べ替えられます。ただし、MACアドレスを含むことはプライバシーの懸念事項です—UUIDは生成者のマシンを明らかにします。この理由から、ほとんどの最新のアプリケーションでは、v1よりもv4を優先します。 UUID v6とv7は、タイムスタンプベースであるv1の利点（ソート可能性）を、より良いプライバシーとパフォーマンスで提供する新しいバージョンです。v6はv1を再配置してタイムスタンプフィールドをソート可能にし、v7はUnixタイムスタンプとランダムビットを使用します。これらは2022年に標準化され、まだ幅広いサポートを得ていませんが、時間順のソートが必要な新しいシステムにとって優れた選択肢です。 UUID v5とv3は名前ベースのUUIDです。名前空間識別子と名前を受け取り、決定論的UUIDを生成します。同じ入力は常に同じUUIDを生成します。v5はSHA-1を使用し、v3はMD5を使用します（非推奨）。これらは、与えられた入力に対して一貫した識別子が必要なときに使用されます—たとえば、URLやドメイン名からUUIDを生成する場合。 ほとんどのアプリケーションでは、UUID v4を使用してください。シンプルで、安全で、プライバシーを保護し、あらゆる場所でサポートされています。時間順のソートが必要で、実装が利用可能な場合はv7を使用してください。決定論的生成が必要な特定のケースにはv5を使用してください。新しいコードではv1とv3を避けてください。
UUIDのベストプラクティス
データベースの主キーにUUIDを使用する際は、トレードオフを理解してください。UUIDは、分散システム、複数のデータベース、サーバー側での生成前にクライアント側で識別子が必要な場合に優れています。しかし、整数よりも多くのストレージスペース（128ビット対32/64ビット）を必要とし、インデックス作成が遅くなる可能性があります。PostgreSQLなどの最新のデータベースには、効率的なUUIDサポートのための専用のUUIDデータ型があります。 順序付けられた挿入のためには、v4ではなくv7（または利用可能な場合はv6）の使用を検討してください。ランダムv4 UUIDをBツリーインデックスに挿入すると、断片化が発生し、パフォーマンスが低下する可能性があります。タイムスタンプベースのv7 UUIDは順次に近い値を生成し、インデックスのパフォーマンスを向上させます。大量の書き込みがあるシステムでは、これは重要です。 暗号的に安全なランダム性を使用してください。v4 UUIDを生成する場合、Math.random()を使用しないでください—予測可能で、セキュリティ用途には不十分です。代わりに、暗号ライブラリを使用してください：JavaScriptではcrypto.randomUUID()またはcrypto.getRandomValues()、Pythonではuuid.uuid4()、Javaではjava.util.UUIDなど。 UUIDを文字列として保存するか、ネイティブ型として保存するかを検討してください。PostgreSQLにはネイティブのUUID型があり、これは文字列（36バイト）よりも効率的（16バイト）です。MySQLにはネイティブ型がありませんが、UUIDをBINARY(16)として保存してスペースを節約できます。NoSQLデータベースは通常、文字列として保存します。 UUIDをURLやAPIで公開する際は、大文字小文字を正規化してください。UUIDは大文字小文字を区別しませんが、一貫性が重要です。小文字に標準化するか、大文字小文字を区別しない比較を使用してください。URLでは、UUIDにハイフンを含めることが標準ですが、一部のシステムではそれらを削除します—一貫性を選択してください。 UUIDの検証を適切に行ってください。ユーザー入力からUUIDを受け取る場合、形式を検証してください。正規表現を使用するか、言語のUUID解析関数を使用してください。無効なUUIDは、多くの場合、バグや悪意のある入力を示します。すべての入力を検証しますが、特にセキュリティに敏感なコンテキストでは検証してください。 NIL UUID（すべてゼロ：00000000-0000-0000-0000-000000000000）を認識してください。これは、欠落または初期化されていない値を示すために使用される特別な値です。アプリケーションでNIL UUIDの意味を決定してください—エラーとして扱うか、nullのような値として扱うか。 パフォーマンスのために、可能な限りUUIDの生成と解析をキャッシュしてください。同じUUID文字列を何度も解析することは無駄です。解析されたUUID値をキャッシュし、アプリケーション全体でバイナリ形式で渡してください。大量のUUIDを扱うシステムでは、これによりパフォーマンスが向上する可能性があります。
ツールを試す
UUIDジェネレーター
詳しく見る
よくある質問
UUIDジェネレーター
よくある質問 →