UUID v4 の構造と122ビットのランダム性
UUID v4 は、128ビットの識別子のうち122ビットを暗号論的乱数で埋める標準形式です。残り6ビットはバージョン（4）とバリアント（RFC 4122準拠）の固定値に割り当てられます。表示は8-4-4-4-12の36文字（ハイフン含む）で、各文字は0-9とa-fの16進数です。このページではcrypto.randomUUIDまたは同等のブラウザAPIを使い、すべての生成をクライアント側で完結させます。ファクトシートが示す通り、122ビットの純粋なランダム性が保証され、時間や順序の情報は一切含まれません。そのため、生成されたUUIDはソート可能ではありますが、その順序に意味はなく、挿入順や時間順とは無関係です。
衝突確率とその現実的な非発生性
122ビットのエントロピーは、2^122通りの値空間を意味します。衝突確率は誕生日問題に従い、n個のUUIDを生成したときの少なくとも1組の衝突確率は 1 - exp(-n^2 / (2 * 2^122)) で近似されます。具体的には、100万個生成しても衝突確率は約1.5×10^-20と実用上無視できます。このページのカウント上限は100個であり、衝突は事実上不可能です。ただし、「事実上不可能」が「絶対に起きない」ではない点は、システム設計者が認識すべきです。特に、分散システムで複数の生成源が独立にUUIDを作る場合、まれな衝突を検出・処理するフォールトトレランスを考慮する場合もあります。
データベースインデックスへの影響 – B-tree断片化
UUID v4 をデータベースのプライマリキーやクラスタ化インデックスに使うと、ランダムな挿入順序がB-treeのページ分割を頻発させ、インデックス断片化を引き起こします。これはファクトシートの核心的な指摘です。時間順にソートされるUUID v7やULIDと異なり、v4は挿入されるたびにツリーの任意の場所に新しいリーフページを割り当てる必要があります。その結果、次の問題が生じます：
- 書き込みスループットの低下
- キャッシュヒット率の悪化
- ストレージの断片化による読み取り性能の劣化
特に大規模なテーブル（数千万行以上）では顕著であり、分散環境で中央発番を使えないという制約とトレードオフになります。ただし、このページのツールはあくまで識別子生成が目的であり、データベース設計における注意喚起としてこの事実を理解しておくことが重要です。
タイムベース識別子との比較 – UUID v7 と ULID
このページのフォーマット選択肢にはUUID v7（時間順UUID）とULID（時間順＋ランダムのハイブリッド）も含まれます。UUID v4はそれらと以下の点で明確に異なります：
| 特性 | UUID v4 | UUID v7 / ULID |
|---|---|---|
| ソート順 | ランダム | 時間順（生成時刻でソート可） |
| 時間情報 | なし | ミリ秒単位のタイムスタンプを含む |
| インデックス断片化 | 大きい | 小さい（時間的局所性あり） |
| プライバシー | 生成時刻を推測されない | タイムスタンプから生成時期がわかる |
ユースケースで言えば、APIトークンやセッションIDのように時間相関を避けたい場合にUUID v4が適します。一方、データベースのプライマリキーとしては、v7やULIDの方がパフォーマンス面で優れます。ファクトシートが「sort arbitrarily（任意の順序）」と明記する通り、v4の無秩序なソート特性は、時間的局所性が必要な場面では欠点となります。
フォーマットカスタマイズの実践 – 大文字とハイフンの扱い
このページでは、大文字/小文字とハイフンの有無を独立に設定できます。大文字にすると16進数のA-Fを使い、小文字はa-fです。相互運用性の観点では、UUIDを標準的な36文字形式で扱うシステム（RFC 4122準拠）は大文字と小文字を区別しないことが多いですが、ファイルシステムやURLで使う場合、大文字小文字の一貫性が重要です。ハイフンを削除すると32文字の連続した16進文字列になり、URLやファイル名でよりコンパクトになります。ただし、多くのシステムはハイフンを含む標準形式を期待するため、削除する場合は受け取り側が対応していることを確認する必要があります。
ファクトシートの通り、これらのオプションを変更すると即座に全IDが再生成されます。これは、同じ乱数系列でも大文字/小文字やハイフンの有無で異なる文字列になるため、一貫性を保つ設計です。
ブラウザ側生成の利点 – プライバシーとレイテンシ
すべての生成はブラウザ内で行われ、ネットワークへのデータ送信は一切ありません。これにより、次の利点があります：
- サーバー負荷ゼロで大量（最大100個）のUUIDを取得可能
- パスワードやトークンなどの機密性の高いIDがネットワーク上に漏れない
- オフライン環境でも使える
crypto.randomUUID()はWeb Crypto APIの一部で、Chromium系、Firefox、Safariの最新バージョンで利用可能です。古いブラウザでは代替実装で安全な乱数を生成します。このページの処理は瞬間的で、100個のUUID生成でも通常1ミリ秒未満です。
FAQ
Q: UUID v4 は本当に重複しないのですか？ A: 衝突確率は極めて低く、実運用上は重複しません。122ビットのランダム空間では、100万個生成しても衝突確率は約10^-20です。ただし、システムの要件によっては衝突検出ロジックを実装する設計もあります。
Q: ハイフンを外してもUUIDとして有効ですか？ A: 技術的には同じ32桁の16進数として機能しますが、標準のRFC 4122形式はハイフンを含む36文字を定義しています。互換性を重視するならハイフン付きを使い、URLやファイル名で短くしたい場合は受け入れ側の仕様を確認してください。
Q: 大文字と小文字はどちらを選ぶべきですか？ A: どちらでも同じ情報を表します。他のシステムとの連携がある場合は、そのシステムの規約に合わせてください。大文字の方が視認性が高いと感じる人もいますが、すべてのシステムが大文字小文字を区別しないとは限りません。
Q: 一度に生成できる最大数はいくつですか？ A: 100個までです。これを超える大量のUUIDが必要な場合は、複数回に分けて生成するか、スクリプトを使った自動化をお勧めします。
Q: ブラウザの互換性はどうなっていますか？
A: モダンブラウザ（Chrome 49+、Firefox 43+、Safari 10.1+）はcrypto.randomUUID()をサポートしています。それ以前のバージョンでは、安全なフォールバック処理で生成します。すべての処理はクライアント側で完結するため、ブラウザの種類によって結果の品質が変わることはありません。
Q: データベースのプライマリキーにUUID v4を使うと問題がありますか？ A: インデックス断片化が発生し、書き込みパフォーマンスが低下します。特に大規模テーブルでは顕著です。時間順にソートされるUUID v7やULIDの方がデータベースとの相性が良いですが、分散環境で中央発番を使えない場合にv4が選ばれるケースもあります。