About
表示言語: 日本語 英語に切り替え

UUIDジェネレーター

ブラウザでv4 (ランダム) またはv7 (時系列順) のUUIDを生成。ランダム性にはWeb Crypto APIを使用します。

  1. ランダムUUIDならv4、時系列順ならv7を選択。
  2. 個数 (最大1000) を設定して生成をクリック。
  3. リスト全体を取得するにはすべてコピーを、1行だけなら手動で選択。
何ができるのか?

v4 UUIDは122ビットの暗号学的に強いランダム性で、idempotencyキー、セッションID、そして不透明で順序のない識別子が欲しい場所すべてで広く使われるデフォルト。v7 UUIDは先頭バイトに48ビットのUnix-millisecondタイムスタンプを埋め込むため、時間的に近く生成された値は辞書順で近くソートされます。これによりv7はデータベースのプライマリキーに適しており、v4のままだとB-treeインデックスを断片化させる挿入が発生します。

例

3つのv4 UUID (ランダム、順序なし):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

同じmillisecond内で生成された3つのv7 UUID (共有プレフィックスに注目):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

よくあるエラーと落とし穴

UUIDをアプリケーションに組み込むときに開発者が実際に遭遇する落とし穴:

  • 挿入順序が重要な場所でv4を使う。 1000万個のランダムv4をインデックスするとB-treeで重いページ分割が発生します。v4を維持するなら、書き込み増幅を受け入れるか、プライマリキーをv7に切り替えてください。
  • ハイフンを削除してバージョンnibbleを失う。 f47ac10b58cc4372a5670e02b2c3d479は依然として有効な32文字のhex UUIDですが、13文字目 (4) はバージョンマーカーで、ランダムなnibbleではありません。32文字すべてがランダムだと仮定しないでください。
  • Math.random()に頼る。 Math.random()上に構築された古いライブラリは暗号学的に強くなく、予測可能な場合があります。crypto.randomUUID() (ブラウザとNode 19+) またはcryptoから読むv7ライブラリを使用してください。
  • v7をタイムスタンプとして扱う。 先頭48ビットは時間を持ちますが残りはランダムなので、同じmillisecondの2つのv7は決定論的に順序付けられません。タイブレーキングに依存しないでください。
  • VARCHAR(36)として保存。 動作しますがネイティブ16バイトUUID / BINARY(16)カラムと比べて保存量が2倍になり、joinが遅くなります。データベースのネイティブ型を使用してください (Postgresではuuid、SQL ServerではUNIQUEIDENTIFIER)。
  • 特定のバージョンを要求するregex。 /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i はv4のみに一致します。後でv7を発行すると、そのregexは有効なIDを無言で拒否します。
よくある質問

UUID v4とv7の違いは何ですか?

v4は122ビットのランダム性にバージョンとバリアントマーカーを加えたもので、時間要素はありません。v7は48ビットのUnix-millisecondタイムスタンプを前置し、残りをランダムビットで埋めるため、時間的に近く生成されたv7値は辞書順でソートされます。B-tree挿入を局所的に保つためにv7をデータベースのプライマリキーとして使用。順序シグナルをまったく望まない場合はv4を使用してください。

重複したUUIDが出ることはありますか?

事実上ありません。v4 UUIDは122個のランダムビットを持つので、10億のバッチで2つが衝突する確率は約10^-18です。単一の衝突の50%の確率に達するには約2.7垓個のv4 UUIDを生成する必要があります。一意生成を前提として扱い、一意性チェックを追加しないでください。

v4は暗号学的にランダムですか?

このツールはcrypto.randomUUID()を使用しており、仕様で暗号学的に強いPRNGから引く必要があります。これはセッションID、idempotencyキー、ほとんどのセキュリティトークンには十分です。署名付きトークンや長いAPIシークレットの代替ではなく、UUIDから暗号化キーを導出すべきではありません。

UUID v7は標準化されていますか?

はい。UUID v7はRFC 9562 (2024年5月) で定義されており、RFC 4122に代わり、オリジナル版と並んでv6、v7、v8を形式化しました。ほとんどの現代の言語にv7実装があります — Postgres、MySQL、SQL Serverはすべて変更なしでUUIDカラムとしてv7値を受け入れます。

バイナリ形式はどう見え、endiannessは重要ですか?

UUIDは16バイトです。正規テキスト形式はそれらを8-4-4-4-12のhex文字にグループ化します。バイトはRFC 9562に従ってネットワーク (big-endian) 順序で書かれるため、018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90はバイト0x01で始まります。Microsoft GUIDは歴史的に最初の3グループをメモリ内でlittle-endianに保存します — .NETバイナリダンプとの相互運用時は注意。

このツールが生成するUUIDを保存しますか?

いいえ。ここで生成したUUIDは保存しません。各値は出力エリアに表示され、更新またはタブを閉じた瞬間に消えます — 何も保存されず、値に関するテレメトリは収集されません。ブラウザの開発者ツールで確認してください。