UUID生成ツール

UUIDは、番号を一元管理しなくても重複しないように作れる128ビットのIDです

UUID(Universally Unique IDentifier)は128ビット、つまり16バイトの識別子です。ふつうは 0192f3a1-7c4e-7b21-9a3f-5c2d8e1f4a6b のように、16進数32桁を8-4-4-4-12で区切って書きます。連番を管理するサーバーがなくても、別々のコンピューターがそれぞれ作った値が事実上重複しない点が最大の特徴です。Microsoft環境では、同じものをGUIDと呼びます。

現在の標準は2024年5月に公開されたRFC 9562で、長く使われてきたRFC 4122に代わるものです。この標準はバージョン1から8までを扱いますが、新しく作るときに実際に選ぶのはたいてい3つです。v4はほぼ全体が乱数の値、v7は先頭に生成時刻を入れて並べ替えられる値、v5は同じ名前を入れれば必ず同じ値になる名前ベースの値です。このツールは3つのバージョンすべてを生成でき、どんなUUIDでも貼り付ければ、中のバージョンと時刻を読み取ります。

UUIDを自分で作って使う場面

データベースが番号を自動で振ってくれるのに、なぜ別にIDを作るのでしょうか。番号を決める場所が1か所ではない場合や、保存する前にIDが先に必要になる場合があるからです。

テスト・サンプルデータ: 会員30人、注文200件のようなダミーデータを入れるときは、重複しないIDが一度に必要です。個数を決めて生成し、JSON配列やSQLリストとしてそのまま貼り付けられます。
保存前に決めるID: オフラインで使うアプリや、複数のステップに分けて保存する画面では、サーバーに送る前にIDを決めておかないと関連付けを保てません。UUIDはどこで作っても重複しないので、サーバーの応答を待つ必要がありません。
複数の場所のデータを統合するとき: 支店ごとに1番から番号を振った表を統合すると、番号が衝突します。最初からUUIDにしておけば、統合のときに番号を振り直さずに済みます。
ファイル・オブジェクト名: アップロードされたファイルの名前をUUIDに置き換えると、同じ名前のファイル同士が上書きし合うことがありません。
リクエスト・ジョブの追跡: 1つのリクエストが複数のサービスを経由するとき、同じUUIDをログに残しておけば、散らばった記録を1本につなげられます。
同じ対象に同じID: URLや商品コードのように、すでに一意な名前を持つ対象に常に同じUUIDを付けたいときは、v5を使います。どのサーバーで計算しても結果が同じなので、ID対応表をやり取りする必要がありません。

使い方

上部でバージョンを選びます。迷ったときは、下のバージョン比較を見てください。最初の画面には、v4が10個すでに生成されています。
v4・v7は個数(1~1,000)を入力して再生成を押します。1・10・100・1,000のボタンを押すと、その個数ですぐに生成します。v5は名前空間を選び、名前を1行に1つずつ入力すると、行ごとにUUIDが出ます。
出力パネルで、文字(小文字・大文字)、形式(8-4-4-4-12・ハイフンなし・波括弧・urn:uuid:)、出力(1行ずつ・JSON配列・SQLリスト)を選びます。値は変わらず表記だけが変わり、一覧に表示されているとおりの形でコピー・保存されます。
一覧の行を押すと、そのUUIDが分解図に展開されます。行末のコピーアイコンや分解図のコピーで1個を、全てコピーやファイル保存で一覧全体を持ち出せます。一覧では矢印キーで移動し、Enterでその行をコピーします。
ほかの場所で受け取ったUUIDを確認するには、分解図の上にある確認欄に貼り付けます。波括弧、urn:uuid:、引用符、ハイフンなしの32桁も読み取り、バージョンとバリアントに加え、v7・v1・v6であれば生成時刻まで表示します。

v4・v7・v5、どれを選ぶか

