要点：UUID v4 はランダムな一意 ID の安全な既定です。作成時刻で並ぶ ID も欲しいなら ULID、短く URL に向く ID が必要なら NanoID が最適です。三つとも システム間の調整を不要にしますが、長さ・並べ替え可能性・インデックス挙動の折り合いが異なります。本ガイドでは各々が何か、いつ使うかを説明します。
一意識別子により、独立したシステムは中央サーバーに「次の番号は？」と尋ねずにレコードを作成できます。この独立性が肝心です。二つのサービス、あるいは二台のオフライン端末が、それぞれ ID を発行しても値が衝突しないと確信できます。
UUID とは実際に何か
UUID は 128 ビットの値で、通常 36 文字——16 進数字 32 個とハイフン 4 個——で書かれます。例：550e8400-e29b-41d4-a716-446655440000。ほぼ常に使いたい版が UUID v4 で、そのうち 122 ビットを乱数で埋め、約 5.3 × 10³⁶ 通りの値になります。ゆえに衝突を見込む必要はありません。いずれかの衝突が 50% の確率に達するには、約 100 京個の UUID を生成する必要があります。
「無視できる」は「不可能」ではありませんが、実務上 v4 は中央調整なしで一意性を提供します。
UUID v4 と v1
UUID v1 はタイムスタンプと生成マシンのネットワーク（MAC）アドレスから作られます。これにより v1 はおおむね時刻順ですが、ID がいつどこで作られたかを漏らしうる——時にプライバシー上の懸念です。UUID v4 はそれらを捨て、純粋な乱数を採ります。順序なし、埋め込みメタデータなし、漏れるものなし。多くの用途で v4 が正しい既定で、v1 はその時刻成分が具体的に必要なときだけ価値があります。
ULID：設計上並べ替え可能
ULID も 128 ビットですが、ハイフン付き 16 進ではなく 26 文字の Crockford base32 で符号化されます。先頭 48 ビットがミリ秒のタイムスタンプ、残り 80 ビットが乱数です。タイムスタンプが先頭にあるため、ULID は作成順に辞書式で並びます。文字列を並べ替えれば文字列を並べるだけで時系列順になります。これは実に有用で、「新しい順」クエリを安くし、データベースの挿入を分散させず順序どおりに保ちます。
NanoID：短く URL 向き
NanoID は既定で URL セーフな文字集合から 21 文字を使うため、パーセントエンコードなしでリンクに収まります。長さは設定可能で、サイズと衝突耐性を天秤にかけられます。短い ID は整然としますが乱数が減るので、公開用や大量発行の識別子には長めに保ちます。NanoID は共有リンク、短い公開 ID、そして 36 文字の UUID が URL で不格好に見える場面で輝きます。
データベースの主キーにはどれ？
ここでの選択は実際の性能に影響します。UUID v4 は主キーとして全く妥当ですが、その乱数性ゆえ新しい行が B-tree インデックスのランダムな位置に挿入され、テーブルの成長につれ断片化とページ分割が増えます。時刻順の識別子——ULID、または新しい UUID v7——はおおむね昇順に挿入され、インデックスを密に、書き込みを局所的に保ちます。大規模で書き込みの多いテーブルのキーには時刻順 ID を、小さなテーブルでは差はめったに問題になりません。
避けたいよくある間違い
- 推測されない ID が欲しいのに連番の整数 ID を公開する——それは乱数 ID の仕事で、オートインクリメントの仕事ではありません。
- 巨大テーブルのクラスタキーにランダムな UUID v4 を使い、挿入が遅い理由に首をかしげる。
- 「容量節約」のため UUID を切り詰める——一意性を保証する乱数を捨てることになります。
- 大量発行の識別子で NanoID を短くしすぎ、衝突リスクを高める。
ID を用途に合わせましょう。UUID 生成ツールで v4・v1・ULID・NanoID を作成し、一般的な一意性には v4、順序が重要なら ULID、ID を URL に置くなら NanoID を選びます。