DEV

UUID ジェネレーター — ブラウザでランダムな UUID v4 識別子を生成

UUID v4、v1、v7 識別子を生成します。暗号学的にランダム（v4）、ワンクリックコピー、バルク生成に対応。すべてブラウザ内で完結します。

● ローカル動作 · タブ内で生成ページ読み込み以降のツールによる通信：0件

こんなツールも

行をソート MD5 ハッシュ UUID ジェネレーター JSON → CSV Base64 エンコード PDF 分割 HAR → cURL TOML ツール .env ヘルパー MsgPack インスペクター PDF 圧縮 PDF → EPUB

ジェネレーターを開く

UUID（Universally Unique Identifier）は 8-4-4-4-12 の 16 進数フォーマットで、ソフトウェアにおいて最もよく知られたパターンのひとつです。すべてのデータベーステーブルに UUID カラムがあり、すべての API レスポンスのどこかに UUID が含まれ、すべての分散システムは協調なしで独立に生成できる識別子を必要とします。この規格は何度か改訂されており、2005 年の RFC 4122、2024 年の RFC 9562 があり、現在推奨されている v7 は、ランダムな UUID が B-tree インデックスを断片化させるという長年の課題を解決しています。新しい挿入がインデックスページのあちこちにランダムに散らばってしまい、末尾に追記されないという問題です。

本ジェネレーターのデフォルトは v4 です。v4 が今でも実運用上最も一般的であるためですが、v7 が新たな標準となりつつあります。この差が最も重要になるのは、UUID が主キーとして使用される場合です。v4 UUID をクラスタ化された B-tree インデックス（MySQL InnoDB、UUID を主キーにした PostgreSQL など）に挿入すると、次の挿入がランダムな位置に着地するため、ページ分割とインデックス断片化が発生します。v7 UUID はミリ秒精度のタイムスタンプを上位ビットに配置するため、時刻順に到着した挿入は同じインデックスページへ追記されます。これはオートインクリメント整数と同じ利点であり、中央集権的なシーケンスジェネレーターによる調整コストを伴いません。作成時刻でソートやインデックス化を行う必要がない場合は、v4 のほうがシンプルで効果も変わりません。

最後に引き継ぎ事項をまとめます。既存の UUID を調査したい場合は、当サイトの UUID デコーダーがバージョン、バariant、埋め込まれたタイムスタンプを抽出します。UUID を JWT の jti クレームとして入れる場合は、JWT デコーダーでクレームのフォーマットを検証できます。決定論的な UUID（同じ入力から常に同じ UUID が生成されるもの）が必要な場合は、SHA-1 ハッシュを用いる v5 が必要になりますが、これはブラウザでは実現できません。そのようなケースでは uuid npm パッケージ、または Python の uuid.uuid5() を使用してください。

使い方

UUID バージョンを選択する
デフォルトは v4（ランダム）で、データベースの主キーや API 識別子として最も一般的に使われています。タイムスタンプと MAC アドレスを組み合わせた識別子が必要な場合は v1、B-tree インデックスで自然な順序になる時間ソート可能な識別子が必要な場合は v7 へ切り替えてください。
必要な数だけ生成する
「Generate」をクリックして 1 件ずつ生成するか、バルク件数（最大 1000）を指定してバッチ生成できます。v4 UUID はいずれも `crypto.getRandomValues` による暗号学的な乱数を使用します。リストは改行区切りのテキストとしてコピーされます。
クリップボードへコピーする
生成された UUID をクリックすると個別にコピーでき、「Copy All」でリスト全体をコピーできます。ハイフン付きの標準 36 文字フォーマットです：`xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx`。

よくある質問

データベースの主キーにはどの UUID バージョンを使うべきですか？

v7（時間順でソート可能）がデータベースの主キーに最適な選択肢です。タイムスタンプの先頭ビットにより、新しい行は B-tree インデックスの末尾へ追記されるため、v4 で発生するページ分割を避けられます。インデックスを作成しない識別子やキーバリュー型のデータベースでは v4 でも問題ありません。MAC アドレスの露出によるプライバシー懸念から、v1 は現在では適切な選択肢とは言えません。

生成される UUID は暗号学的にランダムですか？

v4 UUID は `crypto.getRandomValues()` を使用しており、これはオペレーティングシステムのエントロピーソース（Linux では `/dev/urandom`、macOS では `SecRandomCopyBytes`、Windows では `BCryptGenRandom`）から取得します。TLS、SSH 鍵生成、セッショントークン生成と同じソースです。

衝突が発生する可能性が出てくるのは何件くらい生成したときですか？

v4 の場合、単一の衝突が 50% の確率で発生するまでの件数はおよそ 2.71 × 10^18 です。1 秒あたり 10 億個の UUID を 85 年間生成し続けて、ようやく衝突が 50% の確率で 1 回起こる程度です。現実的には制限要因は UUID 空間そのものではなく、エントロピーソースの品質です。

v1 UUID にカスタムなノードやネームスペースを指定できますか？

v1 UUID にはノード ID が埋め込まれます（従来は MAC アドレス、現在はプライバシー保護のためランダム化されています）。本ジェネレーターはデフォルトで 48 ビット長のランダム値を使用します。一部の v1 実装ではカスタムなノードを指定できますが、ブラウザツールはプライバシーを最優先し、ランダムなノードのみを使用します。

制限事項

v3・v5 の生成には非対応v3（MD5 ハッシュ）および v5（SHA-1 ハッシュ）の UUID には、ネームスペース用 UUID と名前文字列が必要です。本ジェネレーターはユースケース（コンテンツアドレッシング用の決定論的 UUID）が限定的で、かつハッシュ処理は外部でも行えるため、ネームスペースハッシュを実装していません。
v1 のクロックシーケンスは永続化されないブラウザはセッションをまたいで状態を保持できないため、v1 のクロックシーケンスはページ更新時にリセットされます。クロックシーケンスの単調性が重要な本番環境の v1 UUID では、サーバーサイドの UUID ライブラリを使用してください。
UUID-as-base64 や短縮エンコード出力には非対応出力はハイフン付き 16 進数の標準フォーマットです。Base64 や Base62 などへのコンパクトなエンコードが必要な場合は、UUID のバイト列を手動でエンコードするか、Base64 エンコードツールを通して処理してください。

プラットフォーム別の注意点

macOS: Terminal の `uuidgen` コマンドはネイティブに v4 UUID を生成できます。本ブラウザツールは v1 と v7 の生成、テストデータベースへのシード投入や fixture ファイル生成向けのバルク出力を追加します。
Linux: `uuidgen` コマンド（util-linux パッケージ）は v4 UUID を生成できます。v7 生成用の `uuid -v7` フラグは新しいバージョンで利用可能です。シェルループを書かずにバルク生成したい場合は、本ブラウザツールが適しています。
Web: 完全にクライアントサイドで動作します。生成された UUID がブラウザの外へ送信されることはありません。開発時の識別子生成、テストデータベースへのシード投入、fixture ファイルの作成などにお使いください。