UUID生成ツール

UUID生成の使い方

1. 1

   バージョンを選ぶ

   完全ランダムなv4か、先頭に生成時刻が入って時刻順に並ぶv7かを選びます。用途が決まっていなければv4で問題ありません。データベースの主キーとして大量に発行する場合はv7を検討してください。

2. 2

   件数と表示形式を選ぶ

   生成件数（1〜100）、大文字/小文字、ハイフンの有無を指定します。大文字にしてもハイフンを外しても、UUIDとしては同じ値を表示し方だけ変えたものです。

3. 3

   生成してコピーする

   「生成する」を押すと結果が一覧表示されます。「全件コピー」で改行区切りのままクリップボードにコピーできるので、そのまま表計算やSQLへ貼り付けられます。

仕組みと考え方

UUID（Universally Unique Identifier）は128bitの数値で、データベースのレコードやAPIのリソースを一意に識別するために使われます。本ツールは Web Crypto API の crypto.getRandomValues() で暗号学的に安全な乱数を生成し、その乱数を使ってUUIDを組み立てています。処理はすべてブラウザ内で完結し、生成した値が当サイトのサーバーへ送信されることはありません。

v4とv7の違いは、128bitのうち「どこを乱数にするか」です。v4はバージョン4bitとvariant2bitを除いた122bitすべてが乱数で、生成順や生成時刻を値から読み取ることはできません。v7は先頭48bitがミリ秒単位のUNIXタイムスタンプで、残りの74bitが乱数です。つまりv7は前半が時計、後半がくじ引きという構造で、生成した順に文字列としても数値としても昇順に並びます。

重複（衝突）の確率は、この乱数のbit数から見積もれます。v4の122bitは約5.3×10^36通りあり、誕生日問題の近似で計算すると、103兆個（1.03×10^14）を生成したときに1組でも重複が出る確率はおよそ10億分の1です。重複の確率が50%に達するにはおよそ2.3×10^18個（2の61乗）が必要で、これは毎秒10億個を生成し続けても70年以上かかる量です。実務で問題になるのは衝突そのものより、乱数の質が低い実装（Math.random()など）を使ってしまうことのほうです。v7は同一ミリ秒内では74bit＝約1.9×10^22通りの乱数だけが効きますが、1ミリ秒に1,000万個を生成しても重複の確率はおよそ4億分の1で、ミリ秒が変われば時刻部分が異なるため衝突しません。

ブラウザには crypto.randomUUID() という標準機能があり、こちらもv4を1件返します。本ツールとの違いは3点です。①randomUUID() が生成できるのはv4だけで、v7には対応していません。②randomUUID() はセキュアコンテキスト（httpsまたはlocalhost）でしか使えず、社内のhttpページでは undefined になります。③一度に1件しか返らないため、100件まとめて欲しい場合は自分で繰り返す必要があります。乱数の出どころはどちらも同じ crypto の疑似乱数生成器なので、値の品質に差はありません。本ツールは crypto.getRandomValues() で取得したバイト列に自分でバージョンとvariantのbitを書き込むことで、v4とv7を同じ経路で扱えるようにしています。

主キーとして使うときは、保存形式と挿入順序の2点に注意してください。UUIDをハイフン付きの文字列（CHAR(36)）で保存すると1件あたり36バイトを消費し、その値がすべての二次インデックスにもコピーされます。PostgreSQLのuuid型やMySQLのBINARY(16)なら16バイトで済むため、行数が増えるほど差が出ます。挿入順序については、v4は値がランダムなためB-treeインデックスの挿入位置が毎回散らばり、ページ分割とキャッシュミスが増えます。v7は末尾に追記されるかたちになるので、大量に挿入するテーブルではv7のほうが安定します。

どちらのバージョンも、決まった位置のbitに「バージョン番号」（v4なら0100、v7なら0111）と「variant」（10）を書き込むことで、見た目（8-4-4-4-12のハイフン区切り）だけでなく中身からもUUIDの種類を判別できるようになっています。本ツールが生成する値は、この位置のbitが正しく設定されていること、およびv7の先頭48bitが与えた時刻と一致することを自動テストで検証しています。

使いどころ・注意点

• データベースの主キーとして使うなら、挿入順に値が並ぶv7の方がインデックスへの負荷が小さくなりやすい。
• 外部に公開するID（URLに含める識別子など）としては、生成時刻を推測されたくない場合はv4を選ぶ。v7は先頭48bitからミリ秒単位の生成時刻が復元できるため、アカウント作成日時などが読み取れてしまう。
• 主キーをUUIDにすると、その値を参照する子テーブルの外部キーにも同じ長さが伝播する。テーブル1つの都合ではなくスキーマ全体で保存形式（16バイトか36文字か）を決める。
• UUIDは推測されにくいが、認証の代わりにはならない。「URLを知っている人だけが見られる」設計にする場合は、それが実質的に無期限のパスワードになることを理解したうえで使う。
• ハイフンを含めない形式は、環境変数名やファイル名の一部として使いたいときに便利。ハイフンの有無・大文字小文字を変えても値は同じなので、システム内では表記を1つに統一しておく。
• アプリのコード内で1件だけ必要なら crypto.randomUUID() で足りる。v7が必要な場合と、httpsでない環境で動かす場合だけ別の実装を検討する。
• 生成した値は端末内で作られるだけで当サイトには記録されないため、後から同じ値を再表示することはできない。必要な値は都度保存しておく。

よくある質問