MT
My Toolbox

UUID ジェネレーター — UUID v4 & v7 をオンラインで生成

暗号学的にランダムなUUIDを即座に生成。v4（ランダム）とv7（時間ソート可能、RFC 9562）に対応。1個から最大100個まで一括生成。crypto.randomUUID()を使用——ブラウザが処理し、サーバーには何も送信されない。

一意のUUIDを生成
一意識別子を素早く生成

UUID v4 (Random)

Generated using random numbers. No structure, completely random. Suitable for most use cases.

UUID v7 (Time-based)

Generated using a timestamp and random numbers. Sortable by time, improving database performance.

UUIDs (Universally Unique Identifiers) are 128-bit numbers used to identify information in computer systems. The probability of generating two identical UUIDs is virtually zero.

UUIDバージョンの説明

UUIDは、5つのグループに分かれた32桁の16進数でフォーマットされた128ビットの識別子です：550e8400-e29b-41d4-a716-446655440000。バージョン番号は13番目の文字にあります（この例の「4」はv4を意味します）。

UUID v4は純粋なランダムです——122個のランダムビットで、6ビットがバージョンとバリアントマーカー用に予約されています。衝突確率は天文学的に低い：50％の確率で重複が1つ発生するためには、2.71×10^18のUUIDを生成する必要がある。実際には「絶対に起きない」。

UUID v7（RFC 9562で定義、2024年発行）は新参者だ。最初の48ビットにUnixタイムスタンプを入れ、その後にランダムビットが続く。これはv7のUUIDが時系列にソートされることを意味する——データベースインデックスにとって大きな勝利。PostgreSQLとMySQLの両方が、ランダムなv4 UUIDを主キーとして使用すると苦しむ。挿入がランダムだとB-treeインデックスがひどく断片化するからだ。v7は挿入を常にインデックスの末尾に追加することでこれを修正する。

どちらを使うか：v4は順序が重要でないもの（セッショントークン、相関ID、idempotencyキー）に。v7はデータベースの主キー、イベントID、作成時間でソートするものに。2024年以降に新しいプロジェクトを始めるなら、v7をデフォルトに。

使い方

  1. UUIDバージョンを選択：v4（ランダム）またはv7（時間ソート可能）。
  2. 数量を設定——1個ですぐ取得、最大100個で一括生成。
  3. 生成をクリック。結果は即座に表示。
  4. 個別のUUIDまたはすべてをコピー。小文字ハイフン付き、そのまま貼り付け可能。

使用場面

分散システムにおけるデータベースの主キー

複数の書き込みノードがある場合、自動インクリメントIDは壊れる。UUIDなら各ノードが協調なしで独立してIDを生成できる。時系列順序が必要な場合（ほとんどの場合）はv7、IDの作成順序を明示的に隠したい場合はv4を使用。

APIのidempotencyキー

Stripe、AWS、ほとんどの決済APIでは重複請求を防ぐためにidempotencyキーが必要。リクエストごとにv4 UUIDを生成——リクエストが失敗して同じキーで再試行した場合、サーバーは新しいチャージではなく再試行だと認識する。

クラウドストレージのファイル・オブジェクト命名

ユーザーファイルをS3にアップロード？UUIDをオブジェクトキーに使う。衝突なし、ファイル名のサニタイズ不要、アップロード順序の情報漏洩なし（v4）、または簡単な時系列リスト（v7）。

分散トレースの相関ID

リクエストのエントリーポイントでUUIDを生成し、ヘッダーですべてのマイクロサービスに渡す。何かが壊れたとき、そのUUIDで全ログをgrepしてリクエストの完全なパスを確認。v4が最適——ソートは不要、一意性だけ必要。

知っておくべきこと

1.

v4 UUIDはデータベース主キーとして不適切（v7を使う）

ランダムなv4 UUIDは挿入がランダムな位置に行われるためB-treeインデックスの断片化を引き起こす。ページ分割の増加、ディスクI/Oの増加、書き込み速度の低下を意味する。ベンチマークではPostgreSQLでv7 UUIDの方が挿入性能が2〜3倍優れている。既にv4を使用中なら簡単に移行できないが、新しいテーブルにはv7を使う。

2.

UUIDは秘密ではない

