単一の v4 UUID
入力
count: 1 uppercase: off
出力
550e8400-e29b-41d4-a716-446655440000
13 文字目は常に `4`(バージョン)、17 文字目は `8`・`9`・`a`・`b` のいずれか(バリアント)です。残り 122 ビット(`e8400`・`e29b`・`1d4` など)が完全ランダム部分です。
Loading…
すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。
使い方
生成する UUID の個数(1〜100)を設定して Generate を押します。それぞれが新しい v4 UUID で、ブラウザの WebCrypto API から取得した暗号学的に安全な 122 ビットのランダム値です。時刻・MAC アドレス・カウンタは一切埋め込まれません。下流のシステムが 16 進数を大文字で保存する場合(古い SQL Server や Oracle の一部設定など)は Uppercase をオンにしてください。
調整なしで一意な識別子が必要な場面で使います。DB INSERT 前のドラフトレコード ID、HTTP リトライ用の冪等性キー、ログトレース用の相関 ID などです。出力は完全ランダムでソート可能ではありません。作成時刻順に並べたい場合は UUID v7 や ULID を検討してください。生成はすべてブラウザ内で行われ、いかなる値もサーバーに送信されません。
例
シードファイル向けのバルク生成
入力
count: 5 uppercase: off
出力
a1b2c3d4-5e6f-4a7b-8c9d-0e1f2a3b4c5d f9e8d7c6-b5a4-4392-8170-6f5e4d3c2b1a 7c8d9e0f-1a2b-4c3d-9e8f-0a1b2c3d4e5f 3b4c5d6e-7f80-4192-a3b4-c5d6e7f80a1b 12345678-9abc-4def-9012-3456789abcde
バルクモード(最大 100 件)は、テストフィクスチャの初期データ投入、ステージング用の `WHERE id IN (…)` 句の作成、バッチジョブ用の冪等性キーの事前発行などに便利です。Copy All で一覧をまとめてコピーできます。
レガシーシステム向けの大文字
入力
count: 1 uppercase: on
出力
550E8400-E29B-41D4-A716-446655440000
RFC 4122 §3 は生成側に「小文字での出力を推奨」していますが、パース側は両方を受け入れる必要があります。SQL Server の UNIQUEIDENTIFIER や Oracle の RAW(16) はデフォルトで大文字表示するため、入力側でその表記に揃えるとフィクスチャの見た目の差分ノイズを避けられます。
よくある質問
同じ UUID が重複して生成されることはありますか？
実務的にはありません。v4 は 122 ビットのランダム値 = およそ 5.3 × 10^36 通りです。バースデーパラドックスによる 50% 衝突閾値は約 2.71 × 10^18 件の生成。毎秒 10 億件を 100 年生成し続けても、衝突確率は検知閾値未満にとどまります。v4 UUID の重複は確率現象ではなく、コードのバグ(未初期化の乱数生成器、バッファの再利用など)を疑ってください。
v4 はデータベースの主キーに向いていますか？
機能としては可、性能面では多くの場合「向いていない」です。ランダムな ID は B-tree 全体に挿入を分散させ、ページの断片化とバッファキャッシュヒット率の低下を招きます。書き込み頻度の高いテーブルでは PostgreSQL・MySQL・SQL Server のすべてでこの影響が出ます。UUID v7(時刻順)や ULID は無調整性を保ったまま局所性問題を解きます。どうしても v4 を使う場合は、クラスタリング用に連番の `bigserial` を残し、UUID を二次的なルックアップキーにすることを検討してください。
v1・v4・v7 の違いは何ですか？
v1 は 60 ビットのタイムスタンプとホストの MAC アドレスを組み合わせます。ソート可能ですが、ID がどこで作られたかが漏れます。v4 は完全ランダム — 漏洩はないがソート不可。v7(RFC 9562、2024 年)は先頭に 48 ビットの Unix ミリ秒タイムスタンプを置き、後続をランダムにします。ソート可能で MAC 漏洩なし、v4 のストレージカラムにそのまま入ります。v3 と v5 は名前空間と名前に対する決定論的ハッシュで、同じ入力から常に同じ UUID を得たい場合に使います。
`crypto.randomUUID()` はトークン用途として暗号学的に十分安全ですか？
ほとんどの用途では十分です。背後の CSPRNG は WebCrypto の subtle 鍵生成と同じものです。ただし、122 ランダムビットは長寿命のベアラートークンやセッション ID に対して OWASP ASVS が推奨する 128 ビット下限を下回ります。これらの用途には UUID ではなく専用のランダムバイト関数(`crypto.getRandomValues(new Uint8Array(32))` + base64url など)を使ってください。
ハイフンなしの UUID を取得できますか？
直接はできません。本ツールは正規形(8-4-4-4-12)で出力します。コピー後にハイフンを除去するには `s/-//g`(sed)、`replace(/-/g, "")`(JS)、または手動の置換を使ってください。RFC 4122 はパーサに両形式の受け入れを認めていますが、ログや API が想定するのは多くの場合この正規形です。
UUID・ULID・nanoid — どれをいつ使いますか？
UUID は相互運用の既定です。あらゆる言語とデータベースが 128 ビット形式を理解します。ULID は同じ 128 ビットを Crockford base32 の 26 文字で表現し、時刻を先頭に持ち辞書順ソート可能なので URL に向きます。nanoid は 21 文字の URL セーフなランダム文字列で、衝突耐性は UUID v4 と同程度ながらライブラリのフットプリントがはるかに小さいです。システム間で受け渡す識別子なら UUID、URL に露出する短い ID なら ULID か nanoid が妥当です。
関連する概念
UUID(Universally Unique Identifier)は 32 桁の 16 進数とハイフン 4 つで表現される 128 ビット値です(`xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx`)。`M` ニブルがバージョン、`N` ニブルがバリアントを表し、バージョンに応じて最大 122 ビットがペイロードとして残ります。形式は RFC 4122(2005 年)で最初に定められ、RFC 9562(2024 年 5 月)で更新されて v6・v7・v8 が導入されました。
各バージョンはソート可能性・プライバシー・決定性の三つを天秤にかけます。**v1**(タイムスタンプ + MAC)はソート可能ですが、発行ホストを識別できます。**v3 / v5**(名前空間 + 名前のハッシュ、MD5 / SHA-1)は決定論的で、同じ入力から常に同じ UUID が得られます。外部識別子から安定した ID を導きたいときに有用です。**v4**(ランダム)はプライバシー保護できるがソート不可な既定値で、本ツールはこの v4 を生成します。**v6** は v1 のタイムスタンプをバイト順ソート向けに並べ直したものです。**v7** は先頭に 48 ビットの Unix ミリ秒タイムスタンプ、続く部分にランダムビットを置き、現在の DB 主キー推奨形式です。
UUID は隣接する 2 つの考え方の中間に位置します。オートインクリメント整数(`bigserial`・`AUTO_INCREMENT`)は単一のコーディネータを必要とし、レコード数が露出しますが、小さくソートしやすい性質があります。暗号学的にランダムなトークン(`crypto.getRandomValues(32)` → base64url)は UUID v4 よりエントロピーが大きく(256 ビット対 122 ビット)、セッション Cookie やパスワード再設定リンクに向いた選択です。UUID はその中間です。分散生成に十分なランダム性、あらゆる DB ドライバが理解する標準形式を備える一方、セキュリティクリティカルなトークンとしてはエントロピー不足です。