RFC 9562に基づく、新規作成でよく選ぶ3つのバージョン
バージョン	何から作るか	並べ替えると	値から分かること	向いている用途
v4	122ビットの乱数	ばらばら	なし	外部に見えるID、セキュリティに関わる識別子、一般的な用途の大半
v7	ミリ秒の時刻48ビット + 乱数(または連番)74ビット	生成順	生成時刻(ミリ秒)	データベースの主キー、時系列で積み上がる記録
v5	名前空間UUID + 名前のSHA-1	ばらばら	名前が分かれば同じ値を再現できる	すでに一意な名前(URL・ドメインなど)に常に同じIDを付ける

v7を選ぶ最大の理由は並べ替えです。RFC 9562は、時系列順のUUIDを使うと新しい値がインデックスの中で互いに近い位置に入り、データベースのインデックスの局所性が良くなると説明しています。ランダムな値を入れる場合との差は、実際に10倍以上になることがあるとされています。一方、同じ文書のセキュリティの節は、UUIDをセキュリティ用途に使うならv4を使うよう定めています。v7は生成時刻をそのまま含むので、公開されたIDを見るだけで、いつ作られたデータか分かってしまうためです。

v1とv6も時刻を含みますが、機器のMACアドレスをノード値に入れる方式のため、RFC 9562は可能であればv1・v6ではなくv7を使うよう勧めています。v3はv5と同じ名前ベースですがMD5を使い、標準は可能であればv3ではなくv5を使うよう定めています。そのため、このツールが生成するのはv4・v7・v5だけで、ほかのバージョンは確認欄で読み取るだけです。

UUID 1つの読み方

36文字のうち、位置が決まっている文字は2つだけです。ハイフンを除いて数えた13文字目(3番目のグループの先頭)がバージョンで、17文字目(4番目のグループの先頭)の上位2ビットがバリアント(variant)です。RFC 9562の方式ではバリアントのビットが10なので、17文字目は8・9・a・bのいずれかになります。残りの122ビットを何で埋めるかは、バージョンごとに異なります。

5つのグループのビット配置(RFC 9562 5.4・5.5・5.7)
グループ	文字数	ビット	v4	v7	v5
1	8	32	乱数	時刻(ミリ秒)の上位32ビット	SHA-1
2	4	16	乱数	時刻の下位16ビット	SHA-1
3	4	16	バージョン4 + 乱数12	バージョン7 + rand_a 12	バージョン5 + SHA-1 12
4	4	16	バリアント2 + 乱数14	バリアント2 + 乱数14	バリアント2 + SHA-1 14
5	12	48	乱数	乱数	SHA-1

RFC 9562の付録に載っているサンプル値を確認欄に貼り付けると、分解図で同じ配置を確認できます。

RFC 9562 付録Aのサンプル値
バージョン	UUID	読み取った値
v4	`919108f7-52d1-4320-9bac-f847db4148a8`	13文字目は4、17文字目は9(2進数1001、上位2ビットは10)
v7	`017f22e2-79b0-7cc3-98c4-dc0c0c07398f`	先頭12文字 017f22e279b0 = 1,645,557,742,000ミリ秒 = 2022-02-22 19:22:22.000 UTC
v5	`2ed6657d-e927-568b-95e1-2665a8aea6a2`	DNS名前空間 + www.example.com のSHA-1の先頭128ビットで、バージョンとバリアントの位置だけを上書き

v7のrand_a 12ビットは、生成側が自由に決められます。単に乱数で埋めてもよく、同じミリ秒の中で1ずつ増やす連番や、ミリ秒より細かく分けた時刻を入れても構いません(RFC 9562 6.2)。このツールは連番方式(Method 1)を使います。新しいミリ秒になると連番を11ビットの乱数から始め、同じミリ秒の中では1ずつ増やし、4,095を超えたら時刻を1ミリ秒進めます。そのため、一度に1,000個生成しても、一覧の順序と文字列としての並び順が一致します。続く62ビットは、毎回新しい乱数です。

表記の形式と長さ

表記を変えても、128ビットの値そのものは変わりません。受け取るプログラムが求める形式に合わせてください。

