UUID v4ジェネレーター

Generate cryptographically random UUID v4

…

フォーマット

件数:

こちらもどうぞ：UUID v1ジェネレーター UUID v7ジェネレーター UUID v3ジェネレーター UUID v2ジェネレーター ULIDジェネレーター NanoIDジェネレーター CUID v1ジェネレーター CUID2ジェネレーター UUIDデコーダー

UUID v4 は現代のソフトウェアで最も広く採用されている UUID バージョンです。タイムスタンプや名前空間ハッシュからビットを導出する他のバージョンとは異なり、UUID v4 は完全にランダムなデータで構築されており、発生源に関するメタデータを持たない一意の識別子が必要な場合に最もシンプルで移植性の高い選択肢です。

このジェネレーターは crypto.randomUUID() を使用します。これはネイティブブラウザおよび Node.js API であり、オペレーティングシステムの暗号学的に安全な乱数生成器からエントロピーを取得します——TLS 鍵マテリアルに使用されるのと同じソースです。

UUID v4 とは何ですか？

UUID（Universally Unique Identifier）は RFC 4122 で標準化された 128 ビットのラベルです。通常、32 桁の 16 進数がハイフンで 8-4-4-4-12 のパターンにグループ化されて表されます：

550e8400-e29b-41d4-a716-446655440000

UUID v4 では、128 ビットのうち 122 ビットがランダムです。残りの 6 ビットは仕様で定められた固定フィールドです：4 ビットがバージョン（0100 = 4）を、2 ビットが RFC 4122 バリアント（10）をエンコードします。これらの固定ビットにより、3 番目のグループは常に 4 で始まり、4 番目のグループは常に 8、9、a、または b で始まります。

UUID v4 の構造

550e8400-e29b-41d4-a716-446655440000 の分析：

セグメント	ビット	意味
550e8400	32 ビットランダム	time_low（名前は歴史的——v4 では完全にランダム）
e29b	16 ビットランダム	time_mid（歴史的な名前——v4 では完全にランダム）
41d4	4 ビット固定 + 12 ビットランダム	バージョンニブル `4`（バイナリ `0100`）+ 12 ビットランダム
a716	2 ビット固定 + 14 ビットランダム	バリアントビット `10`（最初のバイトの MSB）+ 14 ビットランダム
446655440000	48 ビットランダム	node（v4 では完全にランダム）

Note:4 番目のグループの先頭のバリアントニブルは常に 8、9、a、または b のいずれかです——そのバイトの上位 2 ビットが 10（RFC 4122 バリアントマーカー）に固定されており、残り 2 ビットが自由に変化できるためです。

UUID v4 と他のバージョンの比較

RFC 4122 は 5 つの UUID バージョンを定義しています。それぞれが異なる問題を解決します：

UUID v1タイムスタンプ + MAC

60 ビットタイムスタンプ（1582 年 10 月からの 100 ナノ秒間隔）とホスト MAC アドレスを組み合わせます。マシン内で単調増加します。

Use when: 時間順 ID が必要で、サーバー ID と生成時間の漏洩を気にしない場合。

UUID v3MD5 ハッシュ

決定論的：同じ名前空間 + 名前は常に同じ UUID を生成します。MD5 ハッシュを使用します。

Use when: 既知の名前空間（例：DNS 名）から再現可能な ID が必要な場合。v3 より v5 を推奨します。

UUID v4ランダム

122 ビットの暗号学的に安全なランダム性。タイムスタンプなし、MAC なし、名前空間なし。最も一般的な汎用の選択肢。

Use when: 構造的な意味を持たず最大のプライバシーを持つ一意 ID が必要な場合。

UUID v5SHA-1 ハッシュ

v3 と同様ですが SHA-1 を使用します。名前空間 + 名前から決定論的に生成されます。

Use when: 再現可能なコンテンツアドレス指定識別子（例：URL で識別されるリソースの安定した ID）が必要な場合。

UUID v7時間順ランダム

新しいバージョン（RFC 9562、2024 年）。上位ビットに Unix ミリ秒タイムスタンプをエンコードし、残りはランダムビット。ソート可能でデータベースフレンドリー。

Use when: 自然な時間順を持つデータベースインデックスフレンドリーな ID が必要な場合（新プロジェクトでは v1 より優先）。

UUID v4 を使用するタイミング

追加の制約なしに単に「一意な ID」が必要な状況の大多数で、UUID v4 が正しい選択です：

ユーザーとアカウント ID

アカウント作成時間やサーバー ID を明かさない不透明なユーザー ID。列挙や推測ができません。

データベースの主キー

あらゆるデータベースエンジンで動作します。UUID v4 はクライアントサイドで安全に生成でき、調整なしに分散ソースからマージできます——シーケンステーブルや中央 ID サービスは不要です。

セッションとトークン ID

122 ビットのランダム性により、ブルートフォース推測は計算上不可能です——122 ビットランダムトークンと同等の強度です。

ファイルとオブジェクト名

アップロード、S3 オブジェクトキー、またはキャッシュエントリの重複防止安全なファイル名。2 つのクライアントが同じキーに書き込むリスクがありません。

冪等性キー

リクエストを送信する前にクライアントで UUID を生成します。サーバーは共有カウンターなしに再試行リクエストを安全に重複排除できます。

