他の誰かが作成したものと衝突せず、聞いたこともないマシン上でも、誰の許可を得ることもなく識別子を作成したいですか？ それこそがUUIDの役割です。これは128ビットの数値で、おなじみの 8-4-4-4-12 のパターンに従って36文字で記述されます。誰がどの値を取得するかを調整する仕組みがなくても、2つのUUIDが同じになることがないように設計されています。この無料ジェネレーターはブラウザ上でUUIDを生成します。「バージョン」でバージョンを選択し、個数 で必要な数を指定して、生成 を押すだけです。ページを開いた初期状態では、ほとんどのプロジェクトで求められる単一の v4 が表示されるため、最初の識別子はワンクリックで手に入ります。
各識別子は Web Crypto API を通じてブラウザによって生成されます。バージョン 4 は、ブラウザが提供している場合は crypto.randomUUID() を、そうでない場合は crypto.getRandomValues() を使用します。つまり、Math.random() のような JavaScript の疑似乱数関数ではなく、暗号論的に強力な乱数ソースを使用しています。バージョン 7 は先頭に 48 ビットのミリ秒単位のタイムスタンプを配置し、次に同一ミリ秒内で増加する 12 ビットのカウンター、そして 62 ビットの乱数を続けます。これは RFC 9562 で説明されているソート可能な手法であり、このカウンターの存在により、1000個のバッチがシャッフルされず順番に出力されるようになっています。バージョン 1 は、タイムスタンプとマルチキャストビットが設定されたランダムなノード識別子を組み合わせたものです。そのため、1990年代の初期の実装のようにネットワークカードのアドレス（MACアドレス）が含まれることはありません。バージョン 3 と 5 は全くランダムではなく、MD5 と SHA-1 をそれぞれ使用して名前空間と名前のハッシュを計算します。このハッシュ処理もデバイス上で行われます。サーバーには何も送信されず、ログも記録されません。一度ページが読み込まれれば、オフラインになっても機能し続けます。
「バージョン」は他のすべての要素を決定するフィールドです。バージョン 4 は 122 ビットの乱数であり、構造を持たないため、デフォルトの選択肢として、単に一意性が求められる場合の正解となります。バージョン 7 は 62 ビットの乱数を維持しつつ先頭に作成時間を配置するため、生成された順にソートすることができます。これは識別子がデータベースのキーになる場合に選ぶべきバージョンです。バージョン 1 はオリジナルの時間ベースのスキームであり、未だにそれを要求するシステムのために残されています。バージョン 3 と 5 は特殊なペアです。これらは決定的（deterministic）であり、同じ入力からは常に同じ識別子が生成されます。これらには2つの追加フィールドが必要です。「名前空間」は、標準空間である DNS、URL、OID、X.500 のいずれか、または独自の「カスタム」を選択し、「名前」には識別される文字列を入力します。v5 に URL 名前空間と https://example.com/a を与えれば、今日でも明日でも、他人のマシン上でも同じ UUID が得られます。このため、v3 または v5 が選択されると 個数 フィールドは非表示になります。決定的な値の1000個のコピーは、単に決定的な値が1000個並ぶだけだからです。それ以外のすべてのバージョンでは、個数 は 1 から 1000 まで指定できます。
4つのスイッチは、基盤となる128ビットを変更することなく、出力の形式のみを変更します。「大文字」は16進数を A–F の大文字で出力し、「ハイフンなし」は一部の列やファイル名で好まれるコンパクトな32文字の形式を提供します。「中括弧」は値を { } で囲み、Windows や .NET の世界で GUID と呼ばれる形式にします。詳細オプション にある urn:uuid: は、これを正式な URN にするためのプレフィックスを追加します。これがオンの間は、「中括弧」と「ハイフンなし」がオフになります。なぜなら、標準規格で許容される URN の形式は厳密に1つだけであり、ハイフン付きの正規（canonical）形式だからです。「コピー形式」は、バッチを取得する際の結合方法を決定します。1行に1つ、カンマ区切り、または各値を引用符で囲んでカンマを付けた形式（コード内の配列に直接貼り付け可能）を選べます。結果の下には、乱数のビット数（v4 は 122、v7 は 62）と、v7 の場合はバッチの最初の識別子にエンコードされたタイムスタンプを報告する行があり、値の内部の時間が暗黙のものではなく可視化されます。すべてコピー と ファイルに保存 の両方が 「コピー形式」を尊重します。履歴 は自分のブラウザ内に最新の10個のバッチを保存します。クリックして復元するか、個別のエントリをコピーまたは削除するか、あるいはすべてをクリアできます。クリア は結果を空にしますが設定はそのまま維持します。識別子が50個を超えると、リストは50行並ぶのではなく、1つのスクロール可能なブロックになります。
このページで最も重要なのは、プライマリキーとしての v4 と v7 の違いであり、これは好みの問題ではありません。データベースのインデックスはソートされた順序を保つツリー構造（B-treeなど）であり、新しいキーがその順序のどこに配置されるかが、挿入にかかるコストを決定します。v4 のキーはランダムであるため、連続した挿入はインデックス内の無関係な箇所に配置されます。その結果、いっぱいになったページが分割され、データベースがメモリに保持しているツリーの部分と、次の挿入で必要となる部分がめったに一致しなくなり、インデックスは指し示す行に見合う以上に大きく断片化した状態になります。一方、v7 のキーは現在のミリ秒から始まるため、連続した挿入はツリーの右端に隣接して配置されます。これは自動インクリメントされる整数が生成するパターンであり、インデックス構造が元々想定して構築されたパターンです。これがすべてのトレードオフです。v7 はシーケンシャルなキーの挿入パフォーマンスをもたらしつつ、そもそも UUID を選んだ理由である「誰でもサーバーに尋ねることなく生成できる」という特性を維持します。その代償として、作成時間が識別子の内部から読み取れるようになります。これが問題になるかどうかはフォーマットの問題ではなく、あなたのデータに関する問題です。
UUID の一意性をチェックするものは何もありません。そのサイズ自体が保証となっています。レジストリも、サーバーへのラウンドトリップも、ルックアップ（照会）も存在しません。ジェネレーターは単に数値を生成して引き渡すだけであり、2つの UUID が衝突しない理由は単純に、2^122（約 5.3×10^36）個の v4 の値が存在するからです。誕生日のパラドックスを用いてこれを正直に評価すると、2つの値が一致する確率が50%になるまでに、約 2.7×10^18 個の識別子が必要になります。これは、毎秒10億個の新しい UUID を86年間生成し続ける計算です。これが何を約束し、何を約束しないのかを正確に理解する価値があります。これは絶対的な保証ではなく統計的な保証であり、基盤となる乱数が本物である場合にのみ成り立ちます。シードの初期化が不適切なジェネレーターや、エントロピープールごとクローンされた仮想マシンは、フォーマット自体では検出できない形でこの保証を破壊します。バージョン 7 はこの問題をさらに絞り込みます。単一のミリ秒内では、カウンターはサイコロを振るのではなくインクリメントされるため、ジェネレーターは全く同じ値を繰り返すことができません。そして独立したジェネレーター間では、62 ビットの乱数がその役割を果たします。
UUID は識別子であり、パスワードではありません。バージョン 4 は予測不可能であるため、パスワードリセットリンク、推測不可能な URL、セッショントークン、API キーなど、秘密として扱いたくなる誘惑に駆られます。予測不可能であることは事実ですが、秘密性とは値がどのように扱われるかの性質であり、識別子は設計上、無頓着に扱われます。これらは URL に含まれ、ブラウザの履歴、サーバーのログ、リファラーヘッダー、分析ツールに残り、チャットメッセージに貼り付けられます。他のバージョンはさらに不適切な候補です。バージョン 1 とバージョン 7 はどちらも作成された瞬間をエンコードしているため、それを保持している人は誰でもそれが作成されたおおよその時期を知ることができ、同時に作成されたすべてのものの周辺を絞り込むことができます。バージョン 3 と 5 は意図的に決定的です。メールアドレスの v5 UUID はハッシュ化された秘密ではなく、同じアドレスを持つ人なら誰でも1秒で計算できる値です。物事に名前を付けるには UUID を使用してください。値が未知のままである必要がある場合は、パスワードジェネレーター、または秘密を扱うために構築されたライブラリからのトークンを使用してください。
なぜこの UUID ジェネレーターを選ぶのか？
- ブラウザのみの生成：識別子はデバイス上で作成され、どこにも送信されません
- Web Crypto API の乱数：Math.random() ではなく暗号論的に安全です
- 5つのバージョンを1か所に：ツールを切り替えることなく、v1、v3、v4、v5、v7 を生成できます
- 真にソートされた v7：RFC 9562 で説明されているように、ミリ秒内にカウンターを持っています
- 決定的な v3 と v5：4つの標準名前空間または独自の名前空間を使用できます
- 一度に最大1000個：50個を超えるとコンパクトなスクロール可能なリストになります
- すべての一般的な形式：ハイフン付き、ハイフンなし、大文字、中括弧付き、または urn:uuid: URN
- コードに直接貼り付け可能：行、カンマ区切り、または引用符で囲んだ値としてコピーできます
- 無制限かつ無料：サインアップ不要、使用制限なし、私たちのサーバーには何も残りません
UUID は、名前が空いていることを確認する前に何かに名前を付ける必要がある場所ならどこにでも登場します。アプリケーションコードは、挿入しようとしている行のためにUUIDを生成します。これにより、オブジェクトはデータベースに到達する前からアイデンティティを持ち、書き込みの実行中であってもクライアントがそれを参照できるようになります。分散システムはこれにさらに依存しています。複数のサービスが1つのテーブルに書き込む場合、オフラインのモバイルクライアントが飛行機内でレコードを作成する場合、すでに処理したメッセージを認識しなければならないキューなど、これらはいずれも共有カウンターの順番を待つことができません。バージョン 5 は、すでに持っているものから導き出される安定した識別子という異なるニーズをカバーします。同じドキュメント、同じ URL、または同じアカウントは常に同じ UUID にマッピングされるため、重複させることなくインポートを2回実行できます。他の場所では、単にシステムが要求するフォーマットとして機能します。ログやトレースを通して関連付けられる相関識別子、1000人のユーザーからのアップロードが1つのバケットに届いたときに衝突しないファイル名、Windows レジストリキー、実際のデータのように見せかける必要があるテスト用のフィクスチャデータなどです。
知っておくべきいくつかの妥当な制限があります。1つのバッチは1つのバージョンです。「バージョン」の値はそのバッチのすべての要素に適用されるため、v4 の実行と v7 の実行は2つの別々のバッチとなります。これはジェネレーターであり、インスペクター（検査ツール）ではありません。UUID を貼り付けてそのバージョンやタイムスタンプを読み取ることは、このページではできません。ファイルに保存 は、CSV や JSON ではなくプレーンテキストファイルを書き出します。バージョン 7 はそれが作成された日時をミリ秒単位で公然と明らかにしますが、これは欠陥ではなく真のトレードオフです。また、バージョン 1 も同様に時間を漏らします。これがデータにとって問題になる場合、誰にも何も伝えないバージョン 4 を使用してください。標準規格にある2つの特別な値はバージョンではないため、「バージョン」のオプションにはありませんが、ここからコピーできます。nil UUID の 00000000-0000-0000-0000-000000000000 と、max UUID の ffffffff-ffff-ffff-ffff-ffffffffffff です。このページのすべては、2024年に RFC 4122 に代わる仕様となった RFC 9562 に準拠しているため、出力されたものは UUID を処理するあらゆるライブラリ、データベース、または API で受け入れられます。これらの制限の中で、保証は強力です。すべての識別子は標準に従って、暗号論的に安全な乱数から、あなた自身のマシン上で構築され、他の誰の目にも触れることはありません。