UUID 生成 — v4（ランダム）/v7（時刻順）対応

v4 と v7 の使い分け

UUID v4 は完全ランダム（122ビットの乱数 + バージョン/バリアント2ビット）で、約5.3 × 10³⁶通りの可能性があります。実質的に衝突しません。順序が不要な用途（APIリクエストID、匿名ユーザーIDなど）に適しています。

UUID v7（RFC 9562、2024年制定）は先頭48ビットがUnixミリ秒タイムスタンプ、残り74ビットが乱数。文字列ソートで作成順に並ぶため、データベース主キー用途で大きな性能差を生みます（B-treeインデックスへの挿入が常に末尾になるためページ分割が起きない）。新規DBの主キーにはv7推奨です。

本ツールの仕組み

v4・v7とも crypto.getRandomValues（ブラウザの暗号学的乱数API）を使用。HTTPS や パスワードマネージャーが使うのと同じ乱数源です。v4 は 122ビットを乱数で埋め、v7 は 48ビット時刻 + 74ビット乱数 + RFC準拠のバージョン/バリアントビットを組み合わせます。

生成はすべてブラウザ内で完結し、保存・送信されません。100個のv4 UUID間で衝突する確率は天文学的に小さく、CPUの宇宙線ビット反転よりも稀です。

よくある落とし穴

v4 UUID をDB主キーにすると、ランダム値ゆえに挿入時のB-treeページ分割が頻発しパフォーマンスが落ちます。v7 ならこの問題を回避できます。新規プロジェクトの主キーには v7 を推奨。

推測されたくない用途では UUID をユーザーに露出しないでください。v4 は 122ビットあり推測不可能ですが、v7 は作成時刻が漏れます（多くの用途では問題なし、機密性が高い用途では注意）。

UUID はハイフン込み36文字（32hex + 4ハイフン）。バイナリで16バイト、テキストで36バイト。極端に行数が多いカラムでは VARCHAR(36) ではなく BINARY(16) や ネイティブUUID型での保存を検討してください。