UUID を作る・調べる

版を選んでその場で作ります（7種類ぜんぶ）。元になったバイトと、塗り替わるビットまで見せます。 貼れば何版かも、いつ作られたかも調べられます。

UUID は「重複しない」のではなく「たぶん重複しない」

UUID の要旨（Abstract）にはこう書かれています ── 「時間と空間をまたいで一意であることを意図している」。 ところが同じ文書の 第6.8節を読むと、こう書いてあります。

Although true global uniqueness is impossible to guarantee without a shared knowledge scheme, ...
（共有の仕組みを持たないかぎり、本当に世界規模で一意であることは保証できないものの、…）

つまり UUID の一意性は、保証ではなく確率です。 誰かと相談せずに、それぞれの機械が勝手に作れるのが UUID の値打ちなので、 「世界のどこかで同じものが出ていないか」は原理的に確かめようがありません。 確かめないかわりに、ぶつかる確率を十分に小さくしてある、という作りです。

では、どれくらい小さいのか

乱数から作る4版で、乱数として使われるのは 122ビットです。 ここで効いてくるのが誕生日のパラドックス ── 「40人の教室に、同じ誕生日の2人がいる確率は9割」というあれです。どれか2つがぶつかる確率は、全部を1つずつ見比べるよりずっと早く上がります。

1パーセントに届くのは33京個、 五分五分になるのは271京個あたりです。 この桁は感覚で当てられません。 このページを書いたときも 「1000兆個でようやく1パーセント」と書きかけましたが、 実際に計算すると1000兆個ではまだ 9.4e-6パーセントで、330倍ほど外していました。 だから本文に出しているこれらの個数は、手で書かずに計算した値をそのまま出しています。

この表は近似の式です。「ぜんぶ相異なる確率」を1つずつ掛けていくと、 個数が兆の単位になったところで計算が終わらなくなるので、 よく使われる近似（作った個数を n、取りうる値の数を N として1 −（e の −n²÷2N 乗））で出しています。 桁の感覚をつかむためのもので、下の桁まで正しいという意味ではありません。

ただし、これは乱数がきちんとしている場合の話です。 質の悪い乱数を使えば、この計算とは関係なくぶつかります。 RFC 9562 の第6.9節が暗号用の乱数を使うべきだとしているのはそのためで、 この道具もブラウザの暗号用の乱数（crypto.getRandomValues）を使っています。

128ビットのうち、乱数なのは122ビットです

UUID は全体で128ビットですが、そのうち6ビットは中身が決まっています。 4ビットが版（何版か）、2ビットがバリアント（どの規格のものか）です。 上の道具で「引いた16バイト」を見ると、その2か所だけが塗り替わっているのが分かります。

差は6ビット、つまり64倍です。「UUID は2の128乗通り」と書いてある説明は、 4版については64倍多く見積もっています。

作り方が決まっている版は7種類あります（4種類ではありません）

よく引かれる RFC 4122 は、2024年5月に RFC 9562 が廃止しました（表紙に Obsoletes: 4122 と書かれています）。 このとき6版・7版・8版が増えました。 きっかけは、データベースの主キーに UUID を使うようになったことです。

4版は乱数なので、作った順に並びません。 索引（B木）に入れると 毎回ばらばらの場所に挿し込むことになり、原文の第2.1節はその影響を「劇的（dramatic）になりうる」と書いています。 時刻を頭に置いて時間順に並ぶようにしたのが6版と7版です。

表に出していない版もあります。0版は未使用、2版は DCE Security のために予約されていて作り方が決まっておらず、 9版から15版は将来のために空けてあります。 合わせて16通り（4ビットぶん）です。

⭐ この7種類は、上の道具で全部作れます。版を選ぶと、中身の分け方（どのビットが何なのか）も一緒に出ます。

2版だけは作れません ── 作り方がこの文書に無いからです

版の番号は 0 から 15 まで並んでいるのに、2版だけ、作り方がどこにも書かれていません。 RFC 9562 の第5.2節はまるごと3行で、こう言っているだけです ── 「2版は DCE Security の UUID のためのものである。したがって、これらの UUID の定義はこの仕様の範囲外である」。

つまり抜けているのではなく、よそに置いてあるのです（Open Group の DCE 1.1 という別の仕様の側）。 ⭐ 上の道具で2版が選べないのは、作れないからではなくこの文書だけを見て作ると、それは2版ではない何かになってしまうからです。

⭐ 名前から作る版は、乱数を1ビットも使いません

3版・5版・8版は名前を混ぜて作ります。ここが他と決定的に違うところで、同じ名前空間・同じ名前なら、いつ・誰が・どの機械で作っても必ず同じ UUIDになります（第6.5節）。上の道具で3版か5版を選ぶと、釦を押さなくても、打っているそばから決まるのはそのためです。