RFC 9562のサンプルv4を、いろいろな形式で書いた例
形式	例	文字数	使われる場面
標準(小文字)	`919108f7-52d1-4320-9bac-f847db4148a8`	36	もっとも一般的な表記で、ブラウザのcrypto.randomUUID()の出力
大文字	`919108F7-52D1-4320-9BAC-F847DB4148A8`	36	macOSのuuidgenの出力のように、大文字を使うツール
ハイフンなし	`919108f752d143209bacf847db4148a8`	32	ファイル名や、長さを抑えたいキー
波括弧	`{919108f7-52d1-4320-9bac-f847db4148a8}`	38	RFC 9562が、Microsoftなど一部の実装の出力例として挙げている形式
URN	`urn:uuid:919108f7-52d1-4320-9bac-f847db4148a8`	45	URNが必要な文書・メタデータ

RFC 9562は、16進数の文字を大文字で書いても小文字で書いても、混在させても同じ値だと定めています。ところが、プログラムがUUIDを単なる文字列として比較すると、大文字と小文字は別の値として扱われます。1つのシステムの中では、表記を1種類に統一しておきましょう。

コード・データベース・ターミナルでの生成方法

2026年10月22日時点の公式ドキュメントに基づく
環境	v4	v7
ブラウザ・Node.js	`crypto.randomUUID()`	標準機能なし
Python 3.14以上	`uuid.uuid4()`	`uuid.uuid7()`
PostgreSQL 18	`gen_random_uuid()`, `uuidv4()`	`uuidv7()`
.NET 9以上	`Guid.NewGuid()`	`Guid.CreateVersion7()`
PowerShell	`New-Guid`	標準機能なし
macOSのターミナル	`uuidgen`	標準機能なし
Linux(util-linux)	`uuidgen`	`uuidgen -7`

ブラウザ・Node.js: W3C Web CryptographyのrandomUUIDが作るのはv4だけです。
Python 3.14以上: 3.14でuuid6・uuid7・uuid8が追加され、uuid7は42ビットの連番で、同じミリ秒の中の順序を保ちます。
PostgreSQL 18: uuid_extract_version(), uuid_extract_timestamp()で、バージョンと時刻を読み取れます。
.NET 9以上: NewGuidが作るのはv4です。
PowerShell: ランダムなGUIDを生成します。
macOSのターミナル: 大文字で出力します。
Linux(util-linux): 良質な乱数源があれば、既定はランダム方式です。v5は uuidgen --sha1 --namespace @dns --name www.example.comで生成します。ディストリビューションのutil-linuxのバージョンによっては、-7がない場合があります。

重複する確率はどれほど小さいか

v4は122ビットが乱数なので、取りうる値は2¹²²個、約5.3 × 10³⁶個です。この中からn個を選んだとき、同じ値が1組でも出る確率は、誕生日問題の式 1 − e^{−n(n−1)/(2·2¹²²)} で近似します。

v4 UUIDをn個作ったとき、同じ値が1組でも出る確率
生成した個数	確率
100万個	約9.4 × 10⁻²⁶
10億個	約9.4 × 10⁻²⁰
1兆個	約9.4 × 10⁻¹⁴
1000兆個	約9.4 × 10⁻⁸
約2.7 × 10¹⁸個	50%

確率が50%になる2.7 × 10¹⁸個は、1秒に10億個ずつ生成しても約86年かかる量です。ただし、この計算は乱数が均等に出ることを前提にしています。RFC 9562が暗号学的に安全な乱数生成器を使うよう求めているのはそのためで、このツールもブラウザのcrypto.getRandomValues()を使います。確率は0ではないので、運用データには一意制約を付け、衝突して保存が拒否された場合は新しい値を作り直す処理を入れてください。

v7で重複しうるのは、同じミリ秒に作られた値どうしだけです。1つの生成器の中では連番が増えていくので重複せず、別々の機器が同じミリ秒に作る場合は、後ろ側の62ビットの乱数が区別します。

v7をデータベースのキーに使うとき

