UUID生成器

UUID生成器について

UUIDは128ビットの識別子で、中央で番号を配るサーバーがなくても、各自が作った値が重ならないようにするためのものです。2005年にRFC 4122で規定され、2024年5月にRFC 9562がそれを置き換えて、バージョン6・7・8が追加されました。

このツールはバージョン4(ランダムUUID)だけを作ります。ブラウザのcrypto.getRandomValuesで16バイトを取り、バージョン桁(13文字目)を4に、バリアント桁(17文字目)が8・9・a・bのいずれかになるよう固定します。一度に最大1,000個作れ、大文字やハイフンなしの32文字形式にも変えられます。

UUID文字列の読み方

2d7f7b60-80d6-4402-8639-8e0992715d01では、3つ目のグループ先頭の4がバージョンです。4つ目のグループ先頭の8はバリアントで、RFCの形式に従っていることを示し、規格どおりのUUIDなら必ず8・9・a・bのいずれかです。この固定ビットを除くと、128ビットのうち122ビットがランダムです。

RFC 9562は、16進文字は小文字で出力し、入力では大文字小文字を区別しないよう求めています。大文字オプションは、大文字を前提にした古いシステム(波括弧付きの大文字でGUIDを表示するWindowsのツールなど)に合わせるときだけで十分です。文字列として保存するなら表記を1つに統一しないと、同じIDなのに比較が一致しなくなります。

衝突確率を実際の数字で計算する

ランダムビットが122個なので、取りうる値は2^122(約5.3×10^36)通りです。誕生日問題の近似式 p ≈ 1 − e^(−n²/2N) に当てはめると、10億(10^9)個作ったときにどれか2つが一致する確率は約9.4×10^−20、1兆個でも約9.4×10^−14です。衝突確率が50%になるには約2.7×10^18個、毎秒10億個作り続けても約86年かかります。

この計算は乱数生成器がまともな場合の話です。現実にUUIDが重複した例の多くは確率ではなく実装の問題で、仮想マシンの複製で乱数の状態が同じになった、Math.randomのような暗号用でない乱数を使った、テスト用の固定値を本番に残した、といったものです。このツールはMath.randomで代用しません。Web Crypto APIがない環境では生成ボタンを無効にして理由を表示しますが、現在のブラウザにはすべて備わっています。

主キーにするならv4かv7か

UUIDv7は先頭48ビットにミリ秒単位のUnix時刻を入れ、残り74ビット(バージョン・バリアントを除く)をランダム値か順序保証用のカウンタで埋めます。後から作った値ほど後ろに並ぶので、RFC 9562は可能ならv1・v6ではなくv7を使うよう推奨しています。

差がはっきり出るのはB-treeインデックスです。v4は新しい値がインデックス全体に散らばって入るため、挿入のたびに別のページを読み、分割し、キャッシュにないページを触ることになります。v7は新しい値が常にインデックスの末尾付近に入り、連番の整数に近い振る舞いをします。RFC 9562も、時間順でないUUIDは連続して作っても索引上で近くに並ばず、性能に悪影響があると記しています。

一方でv7は作成時刻がそのまま読み取れます。会員IDや注文番号のように外部に見える値で、登録時期や増加ペースを知られたくないならv4のほうが適しています。このツールはv4専用なので、v7が必要ならデータベースや言語のUUIDライブラリで生成してください。

UUIDを秘密のトークンにしてよいか

正しく作られたv4を推測するのは現実的ではありませんが、RFC 9562はUUIDを推測されにくいものと仮定してアクセス権の証明に使うべきではないとしています。すべての実装が暗号学的乱数を使う保証はなく、v1やv7のように予測できる部分を持つバージョンもあるためです。パスワード再設定リンクなどには、その用途向けのトークン生成を使うほうが安全です。

例

使い方

1. 必要な個数(1〜1,000)を入力します。
2. 使う先が求める場合だけ大文字・ハイフンなしを選びます。小文字・ハイフンありが標準の表記です。
3. 生成された一覧をコピーして使います。

よくある質問