UUID生成（v4・v7）と解析

ランダムなUUID v4と、生成時刻順に並ぶUUID v7を1〜100個まとめて生成。大文字/小文字やハイフンの有無を切り替えでき、既存のUUIDを貼り付けるとバージョン・バリアント・v7の埋め込み生成日時を解析表示します。

使い方

バージョン（v4またはv7）と個数（1〜100）を指定し、「生成する」を押します（値を変えると自動でも再生成されます）。
大文字表記やハイフン省略が必要な場合はチェックボックスで切り替えます。
既存のUUIDを解析したい場合は下の欄に貼り付けると、バージョン・バリアント・（v7の場合は）埋め込まれた生成日時を表示します。

仕組み・根拠

UUID（Universally Unique Identifier）はRFC 9562（2024年公開、旧RFC 4122を置き換え）で仕様が定義された128bitの識別子です。v4は乱数のみから作られるバージョンで、本ツールはcrypto.getRandomValues()（Web Crypto API、暗号論的に安全な擬似乱数生成器）で16バイトを生成し、13文字目のバージョン欄を4に、17文字目のバリアント欄の上位2bitを10に固定します（RFC 9562 §4.4）。

v7はRFC 9562で新設されたバージョンで、先頭48bit（12桁の16進数）にミリ秒精度のUNIX時刻（1970-01-01 UTCからの経過ミリ秒）をビッグエンディアンで埋め込み、残りをランダム値で埋めます（RFC 9562 §5.7）。時刻が先頭に来るため、文字列としてソートすると生成順に並び、多くのRDBMSでB-treeインデックスへの挿入がv4よりも局所的になり断片化を抑えやすいという実務上の利点があります。解析欄でv7のUUIDを貼ると、この先頭48bitを取り出してJSTの日時に逆変換して表示します。

現場の落とし穴: UUID v4を大量にRDBMSの主キー（クラスタ化インデックス）にそのまま使うと、挿入位置がインデックス内でランダムになり、ページ分割やキャッシュ効率の悪化でINSERT性能が劣化するケースが知られています。時系列で生成されるID（v7や、DB側のオートインクリメント）の方がインデックス局所性の面で有利になる場面が多く、用途に応じてv4とv7を使い分けるのが実務的です。また、バージョン欄・バリアント欄はUUID文字列中の固定位置（13桁目と17桁目）にエンコードされているだけで暗号学的な保証ではないため、「ランダムに見える文字列だから安全」と早合点せず、推測されて困る値（パスワードリセットトークン等）には別途十分なエントロピー設計が必要です。

よくある質問

Q. v4とv7、どちらを使うべきですか？

A. 推測されにくいランダム性を重視するならv4、生成順に近い形でソート・インデックスしたい（DBの主キーなど）ならv7が適しています。RFC 9562自体もソート可能性が必要な用途にv7を推奨しています。

Q. 生成したUUIDに重複はありませんか？

A. v4は128bit中122bitがランダムなため、理論上の衝突確率は天文学的に低いですが、ゼロではありません。v7も時刻部分が同一ミリ秒でもランダム部分（約74bit）で衝突回避しています。

Q. 解析でバリアントが「予約領域」と出ました。

A. RFC 9562標準のUUID（Microsoft系や独自形式を除く）はバリアントが10xx（8,9,a,bのいずれか）になります。それ以外はNCS互換やMicrosoft GUID等、別系統の識別子である可能性があります。