相関とトレース ID

すべてのログ行と分散トレーススパンに UUID を添付します。サービスやマシン間での調整は不要です。

Note:ユースケースでソート可能な ID が必要な場合（例：データベース行を挿入時間でクラスタ化したい場合）、代わりに UUID v7 を検討してください。UUID v4 は意図的にランダムであり、高い挿入レートで B ツリーインデックスの断片化を引き起こします。

衝突確率

122 ビットのランダムビットで、UUID v4 の空間には 2¹²² ≈ 5.3 × 10³⁶ の可能な値が含まれます。衝突確率は誕生日問題に従います：

生成された UUID 数衝突確率

10 億（10⁹）約 1 / 5.3 × 10¹⁸

1 兆（10¹²）約 1 / 5.3 × 10¹²

10¹⁸（1 エクサバイト相当）約 1 / 5,300

よく引用されるベンチマーク：単一の衝突が 50% の確率で発生するには、約 2.71 × 10¹⁸ 個の UUID を生成する必要があります。毎秒 10 億個の UUID のレートで、それは約 85 年の継続的な生成が必要です。現実の任意のアプリケーションで、衝突は実際的な懸念ではありません。

コード例

JavaScript——ブラウザおよび Node.js 14.17+

crypto.randomUUID() メソッドはすべての最新ブラウザ（Chrome 92+、Firefox 95+、Safari 15.4+）および Node.js 14.17+ でネイティブに利用できます。パッケージのインストールは不要です。

// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"

// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())

Node.js——旧バージョン（uuid パッケージ）

const { v4: uuidv4 } = require('uuid')

const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"

Python

python

import uuid

# Generate a UUID v4
id = str(uuid.uuid4())
# → '110e8400-e29b-41d4-a716-446655440000'

# The uuid module uses os.urandom() — cryptographically secure
print(uuid.uuid4().hex)  # without hyphens
# → '110e8400e29b41d4a716446655440000'

Go

import "github.com/google/uuid"

id := uuid.New().String()
// → "110e8400-e29b-41d4-a716-446655440000"

// Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic)
// Always prefer github.com/google/uuid for production use

Rust

toml

# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }

rust

use uuid::Uuid;

let id = Uuid::new_v4().to_string();
// → "110e8400-e29b-41d4-a716-446655440000"

よくある質問

UUID v4 は暗号学的に安全ですか？

UUID v4 自体はセキュリティプリミティブではありません——識別子フォーマットです。しかし、crypto.randomUUID()（ブラウザまたは Node.js）または同等の OS レベル API を通じて生成された場合、基礎となるエントロピーは暗号学的に安全です。これは、予測不可能性が重要なセッショントークンや冪等性キーとして UUID v4 値を使用できることを意味します。セキュリティに敏感なコンテキストでは Math.random() ベースの UUID ジェネレーターを使用しないでください——OS CSPRNG から明示的にエントロピーを取得する API のみを使用してください。

2 つの UUID v4 が等しくなることはありますか？

理論的にはありえますが、実際にはありません。現実のデータセット（数十億の ID）内で重複が発生する確率は天文学的に小さく——ハードウェア障害によるデータ破損よりもはるかに起こりにくいです。UUID v4 の衝突は本番システム設計において不可能として扱われます。本当にゼロ衝突保証が必要な場合は、代わりに中央カウンターまたはデータベースシーケンスを使用してください。

UUID v4 vs nanoid——どちらを使うべきですか？

どちらも CSPRNG に支援されたランダム ID ジェネレーターです。主な違い：

UUID v4 は RFC 4122 標準に準拠し、すべてのデータベースとフレームワークで認識され、依存関係が不要です（ネイティブ crypto.randomUUID()）。
nanoid は URL セーフアルファベットを使用し、デフォルトで短い（21 文字 vs 36 文字）。URL の長さや可読性が重要な場合に便利です。npm パッケージが必要です。

外部システムとの相互運用性が重要な場合（API、データベース、ログインフラ）は UUID v4 を優先してください。短い ID が必要でスタック全体を制御する場合は nanoid を優先してください。

データベースで UUID を文字列またはバイナリとして保存すべきですか？

ほとんどのデータベースでは、UUID または BINARY(16) カラム（16 バイト）として保存する方が VARCHAR(36) 文字列（36 バイト）よりも効率的です。PostgreSQL にはネイティブの uuid 型があります。MySQL と MariaDB は BINARY(16) と UUID_TO_BIN() / BIN_TO_UUID() ヘルパーとうまく動作します。SQLite ユーザーは通常 TEXT として保存します。ストレージの選択は一意性や正確性に影響しません。

UUID v4 にハイフンがあるのはなぜですか——省略できますか？

ハイフンは RFC 4122 で定義された標準 UUID 表現の一部です。純粋に装飾的なもので——情報を持たず、128 ビット値に影響しません。省略すると機能的に同等のコンパクトな 32 文字の 16 進数文字列が得られます。ほとんどの UUID パーサーは両方の形式を受け入れます。迷った場合は、サードパーティツールやデータベースとの最大互換性のために標準のハイフン付き形式を使用してください。

const id = crypto.randomUUID()              // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '')     // "550e8400e29b41d4a716446655440000"

言語ガイド

Python UUID v4生成ガイド