UUID ジェネレーター
開発crypto.randomUUID で暗号学的にランダムな UUID(RFC 4122 v4)を生成します。
このページの内容
UUID とは?#
UUID(Universally Unique Identifier、汎用一意識別子。Microsoft システムでは GUID とも呼ばれます)は、128 ビットの識別子で、32 個の 16 進数字が 8-4-4-4-12 にグループ化されたものとして描画されます(例: c9bf1d4d-7d4f-4b3a-8b2c-1e5f6a7b8c9d)。アイデアは単純ですが強力です。中央の権威も、マシン間の調整もなしにオンデマンドで識別子を生成し、それでも 2 つが衝突する確率を実質ゼロにできます。この性質こそが、UUID を分散データベースのデフォルト主キー戦略、ほぼすべての JSON API リソースの id フィールド、マイクロサービスをまたいでログ行を結び付ける相関 ID、アップロードされた blob のファイル名にしているものです。
本ページは RFC 4122 version 4 UUID — 乱数ビットから構築されるバリアント — を生成します。v4 は現代のほぼすべてのケースで欲しいものです。MAC アドレスを運ばず(v1 と違い)、名前空間の階層を埋め込まず(v3/v5 と違い)、一意性のために暗号論的乱数だけに依存します。1 個の UUID、あるいは最大 10,000 個のバッチを、小文字または大文字で、完全にブラウザ内で生成できます。
32 個の 16 進数字のうち 2 つは実は乱数ではありません — それらは UUID 自身の型を宣言します。位置 14(3 つ目のグループの最初の文字)のバージョンニブルは常に 4、位置 19(4 つ目のグループの最初の文字)のバリアントニブルは常に 8、9、a、b です。だからこのページで見るすべての値が xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx と読めます。この 2 つの固定位置は自己記述的な指紋も兼ねます。この形状に一致する文字列は v4 UUID であり、1 行の正規表現で数百万件を検証できます。
使い方#
- 上部の件数数値フィールドに欲しい UUID 数を設定します — 1 〜 10,000 の範囲で。フィールドはこの範囲にクランプされます。
- すべて大文字の出力が必要なら大文字にチェックを入れます(一部のレガシーシステムや Microsoft GUID 規約は
C9BF1D4D-…を好みます)。最近のほとんどのスタックが使う小文字デフォルトのままならチェックを外します。 - 生成をクリックします。等幅の出力領域に値が 1 行 1 つで現れます。
- コピーをクリックしてバッチ全体をクリップボードに取得し、SQL の
INSERT、CSV、テストフィクスチャ、シードスクリプトに貼り付けられます。 - 新しいバッチが必要なときはいつでも生成をクリックしてください — 毎クリックで新しい乱数ビットを引き、これまで存在したことのない値を生成します。
主な機能#
- 本物の暗号論的乱数。 セキュアコンテキストではブラウザの
crypto.randomUUID()を使い、バージョン/バリアントビットに棄却サンプリングを適用するcrypto.getRandomValuesフォールバックを備えます — 識別子には不適切なMath.random()ではありません。 - バッチ生成。 1 クリックで最大 10,000 の UUID を 1 行 1 つで生成できるため、自分でスクリプトを書かずにデータベースやフィクスチャファイルをシードできます。
- 小文字または大文字。 1 つの切り替えで両方の規約をカバーします。
- RFC 4122 v4 準拠。 バージョンニブルは常に
4、バリアントニブルは常に8/9/a/bであるため、すべての値が標準の v4 正規表現に対して妥当です。 - 100% クライアントサイド。 バックエンドもテレメトリもありません。ここで生成した UUID はどこにも記録されず — 現れた瞬間からあなたのものです。
実例#
件数をデフォルトの 5 のまま大文字のチェックを外して生成をクリックすると、次のような 5 行が得られます(実際の値は異なります — 乱数のため)。
7f3a9c2e-1b4d-4e8f-a6c3-9d2b8e1f0a47
2c8d4f1a-9e3b-47a2-8c6d-1f5e9a0b3c28
a1b2c3d4-e5f6-4789-abcd-ef0123456789
9e8d7c6b-5a4f-3210-ba98-76543210fedc
4f3e2d1c-0b9a-8765-4321-fedcba987654
任意の行の 3 つ目のグループを詳しく見てください。常に 4 で始まります。4 つ目のグループを見てください。常に 8、9、a、b で始まります。これらの 2 文字は乱数ではなく、バージョンとバリアントのマーカーであり、1 行のバリデータが文字列を正真正銘の v4 UUID と確認できる理由です。
大文字にチェックを入れて再度生成すると、同じ形状が大文字で出ます。例: 7F3A9C2E-1B4D-4E8F-A6C3-9D2B8E1F0A47 — 同じビットで、大文字 GUID を期待するシステム向けに描画し直しただけです。
よくある質問#
v4 UUID は本当にどれくらい一意ですか? 重複することはありますか?#
数はすぐに馬鹿げた値になります。単一の v4 UUID は 122 ビットの実際の乱数性を持ちます(128 から 4 バージョンビットと 2 バリアントビットを引いたもの)。50% の衝突確率を得るためだけでも約 2.71 × 10^36 個の UUID を生成する必要があります — それは宇宙の年齢より長く、1 秒間に 100 億×100 億×100 億個を生成し続けることに相当します。現実的なデータベースやシステムでは、衝突を不可能として扱い、チェックする必要はありません。
これらの UUID をデータベースの主キーに使っても安全ですか?#
はい — v4 は調整が不要なことから、その目的に最もよく選ばれます。唯一の注意はインデックスの断片化です。純粋にランダムなキーは B ツリー全体に散らばるため、非常に書き込みの多い PostgreSQL や MySQL のテーブルでは UUIDv7(時刻順)バリアントが好まれることがあります。アプリケーションレベルのリソース ID、相関 ID、ほとんどのテーブルでは、プレーンな v4 で十分です。
なぜ Math.random() で UUID を作るのではダメなのですか?#
Math.random() は暗号論的に堅牢ではないためです — 出力は、数個の ID を観察した攻撃者が他を推測できるほど予測可能になり得ます。本ツールは意図的に crypto.randomUUID()(と、バージョン/バリアントを正しく処理する crypto.getRandomValues フォールバック)を使い、OS の CSPRNG から引き出します。ユーザー、セッション、リソースを識別するものでは、その区別が重要です。
ここで version 1、version 5、名前付き UUID を生成できますか?#
いいえ — 本ページは意図的に v4 専用です。v4 は実用ケースの圧倒的多数をカバーし、乱数源以外の入力を必要としないためです。名前ベースの v5 UUID(名前と名前空間から決定論的)が必要な場合は、それは別の計算であり、アプリケーションコードか専用ツールに属します。