UUIDの生成方法
- v4(ランダム)かv7(時刻順)を選びます。
- 生成数を決めます。1回に1〜1,000個まで作れます。
- 形式を選びます。大文字、32文字に詰めるハイフンなし、Windowsのレジストリファイルや一部の.NETコードで使われる波かっこ { } で囲むがあり、組み合わせることもできます。
- コピーで一覧全体をクリップボードに入れるか、.txtでダウンロードで1行に1つずつ保存します。生成を押すと新しい一覧になります。
オプションを変えると、今の一覧の書式が変わるのではなく、新しい一覧が生成されます。必要な一覧は、形式を切り替える前にコピーしておいてください。
UUIDの構造
UUID(universally unique identifier)は128ビットの数値で、通常は16進数32桁を8-4-4-4-12の5つのグループに分けて書きます。2つの位置には決まった情報が入ります。3番目のグループの先頭桁がバージョン、4番目のグループの先頭桁がバリアントです。2024年にRFC 4122に代わって策定されたRFC 9562の標準バージョンでは、バリアントは必ず8、9、a、bのいずれかです。
| バージョン | 例 | ビットの中身 |
|---|---|---|
| v4 | 3f2c8e91-6b0d-4a57-9c1e-27d4f08b6a3e | ランダムな122ビット |
| v7 | 019b76da-a800-7a3c-9f12-5c0e8b4d71e6 | ミリ秒単位のUnix時間48ビット、続いてカウンターとランダムデータの74ビット |
v4とv7のどちらを使うか
バージョン4はおなじみのランダムなUUIDで、JavaScriptの crypto.randomUUID() やPythonの uuid.uuid4() など、多くのライブラリが標準で生成するものです。IDから何の情報も読み取れないようにしたいときや、順序が関係ないときに使います。URLに出る公開ID、ファイル名、ログの相関IDなどです。
バージョン7はタイムスタンプで始まるため、後から作ったIDが先に作ったIDより後ろに並びます。テキストとして比べてもバイト列として比べても同じです。これはデータベースの主キーで効いてきます。ランダムなv4のキーをBツリーのインデックスに挿入すると書き込みがインデックス全体に散らばりますが、v7のキーは順番どおりに届いて末尾付近に追加されるので、インデックスがコンパクトに保たれ、挿入も速くなります。このツールは同じミリ秒の中では12ビットのカウンター(開始値はランダム)を使うため、v7のUUIDを1,000個まとめて作っても厳密に昇順になります。
例:v7 UUIDに含まれる時刻を読む
019b76da-a800-7a3c-9f12-5c0e8b4d71e6 を例にします。先頭の16進数12桁 019b76daa800 が生成時刻です。これを進数変換の16進数の欄に貼り付けると 1767225600000 になり、その値をUnixタイムスタンプ変換に入れると、2026年1月1日 00:00:00.000 UTC(日本時間の午前9時)だとわかります。同じ方法でレコードの作成日時がわかるため、作成時刻を知られたくない場面ではv7のIDを使わないほうが安全です。
どのくらい「一意」なのか
v4 UUIDが取りうる値は2¹²²通り、約5.3 × 10³⁶通りです。誕生日のパラドックスによれば、重複が1つでも生じる確率が50%に達するには、約2.7 × 10¹⁸個を生成する必要があります。v4 UUIDを1兆個作るシステムでも、どれか2つが一致する確率は約10兆分の1です。これは質のよい乱数源が前提で、このページはブラウザの暗号論的に安全な乱数生成器 crypto.getRandomValues を使っています。実際の重複は偶然ではなく、コピーされたシード、使い回した一覧、本番環境に残ったテスト用の生成器といったバグから生まれます。
その他のバージョンの概要
- v1とv6は、タイムスタンプとノード識別子(かつてはネットワークカードのMACアドレス)を組み合わせたものです。v6はv1のフィールドを並べ替えて時刻順にソートできるようにしたものですが、RFC 9562は新しいシステムにはv7を推奨しています。
- v3とv5はランダムではありません。名前空間と名前をそれぞれMD5とSHA-1でハッシュするため、同じ名前からは常に同じUUIDが得られます。
- v8はベンダー独自のレイアウトのための枠です。
- nil UUIDはすべて0の
00000000-0000-0000-0000-000000000000で、「値なし」を表すのによく使われます。
実践的なヒント
- データベースが対応していれば、UUIDは36文字の文字列ではなく、専用の
uuid型の列や16バイトのバイナリで保存しましょう。比較が速くなり、インデックスも小さくなります。 - UUIDは大文字・小文字を区別せずに比較してください。標準では小文字で書き、Microsoftのツールは大文字で書くことが多いのですが、どちらも同じ値です。
- ハイフンを除いたUUIDも同じ数値です。あるシステムが値を受け付けないときは、IDを疑う前に、ハイフンや波かっこが必要かどうかを確認しましょう。
よくある質問
GUIDとUUIDは同じものですか?
はい。GUIDは同じ128ビット形式のMicrosoftでの呼び名で、ふつうは波かっこの中に大文字で書きます:{3F2C8E91-6B0D-4A57-9C1E-27D4F08B6A3E}。大文字と波かっこを両方オンにするとこの形式になります。
UUIDをパスワードや秘密のトークンとして使えますか?
避けてください。v4 UUIDは推測しにくいものの、あくまで識別子として設計されており、多くのシステムはIDをログやURLにそのまま残します。v7 UUIDはランダムなビットが少なく、生成時刻まで明かしてしまいます。秘密の値には、その用途のために作られたランダムなトークンを使いましょう。
複数のサーバーで作ったv7 UUIDも順序が保証されますか?
サーバー同士の時計が合っている範囲でのみ保証されます。1つの生成器の中では順序は正確ですが、複数のサーバーで同じミリ秒に作られたり、時計がずれていたりすると、順序が入り混じることがあります。
どのUUIDも2つ目のハイフンの後が4か7なのはなぜですか?
その桁がバージョンのフィールドで、3つ目のハイフンの後の先頭桁がバリアントのフィールドです。どちらも標準で固定されているため、v4 UUIDのランダムなビットは128ではなく122になります。これらの桁はIDの作り方を示すだけで、生成器の乱数の質までは証明できません。