HNに聞いてみる: 実際にUUID v4の衝突が発生しました…

2026年5月8日

概要

UUID v4の重複発生という極めて稀な現象
npmパッケージ「uuid」を利用した純粋なUUID生成
15,000件中1件の衝突という統計的にほぼ不可能な事象
原因の推測と一般的な再現性の有無
対策や今後の注意点

UUID v4重複の事例とその不可解さ

UUID v4 は理論上、 重複の確率が極めて低い 識別子生成手法
利用している npmパッケージ「uuid」 は広く使われる標準的実装
15,000件程度のデータベース で1件のUUID重複が発生
生成方法は import { v4 as uuidv4 } from "uuid"; const document_id = uuidv4(); のシンプルな呼び出し
UUIDの手動編集や加工は一切なし

UUID v4の重複確率と理論

UUID v4は 128ビット（約3.4×10^38通り） のランダム値
15,000件程度での衝突確率 はほぼゼロ（誤差レベル）
「誕生日のパラドックス」でも 10億件超で初めて現実的な衝突確率
理論上、 この規模での衝突は「ありえない」 とされる

可能性のある原因

バグや実装ミス （パッケージ側、依存モジュール、乱数生成器の不具合）
環境依存の問題 （OSレベルの乱数ソース不具合、仮想化・コンテナ環境のエントロピー不足）
キャッシュやプロセス間の状態共有 によるUUIDの再利用
運用・デプロイ時の何らかの副作用 （例：UUID生成をラップしている自作コードのバグ）
npmパッケージのバージョン不整合 や古いバージョン利用

実際に同様の事例はあるのか

世界的にも極めて稀な報告
- GitHub issueやStack Overflowでも ほぼ前例なし
- 一部、 乱数ソースの初期化失敗 や Dockerコンテナの複製 で似た現象の報告あり
npm「uuid」パッケージのissue で過去に乱数生成関連のバグ報告が存在

今後の対応・確認事項

uuidパッケージのバージョン確認 と最新版へのアップデート
乱数ソースのエントロピー や システム依存性 の確認
UUID生成直後に重複チェック を一時的に導入
同一タイムスタンプ/プロセス/初期化条件 での再現テスト
同様の事象が継続する場合は、OSやNode.jsの乱数生成器の不具合も疑う

まとめ・今後の注意点

UUID v4の重複は理論上ほぼ不可能 だが、現実には「絶対」は存在しない
乱数生成の信頼性 や パッケージの健全性 を常に監視
再発時はシステム全体の乱数初期化や依存環境の見直し が必要
万一の衝突検出ロジック を設けることで、予期せぬ事態への備えが可能

Hackerたちの意見

完全に同意だわ。意味が分からない。でも…考えられるのは、元々ユーザーのスマホでUUIDv4を生成してからデータベースに送ってたってことかな。今朝衝突したUUIDはUbuntuサーバーで作られたみたいだし。UUIDv4がどうやって生成されるのか、生成される機械の何がアルゴリズムに関係してるのかはよくわからないけど、思いつくのはそれだけだな。以前はユーザーのデバイスで生成してたのが、ここ数ヶ月でサーバーで生成するようになったってこと。

└

UUIDv4の衝突は統計的に見て非常にありえないことだよね。もっとありそうなのは、両方のシステムが同じシードを使ってたってこと。これがほんの数バイトの差で、衝突の確率が数十億分の1、あるいは数百万分の1に増えることもある。

└

ユーザーにUUIDを生成させてるの？正直言って、変なことやってる可能性の方が、実際にUUIDの衝突を経験する可能性より高いと思うよ。データベースはその衝突をどうやって「フラグ」立てたの？

└

あなたの具体的なセットアップでcrypto.jsが実際に何をしてるか、ちゃんと確認した方がいいよ。弱いポリフィルが存在するから…。

└

もし二つのデバイス上で生成されたUUIDだったら、衝突が起こるのも理解できる。安いエンドデバイスがランダム数生成器を正しくシードしてないことがあって、衝突する「ランダム」な値が出ることもあるし、適切な暗号学的RNGの代わりに安いRNGを使ってるライブラリもあって、さらに悪化することもある。でもサーバー上ではそんなことは起こるべきじゃない、特に2026年にはね（過去にはVMのRNGをシードするのがちょっと問題だったけど）。たとえ一つのUUIDが悪く生成されても、本当にランダムなUUIDがそれと衝突することは統計的にありえないよ。両方の生成器に問題がないと。

あなたが話してることは極めて稀なことだから、今すぐ地球が小惑星で壊滅する可能性の方が高いよ…。

└

小惑星が省略記号を打ってコメント追加ボタンをクリックするくらい稀だね。

└

UUIDの衝突が起きて、地球が小惑星に壊されるなんて、統計的に見てもさらに珍しいことだよね。

└

単一のデータベースでUUIDを使う場合は、確かに天文学的に稀だよ。でも、地球上のどのコンピュータシステムもUUIDの衝突を経験したことがないって言うのは全然違う話だよ。システムの数も天文学的だからね。

└

そんなに珍しいわけじゃないよ。計算したところ、隕石に当たるよりも少ない確率だってわかったし、UUIDに関するWikipediaの記事にそのことやバースデーパラドックスについてのセクションも追加したんだけど、数年前に削除されたり置き換えられちゃった。（もし私の情報が正しければ、実際に隕石に当たった女性がいて、彼女は生き残ったけど、足に怪我をしたらしい。）UUIDの衝突が起きた場合、ほぼ確実にソフトウェアのバグかコンピュータのグリッチが原因だよ。宇宙線の影響かもしれないし、宇宙線がコンピュータのメモリやCPUに干渉するのは意外とよくあることなんだ。

└

スレッドで他の人が言ってたように、適切にシードしないとすごく一般的だよ！君の言い方だと、SFの密度の小惑星帯に囲まれている地球が衝突するくらい珍しいってことかな。

誰も信じないだろうけど、面白い話があるんだ。10年前、友達がスタートアップのCTOに就任したんだけど、その会社は急成長中で、開発者が200人くらいいたんだ。彼の初週に、新しいUUIDを生成するためのマイクロサービスがあることを発見したんだ。一つのエンドポイントに専任のエンジニアが3人いて、データベース担当もいた（話がややこしくなるね）。他のチームは「安全な」UUIDが必要なときはこのサービスを呼ぶように指示されてた。友達は「なんで？」って思ったら、このサービスには以前発行されたUUIDを保存するためのDBがあったんだ。リクエストはこう処理されてた：UUIDを生成して、自分のデータベースをチェックして新しく生成したUUIDが以前のUUIDと重複しないか「検証」してから、挿入してクライアントに返すって感じ。安心感があるのかな。チームは自分たちのカンバンボードとスプリントも持ってた。

Hacker Newsで議論の続きを見る

ハクソク