無料UUIDジェネレーター

ランダムなUUID v4値を瞬時に生成します。

データはデバイスから送信されません

クイック生成

-

一括生成

UUIDについて

UUID（Universally Unique Identifier）は、空間と時間を超えて一意になるように設計された128-bit識別子です。最も一般的なバージョンであるUUID v4は、ランダムまたは擬似ランダム数を使用して生成されます。形式は8-4-4-4-12の16進数文字で、例えば550e8400-e29b-41d4-a716-446655440000のようになります。

40 年の歴史、Apollo から RFC 9562 まで

UUID 概念は1980年代中盤の Apollo Network Computing System(NCS)で生まれました、Apollo Computer の Paul Leach と Rich Salz によって中央登録なしで分散コンピューティングをサポートするために設計されました。フォーマットは Open Software Foundation Distributed Computing Environment(OSF DCE)に1989年に採用され、1995 年に ITU-T X.667 / ISO/IEC 9834-8 として国際的に標準化されました。IETF は 2005 年 7 月の RFC 4122(Leach、Mealling、Salz)に仕様を取り入れました、それは20 年間標準的なリファレンスになりました。RFC 4122 は 2024 年 5 月の RFC 9562 によって更新され、それはすべての元のバージョン(v1 から v5)を保持し、3 つの新しいバージョン(v6、v7、v8)を追加し、特別な定数「Nil UUID」(すべてゼロ)と「Max UUID」(すべて 1)を正式に定義しました。バージョン系図は重要です、各バージョンが異なる特性を交換するからです:時間ベース(ソート可能、漏洩)、名前ベース(入力から決定論的)、ランダム(普遍的、不透明)、カスタム(必要なもの)。新しいアプリケーションのための現代のベストプラクティスは主キーのために v4(ランダム)から v7(タイムスタンプ + ランダム)に移行しました、ソート可能性が望ましくない不透明な識別子のためには v4 が依然として正しい答えのままです。

8 つのバージョン、プレーンな日本語で

なぜ v7 がデータベースキーのために v4 より好まれるか

ランダム主キー(UUID v4)は B-tree や類似のインデックスで主キーで行を順序付けるデータベースで十分に文書化されたパフォーマンスコストを持ちます。各新しい挿入はインデックス内のランダムな位置に着地し、インデックスページをフラグメント化、ディスク書き込み増幅を増やし、最近挿入された行が一緒にクラスタリングされる代わりに多くのページに散らばるのでページキャッシュを破壊します。シーケンシャルキー(自動インクリメント整数、ULID、UUID v7)はすべてインデックスの右端に挿入され、ワーキングセットを小さく書き込み増幅を最小限に保ちます。「ランダムキーアンチパターン」批判は NEWID 対 NEWSEQUENTIALID 周りの初期 SQL Server ドキュメントにさかのぼり、Postgres コミュニティによって v4 vs v7 のために再表現されました。トレードオフ:v7 は各行の作成時間を漏らします、それは特定のアプリケーションでプライバシーまたは情報漏洩懸念になる可能性があります(例えばその UUID を読むことでアカウントがいつ作成されたかを伝えられる)。ほとんどのアプリケーションには、パフォーマンス利益がタイムスタンプ漏洩を上回ります、高プライバシーアプリケーションには、v4 が依然として正しい答えのままです。

衝突確率、誕生日パラドックスの数学

UUID v4 は 122 ビットのランダム性を持ち、約 5.3 × 1036 可能な値を与えます。誕生日パラドックスはあらゆる衝突の 50 % チャンスのために名前空間サイズの平方根が必要だと言います、約 2.71 × 1018 UUID。人間の言葉に翻訳すると:毎秒 10 億の UUID を継続的に生成すると、単一の衝突の 50 % チャンスを得るのに約 86 年かかります。普通のアプリケーションスケール生成率(1 日に何千または何百万)には、実用的な衝突リスクはゼロです。実際のシステムでの「重複 UUID」の最も可能性のある原因は、CSPRNG ではなく Math.random() を使用するバグのある生成器、起動時にエントロピーが不十分な生成器、または同じシードで 2 つの生成器を偶然シードするプロセスです、基礎の数学ではありません。この生成器はブラウザの crypto.randomUUID()(利用可能な場合)または crypto.getRandomValues() を使用します、両方とも OS の CSPRNG(Linux getrandom()、Windows BCryptGenRandom、macOS SecRandomCopyBytes)から引き出します、TLS セッションキーに使用されるのと同じエントロピーソース。

ブラウザ実装、crypto.randomUUID()

