UUID解説 — v4 vs v7

UUID（Universally Unique Identifier）は、中央の番号配布機関なしに何かを一意に識別するための128ビットのラベルです。一意な行ID、衝突しないファイル名、分散システム用のキーが必要になったことがあれば、UUIDに出会ったことがあるでしょう。UUIDジェネレーターは、Web Cryptoを使ってv4・v1・v7をローカルで生成します — サーバーには何も送信されません。

TL;DR

UUIDは128ビットの識別子で、選ぶバージョンによってそのビットの意味が変わります。

v4は完全ランダム（既定） — 単に一意なIDが必要なときの標準的な選択です。
v7は時刻でソート可能 — Unixミリ秒タイムスタンプを埋め込むため、時系列でソートされ、データベースのインデックスキーとしてはるかに優れています。
Web Cryptoでローカル生成 — crypto.getRandomValuesがブラウザー内でランダム性を担うため、サーバーは関与せず、値がデバイスから外に出ることはありません。

UUIDとは何か

UUIDは128ビットのデータで、慣例としてハイフンで区切られた5つのグループに32桁の16進数として表現されます — 8-4-4-4-12の配置です。

550e8400-e29b-41d4-a716-446655440000

数ビットはバージョン（上の第3グループの 4 はv4を示す）とバリアント（第4グループの先頭 a/b/8/9）のマーク用に予約されています。それ以外は実際の識別データを担い、そのデータが何かはバージョンによります。全体の空間 — 2¹²⁸通りの値 — は膨大なので、現実的な規模ではランダムなUUIDが衝突することは実質的にありません。

UUIDが違う点の一つは、秘密ではないことです。識別子であり、ナンバープレートのようなものです。一つ知ったからといって別のものを導出できるわけではありませんが、UUID単体ではアクセス制御を何も提供しません — パスワードやトークンとして使わないでください。

UUID v4 — ランダムの既定値

「UUID」と言うとき、ほとんどの人がv4を指します。128ビットのうち122ビットがランダム（6ビットはバージョンとバリアントで固定）で、暗号論的乱数源から取得されます。その結果、時間・場所・他の値との関係を持たない識別子になります。

乱数空間がこれほど大きいため、独立して生成した2つのv4 UUIDが衝突する確率は天文学的に小さく、もっともらしくなる前に毎秒数十億を何年も生成し続ける必要があります。そのためv4は、順序を気にせず一意なIDが必要なあらゆる場面 — リクエストID、セッションキー、ファイル名 — で正しい選択です。代償は、v4の値が空間内に一様に散らばることで、これはデータベースのインデックスにとって好ましくありません（後述）。

UUID v7 — 時刻でソート可能なもの

v7は先頭ビットにUnixミリ秒タイムスタンプを埋め込み、残りのビットはランダムです。決定的な結果は、v7 UUIDが生成された順にソートされることです。

これはデータベースにとって重要です。主キーのインデックスは、挿入が連続しているときに最もうまく働きます。新しい行が（「ランダムにページ全体に散らばる」のではなく）インデックス内で隣り合って配置される（追記パターン）からです。v4の挿入はランダムなページを叩き — ランダムなディスクI/O、ページ分割、テーブルが大きくなるにつれてのインデックス断片化を引き起こします。v7の挿入はまとまるので、データベースは順次書き込みし、インデックスはコンパクトに保たれます。

時間とともに成長するテーブル — 注文、イベント、ログ行 — では、v7が通常より良い主キーです。機械間の調整なしに一意性は保たれつつ、インデックスが適切に振る舞います。

UUID v1 — レガシーなもの

v1もタイムスタンプ（1582年以降の100ナノ秒クロックの60ビット）とノード識別子をエンコードします。このノード識別子は歴史的にマシンのMACアドレスから導出されていました。v7と同じ意味でソート可能ですが、今ではめったに正しい選択にならない2つの欠点があります。

プライバシーの漏洩 — 全UUIDにMACアドレスを埋め込むと、生成元マシンのネットワークハードウェアが明らかになり、あるノードからのUUIDが簡単に紐付け可能になります。プライバシー・バイ・デフォルトの時代において、それは現実のコストです。
v7に対する実質的な利点がない — v7はクリーンなUnixミリ秒タイムスタンプとハードウェアの指紋なしで時刻順を与えるため、v1に手を伸ばす理由はほぼ消えました。

既存のv1データがあれば、それでも問題なく機能します。ただ新しいシステムをv1で始めないでください。v4（順序が重要でないとき）またはv7（重要なとき）が、実質的にあらゆる現代のニーズをカバーします。

手順: UUIDを生成する

UUIDジェネレーターはWeb Cryptoを使い完全にブラウザー内で動くため、乱数バイトはローカルで生成され、何もアップロードされません。手順は次のとおりです。

バージョンを選びます。 v4 / v1 / v7 の各ボタンで生成するUUIDバージョンを選びます（既定はv4）。
件数を選びます。 件数セレクトで生成数を指定します: 5、10、25、50、100（最大100）。既定は10です。
フォーマットを選びます。 7つの出力フォーマットが結果を形作ります:
- plain — 標準の 8-4-4-4-12 形式、550e8400-e29b-41d4-a716-446655440000 のように。
- UPPER — すべて大文字、大文字を好むシステム向け。
- ハイフンなし — 32桁の16進数を連結、550e8400e29b41d4a716446655440000 のように。
- {braces} — {...} で囲む、Microsoft GUIDスタイル。
- “string” — 二重引用符で囲み、JSON値にそのまま貼れるように。
- SQL IN — ('...','...') の形式で、SQLの IN (...) 句向け。
- JS array — ["...","..."] の形式で、そのまま使えるJavaScript配列リテラル。
生成します。 新規を押すと単一のUUIDが、生成を押すと指定した件数を一括で生成します。
コピーします。 コピー を押すと、生成したすべての値をクリップボードにコピーします。

バージョンを切り替えると、そのバージョンの新しい単一値が即座に生成されるため、フォーマットを並べて比較できます。

よくある質問

UUIDは秘密ですか？

いいえ。UUIDは識別子であり、秘密ではありません。あるUUIDを知ったからといって別のものを予測できるわけではなく、v4/v7の値単体ではアクセスを許しません。推測が困難であるべきもの — パスワード、APIトークン、セッションの秘密 — が必要なら、パスワード・トークンジェネレーターで本物の秘密を生成してください。UUIDは一意性のためのもので、アクセス制御のためのものではありません。

データベースにはv4とv7どちらを使うべき？

時間とともに成長するテーブルなら、通常 v7 がより良い主キーです。作成時刻でソートされるため、挿入が連続し、インデックスがランダムI/Oで断片化する代わりにコンパクトに保たれます。順序が重要でなく、最も広い互換性が欲しいとき — リクエストID、キャッシュキー、値が単なるラベルの場所 — は v4 を使います。迷ったら、新しい主キーにはv7、それ以外にはv4を選んでください。

どのフォーマットを選ぶべき？

値がどこへ行くかによります。plain は安全な既定値で、ほとんどのシステムが期待するものです。UPPER はGUIDを大文字で保存するシステムに合います。ハイフンなし は4バイト節約し、詰まった形式に収まります。{braces} はMicrosoft GUIDの慣習に従います。“string” はJSON値に直接入り、SQL IN はデータベースクエリに、JS array はJavaScriptのソースに入ります。行き先に合う形を選んでください。

たくさん一度に生成できますか？

はい。件数（最大100）を設定し生成を押せば、その数のUUIDを一度に生成でき、次に コピー ですべて取得できます。1つだけ必要なら、新規が件数に触れずに単一の値を生成します。