UUIDを生成
安心・安全：ファイルは保存されません
どのバージョン？
ここにUUID（0個）が表示されます。
使い方
バージョンを選ぶ
推測されてはいけないものにはv4。データベースのキーにはv7。違いは決め付けずにページ上で説明しています。
個数を選ぶ
1個から一度に1万個まで。大文字、波かっこ付き、ハイフンなし、コードにそのまま使える引用符付きリストなどの書式も選べます。
コピー
すべてコピーするか、テキストファイルとしてダウンロードします。
バージョン4か7か、そしてデータベースでそれが重要な理由
UUIDは128ビットの値で、おなじみの8-4-4-4-12の区切りで32桁の16進数として書かれます。そのうち6ビットはバージョンとバリアントを示すのに使われるため、バージョン4では122ビットがランダムです。1秒に10億個を100年間生成し続けても、同じものが2回出る可能性は圧倒的に低いほどの量です。それが魅力のすべてです。一度も通信したことのない2つのシステムが、それぞれ識別子を作り出しても、衝突しないと安心して前提にできます。
それが成り立つには本物のランダムさが必要で、ここでは普通の乱数生成器ではなく暗号学的乱数源から得ています。この違いが重要になるのは、識別子がパスワード再設定リンクや推測できない共有URLのように、権限を与えるトークンとして使われる場合です。予測可能な生成器だと、過去の値から次の値を割り出せてしまいます。暗号学的乱数源なら、予測できるものは何もありません。
バージョン7が存在するのは、バージョン4がデータベースの主キーとして振る舞いが悪いからです。 先頭に48ビットのミリ秒タイムスタンプを置き、残りをランダムで埋めるので、続けて生成したUUIDは作成順に並びます。見た目の問題に聞こえますが、そうではありません。ランダムなキーは挿入をインデックス全体に散らばらせるため、書き込みのたびに異なるページに触れ、キャッシュが効かなくなります。一方、時系列順のキーは一方の端に追加されていきます。大きなテーブルでは挿入のスループットに大きな差が出ます。これがv7が標準化された理由です。
トレードオフは実在し、比較検討する価値があります。バージョン7のUUIDは、見た人に作成されたおおよその時刻をミリ秒単位で教えてしまいます。また、連続したUUIDからは、レコードを作成するペースが分かります。内部のキーなら問題ありません。注文番号、文書へのリンク、ユーザーIDのようにURLに出る識別子では、バージョン4にはない小さな情報漏えいになります。両方が重要なら、主キーにはv7、公開するものにはv4を使ってください。
ほかの目的には
UUIDは使う場所で生成してください。どのデータベースや言語にも組み込まれています。PostgreSQLなら gen_random_uuid()、MySQLなら UUID()、JavaScriptなら crypto.randomUUID()、Pythonなら uuid.uuid4() です。ブラウザでまとめて生成してコードに貼り付けるのは、フィクスチャやテストなら問題ありませんが、実際に動くものには不適切です。
v7を選ぶ理由が並べ替えられるキーなら、知っておく価値のある代替手段があります。ULID は同じ考え方を、より短く大文字小文字を区別しない26文字で表します。Snowflake の識別子は64ビットに収まるため、UUIDの128ビットに比べてインデックスのサイズが半分になります。そして多くのデータベースでは、普通の自動採番の整数が今でもどれよりも速く小さいのです。UUIDがそのコストに見合うのは、複数の場所で同時に識別子を作る必要がある場合で、そうでなければ見合いません。
よくある質問
v4とv7、どちらを使えばよいですか？
データベースの主キーならv7。パスワード再設定リンク、招待コード、セッションIDのように、推測できてはいけないものならv4。判断はそれだけです。ほとんどの生成ツールがv4しか提供していないため、多くの人は選択肢があったことすら知りません。
なぜv4はデータベースのキーに向かないのですか？
完全にランダムなのに、データベースのインデックスは並べ替えられているからです。新しいランダムなキーはインデックスのばらばらな位置に入るため、挿入のたびに異なるページに触れ、キャッシュが効かなくなり、インデックスは断片化して膨らんでいきます。大規模で書き込みの多いテーブルでは、時間とともに悪化する目に見える速度低下になります。理論上の懸念ではありません。PostgresとMySQLのドキュメントが今ではどちらもこの問題を取り上げているのは、そのためです。
UUID v7とは何ですか？
先頭の48ビットがミリ秒単位のタイムスタンプで、その後にランダムな値が続くUUIDです。グローバルに一意で128ビットであることは変わりませんが、時刻が先頭にあるため、v7のUUIDは作成された順に並びます。新しいキーはインデックス全体に散らばらず末尾に追加されていきます。まさに自動採番の整数と同じ振る舞いで、しかもUUIDの一意性を備えています。2024年にRFC 9562で標準化され、新しいテーブルには現在これが推奨されています。
ここで生成したv7のUUIDは本当に順番に並びますか？
はい、同じミリ秒の中でも並びます。ほとんどの実装が間違えるのがこの部分です。タイムスタンプはミリ秒単位の精度しかないため、ループで1000個のIDを生成すると1ミリ秒以内に終わります。下位ビットが純粋にランダムだと、その1000個は作成された順には「並びません」。この生成ツールはRFC 9562に記載されている単調増加カウンターを使うため、一括生成したものは毎回必ず厳密に昇順になります。1000個生成して並べ替えてみてください。作成された順に戻ってきます。
v7のUUIDを公開しても安全ですか？
1点に注意すれば大丈夫です。v7は仕様上、作成された時刻をミリ秒単位で明らかにします。データベースのキーなら通常は無害で、むしろ便利なこともあります。しかし、作成時刻そのものが機密である場合や、識別子を推測できないものにする必要がある場合は、v4を使ってください。v7にも74ビットのランダムな部分があり、これは十分な量ですが、タイムスタンプはIDを持っている人なら誰でもそのまま読み取れます。
セキュリティ用途に十分なランダムさですか？
はい。ランダムさはブラウザの暗号学的に安全な生成器である `crypto.getRandomValues` から得ており、`Math.random` は決して使いません。この違いは実際の脆弱性を生んできました。`Math.random` は高速ですが予測可能で、それをもとに作られたセッショントークンが実際に推測された例があります。v4のUUIDには122ビットのランダムな部分があり、衝突を実用上心配する必要はありません。
UUIDはお使いの端末で生成されますか？
はい、すべて端末内で生成されます。識別子の場合、これは重要です。他人のサーバーから取得したUUIDは、他人がすでに見たUUIDです。秘密の値を生成しているなら、それでは意味がありません。ここで生成したUUIDがブラウザの外に出ることはありません。ページを読み込んだ後にWi-Fiをオフにしても、まったく同じように動作します。私たちの言葉をうのみにせず、プライバシーに関する主張を自分で確かめる最も簡単な方法です。
Nil UUIDとは何ですか？
すべてゼロのUUIDです：00000000-0000-0000-0000-000000000000。nullが使えない場面で「なし」や「未設定」を表すために予約された、有効なUUIDです。その反対の、すべてfのMax UUIDは、並べ替えの番兵値として使われることがあります。まれに必要になり、正確に入力するのが面倒なので、どちらもここで用意しています。
ご注意： バージョン4のUUIDは、Math.randomではなくブラウザの暗号学的乱数源から生成されるため、識別子として安全に使えます。バージョン7はミリ秒単位のタイムスタンプを含んでおり、それがきれいに並ぶ理由ですが、同時に、作成されたおおよその時刻が漏れることも意味します。それが問題になる場面ではv7を使わないでください。
このツールをあなたのサイトに設置
ブログ、授業のページ、ヘルプ記事などに無料で設置できます。コードを1つ貼り付けるだけで、訪問者がそのページ上でツールを使えるようになります。