Web Crypto API は RFC 4122 準拠の v4 UUID 文字列を返す 1 回呼び出し生成器として crypto.randomUUID() を公開します。それは Chrome 92(2021年7月)、Firefox 95(2021年12月)、Safari 15.4(2022年3月)で出荷され、約 2022 年からすべての現代のブラウザでベースライン利用可能です。古いブラウザのために、標準的なフォールバックは 16 バイト Uint8Array を割り当て、crypto.getRandomValues() でそれを埋め、バージョンニブルを 4 に設定(7 番目のバイトの上位ニブル = 0x40)、バリアントビットを 10xxxxxx に設定(9 番目のバイトの上位 2 ビット = 0x80)、バイトを 8-4-4-4-12 16 進文字列にフォーマットすることです。この生成器は存在する場合 crypto.randomUUID() を使用、そうでなければ手動フォールバック、出力は両方のケースで同一、フォールバックパスでわずかに遅いだけ。両方のパスはブラウザで完全に実行されます、何もネットワークを横断しません。

ユースケース、それぞれが実際に必要とするもの

知っておく価値のある代替

UUID は普遍的なデフォルトですが唯一のオプションではなく、特定のユースケースのために知っておく価値のあるいくつかの代替があります。ULID(Universally Unique Lexicographically Sortable Identifier、Alex Knol、~2016):UUID のような 128 ビット、しかし 32 16 進桁の代わりに 26 文字 Crockford-Base32 でエンコード、よりコンパクトで URL 安全大文字小文字を区別しない。最初の 48 ビットはミリ秒の Unix タイムスタンプなので、ULID は作成時間で辞書順にソートします。概念的に UUID v7 に非常に近い、何年も前。Snowflake(Twitter、2010):64 ビット、UUID よりはるかに小さく、SQL BIGINT に収まる。41 ビットタイムスタンプ + 10 ビットマシン ID + ミリ秒あたり 12 ビットシーケンス。Twitter/X、Discord、Instagram、64 ビット主キーがハード制約の多くの大規模システムで使用されます。KSUID(Segment、2017):27 文字、秒精度タイムスタンプ + 128 ビットランダム性。UUID より小さい文字列表現のためにミリ秒精度を交換します。nanoid(Andrey Sitnik、2017):設定可能な長さの URL 安全ランダム識別子を生成する小さなライブラリ。デフォルト 21 文字は UUID v4 と同様の衝突耐性をはるかに少ないバイトで提供します。UUID を埋め込む公開 URL には、nanoid はより短くより親しみやすい。トレードオフ:nanoid 識別子はそれらを UUID として区別するバージョン + バリアントマーカービットを持ちません、したがって UUID 風の値を期待するシステムにフィットしません。

URL 安全性とフォーマットバリエーション

ハイフン付きの正規形式の UUID(550e8400-e29b-41d4-a716-446655440000)は URL 安全です、各文字(小文字、数字、ハイフン)は RFC 3986 によって定義された予約されていないセット内です。これは UUID をパーセントエンコーディングなしで URL パスやクエリ文字列に直接ドロップできることを意味します。一部のシステムはコンパクトさのためにハイフンを削除し、依然として URL 安全な 32 文字 16 進文字列(550e8400e29b41d4a716446655440000)を生成します、UUID 構造が固定なので変換は可逆です。一部のシステムは UUID を中括弧でラップします({550e8400-e29b-41d4-a716-446655440000})、Microsoft の GUID 慣習、中括弧は装飾的で URL を決して横断しません。一部のシステムは 16 進文字を大文字にします、UUID は仕様により大文字小文字を区別しませんが、システム内の一貫性は重要です。この生成器は UUID をフィードするあらゆるパイプラインとの互換性のために 3 つのオプション(大文字、中括弧、ハイフンなし)すべてを提供します。

UUID vs GUID、同じもの、異なる名前

UUID は IETF、ISO、ほとんどのオープンソースプロジェクトで使用される標準用語です。GUID(Globally Unique Identifier)は Windows、.NET、COM/OLE、SQL Server、Active Directory、Windows Registry で使用される Microsoft 用語です。両方とも同じ 8-4-4-4-12 16 進形式の同じ 128 ビット識別子を指します。機能的に交換可能、Windows によって生成された GUID は UUID が期待される場所で使用でき、その逆も同様です。知っておくべき唯一の違い:Microsoft の GUID 生成は歴史的に多くの API で UUID v4 を使用してきましたが、いくつかの古い COM/OLE コンテキストで UUID v1(MAC アドレス付き)を使用、これは Microsoft の COM 仕様で文書化されています。Microsoft 起源システムから GUID を受け取り、どのバージョンか知りたい場合は、バージョンニブル(13 番目の 16 進文字、v1 には '1'、v4 には '4' など)をチェックしてください。

プライバシー、なぜここでもブラウザのみが重要か

