元記事は、Hacker News の Ask HN 投稿です。
投稿者は「今朝、データベースが重複 UUID を検出した」と書き込みました。
しかも、ただの重複っぽいミスではありません。
投稿者は使っていたコードもシンプルだと説明しています。
import { v4 as uuidv4 } from "uuid";
const document_id = uuidv4();
つまり、「ライブラリに任せてUUIDを発行して、そのままDBに入れているだけ」。
それで衝突した、という話です。
しかもデータベース全体のレコード数は 約1万5000件。
普通に考えると、UUID v4 の衝突なんて天文学的に起きにくいはずです。
だから投稿者も「どう考えてもおかしい」と困惑していました。
個人的にも、これはかなり面白い話だと思います。
というのも、UUIDって「衝突しないための便利ID」の代表格みたいに扱われがちだからです。
それが実際にぶつかったとなると、「え、そんなことあるの？」となるのは自然です。
UUID は Universally Unique Identifier の略で、ざっくり言うと「世界で重複しにくいID」です。
その中でも v4 は、内容のほとんどをランダムに決める方式です。
よくあるイメージとしては、
という感じです。
ただし、ここで大事なのは “ランダムに見える” ことと “本当に十分ランダム” であることは別 だという点です。
UUID v4 は、ちゃんとした乱数源（entropy source）に支えられて初めて「衝突しにくい」わけです。
最上位のコメントで、あるユーザーはかなり本質的なことを言っています。
UUIDv4 の安全性は、高品質な entropy source があることを前提にしている。
その前提は、ハードウェア不良やソフトウェアバグ、entropy の意味を理解していない開発者によって壊れることがある。
要するに、UUID v4 が悪いというより、UUID を作る元の“乱雑さ”が壊れていると事故る、という話です。
ここ、地味ですが超重要です。
ランダムIDは「理論上ほぼ被らない」のであって、「宇宙の法則として絶対に被らない」わけではありません。
もし乱数生成器が変な状態なら、同じIDを何度も出してしまうことはありえます。
しかも entropy が壊れているかどうかは、意外と検出が難しい。
だから多くのシステムは、その異常に気づけないまま使い続け、衝突が起きて初めて発覚する。
これはかなり嫌な現実です。かなり人間くさい失敗でもあります。
コメント欄では、Cloudflare がオフィスに置いている lava lamp wall の話も出てきました。
あの、ゆらゆら動くランプの壁です。
これは見た目が面白いだけではなく、entropy の源の一つとして有名です。
Cloudflare は他にも、pendulum（振り子）や mobile など、いろいろな物理現象を使って乱雑さを集めているそうです。
ここでのポイントは、物理世界はコンピュータよりランダムっぽいということです。
ソフトウェアだけで完璧なランダムを作るのは難しいので、
みたいな「予測しづらい現象」を混ぜることで、乱数の質を上げるわけです。
私はこの話、すごく好きです。
コンピュータの世界って基本的に「再現性」が命ですが、乱数だけは逆に「再現できないこと」が命なんですよね。
そのギャップがいかにも面白い。
コメント欄では、少し数学っぽい話として Von Neumann method も話題になりました。
これは、偏ったコイン（表が出やすいコイン）から、偏りのない結果を取り出す方法です。
やり方はシンプルで、
HT か TH なら採用HH と TT は捨てるというものです。
なぜこれで公平になるのかというと、HT と TH は起こる確率が同じだからです。
コインが表寄りでも裏寄りでも、順番の入れ替わりは対称なので、採用したときだけ見れば 50/50 になる、という理屈です。
このあたりのコメントは、技術の話なのに妙に楽しいです。
「乱数って、こんなふうに“偏りを消す”ことができるのか」と気づかされます。
数学の力って、こういうところで気持ちよく効くんですよね。
コメントの流れでは、「entropy の源は多ければ多いほどいい」という意見もありました。
ただ、これは半分正しくて半分危ういと思います。
たしかに、複数の独立した entropy を混ぜるのは有効です。
でも大事なのは数ではなく、独立性と品質です。
つまり、「100個集めたから勝ち」ではないんですよね。
むしろ、ちゃんと質の違う入力を、ちゃんと混ぜることが大事だと思います。
この投稿が面白いのは、単なる珍事ではなく、実務的な怖さがあるからです。
UUID v4 は多くのシステムで「ほぼ安心して使える」便利な仕組みです。
でも、今回のように実際に衝突が起きたなら、考えるべきは「UUIDは信頼できない！」ではなく、
といった、周辺の土台です。
ここが重要です。
IDの方式そのものより、IDを作る基盤の健全性のほうが本質的なリスクになりうる。
これは、実装の細部よりインフラや環境のほうが怖い、という現場あるあるでもあります。
個人的には、この話は「UUID v4 が壊れた」というより、**“ランダム” を信用しすぎると痛い目を見る**という教訓だと感じました。
人は「UUIDはほぼ一意」という言葉を聞くと、つい「まあ大丈夫でしょ」と思ってしまいます。
でも実際には、そこには
みたいな、無数の前提が挟まっているんですよね。
技術って、便利になるほどブラックボックス化しがちです。
だからこそ、こういう「ありえないはずの事故」は、むしろありがたい警鐘なのかもしれません。
このHacker Newsの投稿は、単なる珍事件ではなく、
UUID v4 の信頼性は“十分な entropy があること”を前提にしている、という基本を思い出させる話でした。
「重複しないはずのIDが重複した」とき、疑うべきはUUIDの数学だけではありません。
その背後にある乱数生成の品質、環境、実装全体です。
そして何より、コンピュータの世界で「ランダム」は思っているよりずっと繊細だ、ということ。
そこがこの話のいちばん面白くて、いちばん怖いところだと思います。
参考: Ask HN: We just had an actual UUID v4 collision... | Hacker News