UUID v7ジェネレーター
UUIDジェネレーターのプリセット
時間順のUUID v7識別子を生成します — データベースの主キーとして使うためにRFC 9562で標準化されたバージョンです。タイムスタンプが値の先頭にあるため、連続した挿入は連続したままで、ランダムなv4キーが引き起こすようなインデックスの断片化が起こりません。
- ファイルは端末の外に出ません
- 無料、登録不要
- 透かしなし
- 一度読み込めばオフラインでも動作します
UUIDジェネレーターの使い方
- 1
バージョンを選ぶ
汎用のランダムIDにはv4、IDがデータベースの主キーになる場合はv7です。
- 2
個数を設定
1つから1000まで一度に生成します。
- 3
コピーまたはダウンロード
リストをクリップボードにコピーするか、テキストファイルとしてダウンロードします。
v7が2024年になってようやく標準化された理由
何年もの間、UUIDの衝突耐性を望みながらも連続した整数のインデックスに優しい順序付けを望むエンジニアリングチームは、独自の非標準ハイブリッドを構築せざるを得ませんでした — 一般的には、手動で生成したタイムスタンプをランダムなUUIDの先頭に付ける方法で、これはそのための公式な標準が存在する前から、いくつかの著名な分散システム企業がさまざまな形で使っていたアプローチです。RFC 9562は、その公式標準がなくても各チームが独立して同じアイデアのわずかに異なる非互換のバリアントを再発明することなく、異なる言語とデータベース全体の実装が同じ時間順の構造を生成・認識できるよう、そのパターンを特にこの目的のための公式なUUIDバージョンとして正式化しました。
タイムスタンプが値の中で実際にどこにあるか
UUID v7の先頭48ビットはミリ秒単位のUnixタイムスタンプをエンコードしており、これが値にソート順序を与えます — 2つのUUID v7値を平坦な文字列として比較すると、どちらが先に生成されたかを正しく反映します。タイムスタンプ部分が比較を支配するためです。残りのビットはv4と同様に暗号学的にランダムなデータで埋められたままなので、値は完全にランダムなUUIDと同じくらい推測に対して耐性があります — 変わるのはソートの振る舞いだけで、予測不可能性ではありません。
実際のアプリケーションにとって「インデックスに優しい」が意味すること
純粋な挿入速度を超えて、時間順の主キーには日々重要な第2の実用的な利点があります: 単純な`ORDER BY id`クエリから、レコードを時系列に並べるためだけの別の`created_at`列と追加のインデックスを必要とせず、行が自然に作成順に返されます。頻繁に「最新順」でクエリされるテーブル — アクティビティログ、キュー、監査証跡など — にとって、v7の主キーは、別途維持するコストとしてではなく、ID自体の副産物として無料でその順序付けを与えます。
よくある質問
UUID v4とv7の違いは何ですか？
v4は完全にランダムです。v7は先頭ビットにミリ秒単位のタイムスタンプを設定するため、後で生成されたIDは前のものより後ろに並びます。どちらも実務上は同じように推測不可能です。v7は加えてたまたま順序付けられています。
データベースの主キーにはどちらを使うべきですか？
v7です。ランダムなv4キーはB-treeインデックス全体に挿入を分散させ、断片化させ、大規模での書き込みを大きく遅くします。v7キーは順序どおりに追加されるため、挿入は連続したままです — これが2024年にv7が標準化された理由です。
2つのUUIDが同じになることはありますか？
数学的には可能ですが、実務上はありません。UUID v4は122のランダムビットを持ちます — 衝突がありそうになる前に約2.7×10^18個生成する必要があります。比較として、これは地球上の砂粒の数より多いUUIDです。
安全に生成されますか？
はい。`Math.random`ではなく、オペレーティングシステムの暗号学的ランダムソースである`crypto.getRandomValues`を使います。これはUUIDが共有リンク、退会URL、パスワードリセットキーのような能力トークンとして使われる場合に重要です。
UUIDとGUIDは同じものですか？
はい。GUIDは同じ128ビット識別子のMicrosoftによる名称です。見つかる唯一の違いは形式です: Microsoftのツールはしばしばそれらを波括弧で囲み大文字を使います。どちらもこのツールが生成できる形式です。