UUID とは何ですか？
UUID(汎用一意識別子)は 550e8400-e29b-41d4-a716-446655440000 のような 36 文字の文字列として表現される 128 ビットの値です。書式とバージョンの意味は、v1〜v5 については RFC 4122 が、新しい v6・v7・v8 については RFC 9562 が定義しています。このツールは v4(完全ランダム)、v1(タイムスタンプ + ランダムなノード ID)、v7(Unix ミリ秒タイムスタンプの接頭部 + ランダム接尾部で、生成時刻順にソート可能)をすべてブラウザ上で、プラットフォームの Web Crypto API を用いて生成します。サーバーへデータは一切送信されません。
UUID 生成はどのように機能しますか？
各バージョンは決定性、ソート可能性、エントロピーのバランスの取り方が異なります。ツールは選択に応じて適切なアルゴリズムを選びます:
- v4(ランダム)はブラウザの
crypto.randomUUID()を呼び出し、122 ビットの暗号学的乱数を返します。6 ビットの固定ビット(バージョン0100とバリアント10)は所定の位置に設定されます。衝突は天文学的に起こりにくく、50% の確率で 1 件の重複に当たるには約 2.71 × 10^18 個の v4 UUID を生成する必要があります。 - v1(タイムスタンプ + ノード)は、60 ビットのグレゴリオ暦タイムスタンプ(1582-10-15 を起点とする 100 ナノ秒刻み)を
time_low/time_mid/time_hi_and_versionに詰め、バージョンニブルを0001に設定し、バリアントビット付きの 14 ビットクロックシーケンスを選び、マルチキャストビットを強制的に立てた 48 ビットのランダムノード ID を使用します(RFC 4122 §4.5 はハードウェア MAC が利用できない場合のランダムノード ID を明示的に許可しており、マルチキャストビットがそれを非 MAC として印付けます)。 - v7(ソート可能なタイムスタンプ)は、RFC 9562 §5.7 に従って、48 ビットのビッグエンディアン Unix ミリ秒タイムスタンプ、続いて 4 ビットのバージョン
0111、12 ビットの乱数、2 ビットのバリアント10、さらに 62 ビットの乱数の順に配置します。タイムスタンプが上位ビットに置かれるため、v7 UUID は生成順に辞書順でソートされます — 他の UUID バージョンでは追加のエンコードなしには得られない性質です。 - すべての乱数性はブラウザの暗号学的に安全な RNG である
crypto.getRandomValues()から得られます。v1 と v7 はいずれも同一クロックティック内での単調性ガードを備えており、同じティック内で連続して呼び出された 2 回目の値が 1 回目より上位にソートされるよう保証します — ミリ秒クロックを追い越す大量生成にとって重要です。 - 生成後にはフォーマットパイプラインが走ります。ハイフンを取り除く、大文字に変える、値を波括弧で囲む(
{…}— Microsoft の GUID 慣習)、生の 16 バイトを base64(22 文字、padding なし)として表示する、といった選択が可能です。base64 はそれ自体が独自の表現なので、base64 モードは他のフォーマットオプションを上書きします。
この UUID 生成器を使う理由は何ですか？
- ブラウザの外に何も出ません。Web Crypto API はローカルで動作し、初回ドキュメント読み込み以降、ページはネットワークリクエストを一切行いません。DevTools を開いて「生成」をクリックしても、Network パネルは静かなままです。
- RFC 準拠の出力。v4 は RFC 4122 §4.4、v1 は §4.2 と §4.5、v7 は RFC 9562 §5.7 に従います。バージョンニブルとバリアントビットは規格が指定する位置に置かれており、すべての UUID は対応するバージョンの標準正規表現を通過します。
- データベースキーに適したソート可能な v7。Postgres・MySQL・SQL Server で v7 UUID をクラスタード主キーとして使うと、インデックスへの挿入は追記のみとなり、ページ分割やランダム I/O が発生しないままグローバル一意性を保てます。v4 はビットがランダムなのでこれができません。
- レート制限のない大量生成。1 個、10 個、100 個、1,000 個の UUID を一度に生成できます。クォータも会員登録もありません — ツールはあなたのタブで動くため、上限はベンダー API のプランではなく、あなたの CPU です。
UUID の一般的な用途は何ですか？
UUID は中央権限と調整せずに世界的に一意な識別子が必要な場面で広く使われます:
- データベースの主キー。オートインクリメントの整数は行数を漏らし、シャーディングを壊します。UUID はシャード間で安定し、地域間でのマージも安全で、(v7 なら)ページ分割なしで B-tree の挿入をホット領域に保ちます。典型的なアプリは UUID をクライアント側で生成し、INSERT に乗せて送るので、キーのためにサーバーへの往復は不要です。
- リクエスト相関 ID。HTTP ミドルウェアは到着するリクエストごとに v4 UUID を付け、各スパンでログに残し、(多くは
X-Request-Idヘッダとして)下流に伝播します。顧客がバグを報告したら、サポートエンジニアは ID を貼り付けるだけで、サービスと時間帯をまたいだリクエストのトレースが一意に浮かび上がります。 - 冪等性キー。決済 API(Stripe、Adyen、Square)は
Idempotency-Keyヘッダを受け付け、再試行されたリクエストでも顧客が二重請求されないようにします。クライアントで生成された UUID は論理的操作ごとにキーが一意であることを保証し、これらの API が要求する契約そのものです。
UUID の例はどのようなものですか？
Node.js やモダンブラウザでは、crypto.randomUUID() という一行で新しい v4 UUID — 例えば 3f50b5a8-2c54-4b9c-9c1f-3e5c7e2b8d12 — が返ります。これをリクエスト ID や冪等性キーに使えます。UUID をクラスタード主キーになるデータベースのカラムに入れる場合は、代わりに v7 を生成します。1 ミリ秒間隔で作られた 2 つの v7 値、例えば 0190a3b0-7d4f-7c9e-8b21-a4d6f0bd9c11 と 0190a3b0-7d50-7f15-9c4e-72b3e0c1d8a4 は、生成順に辞書順でソートされます。Postgres の uuid 型は両バージョンを同じように保存しますが、差はインデックス書き込み時に現れ、v7 は B-tree の右端に追記される一方、v4 の挿入は散らばってランダム I/O を強います。
この UUID ジェネレーターは、ただ一つの仕事をします — クリックを 1 つあるいは複数の RFC 準拠の識別子に変え、必要な形式で出力し、リクエストをどのサーバーにも送りません。バージョンを選び、数を選び、形式を選んだら — 生成して、コピーして、次に進んでください。