バイナリで保存する: RFC 9562は、UUIDを文字として保存すると128ビットの値に288ビットを使うことになるため、可能であれば128ビットのバイナリで保存するよう述べています。PostgreSQLのuuid型のような専用の型があれば、それを使います。
並べ替えはバイト順で: v7は、バイトを先頭から比較するか、同じ大文字・小文字で書いた文字列を辞書順に並べれば、生成順になります。大文字と小文字を混ぜると、文字列の並び順が崩れます。
時刻は参考値: v7の先頭48ビットは、作成した機器の時計です。RFC 9562はその時刻が実際の時刻にどれだけ近いかは保証しないと述べており、PostgreSQLのドキュメントも、取り出した時刻が生成時刻と完全には一致しないことがあると述べています。正確な生成時刻が必要なら、別の列を用意してください。
データベースに作らせる: RFC 9562は、1つのデータベースにすべてのデータを置く場合は、データベースが生成したUUIDが順序をもっともよく保つと述べています。このツールで作った値はテストデータや先に決めておくIDに使い、運用中に積み上がり続けるキーは、データベースやサーバーの関数で生成するのが適切です。

よくある間違い

先頭8文字だけを切り出して使う: 8文字は32ビットなので、約7万7千個集まるだけで同じ値が出る確率が50%になります。短くして使いたい場合でも、切り出した値がUUIDと同じ一意性を持つとは考えないでください。
UUIDを知っていることだけでアクセスを許可する: RFC 9562のセキュリティの節は、UUIDは推測しにくいと仮定してはならず、持っているという事実だけで権限を与える値として使ってはならないと定めています。共有URLにUUIDが入っていても、権限の確認は別に必要です。
v7で作った公開ID: アドレスバーに表示される会員番号をv7で作ると、登録時刻が分かってしまいます。時刻が分かってはいけない場所には、v4を使います。
v5の名前のわずかな違い: www.example.comとwww.example.com.、前後の空白、大文字・小文字の違いはすべて別の名前なので、別のUUIDになります。RFC 9562も、同じ名前でも表記が複数ありうること、表記ごとに別のUUIDになることを説明しています。このツールは名前を直さず、入力されたままUTF-8で計算します。
バイト順が異なるGUID: .NETのGuid.ToByteArray()は、先頭3つのグループのバイト順を入れ替えて返します。文字列でやり取りする場合は同じですが、バイトで受け渡すときは順序を確認してください。
名前ベースのUUIDを主キーにする: RFC 9562は、郵便番号や免許番号のように変わらないと思われていた値が、後から変わることはよくあると述べ、名前ベースのUUIDを主キーに使わないよう定めています。

制限と注意点

一度に生成できるのは1,000個までです。v5は名前を1,000行まで計算します。
v7の順序が続くのは、このページの中だけです。別のタブや機器で同じミリ秒に作られた値との順序は保証しません。
v7の時刻には、この機器の時計を使います。機器の時計がずれていれば、UUIDに入る時刻もずれます。
v5はSHA-1を使います。RFC 9562は、SHA-256などほかのハッシュで作る名前ベースのUUIDはv5ではなくv8にするよう定めており、このツールはv8を生成しません。
v1・v3・v6・v8は、確認欄での読み取りのみです。v1・v6のノード値は、機器のMACアドレスの可能性があります。
生成したUUIDは、再読み込みすると消えます。必要な一覧は、コピーするかファイルに保存しておいてください。

出典

基準日 RFC 9562、W3C Web Cryptography、PostgreSQL 18・Python・.NET・PowerShell・util-linuxのドキュメントは、2026年10月22日に原文で確認しました。サンプル表のv4・v7・v5の値は、このツールとPython 3.14のuuidモジュールで同じ結果になることを照合し、確率の表は上の式で計算しました。