UUIDは識別子であり、セキュリティトークンではない。v7 UUIDは作成時刻を漏らす（タイムスタンプが最初の48ビットにある）。v4 UUIDはランダムだが122ビットのエントロピーしかない——一意性には十分だが、セキュリティ敏感なトークンには不十分。ブルートフォースに対抗する必要があるAPIキーやセッショントークンには256ビットの乱数値を使う。

3.

データベースにはvarchar(36)ではなくbinary(16)で格納

テキストとしてのUUIDは36文字（ハイフン含む）。バイナリでは16バイト——半分以下のストレージ。PostgreSQLにはネイティブUUIDタイプ（16バイト）がある。MySQLのBINARY(16)とUUID_TO_BIN()もうまく機能する。UUID外部キーを持つ行が何百万行もある場合に重要。

4.

必要でない限りハイフンを取り除かない

標準フォーマットは8-4-4-4-12でハイフン付き。ハイフンを除去するシステムもある（32個の16進数）。どちらも有効だが、ハイフンはUUIDをより読みやすくし、バージョン桁（位置13）を見つけやすくする。システムが明示的に除去を要求しない限り、ハイフンは残す。

例

UUID v4 — 純粋なランダム

位置13の「4」（バージョン）と位置17の8/9/a/b（バリアント）に注目。

Input

バージョン: v4

Output

f47ac10b-58cc-4372-a567-0e02b2c3d479

UUID v7 — 時間ソート可能

位置13の「7」に注目。最初の12個の16進文字がミリ秒単位のUnixタイムスタンプをエンコード。

Input

バージョン: v7

Output

018f6b2d-3c4a-7b12-9f8e-1a2b3c4d5e6f

機能

  • UUID v4：crypto.randomUUID()による122ビットの暗号学的ランダム
  • UUID v7：ミリ秒精度タイムスタンプ + ランダムビット（RFC 9562）
  • 一括生成：ワンクリックで最大100個のUUID
  • 標準8-4-4-4-12フォーマット、小文字16進数
  • ワンクリックで個別またはすべてのUUIDをコピー
  • 100%ブラウザ内で動作——ネットワークリクエストゼロ

よくある質問

2つのUUIDが衝突することはある？

v4の場合：確率は2^122分の1（約5.3×10^36）。毎秒10億個のUUIDを85年間生成して、やっと50％の衝突確率に達する。実際のシステムでは起こらない。v7の場合：タイムスタンプ部分が異なるミリ秒に生成されたUUIDの衝突を保証するため、リスクはさらに低い。

データベースにはUUID v4とv7どちらを使うべき？

ほぼ常にv7。ランダムなv4 UUIDはB-treeインデックスの断片化を引き起こす——挿入がランダムな位置に行われ、ページ分割を引き起こし、書き込み性能を劣化させる。v7 UUIDは時間順なので挿入は常にインデックスの末尾に追加される。PostgreSQLベンチマークではv7の方が挿入スループットが2-3倍良い。v4を使う唯一の理由は作成順序を明示的に隠す必要がある場合。

UUID v7からタイムスタンプを抽出できる？

できる。v7 UUIDの最初の48ビットはミリ秒単位のUnixタイムスタンプ。暗号化も隠蔽もされていない。作成時刻が機密情報なら代わりにv4を使う。ほとんどの用途（データベースID、イベントログ）では作成時刻の公開は問題なく、実際に有用。

UUID vs ULID vs nanoid——どれを使うべき？

UUID v7とULIDは同じ問題（時間ソート可能なユニークID）を解決するが、UUID v7は現在公式RFC標準（9562）。nanoidは短い（21文字 vs 36）が標準ではない——URLスラグには良いがデータベースPKには不向き。相互運用性と標準準拠が必要ならUUID v7。URL用の短いIDが必要ならnanoid。

データベースにUUIDを効率的に格納するには？

利用可能ならデータベースのネイティブUUIDタイプを使う（PostgreSQLには16バイトのものがある）。MySQLではUUID_TO_BIN(uuid, 1)付きのBINARY(16)を使う——スワップフラグがv1/v7でインデックス性能向上のためバイトを並べ替える。大容量テーブルでVARCHAR(36)として格納しない——ストレージの無駄で比較も遅くなる。数百万行では差は測定可能。

ヒントと関連ワークフロー