バージョン(ランダムの v4・時系列の v7)と個数を選ぶと、ブラウザの暗号学的乱数で UUID を生成します。大文字・ハイフンなしの形式に対応し、値はページの外に出ません。
v4 は 122bit を crypto.getRandomValues で埋めます — Math.random ではないので予測・衝突の心配なく使えます。
v7 は先頭 48bit が生成時刻(Unix ミリ秒)なので、文字列順がそのまま時系列です。インデックスの断片化を避けたい主キーに向いています。
UUID(汎用一意識別子)は 128bit の識別子です。表記は hex 32桁を 8-4-4-4-12 に区切った xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 形で、標準は RFC 9562 です。
本質は中央の発行機関なしにどこで作っても重複しないことです。サーバー・クライアント・オフラインのどこで作った ID でも、後でひとつの DB に集めて衝突しません。
v4 は全体がランダム(122bit)です。値に情報がないため、漏れても生成時刻や順序を推測できません。外部に見せる ID など推測不能性が要る場所に向きます。
v7 は先頭 48bit が生成時刻(Unix ミリ秒)で、残り 74bit がランダムです。文字列の並びが時系列になるので DB 主キーに向きます — v4 を主キーにすると挿入位置がランダムになり B-tree インデックスが断片化します。
代わりに v7 は値から生成時刻が読めます。それが問題になる場所では v4 を使ってください。
v4 の乱数空間は 2¹²² ≈ 5.3 × 10³⁶ です。毎秒10億個を100年作っても、衝突が1件でも起きる確率は100万分の1に届きません(誕生日のパラドックスで計算)。
実務で UUID の衝突を心配する必要はありません — 衝突が起きたなら乱数生成器の故障であって、確率の問題ではありません。
だからこそ Math.random のような予測可能な乱数で UUID を作ってはいけません。このツールは crypto.getRandomValues だけを使います。
RFC 9562 は小文字での出力を標準とし、読み取り側には大文字も受け入れるよう求めています。つまり A1B2… と a1b2… は同じ UUID です — 比較するときはどちらかに正規化してください。
ハイフンは人間が読むための区切りです。DB のカラム名や URL、ファイル名のように文字数が惜しい場所ではハイフンなしの32文字も使われます(このツールの「ハイフンを除く」オプション)。保存自体は文字列36文字より 16バイトのバイナリ(PostgreSQL の uuid 型など)のほうが半分以下で済みます。
古い Microsoft の GUID 表記のように {…} で囲む流儀もあります — 値は同じで包装が違うだけです。
v1 は時刻と MAC アドレスの組み合わせです。生成した機器が値から分かるプライバシー問題があり、時系列の性質だけなら v7 のほうがきれいに実現します。
v3/v5 は乱数ではなく名前をハッシュして作ります(それぞれ MD5・SHA-1)。同じ入力なら常に同じ UUID になるため、決定的な ID が必要な場面で使います — 生成器というより計算器です。
つまりオンライン生成器が扱うのは実質 v4 と v7 の2つです。ランダムな ID は v4、並び順が要る ID は v7 — この2つでほぼすべての用途が覆えます。
crypto.getRandomValues で16バイトを埋め、RFC 9562 が定めるバージョン(13桁目の hex)と変種(17桁目)のビットだけを上書きします。Math.random は予測可能なので使いません。
v7 は Date.now() のミリ秒を先頭 48bit にビッグエンディアンで入れます。同じミリ秒の中では残り 74bit の乱数が順序を決めるため、厳密な単調増加が必要なら DB のシーケンスを併用してください。
生成した値がサーバーへ送られることはありません。生成もコピーもブラウザの中で完結し、ページを離れれば値も消えます。
迷ったら v4 です — 標準的なランダム UUID でどこでも通用します。DB 主キーやイベント ID のように生成順に並ぶべき値なら v7 がインデックス効率で有利です。
理論上はあり得ますが実用上はありません。v4 は 122bit の乱数で、毎秒10億個を100年生成しても衝突確率は事実上ゼロです。
いいえ。ブラウザの暗号学的乱数で生成し、ネットワーク要求は送りません。ページを離れると値も消えます。