UUID（Universally Unique Identifier：汎用一意識別子）は、RFC 4122で標準化された128ビットの識別子です。UUIDは、中央による調整を必要とせずに、分散システム内の情報を一意に識別するために使われます。次の連番を生成するために中央のデータベースを必要とする自動採番の整数とは異なり、UUIDは分散システム内のどのノードでも、ノード間の通信や同期を一切行わずに独立して生成できます。この特性により、複数のサーバー、データベース、地理的なリージョンにまたがる現代のアプリケーションアーキテクチャにとって、UUIDは欠かせない存在になっています。
汎用一意識別子という概念は1980年代にさかのぼります。当時、Open Software Foundation（OSF）がDistributed Computing Environment（DCE）の一部としてUUIDを開発しました。その後、仕様は2005年7月に公開されたRFC 4122としてInternet Engineering Task Force（IETF）によって標準化されました。それ以来、UUIDはほぼすべてのプログラミング言語とプラットフォームで採用されており、JavaScript、Python、Java、C#、Go、Rustなど多くの言語に生成関数が組み込まれています。
UUIDのフォーマット
UUIDは通常、ハイフンで区切られた5つのグループに分けて表示される32桁の16進数として表現されます：
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
例：f47ac10b-58cc-4372-a567-0e02b2c3d479
この32桁の16進数は128ビットのデータを表します。フォーマットは次のように分解できます。最初の8桁（32ビット）は時間ベースのUUIDにおける時刻関連の要素を表し、続いて4桁のグループ（16ビット）、バージョン番号を含む4桁のグループ（16ビット）、バリアントを含む4桁のグループ（16ビット）、そして最後にノードまたはランダム要素を表す12桁のグループ（48ビット）が続きます。
バージョン番号は3番目のグループに埋め込まれています。たとえばUUID f47ac10b-58cc-4372-a567-0e02b2c3d479 では、3番目のハイフンの後にある数字 4 が、これがバージョン4のUUIDであることを示しています。バリアントは4番目のグループの最上位ビットで示されます。UUIDのフォーマットでは、ハイフンなしの正規表記（f47ac10b58cc4372a5670e02b2c3d479）やURN表記（urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479）もサポートされています。
UUIDの生成方法
UUIDのバージョンによって、一意の識別子を生成するための戦略は異なります。これらの戦略を理解しておくと、アプリケーションに適したバージョンを選びやすくなります。
UUID v1（時間ベース）
UUID v1は、現在のタイムスタンプ、クロックシーケンス、ノードのMACアドレスを組み合わせます。タイムスタンプは、1582年10月15日（グレゴリオ暦の改暦の日）からの100ナノ秒間隔を数えた60ビットの値です。これによりUUID v1は時間とともに単調増加するという性質を持ち、データベースのインデックス性能に有利に働く場合があります。
ただし、UUID v1にはプライバシー上の懸念があります。MACアドレスによって、そのUUIDを生成した特定のマシンが特定できてしまうためです。複数のv1 UUIDを観測した攻撃者は、そのマシンのMACアドレスを割り出し、さまざまなコンテキストをまたいでマシンを追跡できる可能性があります。このため、MACアドレスをランダムな48ビット値に置き換えていない限り、UUID v1が公開向けのアプリケーションで使われることはほとんどありません。
UUID v4（ランダム）
UUID v4は122ビットの乱数（6ビットはバージョンとバリアントの識別子用に予約）を生成し、約5.3×10^36通りの値を作り出します。調整も状態もネットワークアクセスも不要なため、最も広く使われているUUIDバージョンです。どのノードでもいつでもv4 UUIDを生成でき、衝突する確率は天文学的に低くなります。
UUID v4の乱数は、出力が予測できないことを保証するために、暗号学的に安全な乱数生成器（CSPRNG）から取得する必要があります。古いブラウザのJavaScriptにおけるMath.random()のような弱い乱数生成器を使うと、生成器の内部状態が繰り返される可能性があるため、実際に衝突が起きることがあります。
UUID v7（時刻順序付き）
UUID v7はRFC 9562で定義された新しいバージョンで、ミリ秒単位のUnixタイムスタンプとランダムなビットを組み合わせます。タイムスタンプが最上位ビットを占めるため、v7 UUIDは時間とともに単調増加します。この順序性により、ランダムな順序がB-treeインデックスの断片化やページ分割を引き起こすv4と比べて、データベースのインデックス性能が大幅に向上します。
現代のアプリケーションでは、UUID v7がデータベースの主キーに推奨される選択肢です。v4と同じ衝突耐性を持ちながら、連番の整数に近いデータベース性能を提供します。PostgreSQL、MySQL 9+、SQLiteといった主要なデータベースは、UUID v7の生成に対するネイティブサポートを追加しています。
UUIDバージョンの比較
| バージョン | 方式 | 一意になる範囲 | 衝突リスク | 最適な用途 |
|---|---|---|---|---|
| v1 | 時刻 + MACアドレス | 時間と空間 | 極めて低い | 分散システム |
| v3 | 名前空間のMD5ハッシュ | 名前空間 + 名前 | 低い | 名前ベース（MD5） |
| v4 | ランダム | ランダムビット | 極めて低い | 汎用 |
| v5 | 名前空間のSHA1ハッシュ | 名前空間 + 名前 | 低い | 名前ベース（SHA1） |
| v6 | 時刻順序付き（v1の並べ替え） | 時間と空間 | 極めて低い | データベース（順序付き） |
| v7 | 時刻順序付き + ランダム | 時間とランダム | 極めて低い | データベース（推奨） |
バージョン3とバージョン5は決定論的なUUIDです。同じ名前空間と同じ名前が与えられれば、常に同じUUIDが生成されます。これは、マッピングを保存することなく、複数のシステム間でリソースに一貫した識別子を持たせたい場合に便利です。たとえば、アプリケーションの名前空間内でユーザーのメールアドレスからv5 UUIDを生成すれば、複数のマイクロサービス間で一貫したユーザー識別子を作成できます。
UUID v4の衝突確率
UUID v4の衝突確率はしばしば誤解されています。誕生日のパラドックスによれば、生成したUUIDの数が取り得る値の総数の平方根に近づくと、衝突が起こりやすくなります。UUID v4の場合、2^122の平方根はおよそ2^61、つまり約2.3×10^18個のUUIDに相当します。
| 生成するUUIDの数 | 衝突確率 |
|---|---|
| 10億 | 1,000,000,000,000,000分の1 |
| 100億 | 10,000,000,000分の1 |
| 1000億 | 100,000分の1 |
| 1兆 | 約50%の確率 |
実感しやすいように言い換えると、1秒間に10億個のUUIDを生成したとしても、1回の衝突が起きる確率が50%に達するまでには約73年かかります。実用上のほぼすべてのアプリケーションでは、UUID v4の衝突は起こり得ないものと考えて問題ありません。
UUID v4には約5.3×10^36通りの値があります。衝突する確率を50%にするには、約2.7×10^18個のUUIDを生成する必要があります。
UUIDを使うべき場面
適切なUUIDバージョンの選択は、具体的なユースケースとインフラストラクチャによって変わります。
| シナリオ | 推奨バージョン |
|---|---|
| データベースの主キー（分散環境） | v7（時刻順序付き） |
| セッション識別子 | v4 |
| トランザクションID | v4またはv7 |
| ファイル名 | v4 |
| URLパラメータ（短くしたい場合） | v4（Base64エンコード） |
| DNS/URLの名前空間 | v5 |
レコードが複数のサーバーで作成され、後から統合される分散データベースシステムでは、UUIDによって中央集権的なID生成が不要になります。このユースケースではUUID v7が強く推奨されます。時刻順序を持つ性質により、新しい行を挿入してもB-treeインデックスが良好な性能を維持できるからです。PostgreSQLでは、v4向けにgen_random_uuid()関数を、v7向けにpg_uuidv7などの拡張機能を利用できます。
セッション識別子には、UUID v4の十分なランダム性によってセッション予測攻撃を防ぐことができます。UUID v4で生成したファイル名は、"document.pdf"や"image.jpg"のような一般的な名前でユーザーがファイルをアップロードしたときの名前の衝突を避けられます。UUIDをURLに含める必要がある場合は、Base64でエンコードすることで文字列の長さを36文字から22文字に短縮でき、URLが読みやすくなります。
UUIDを使うべきでない場面
UUIDは汎用性が高い一方で、すべての状況に適しているわけではありません。
-
連番（自動採番を使う場合）。アプリケーションが単一のデータベースサーバーで動作し、複数のソースからのデータを統合する必要がないのであれば、自動採番の整数のほうが性能が高く、ストレージも小さく、デバッグも簡単です。
-
短いURL（nanoidのような短いIDを使う場合）。UUIDの文字列は36文字あり、URL短縮サービスや紹介コードなど、簡潔さが重要な場面には長すぎます。nanoidのようなライブラリは、設定可能な文字種と長さを使って、より短くURLセーフな識別子を生成します。
-
人間が読む識別子。UUIDは人間が読んだり入力したり記憶したりするためのものではありません。請求書番号、注文ID、顧客参照コードには、チェックディジット付きの英数字コードなど、口頭で伝えやすい形式を使ってください。
-
非常に小さなデータセット（100行未満）。データセットが小さく、生きている間に自動採番の整数が範囲を使い切ることがないのであれば、UUIDを使うメリットはありません。追加のストレージコスト（UUIDは16バイト、32ビット整数は4バイト）は不要です。
コードでUUIDを生成する
オンラインのジェネレーターは単発の用途には便利ですが、通常はアプリケーション内でプログラムからUUIDを生成することになります。
JavaScript（ブラウザ）
const uuid = crypto.randomUUID();
console.log(uuid); // "f47ac10b-58cc-4372-a567-0e02b2c3d479"
Node.js
const { randomUUID } = require('crypto');
const uuid = randomUUID();
Python
import uuid
# バージョン4
uuid_v4 = uuid.uuid4()
print(uuid_v4)
# バージョン1
uuid_v1 = uuid.uuid1()
print(uuid_v1)
PostgreSQL
-- バージョン4
SELECT gen_random_uuid();
-- バージョン7（pg_uuidv7拡張が必要）
CREATE EXTENSION IF NOT EXISTS pg_uuidv7;
SELECT uuidv7_generate();
コードを書かずにさまざまなバージョンのUUIDをオンラインで生成するには、UUIDジェネレーターツールをご利用ください。