「名前空間」はどの世界の名前かを表す UUID です。同じ www.example.com でも、DNS の名前として見るか URL として見るかで 別の UUID になります。第6.6節が4つ定めています ── よく見ると 6ba7b810・6ba7b811・6ba7b812・6ba7b814 と、6ba7b813 だけ飛んでいます。写し間違いではなく、原文が「この値は定義されていないので使うべきでない（SHOULD NOT）」と名指しで書いているためです。

3版は MD5、5版は SHA-1 を使います。同じ第5.3節が「できるかぎり3版ではなく5版を使うべき」としています。 では SHA-256 のような新しいものを使いたいときは？ ── そこで8版です。第5.5節が「5版を使ってはならない（MUST NOT）、8版の枠でなければならない（MUST）」と決めていて、付録B.2 にその実例が載っています。上の道具の8版はこれです。

⭐⭐ 原文が2か所まちがっていました

1版と6版を作ってみたら、原文どおりに書いたのに付録の答えと合いませんでした。RFC には正誤表（errata）があり、見に行くと どちらも報告済み・検証済みでした。

⭐ どちらも付録の試験値が正しい側を裏づけていました。 本文と試験値が食い違っていて、本文のほうが誤っていたわけです。

持ち帰るものはここです ──原典を開いたら、正誤表も開いてください。本文だけを読んで作ると、それらしく動くのに世界中のどの実装とも一致しない、 という壊れ方をします。しかも見た目は完全に UUID のままなので、目では絶対に気づけません。

1版に機械の情報が入っていた話

いちばん古い1版は、時刻とその機械のネットワーク機器の番号（MAC アドレス）から作ります。 世界で重ならない番号を使えば確実だ、という考え方でした。

いまはこれが使うべきでないものとされています。 RFC 9562 の第8節は「MAC アドレスは本質的にプライバシーとセキュリティの危険をはらむ」として、UUID の中で使うべきでない（SHOULD NOT）と定めています。 第2.1節はもう少し具体的で、さらされた MAC アドレスは、その機器を探し出す足がかりになる（最低でも製造元が分かる）と書いています。

おまけに、仮想機械やコンテナが当たり前になったいま、MAC アドレスそのものが 一意だと保証できなくなりました。 一意にするために入れたものが、 一意でもなく、しかも身元を明かす ── というわけです。

全部0と、全部1

2つだけ特別な値があります。 Nil UUID（00000000-0000-0000-0000-000000000000）は128ビットすべてが0で、「ここに値が無い」ことを表すために取ってあります。Max UUID（ffffffff-ffff-ffff-ffff-ffffffffffff）はすべてが1で、「一覧の終わり」のような目印に使えます。

おもしろいのは、この2つはどちらも RFC 9562 が定めたバリアントに入らないことです。全ビットが0なら上位2ビットも 00 になり、 全ビットが1なら 11 になるので、 どうやっても 10にならないからです。 上の「貼ると調べる」に入れてみると、版の欄が0版・15版に見えるのもそのためです。 名前で答えるようにしてあります。

UUID を鍵の代わりに使ってはいけません

RFC 9562 の第8節は、はっきりこう書いています。

Implementations SHOULD NOT assume that UUIDs are hard to guess. For example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access).
（UUID が推測しにくいと仮定すべきではない。たとえば、持っているだけでアクセスを許す識別子として使ってはならない）

「URL を知っている人だけが見られる」という作りは、UUID の推測しにくさに頼っています。 4版で暗号用の乱数を使っていればすぐには当てられませんが、1版や7版は時刻が入っているので、 いつ作られたかが分かるうえ、近い時刻のものは近い値になります。 鍵が必要なときは、鍵として作られたものを使ってください （このサイトならパスワード生成のほうです）。

出どころ

版・バリアント・ビットの数え方・引用文は、すべて RFC 9562「Universally Unique IDentifiers (UUIDs)」（新しいタブで開きます）（2024年5月・Standards Track）の原文です。 節の番号は本文に書いたとおりで、122ビットという数は第5.4節の 48 + 12 + 62 を足したものです。 作り方の検算には、同じ文書の付録A・付録Bに載っている検査用の値をそのまま単体テストに入れてあります （原文が「この16バイトからこの UUID になる」と書いているとおりになるか）。

ブラウザの乱数については W3C Web Cryptography API（新しいタブで開きます）の原文です。 この仕様には crypto.randomUUID() という4版を作る関数もありますが、安全なコンテキストでしか使えないと定義されている（[SecureContext]）ので、この道具は使っていません。 かわりに16バイトを自分で引いて組み立てているので、引いたバイトと塗り替わったビットを画面に出せます。