UUID生成ツール
UUID生成ツールの使い方
このツールは、UUIDを生成します。
「UUID VERSION」と「FORMAT OPTIONS」を選択すると、リアルタイムで生成して表示します。
UUIDとは何か
UUID（Universally Unique Identifier）は、128ビット＝32桁の16進数で表される識別子です。標準的な表記は以下のようにハイフンで5つのグループに区切られます。
550e8400-e29b-41d4-a716-446655440000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
↑ ↑ M=version, N=variant第3ブロック（Mxxx）の 最初の1桁はUUIDのバージョンです。v1なら1、v4なら4、v7なら7になります。
第4ブロック（Nxxx）の 最初の1桁 は「バリアント」と呼ばれ、UUIDのレイアウト規則を示します。
現在の標準（RFC 4122）では、この位置のビットは 10 で始まる必要があるため、16進数では 8, 9, a, b のいずれかになります。
「Universally Unique（世界中でユニーク）」という名の通り、中央サーバーなしに生成しても衝突する確率が事実上ゼロです。数学的には、v4 UUIDを1秒間に10億個生成し続けて最初の衝突が起きるまで約85年かかると言われています。
UUIDのバージョン比較
RFCで定義されているバージョンは複数あります。開発現場でよく使われる3つを詳しく解説します。
v1 タイムスタンプベース
6ba7b810-9dad-11d1-80b4-00c04fd430c8
└──────↑1┘
タイムスタンプ仕組み：
- 生成した時刻（100ナノ秒精度）を第1〜第3ブロック（バージョン桁を除く）に埋め込む
- MACアドレス（ネットワークカードの固有ID）をノード部分に使用
メリット：
- UUIDを見るだけで生成時刻が特定できる
デメリット：
- タイムスタンプは第1ブロック（Low）、第2ブロック（Mid）、第3ブロック（High）の順に詰め込まれるため時間が経過しても先頭の数字が激しく変化しソートに向かない
- MACアドレスが含まれるためプライバシーリスクがある
仕様は非推奨： 現在はバージョン1よりもバージョン7を使うべきとされています。
v4 完全ランダム
最もよく使われます。
550e8400-e29b-41d4-a716-446655440000
↑4 ↑8,9,a,b（variant）仕組み：
- 122ビットを暗号論的に安全な乱数で生成
- バージョン（4ビット）とバリアント（2ビット）のみ固定
メリット：
- シンプルで実装が容易
- サーバー・クライアントどこでも生成できる
- 生成時刻や環境情報が漏れない
デメリット：
- 完全ランダムのためDBのB-treeインデックスにキャッシュミスが起きやすい
- 大量挿入時にパフォーマンスが低下することがある
向いている使い方： ユーザーID、セッションID、APIキー、一般的なエンティティのID
v7 — タイムスタンプ＋ランダム
次世代の標準（RFC 9562で標準化、2024年）です。
018f2ac4-d7b8-7000-8a1e-1a2b3c4d5e6f
└─────┘↑7
Unixタイムスタンプ(ms精度)仕組み：
- 上位48ビットにUNIXタイムスタンプ（ミリ秒）を格納
- 残りの74ビットをランダムに生成
メリット：
- タイムスタンプが含まれるためDBの挿入順が単調増加→ B-treeインデックスが効率的
- v4のランダム性によるプライバシーも保ちつつ、時系列ソートが可能
- v1のMACアドレス問題を解決
デメリット：
- 比較的新しいため、古いライブラリでは未対応の場合がある
向いている使い方： 大規模なDBのプライマリキー、高頻度INSERT、PostgreSQL・MySQLでのパフォーマンス重視設計
その他のバージョン
| Version | 仕組み | 主な用途 |
|---|---|---|
| v2 | v1 + DCEセキュリティ | UNIXのUID/GIDを埋め込む（ほぼ使われない） |
| v3 | MD5ハッシュ | 名前空間+名前から決定論的に生成 |
| v5 | SHA-1ハッシュ | v3の後継（v3よりこちらを推奨） |
v3/v5は「同じ入力からは必ず同じUUIDが生成される」決定論的な性質を持ち、URL正規化やデータの重複排除に使われます。
開発者目線での活用シーン
1. データベースのプライマリキー
-- PostgreSQL
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- v4相当
name TEXT NOT NULL
);AutoIncrementの整数IDと違い、IDを見ただけでレコード数が推測されないため、APIレスポンスで公開しても安全です。また複数DBにデータを分散させる際、IDの衝突を心配せずに済みます。
2. 冪等性キー（Idempotency Key）
決済・メール送信など「同じリクエストを2回送っても1回しか処理されない」ことを保証するために使います：
POST /api/payments
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000ネットワーク障害でリトライが発生しても二重課金を防げます。
3. ファイル名・オブジェクトストレージのキー
// S3へのアップロード
const key = `uploads/${uuidv4()}.${ext}`;
await s3.putObject({ Bucket: 'my-bucket', Key: key, Body: file });ユーザーが同名ファイルをアップロードしても衝突しません。
4. 分散トレーシング
マイクロサービス間でリクエストを追跡するTrace IDとして：
X-Trace-ID: 018f2ac4-d7b8-7000-8a1e-1a2b3c4d5e6f ← v7なら時刻順にソート可能UUID vs ULID vs NanoID
UUIDに近い代替として以下もあります：
| UUID v4 | UUID v7 | ULID | NanoID | |
|---|---|---|---|---|
| 長さ | 36文字（ハイフンあり） | 36文字 | 26文字 | カスタム可 |
| ソート可能 | ❌ | ✅ | ✅ | ❌ |
| 標準仕様 | ✅ RFC | ✅ RFC | ❌ | ❌ |
| URL安全 | △ | △ | ✅ | ✅ |
| 衝突耐性 | 非常に高い | 非常に高い | 高い | 高い |
迷ったらv4、パフォーマンスを追求するDBにはv7、URLに埋め込みたいならULID / NanoIDが現在のベストプラクティスです。
よくある用途
- ローカル開発中にDBの初期データ（シード）を手作業で書きたい
- 設計書や仕様書にサンプルIDを記載したい
- デモ画面に記載するIDを生成したい
注意点
プライバシーについて
本ツールはブラウザ上で処理を行うため、入力されたデータが外部サーバーに送信されることはありません。
