UUID生成ツール
UUID v4（ランダム）をブラウザ上で一括生成します。標準形式・大文字・ハイフンなし・波括弧付き・URN形式など複数の表示形式に対応。
UUIDのバージョン一覧
| バージョン | 生成方式 | 説明 |
|---|---|---|
| UUID v1 | タイムスタンプ + MACアドレス | 生成時刻とネットワークカードのMACアドレスから生成。生成元の端末が特定できてしまうためプライバシー上の懸念があり、現在は新規採用が減っている。 |
| UUID v3 | 名前空間 + MD5ハッシュ | 指定した名前空間とキー文字列をMD5でハッシュ化して生成。同じ入力からは常に同じUUIDが得られる（決定論的）。MD5の衝突脆弱性から新規用途にはv5が推奨される。 |
| UUID v4 | 完全ランダム | 暗号論的疑似乱数から生成。生成元の情報を含まずプライバシー上安全で、実装も簡単なため最も広く使われている。本ツールが生成する形式。 |
| UUID v5 | 名前空間 + SHA-1ハッシュ | v3と同じ名前空間方式だがSHA-1を使用。決定論的な生成が必要な場合（同じデータから常に同じIDを再現したい場合）に推奨される。 |
| UUID v6 | 再配置タイムスタンプ + ランダム | 2024年にRFC 9562で標準化。v1のタイムスタンプ構造を並び替え、バイト列の辞書順とタイムスタンプの前後関係を一致させた。データベースのインデックス効率が向上する。 |
| UUID v7 | Unixタイムスタンプ + ランダム | 2024年にRFC 9562で標準化。ミリ秒単位のUnixタイムスタンプを先頭に持つため生成順にソート可能。新規開発ではv4の代替として採用が広がっている。 |
Tips
- 生成したUUIDはブラウザ内のJavaScript（Web Crypto API）で処理され、toolbase.cc のサーバーには一切送信されません。
- データベースの主キーやAPIのリクエストID等、一意性が必要だが連番にしたくない場合にUUID v4が広く使われます。
- UUID v4は128ビットのうち122ビットがランダムなため、衝突する確率は天文学的に低いです（10億個生成しても衝突確率は約50%に達するには約2.7×10¹⁸個必要）。
- 「ハイフンなし」形式はURLのパスセグメントやファイル名として使う際に便利です。「波括弧付き」形式はWindowsのCOM/レジストリ関連（GUID）で使われる形式と同じです。
- 生成件数を増やしてから「すべてコピー」を使うと、テスト用データやシードデータの一括作成に便利です。
よくある質問
理論上はゼロではありませんが、UUID v4は122ビットのランダム性を持つため、実用上は無視できるレベルです。毎秒10億個のUUIDを100年間生成し続けても、重複が1つ発生する確率は約50%にしかなりません。
はい、基本的に同じ概念です。GUID（Globally Unique Identifier）はMicrosoftが自社の実装に使った呼び名で、UUIDと互換性のある128ビットの識別子を指します。波括弧付き形式
{xxxxxxxx-xxxx-...} はWindowsのCOM/レジストリでよく使われるGUID表記です。UUID v4はランダムなため、連番の整数（AUTO_INCREMENT）に比べてインデックスサイズが大きくなりやすく、挿入性能が劣化する場合があります。挿入順のソート性が必要な場合は、時刻情報を含むUUID v7や、代替としてULIDの採用を検討する価値があります。
一意性だけが必要ならUUID v4が最も簡単で安全です。同じ入力から常に同じIDを再現したい場合はv5、生成順のソート性やDB挿入効率を重視する新規開発ではv7が有力な選択肢です。v1・v3は現在は新規採用が少なくなっています。
余談ですが ― なぜ128ビットも使うのか
UUID（Universally Unique Identifier）は1980年代にApollo Computerが分散システム向けに考案し、後にOSF（Open Software Foundation）がDCE（Distributed Computing Environment）の一部として標準化しました。現在の仕様はIETFのRFC 4122（2005年）、そして2024年に拡張版のRFC 9562が公開されています。
128ビットという長さは一見過剰に思えますが、複数のサーバー・端末が互いに一切通信せずにそれぞれ独立してIDを発行しても、実用上衝突しないことを保証するための設計です。中央のID発行サーバーを立てて連番を管理する方式は、そのサーバーが単一障害点になったり、発行のたびに通信が必要になったりするコストが生じます。UUIDはその調整コストをゼロにする代わりに、十分な長さのランダム性で衝突確率を無視できるレベルまで下げています。
一方でUUID v4はランダムであるがゆえに、データベースのB-Tree系インデックスに挿入する際に挿入位置がバラバラになり、ページ分割が頻発してパフォーマンスが劣化するという弱点があります。この問題に対応するため考案されたのが時刻順にソート可能なUUID v7で、先頭にUnixタイムスタンプを持つことでランダム性を保ちながら挿入局所性を確保しています。