データベースのレコードIDや、APIのエンドポイントURLで、こんな文字列を見たことはありませんか?

550e8400-e29b-41d4-a716-446655440000

これがUUIDです。なぜ普通の連番(1, 2, 3...)ではなく、こんな長い文字列をIDとして使うのでしょうか?この記事では、UUIDの仕組みとバージョンごとの違い、実際の使い方を解説します。

UUIDとは?

UUID(ユー・ユー・アイ・ディー)は Universally Unique Identifier の略で、128ビット(32桁の16進数)の識別子です。RFC 4122として標準化されており、ハイフンで5つのグループに区切った形式で表記されます。

最大の特徴は「中央管理なしに世界中で一意」である点です。データベースのシーケンスやサーバーとの通信なしに、クライアント側で生成しても衝突(重複)がほぼ起きません。理論上の衝突確率は天文学的に低く、実用上は「絶対に被らない」と考えて問題ありません。

UUIDのバージョン比較

UUIDにはいくつかのバージョンがあり、生成方法と用途が異なります。現在よく使われるのは v1・v4・v7 の3つです。

バージョン 生成方法 ソート可能 主な用途
v1 時刻 + MACアドレス △(時刻部分が前半でない) ログ記録、診断・トレース
v4 完全ランダム × DBの主キー(広く使われる)
v7 Unixミリ秒 + ランダム DBの主キー(新規採用推奨)

v4が広く使われる理由

v4は完全ランダムで生成されるため、シンプルで依存がありません。多くのライブラリがデフォルトでv4を使っており、現在最も普及しています。

v7が新しい標準として注目される理由

v7は先頭にUnixタイムスタンプ(ミリ秒)を含むため、生成順にソートできます。これはデータベースのBツリーインデックスとの相性が良く、v4と比べてインデックスの断片化が少なく書き込みパフォーマンスが向上します。2024年以降の新規プロジェクトではv7が推奨されるケースが増えています。

UUIDの具体的な使い方

データベースの主キー(PK)

複数のデータベースやサービスにまたがってレコードを作成する場合、連番IDだとサーバーごとに重複が発生します。UUIDなら分散環境でもIDの一意性が保証されます。

APIエンドポイントのリソースID

/api/orders/1 のような連番IDは、総数の推測や順番の推測がされやすいというセキュリティ上の問題があります。UUIDを使うと /api/orders/550e8400-e29b-41d4-a716-446655440000 となり、外部から推測しにくくなります。

ファイル名のユニーク化

アップロードされたファイルにUUIDをつけることで、ファイル名の衝突を防げます。

// 例: アップロードファイルの保存
const fileId = crypto.randomUUID(); // v4を生成
const fileName = `${fileId}.jpg`;

よくある質問(FAQ)

v4とv7、どちらを使えばいいですか?
新規プロジェクトであればv7を推奨します。時刻順にソートできるためDBのパフォーマンスが良く、作成日時を別途保存する必要がないメリットもあります。既存システムでv4を使っている場合は、互換性を考慮して無理に移行する必要はありません。
連番ID(AutoIncrement)との違いは何ですか?
連番IDはシンプルで人間が読みやすく、データベースの処理も高速です。ただし、分散環境では重複が起きやすく、総件数や順序が外部から推測されるリスクがあります。UUIDはその逆で、分散システムや外部公開するIDに向いています。
UUIDが被ること(衝突)はありますか?
理論上はゼロではありませんが、実用上は無視できるほど低い確率です。v4の衝突確率を示す有名な計算では「毎秒10億個のUUIDを生成し続けて約85年後に50%の確率で最初の衝突が起きる」とされています。通常の開発では気にする必要はありません。

まとめ

  • UUIDは128ビットの一意な識別子で、中央管理なしに世界中で重複しないIDを生成できる
  • v4は完全ランダムで最も普及しているバージョン
  • v7は時刻順ソートが可能で、DBの主キーとして新規採用が増えている
  • 連番IDが不向きな分散環境・外部公開IDにUUIDが活躍する

UUIDを今すぐ生成したい場合は以下のツールをどうぞ。