UUID v4かv7か：どちらを選ぶべきか、そしてその理由

ランダムな識別子だけが必要なときはUUID v4を使います。データベースのキーにする場合や、作成時刻順に並べたい場合はUUID v7を使います。どちらも128ビットで、同じ36文字の形式で書かれるため、違いはビットの並び方にあります。下のUUID生成では、どちらのバージョンも一度に1〜500件まで、ブラウザ上で作成できます。

UUID生成コード用の一意なIDが必要無料で使う

UUIDの見た目

UUID（universally unique identifier）は128ビットの数値で、16進数の32桁を、8・4・4・4・12桁の5つのグループに分け、ハイフンで区切って表します。例として 3f2b8c1e-6d4a-4f7b-9c2e-8a1d5e0b7f63 があります。

数値の中には固定されている部分が2つあります。4ビットはバージョンを表すため、3番目のグループはv4なら4、v7なら7で始まります。2ビットはバリアントを表すため、4番目のグループは8、9、aまたはbで始まります。残りの部分が識別子そのものです。バリアントとバージョンのビットがあるため、v4のUUIDのランダムなビットは128ではなく122ビットになります。

UUID v4：ランダム

v4のUUIDは、先ほどの固定ビットを除けばランダムです。122個のランダムなビットがあるため、同じ値が重複することはほぼありません。仮に10億個のv4 UUIDを生成したとすると、どの2つかが一致する確率はおよそnの2乗を、取りうる値の数の2倍で割ったもので、約10の19乗分の1です。つまり、衝突を気にしながら設計する必要はほとんどありません。

この見積もりは、生成器が暗号学的な乱数源からビットを取っていることを前提にしています。予測可能な生成器では、この前提が崩れます。このツールは、crypto.randomUUIDやcrypto.getRandomValuesを通じて、ブラウザの暗号学的な乱数源を使っています。

UUID v7：時刻が先

v7はRFC 9562で定義されています。最初の48ビットにはミリ秒単位のUnix時刻が入るため、後で作られたIDほど先頭の部分が大きくなります。その後にバージョンのビット、ランダムなビット、バリアントのビット、さらにランダムなビットが続きます。ランダムな領域の一部にはカウンターを入れることができ、同じミリ秒内に複数のIDを作る場合でも順序を保てます。

時刻が先頭にあるため、同じ大文字・小文字の形式でIDを文字列として並べると、ミリ秒単位で作成時刻順に並びます。これは16進数の桁数が固定で、時刻が先頭の文字に入っているからできることです。

時刻は外からも読み取れます。v7のUUIDを見れば、おおよその作成日時がわかります。UUID生成の検査欄に入力すると、先頭の48ビットを日付と時刻に戻して表示するので、自分で確認できます。

v7がデータベースのインデックスに向いている理由

データベースのインデックスは、通常、キーの順序を保つB-treeという構造で作られています。キーがv4のようにランダムだと、新しい行はインデックス内のランダムな位置に入ります。そのためデータベースは、インデックスの多くの場所に書き込む必要があり、ページの分割やキャッシュミスが増えます。大きなテーブルでは、この負荷が積み重なります。

v7のキーは時刻の部分が増えていくため、既存のほぼすべてのキーより大きくなります。新しい行はインデックスの末尾近くに追加され、自動採番の数値とよく似た動きをします。最近使われたインデックスのページはメモリに残りやすく、書き込みも整理された状態を保てます。この差は、絶えず増え続ける大きなテーブルで最も目立ち、小さなテーブルではほとんど気になりません。

v4とv7の選び方

• データベースの主キー、または時間とともに増えるテーブル： v7。インデックスが整然と保たれます。
• ログ、イベント、メッセージなど、時刻順に並べることが多いもの： v7。IDそのものが順序を持ちます。
• 作成時刻を外部に知られたくない公開用のID： v4。v7のIDからは作成時刻がわかってしまいます。
• 時計が正確でない多数のデバイス： v4でもv7でも一意性は保たれます。一意性はランダムなビットが担っているためです。v7の並び順だけが、時計の正確さに依存します。

どちらのバージョンも標準仕様ですが、古いライブラリはv4しか対応していないことがあります。RFC 4122は長年にわたってバージョン1〜5を定めていました。RFC 9562は2024年5月に公開され、RFC 4122を置き換えて、バージョン6、7、8を定めています。依存する前に、使っているライブラリがv7に対応しているか確認してください。

UUIDの保存

文字列として書いたUUIDは36文字になります。16バイトのバイナリ形式で保存すると、はるかに少ない容量で済みます。多くのデータベースには、この目的のためのネイティブのUUID型や16バイトのバイナリ列があり、文字列より高速に比較できます。

形式は1つに決めて、統一してください。大文字、小文字、ハイフン、波かっこは、人にとっては同じUUIDですが、データベースや文字列の比較では別の値として扱われることがあります。生成ツールの大文字、ハイフンなし、波かっこのオプションは、そうした形式が必要なシステムのためにあります。

UUIDを秘密の情報として使わない

UUIDは識別子であり、パスワード、セッショントークン、アクセスキーではありません。一意であるように作られているのであって、推測されにくいように作られているわけではありません。v7のUUIDには作成時刻も含まれます。また、識別子はリンク、ログ、メール、スクリーンショットに貼り付けられることがあり、それを見た人なら誰でも再利用できてしまいます。

アクセス制御はサーバー側で行うべきものです。IDを知っているからといって、そのIDが指すレコードを自動的に閲覧や変更できるわけではありません。パスワード、パスフレーズ、トークンには、秘密の情報のために作られた生成ツールを使ってください。パスワード生成は、安全な乱数を使って、お使いの端末上でランダムなパスワードや単語のパスフレーズを作成し、その強度も推定します。長さと乱数性が大切な理由については、強いパスワードとエントロピーをご覧ください。

ツールの使い方

1. ランダムなIDならバージョン4、時刻順に並ぶIDならバージョン7を選びます。
2. 件数を1〜500件の範囲で指定します。
3. コードで特定の形式が必要な場合は、大文字、ハイフンなし、波かっこにチェックを入れます。
4. すべてコピーするか、一覧を.txtファイルとしてダウンロードします。
5. 検査欄に任意のUUIDを貼り付けると、そのバージョン、バリアント、そしてv7の場合は埋め込まれた時刻を確認できます。

よくある質問

v4のUUIDは一意ですか？ 実用上は一意です。122個のランダムなビットがあるため、重複はほぼ起こらず、重複を確認する必要はありません。

すべてにv7を使うべきですか？ いつもそうとは限りません。データベースのキーや、時刻順に並べるものにはv7を使ってください。作成時刻を隠したい場合はv4を使ってください。

UUIDをパスワードとして使えますか？ 使えません。UUIDは識別子です。秘密にしておく必要があるものには、パスワード生成ツールを使ってください。

このツールはIDをどこかに送信しますか？ 送信しません。IDはお使いのブラウザ内で作成され、表示され、サーバーには送られません。