UUID は本質的な意味を持ちません、なぜ生成器がローカルで実行されることが重要なのか? 2 つの理由。第一に、UUID がセッショントークン、冪等性キー、その他の秘密のような識別子として使用されるとき、サードパーティサーバーで生成することはそのサーバーが使用前に値を見たことを意味します、小さいが実際の露出。第二に、「暗号的なランダム性」を約束するサーバー側生成器はユーザーが検証できません、バグのあるまたは悪意のあるサーバーは見かけ上ランダムだが非ランダムな値を返す可能性があり、バイアスを検出する方法がありません。ブラウザのみの生成器はアプリケーションがサーバー側で実行するのと同じ crypto.randomUUID() 呼び出しを実行します、エントロピーは同じ OS ソース(Linux getrandom()、Windows BCryptGenRandom、macOS SecRandomCopyBytes)から来ます、第三者は出力を見ません。Generate をクリックする間に DevTools の Network タブを開いて確認できます、発信リクエストはありません。ロード後にページをオフライン(機内モード)にしても生成器はまだ動作します。

よくある質問

UUIDとGUIDの違いは何ですか？

本質的には同じものです。UUIDは標準用語（RFC 4122）であり、GUID（Globally Unique Identifier）はマイクロソフトの用語です。どちらも同じ8-4-4-4-12の16進形式の128-bit識別子を指します。

2つのUUIDが同じになることはありますか？

理論的にはあり得ますが、確率は天文学的に低いです。UUID v4には122のランダムビットがあり、約5.3 × 10³⁶通りの値が可能です。1回の衝突が50％の確率で発生するには、何十年もの間、毎秒数十億のUUIDを生成する必要があります。

これらのUUIDは暗号学的に安全ですか？

はい。このジェネレーターは、暗号学的に強力なランダム値を提供するWeb Crypto API（crypto.getRandomValues）を使用しています。出力は、セッショントークンのようなセキュリティに敏感なユースケースに適しています。

データベース主キーに UUID v4 と v7 のどちらを使うべきですか?

v7 はデータベースがサポートする場合の現代の推奨です。v4(ランダム)は B-tree インデックスのランダムな位置に挿入し、インデックスをフラグメント化し、ページキャッシュを破壊します。v7(タイムスタンプ + ランダム、RFC 9562 2024 年 5 月)は ID が作成時間でソートするのでインデックスの右端に挿入、自動インクリメント整数と同じ書き込みパフォーマンス、UUID の分布と一意性で。Postgres 18+ は組み込み uuidv7() を持ちます。トレードオフ:v7 は各行の作成時間を漏らします、それは特定のアプリケーションでプライバシー懸念になる可能性があります。ほとんどのユースケースには、パフォーマンス利益がタイムスタンプ漏洩を上回ります。

ULID、KSUID、nanoid とは?

代替 ID フォーマット。ULID(Alex Knol、~2016):UUID のような 128 ビットだが 26 文字 Crockford-Base32 でエンコード、タイムスタンプで辞書順にソート。KSUID(Segment、2017):27 文字、秒精度タイムスタンプ + 128 ビットランダム。nanoid(Andrey Sitnik、2017):設定可能な長さの URL 安全ランダム ID を生成する小さなライブラリ、デフォルト 21 文字ははるかに少ないバイトで UUID v4 と同様の衝突耐性を与える。Snowflake(Twitter、2010):SQL BIGINT に収まる 64 ビット ID、Twitter、Discord、Instagram で使用。受信側システムが UUID 形式を期待する場合は UUID を使用、サイズ、ソート可能性、または URL フレンドリーさの特定の要件がある場合は代替を使用してください。

UUID はどこかに送信されますか?

いいえ。各 UUID は Web Crypto API を使用してブラウザでローカルに生成されます。生成器はネットワークリクエストを決して行いません、Generate をクリックする間に DevTools の Network タブを確認するか、ロード後にページをオフラインにしてもツールがまだ動作することを確認してください。第三者が使用前に値を見ることを望まないセッショントークン、冪等性キー、その他の識別子の生成に安全です。

関連ツール

無料パスワードジェネレーターオンライン

強力でランダムなパスワードを瞬時に生成。長さをカスタマイズし、大文字、小文字、数字、記号を含めることができます。無料、ブラウザで動作。

無料ハッシュジェネレーター

テキストまたはファイルからMD5、SHA-1、SHA-256、SHA-384、SHA-512のハッシュを生成します。HMAC署名をサポート。ブラウザベース、アップロード不要。

乱数ジェネレーター

無料のオンライン乱数ジェネレータ。 暗号化された乱数を任意の範囲で作成。 ユニーク値、ソート、バッチ生成のオプション。