01IETF RFC 9562 — Universally Unique IDentifiers (UUIDs)2024年5月、RFC 4122を置き換え。4章表記、5.4 v4、5.5 v5、5.7 v7、6.2 単調増加、6.11 ソート、6.13 DB、8章セキュリティ、付録A サンプル
02W3C — Web Cryptography API, randomUUIDバージョン4のUUIDを小文字の文字列で生成する手順
03PostgreSQL 18 — 9.14 UUID Functionsgen_random_uuid、uuidv4、uuidv7、uuid_extract_timestamp、uuid_extract_version
04Pythonドキュメント — uuid3.14でuuid6・uuid7・uuid8を追加、uuid7の42ビット連番
05Microsoft Learn — Guid.CreateVersion7.NET 9以降、RFC 9562のバージョン7
06Microsoft Learn — Guid.NewGuidバージョン4のUUID、122ビットのエントロピー
07Microsoft Learn — Guid.ToByteArray先頭の4バイトのグループと、続く2バイトのグループ2つの順序を入れ替える
08Microsoft Learn — New-GuidランダムなGUIDを生成するPowerShellコマンド
09uuidgen(1) — util-linuxのマニュアル既定はランダム方式、-7(--time-v7)、--sha1 --namespace @dns

よくある質問

UUID v4とv7のどちらを使えばよいですか?

データベースの主キーのように、新しい値がインデックスの末尾に順に積み上がるほうがよい用途には、v7が向いています。先頭48ビットが生成時刻なので、文字列として並べ替えても生成順になります。生成時刻が分かってはいけない値や、セキュリティに関わる識別子にはv4を使います。RFC 9562も、セキュリティ用途のUUIDにはv4を使うよう定めています。

UUIDは何文字ですか?

標準の表記は、16進数32桁とハイフン4個を合わせた36文字です。ハイフンを除くと32文字、波括弧を付けると38文字、先頭にurn:uuid:を付けると45文字です。値そのものは128ビット、つまり16バイトです。

UUIDのバージョンはどう確認しますか?

3番目のグループの先頭の文字、つまりハイフンを除いて数えた13文字目がバージョンです。4番目のグループの先頭の文字が8・9・a・bのいずれかであれば、RFC 9562のバリアントです。このツールの確認欄に貼り付けると、バージョンとバリアント、v7・v1・v6であれば生成時刻まで読み取ります。

UUID v4が重複する確率はどれくらいですか?

v4は122ビットが乱数なので、10億個を生成しても、その中に同じ値が1組でも出る確率は約9.4 × 10⁻²⁰です。重複する確率が50%になるには、約2.7 × 10¹⁸個が必要です。0ではないので、運用データには一意制約も併せて設定してください。

UUID v7から生成時刻は分かりますか?

はい。先頭12文字(48ビット)が、1970年1月1日UTCから数えたミリ秒です。確認欄に貼り付けると、機器のタイムゾーンとUTCで表示します。ただし、生成した機器の時計がそのまま入った値なので、正確な記録時刻としては信頼できません。

UUID v5はどんなときに使いますか?

同じ名前から常に同じUUIDが必要なときに使います。名前空間のUUIDと名前をつなげてSHA-1を求め、先頭128ビットを使います。たとえば、DNS名前空間とwww.example.comは、どこで計算しても2ed6657d-e927-568b-95e1-2665a8aea6a2です。名前が1文字違うだけで、まったく別の値になります。

UUIDをパスワードや認証トークンとして使ってもよいですか?

いいえ。RFC 9562は、UUIDは推測しにくいと仮定してはならず、持っているというだけでアクセスを許可する値として使ってはならないと定めています。UUIDが含まれるURLにも権限の確認が必要で、秘密のトークンは目的に合った方法で別に発行します。

GUIDとUUIDは別のものですか?

同じ128ビットの識別子を指す、別の呼び名です。RFC 9562も、UUIDはGUIDとも呼ばれると記しています。ただしMicrosoft方式は、バイナリで保存するときにリトルエンディアンを使います。たとえば.NETのGuid.ToByteArray()は、先頭の4バイトのグループと、続く2バイトのグループ2つの順序を入れ替えて返すので、バイトで受け渡すときは順序を確認してください。