UUID v7 の仕組み——このジェネレーターが解決する問題
このページは、1～100のカウントと表示設定（大文字／小文字、ハイフンの有無）を指定すると、タイムソート可能で推測不可能な36文字の識別子リストを即座に返す。UUID v7は先頭に48ビットのUnixミリ秒タイムスタンプを埋め込み、残りを乱数ビットで構成する。これにより、UUID v4が抱えるインデックスの局所性問題——ランダムなID分布がBツリーのページ分割を頻発させる問題——を解決しながら、暗号学的に推測不可能な性質を維持する。ただし、同じミリ秒内で生成されたIDどうしの厳密な順序は保証しない。このトレードオフが、並列分散システムでv7を採用する際の設計上の注意点となる。
128ビットの内訳——タイムスタンプとランダム部分
UUID v7は128ビット全体を以下のように割り当てる。
- 48ビット: Unixミリ秒タイムスタンプ（1970年1月1日からの経過ミリ秒）。これが先頭に置かれる。
- 4ビット: バージョン（値は7固定）。
- 2ビット: バリアント（10xx形式。RFC 4122準拠）。
- 残り74ビット: 暗号論的乱数。
36文字のテキスト表現は、8-4-4-4-12のグループに区切られた16進数である。タイムスタンプ部分が先頭グループ（8文字）と次のグループ（4文字の前半）に現れるため、文字列の辞書順がだいたい生成時刻順と一致する。これが「ソート可能」の実装上の根拠である。
なぜタイムベースソートがデータベースインデックスを救うのか
UUID v4は完全ランダムなため、テーブルにレコードを挿入するたびにBツリーのほぼランダムなページを更新する。これはインデックスのキャッシュ効率を低下させ、挿入スループットを著しく損なう。特にSSDのようなストレージではランダム書き込みのコストが顕著になる。
UUID v7が先頭にタイムスタンプを持つことで、Bツリーは連続したキー範囲を受け取る。新しいIDは常に現在の最大値より大きな値を持つため、インデックスの右端で追加が行われ、ページ分裂の頻度と範囲が抑えられる。これはインサート性能を桁違いに改善する場合がある。
同じミリ秒内の順序——保証されないという本当の意味
このツールの生成はブラウザ内で行われ、JavaScriptの単一スレッドで動作するため、同じ処理ループ内で生成されるIDは事実上ミリ秒の分解能では同一タイムスタンプを持つ。しかし、同じミリ秒内のIDどうしの順序はランダムである。これはv7の仕様上の制約であり、厳密な発行順序が必要なユースケース（イベントソーシングの順序保証など）には別の仕組み（シーケンス番号の追加や、ミリ秒をさらに分割する機構）が必要になる。
一方で、この制約は並列性の利点をもたらす。複数のマシンやスレッドが独立してIDを生成しても、タイムスタンプ部分だけは一致するかもしれないが、ランダム部分が衝突しない限りユニークであり続ける。中央集約型のシーケンサが不要になるのは、分散システムにとって大きなメリットである。
ブラウザ内生成の実務的な利点と限界
このツールはすべてのUUIDをブラウザのcrypto.getRandomValues()で生成する。サーバーに何も送信しないため、機密性が要求されるプロジェクトでも安心して使える。また、オプションを変更すると即座に再生成されるため、表示形式の違い（大文字⇔小文字、ハイフンの有無）を瞬時に確認しながら設計を進められる。
ただし、ブラウザの乱数ジェネレーターはシステム依存であり、真のハードウェア乱数が使えない環境では擬似乱数にフォールバックする可能性がある。とはいえ、通常の開発作業やテスト用途では実用上問題になることはまずない。
書式設定が実運用に与える影響
- 大文字 / 小文字: 標準UUIDは小文字が推奨される（RFC 4122）。大文字にすると16進数表記としては正しいが、文字列比較やインデックス検索で大文字小文字を区別するかどうかが問題になる。多くのデータベースは大文字小文字を区別しない照合順序を使うことが多いが、厳密な一貫性が求められるなら小文字に統一するのが安全。
- ハイフンの有無: ハイフンなしのUUID（32文字）は、ファイル名やURLに埋め込むときに便利だが、多くのUUIDパーサーはハイフンありを期待する。データベースの主キーとして保存するなら、標準形式（ハイフンあり）をそのまま格納するか、バイナリ変換してスペースを節約するかを選ぶ。
このツールでは、これらの設定を切り替えながら即座に結果を確認できるため、運用環境に合わせた最適な形式を決定しやすい。
よくある質問
Q: UUID v7 と v4 の違いは何ですか？ A: v7 は先頭48ビットがタイムスタンプであるため、生成時刻順にソート可能。v4 はすべてのビットがランダムで、時間順ソートは不可能。代わりに v7 は同じミリ秒内での順序を保証せず、v4 は完全に順序がない。
Q: 同じミリ秒内で生成した複数の ID の順序は保証されますか？ A: 保証されません。同じミリ秒内の ID の順序はランダムです。これは仕様上の設計であり、並列システムでの独立性を確保するためのトレードオフです。
Q: 1回に何個まで生成できますか？ A: 1 から 100 個の間で指定できます。変更は即時反映され、再生成ボタンは不要です。
Q: 大文字やハイフンなしの形式を使うべきですか？ A: 標準は小文字＋ハイフン（36文字）です。大文字にすると一部システムで大文字小文字問題が発生する可能性があります。ハイフンなしはストレージ節約に有効ですが、パーサーとの互換性に注意してください。
Q: このツールはサーバーにデータを送信しますか？
A: いいえ。すべての生成はブラウザの crypto.getRandomValues() でローカルに行われます。サーバーに ID や設定が送信されることはありません。
Q: UUID v7 で衝突は起こりますか？ A: ランダム部分（74ビット）が衝突する確率は、UUID v4 と同等に極めて低いです。同じミリ秒内でも、74ビットのランダム空間により実用上問題になる衝突はほぼ発生しません。