UUID は衝突しないのか - 間違った運用と実装で重複を招くパターン

UUID を主キーにしていたのに、ある日 duplicate key が出る。 この瞬間、かなりの確率で「UUID って結局ぶつかるのでは」という話になります。

ただ、実務で起きる UUID 重複の多くは、UUID という規格そのものの問題 というより、規格が前提にしている生成条件を実装や運用で壊している ケースです。RFC 9562 では UUIDv4 は 122 ビットのランダム領域を持ち、UUIDv7 もタイムスタンプ以外の 74 ビットを一意性のための乱数やカウンタに使う前提で定義されています。一方で、UUIDv8 は「実装依存であり、一意性を前提にしてはいけない」と明記されています。¹²³ また、Python 標準ライブラリでも uuid4() は暗号学的に安全な方法で生成されると説明されており、少なくとも「ちゃんとした実装を普通に使う」限り、UUID 側の前提はかなり強いです。⁴

この記事では、間違った運用や実装で UUID が衝突してしまう典型パターン を、再発防止策とセットで整理します。 内容は 2026 年 3 月時点 で確認できる RFC 9562、Python 公式ドキュメント、PostgreSQL 公式ドキュメントをもとにしています。⁵⁴⁶

この記事で使う用語

以降の章で、英語のまま出てくる術語を先に一行ずつ訳しておきます。

1. まず結論

先に短くまとめると、危ないのはこのパターンです。

要するに、UUID が衝突した というより、UUID に期待していた一意性を、途中の設計で削っている ことが多いです。

この記事の知識マップ

UUIDの衝突事故の多くは規格そのものではなく、生成や運用が前提を壊すことで起きると整理する記事です。RFC 9562が定めるUUIDv4はCSPRNGによる122ビットの乱数領域を、UUIDv7はカウンタによる単調性の設計を前提としており、固定seedの弱いPRNGでの自作やfork・snapshot後の生成器状態の巻き戻り、UUIDv3/v5を新規採番用途に誤用すること、UUIDv8の実装依存な一意性への過信、128ビットを削る切り詰めがいずれも重複を招きます。RFC自身が真のglobal uniquenessを絶対保証しないとしている以上、DB側のUNIQUE制約が重複挿入を防ぐ最終防衛線になります。

flowchart LR
    accTitle: UUIDの衝突を招く実装パターンの知識マップ
    accDescr: UUIDv4・UUIDv7・UUIDv3/v5・UUIDv8・UUIDv1/v6それぞれがRFC 9562で定義されること、弱いPRNGでの自作・生成器の状態の巻き戻り・name-based UUIDの新規採番への誤用・カウンタの桁あふれ・時刻の巻き戻り・切り詰めがいずれもUUIDの衝突を招くこと、CSPRNGの利用とfork後の再seedとDB側の一意制約がその対策になることを示す図
    uuid["UUID"]
    rfc9562["RFC 9562"]
    csprng["CSPRNG"]
    uuidv4["UUIDv4"]
    weak_prng_uuid["弱いPRNGによるUUID自作"]
    new_record_id_issuance["新規採番"]
    name_based_uuid["UUIDv3/v5"]
    uuidv8["UUIDv8"]
    uuid_collision["UUIDの衝突"]
    generator_state["生成器の状態"]
    counter_rollover["カウンタの桁あふれ"]
    clock_rollback["時刻の巻き戻り"]
    uuid_truncation["UUIDの切り詰め"]
    db_unique_constraint["DB側の一意制約"]
    fork_reseed["fork後の再seed"]
    uuidv7["UUIDv7"]
    monotonicity["単調性"]
    namespace_uuid["namespace"]
    canonicalization["正規化"]
    uuidv1_v6["UUIDv1/v6"]
    csprng -->|"推奨される対応"| uuidv4
    weak_prng_uuid -->|"用いるのは非推奨"| new_record_id_issuance
    name_based_uuid -->|"用いるのは非推奨"| new_record_id_issuance
    uuidv8 -->|"用いるのは非推奨"| new_record_id_issuance
    weak_prng_uuid -.->|"原因になり得る"| uuid_collision
    generator_state -.->|"原因になり得る"| uuid_collision
    name_based_uuid -.->|"原因になり得る"| uuid_collision
    counter_rollover -.->|"原因になり得る"| uuid_collision
    clock_rollback -.->|"原因になり得る"| uuid_collision
    uuid_truncation -->|"原因になり得る"| uuid_collision
    db_unique_constraint -->|"軽減する"| uuid_collision
    fork_reseed -->|"軽減する"| uuid_collision
    csprng -->|"防止する"| weak_prng_uuid
    uuidv7 -.->|"利用する"| monotonicity
    counter_rollover -.->|"両立しない"| monotonicity
    clock_rollback -.->|"両立しない"| monotonicity
    name_based_uuid -->|"利用する"| namespace_uuid
    name_based_uuid -->|"前提とする"| canonicalization
    uuidv4 -->|"で確認できる"| rfc9562
    uuidv7 -->|"で確認できる"| rfc9562
    name_based_uuid -->|"で確認できる"| rfc9562
    uuidv8 -->|"で確認できる"| rfc9562
    uuidv1_v6 -->|"で確認できる"| rfc9562
    uuidv1_v6 -.->|"原因になり得る"| uuid_collision
    uuid -->|"で確認できる"| rfc9562

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全25件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. まず疑うべきは「UUID の数学」ではなく「生成と運用」

UUID の話がややこしくなるのは、バージョンごとに性質が違うからです。

• UUIDv4 はランダムベースです。RFC 9562 では version / variant を除く 122 ビットが乱数で埋まります（Section 5.4）。¹
• UUIDv7 は時系列ソートしやすい構造で、Unix ミリ秒タイムスタンプに加えて、残りを乱数や carefully seeded counter で構成します（Section 5.7）。²
• UUIDv3 / v5 は name-based です。同じ namespace と同じ canonical name なら、同じ UUID が出るのが正しい挙動です（Section 6.5）。⁷
• UUIDv8 は実験用・ベンダー独自用であり、一意性は実装依存です。RFC は「一意性を前提にしてはいけない」としています（Section 5.8）。³

つまり、「UUID を使っている」と言っても、その中身が

• 標準ライブラリの uuid4() なのか
• 自前の timestamp + random なのか
• uuid5(namespace, name) なのか
• 見た目だけ UUIDv8 の独自フォーマットなのか

で、話がまったく変わります。

flowchart TD
    A[UUID 重複が見つかる] --> B{本当にどこで同じ値になったか}
    B --> C[生成器が弱い]
    B --> D[状態が巻き戻った]
    B --> E[name-based UUID の誤用]
    B --> F[保存時に切り詰めた]
    B --> G[DB 側で一意制約がない]
    C --> H[実装ミス]
    D --> H
    E --> H
    F --> H
    G --> H

実務では、この図の右側から見ていくほうが早いです。

もう少し手順として書くなら、確認コストが低いところから順に潰す のが実際的です。次の順番だと、必要な道具が「SQL を 1 本流す」「コードを grep する」「運用手順を確認する」と段階的に増えていくので、途中で原因が分かればそこで止まれます。

flowchart TD
    S["duplicate key や重複データを検知"] --> Q1{"1. DB に UNIQUE / PRIMARY KEY はあるか（8章）"}
    Q1 -- ない --> A1["制約なしで静かに混入していた。<br/>まず制約を張り、重複の入口を止める"]
    Q1 -- ある --> Q2{"2. 保存と比較でフル長 128 ビットを維持しているか（7章）"}
    Q2 -- 切り詰めている --> A2["prefix 比較、64 ビットへの潰し込み、<br/>カラム長不足による末尾切れを疑う"]
    Q2 -- 維持している --> Q3{"3. 生成は標準 API か（3章・5章）"}
    Q3 -- 自前実装 --> A3["弱い PRNG での自作、または<br/>name-based UUID の採番用途への誤用を疑う"]
    Q3 -- 標準 API --> Q4{"4. fork / snapshot / clone 後に生成器の状態を引き継いでいないか（4章）"}
    Q4 -- 引き継いでいる --> A4["生成器の状態が巻き戻っている"]
    Q4 -- 問題なし --> A5["残るのは独自の時刻系実装や<br/>UUIDv8 の設計そのもの（6章）"]

3. パターン1: UUIDv4 を名乗りながら、実際は弱い PRNG を使っている

一番ありがちなのはこれです。

• Math.random() 相当の一般用途 PRNG で 128 ビット分作る
• 起動時に time() や PID で seed を入れる
• 「UUID 形式っぽい 32 hex 桁」を自前で組み立てる

見た目は UUID でも、乱数源が弱ければ、同じ系列が別プロセスや別ノードで再現 されます。

コードにすると分かりやすいです。次は Python 3 の標準ライブラリだけで動く、やってはいけないほうの例 です。

# 悪い例: 一般用途の PRNG を seed 固定で回し、UUID 形式の文字列を自前で組み立てる
import random


def make_pseudo_uuid(seed: int) -> str:
    rng = random.Random(seed)          # 同じ seed なら毎回まったく同じ系列になる
    value = rng.getrandbits(128)
    hex_digits = f"{value:032x}"
    return "-".join([
        hex_digits[0:8],
        hex_digits[8:12],
        hex_digits[12:16],
        hex_digits[16:20],
        hex_digits[20:32],
    ])


first = make_pseudo_uuid(12345)
second = make_pseudo_uuid(12345)
print(first == second)   # True: 別プロセスでも別ノードでも、seed が同じなら同じ値が出る

この例には、実は問題が 2 つあります。

1. random.Random は一般用途の PRNG なので、seed が同じなら系列がそのまま再現します。起動時刻や PID を seed にしても、同時起動や clone で衝突しえます。
2. version / variant のビットを一切設定していないので、そもそも RFC 9562 の UUIDv4 ではありません。UUID の形をした 128 ビットの数 でしかない、というのが正確なところです。

対して 良いほうの例 は、拍子抜けするほど短くなります。

# 良い例: 標準 API をそのまま使う。seed も版数も自分で触らない
import uuid

new_id = uuid.uuid4()
print(new_id.version)    # 4: version ビットは API 側が正しく埋めてくれる
print(uuid.uuid4() != uuid.uuid4())   # True: 呼ぶたびに別の値になる

RFC 9562 は、UUID の一意性と予測困難性の両方のために、CSPRNG を使うべき としています（Section 6.9 Unguessability）。これは推奨要件（SHOULD）であり、用途によっては例外設計もあり得ますが、一般用途 PRNG で UUID を自作するならその理由を説明できる状態にしておくべきです。さらに、process fork のような状態変化時には CSPRNG 状態を適切に再 seed すべき と書いています。⁸ Python の uuid.uuid4() も、暗号学的に安全な方法でランダム UUID を生成すると説明しています。⁴

ここでの実務上の結論は単純です。

• UUID を自作しない
• 乱数 seed を手でいじらない
• 標準ライブラリか、広く使われた実装をそのまま使う

「軽いから」「昔から使っているから」で独自生成器を持ち続けると、あとで最も高くつきます。

4. パターン2: fork、snapshot、clone で生成状態を巻き戻す

二番目に危ないのは、生成器の状態が複製・巻き戻しされる運用 です。

RFC 9562 は、fork 後の再 seed を明示的に勧めていますし（Section 6.9）、stable storage を持たない実装は clock sequence、counter、random data の生成頻度が増え、重複確率が上がる と説明しています（Section 6.3 UUID Generator States）。⁸⁹

ここから自然に出てくる実務上の推論があります。

• VM snapshot 取得後に同じイメージを複数復元する
• コンテナイメージ起動時に同じ初期状態から独自生成器が立ち上がる
• worker fork 後に PRNG 状態やカウンタ状態を共有してしまう

こうした運用では、UUID の生成系列が意図せず再現 されえます。 これは RFC がそのまま「snapshot は危険」と書いているわけではありませんが、fork 後の再 seed と generator state の扱いに関する注意から導ける、かなり実務的な注意点です。⁸⁹

対策はこのあたりです。

• 独自の UUID 生成状態を長く持たない
• fork / clone / restore の直後に再初期化する
• 可能なら OS 由来の乱数を毎回利用する実装に寄せる
• 高頻度生成器なら、状態管理と再 seed の仕様を明文化する

5. パターン3: UUIDv3 / v5 を「毎回新しい ID」と誤解する

UUIDv3 / v5 は collision しにくいランダム ID ではありません。 同じ名前から同じ ID を再生成できる決定論的 ID です。

RFC 9562 では、同じ canonical format の same name を same namespace で生成した UUID は等しくなければならない と書かれています（Section 6.5 Name-Based UUID Generation）。⁷ なので、こういう使い方をすると、重複は事故ではなく仕様どおりの動きです。

• uuid5(NAMESPACE_URL, "https://example.com/users/42") を毎回「新規採番」として使う
• tenant を namespace に入れず、全顧客共通 namespace + email で発番する
• 同じ論理名を retry ごとに再発番しても、別 ID になると思い込む

これも短いコードで確認できます。Python 3 の標準ライブラリだけで動きます。

# 誤用例: uuid5 を「新規採番」だと思って使う
import uuid

url = "https://example.com/users/42"

first = uuid.uuid5(uuid.NAMESPACE_URL, url)
second = uuid.uuid5(uuid.NAMESPACE_URL, url)
print(first == second)   # True: 何回呼んでも同じ。これは仕様どおりの動き

# しかも、name の正規化がぶれると今度は逆に別 ID になる
with_slash = uuid.uuid5(uuid.NAMESPACE_URL, url + "/")
print(first == with_slash)   # False: 末尾スラッシュ 1 個で別 UUID

# 新規採番がしたいなら、そもそも版が違う
print(uuid.uuid4() != uuid.uuid4())   # True

uuid5 を使うなら、name をどう正規化してから渡すか を先に決めて、その正規化関数を 1 か所に集めるのが安全です。

# 良い例: canonicalization を関数に切り出し、必ずそれを通してから uuid5 に渡す
import uuid

# tenant ごとに namespace を分ける。この値は仕様として固定し、あとから変えない
TENANT_NAMESPACE = uuid.uuid5(uuid.NAMESPACE_DNS, "tenant-a.example.com")


def canonical_user_url(user_id: int) -> str:
    # スキーム、ホスト、末尾スラッシュの有無まで含めて 1 つの形に決める
    return f"https://example.com/users/{user_id}"


def user_uuid(user_id: int) -> uuid.UUID:
    return uuid.uuid5(TENANT_NAMESPACE, canonical_user_url(user_id))


print(user_uuid(42) == user_uuid(42))   # True: 同じ対象なら必ず同じ ID

逆に、name の canonicalization がぶれていると、同じ対象なのに別 UUID になります。RFC も canonical representation の扱いを繰り返し強調しています（Section 5.5、Section 6.5）。⁷¹⁰

この系統で大事なのは、

• UUIDv3 / v5 は「重複しない採番」ではなく「同じ入力なら同じ ID」
• namespace 設計を曖昧にしない
• name の canonicalization を仕様化する

の 3 点です。

6. パターン4: 時刻系 UUID や UUIDv8 を自前実装している

UUIDv1 / v6 / v7 / v8 は、見た目だけ真似すると危ない です。

6.1 UUIDv1 / v6 で node や clock sequence を雑に扱う

RFC 9562 では、UUIDv6 は DB locality 改善のために UUIDv1 を並べ替えたもので、clock sequence や node を扱います（Section 5.6）。さらに、分散環境の node collision resistance（Section 6.4）や state 保持（Section 6.3）について、いくつも注意があります。¹¹⁹¹²

しかも RFC は、仮想マシンやコンテナの登場により、MAC address の一意性はもはや保証されない とまで書いています。⁵

なので、

• MAC アドレスだから一意だろうと決め打ちする
• node ID をイメージ焼き込みで複製する
• clock sequence を再起動ごとに固定値へ戻す

のような設計は危険です。

6.2 UUIDv7 を自作して counter rollover や clock rollback を放置する

UUIDv7 はかなり実用的ですが、RFC は高頻度生成時の monotonicity と counter handling を丁寧に書いています（Section 6.2 Monotonicity and Counters）。clock rollback や counter rollover で重複を knowingly return してはいけない とも明示されています。²¹³

ということは、

• 同一ミリ秒内で大量発番するのに counter 設計がない
• 時刻が戻ったときに何もせず生成を続ける
• 複数プロセスが同じ internal counter を別々に初期化する

といった実装は危ないです。

どのくらいの発番頻度から気にするべきか

「自分のシステムは該当するのか」を判断するには、ビットの割り当てを見るのが早いです。

RFC 9562 の UUIDv7 は、48 ビットのミリ秒タイムスタンプのあとに rand_a（12 ビット）、さらに variant のあとに rand_b（62 ビット）が続く構造です。² そして Section 6.2 では、単調性を保つ方法として、rand_a の 12 ビットを専用カウンタにする方法（Method 1）と、rand_b 側を「ランダムに初期化されたカウンタ」として使う方法（Method 2）、rand_a の最大 12 ビットをミリ秒より細かい時刻精度に置き換える方法（Method 3）が示されています。¹³

ここから、目安はこう読めます。

ここで 12 ビット = 4096 件まで使える、と単純に読まないでください。RFC 9562 は、カウンタを予測されにくくするために tick ごとにランダムな値で初期化することを求めています。¹³ 初期値が 4000 なら、その tick で使えるのは残り 96 件しかありません。1 tick 内で使える件数は「4096 − 初期値」であって、4096 ではありません。

RFC はこの対策として、カウンタの上位ビットを 0 にしておき、初期化するのは下位側だけにする方法を挙げています。¹³ たとえば最上位 1 ビットを 0 に固定して下位 11 ビットだけ乱数にすれば、初期値は最大でも 2047 なので、どの tick でも 2048 件は必ず確保できます。確保できる件数は、カウンタ幅ではなく初期化の許容範囲で決まります。

これを踏まえると、目安はこうなります。

「毎秒数百万件を出さないから rollover は無関係」とは言えません。上限は初期化の設計で決まるので、発番頻度が中程度でも、初期値を 12 ビット全域から取っていれば一周し得ます。rollover したときに何をするかを決めないまま出荷すると、そこで重複が出ます。まず初期化の許容範囲を決め、次に rollover 時の挙動を決める、という順番で設計してください。

ただし、ここで安心して終わらせないほうがよい点が 2 つあります。

• clock rollback は発番頻度と無関係に起きます。 NTP 補正、VM のサスペンド復帰、手動の時刻変更で時刻は普通に戻ります。毎秒 10 件しか作らないシステムでも対策は要ります。
• 「1 生成器あたり」なので、プロセス数を掛ける必要があります。 100 プロセスがそれぞれ独立にカウンタを持ち、しかも同じ初期値から始めるなら、1 プロセスあたりの発番数が少なくても系列は重なります。

6.3 UUIDv8 を「新しい UUID 規格」くらいの軽い気持ちで使う

UUIDv8 は便利そうに見えますが、RFC 9562 はかなりはっきりしていて、UUIDv8 の一意性は実装依存であり、前提にしてはいけない としています（Section 5.8）。³

なので、

• timestamp を埋め込む
• shard id を埋め込む
• 何か業務意味を埋め込む
• 残りは適当に random を入れる

という「自社独自 UUID」は、その設計書が UUID の一意性仕様そのもの です。 レビューなしで入れるには危険すぎます。

7. パターン5: UUID を途中で短くしてしまう

生成までは正しくても、保存や比較の段階で壊してしまうことがあります。

典型例を挙げます。

• 先頭 8 文字だけを外部キー代わりに使う
• 128 ビット UUID を 64 ビット整数へ潰す
• 文字列カラム長が足りず、末尾が切れる
• ログや画面表示の短縮表現を、そのまま一意キー扱いする

ここで大事なのは、表現を変えること自体が悪いわけではない ことです。

• ハイフンを外す
• 小文字 / 大文字をそろえる
• バイナリ 16 バイトで持つ

のように、128 ビットを落とさない変換 は問題ありません。 危ないのは、一意性の材料そのものを削る変換 です。

特に「人が見やすい短縮 ID」を別途作ったのに、それがいつのまにか本来の UUID より優先される設計は事故になりやすいです。

8. パターン6: DB 側に一意制約がない

そして、これが特に重要です。

UUID が十分衝突しにくいとしても、本当に重複を許容できないなら、保存先でも一意制約を持つべき です。

PostgreSQL の公式ドキュメントでは、unique constraint は列や列集合の値が表全体で一意であることを保証し、primary key は unique かつ not null な行識別子になると説明されています。⁶

RFC 9562 も、UUID は実装上十分な一意性を提供できる一方で、真の global uniqueness を絶対保証することはできない としています。さらに collision impact が高い用途では、より強い対策を取るべきとしています（Section 6.7 Collision Resistance、Section 6.8 Global and Local Uniqueness）。¹⁴

実務では、この組み合わせが基本になります。

• UUID は衝突しにくい ID として使う
• DB は UNIQUE / PRIMARY KEY で最終防衛線を持つ
• 重複時の retry / idempotency / incident logging を設計する

UUID を使うことと、一意制約を置かないことは、同義ではありません。

9. 実務向けチェックリスト

最後に、導入や監査でそのまま使いやすい形にまとめます。 1 章の結論表が「何が危ないか」の一覧だったのに対して、こちらは どうやって自分のシステムを確認するか の一覧です。

5 番の確認は、PostgreSQL なら次の 1 本で済みます。

-- public.orders の uuid 列に一意性が張られているかを一覧する。
-- テーブル名と列名は対象に合わせて置き換える
WITH target AS (
    SELECT attrelid, attnum
    FROM   pg_attribute
    WHERE  attrelid = 'public.orders'::regclass
      AND  attname  = 'uuid'                    -- ← 調べたい列
      AND  NOT attisdropped
)
SELECT c.conname                     AS name,
       c.contype::text               AS kind,      -- p = 主キー / u = 一意制約
       array_length(c.conkey, 1) = 1 AS prevents_dup, -- その列だけで重複を防げるか
       pg_get_constraintdef(c.oid)   AS definition
FROM   pg_constraint AS c JOIN target AS t ON c.conrelid = t.attrelid
WHERE  c.contype IN ('p', 'u')
  AND  t.attnum = ANY (c.conkey)                -- その列を鍵に含むものだけ
UNION ALL
SELECT i.relname                     AS name,
       'i'                           AS kind,      -- i = 制約を伴わない一意インデックス
       -- 部分インデックス(indpred が非NULL)は条件に合う行の中でしか一意を保証しない
       x.indnkeyatts = 1 AND x.indpred IS NULL AS prevents_dup,
       pg_get_indexdef(x.indexrelid) AS definition
FROM   pg_index AS x
JOIN   pg_class AS i ON i.oid = x.indexrelid
JOIN   target AS t ON x.indrelid = t.attrelid
WHERE  x.indisunique
  AND  EXISTS (                                 -- INCLUDE 列は鍵ではないので数えない。
         SELECT 1                               -- indkey の先頭 indnkeyatts 個だけを見る
         FROM   generate_series(0, x.indnkeyatts - 1) AS k(i)  -- indkey は 0 始まり
         WHERE  x.indkey[k.i] = t.attnum)
  AND  NOT EXISTS (                             -- 制約に紐づく索引は上で出している
         SELECT 1 FROM pg_constraint AS c2 WHERE c2.conindid = x.indexrelid);

読み方は2段階です。

• kind は主キーが p、一意制約が u、CREATE UNIQUE INDEX で張った制約を伴わない一意インデックスが i です。¹⁵
• prevents_dup が true の行が1つも無ければ、その列の重複は防げていません。

「テーブルに一意制約があるか」で判定しないでください。主キーが連番の id にあるだけで UUID 列は無制約、という設計はごく普通にあります。テーブル単位で数えると、その状態を「最終防衛線あり」と誤って報告します。同じ理由で、UUID を含む複合キーがあっても UUID 単独の重複は通るので、prevents_dup を見る必要があります。

もう1つ、pg_constraint だけを見ないでください。一意性を CREATE UNIQUE INDEX で入れている設計も普通にあり、そちらは pg_index にしか現れません。制約だけ数えて「最終防衛線がない」と報告すると、既にある索引を見落として不要なスキーマ変更へ話が進みます。上の1本なら、どちらの形でも拾えます(indnkeyatts は PostgreSQL 11 以降です)。

インデックス側の判定は、単純に「indkey にその列が入っているか」で書くと2通りの誤検知を出します。どちらも「防げている」と誤って報告する側に倒れるので、そのまま合格印を押すことになります。

• INCLUDE 列を鍵と数えてしまう。CREATE UNIQUE INDEX ... ON orders(id) INCLUDE (uuid) の indkey には、鍵ではない uuid も並びます。¹⁵ 一方 indnkeyatts は鍵の本数(この例では1)なので、indnkeyatts = 1 と uuid を含むことが同時に成立し、id に張った索引が「uuid の重複を防いでいる」ことになります。鍵は indkey の先頭 indnkeyatts 個だけなので、そこに限って照合します(indkey の添字は 0 始まりです¹⁵)
• 部分インデックスを全体の保証と数えてしまう。CREATE UNIQUE INDEX ... ON orders(uuid) WHERE active は、条件に合う行の中でしか一意を保証しません。active でない行どうし、あるいは索引に載る行と載らない行のあいだで、同じ UUID が普通に共存できます。indpred が非NULLならそれが部分インデックスなので、¹⁵ 全体の重複防止としては数えません(索引そのものは一覧に残るので、definition の WHERE 句を見て条件付きの防衛線として扱えます)

10. まとめ

UUID の衝突事故は、たいてい UUID が弱い のではなく、UUID の前提を実装や運用で壊している ところから始まります。

• 弱い乱数で自作する
• fork や snapshot 後の状態を巻き戻す
• name-based UUID を採番用途に使う
• v7 や v8 を軽く自前実装する
• 途中で短縮して一意性を捨てる
• DB 側の一意制約を外す

このあたりをやってしまうと、こちらから衝突しやすい状況を作りに行っている のとほとんど変わりません。

重複を見つけたら、まず疑うべきは UUID の数学より、生成器、状態管理、保存形式、制約設計 です。 その順で見れば、たいてい原因はかなり絞れます。

11. 関連記事

• FileSystemWatcher実務ガイド - 取りこぼしと重複対策
• ファイル連携の排他制御の基礎知識 - ファイルロックと原子的 claim のベストプラクティス

12. 参考資料

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

UUIDは衝突しないのですか？

普通に使えば十分衝突しにくいです。RFC 9562 では UUIDv4 は 122 ビットのランダム領域を持ち、UUIDv7 もタイムスタンプ以外の 74 ビットを一意性のための乱数やカウンタに使う前提で定義されています。Python の uuid4() のように、ちゃんとした実装を普通に使う限り前提はかなり強いです。ただし RFC 9562 自身が、UUID は真の global uniqueness を絶対保証することはできないとしており、衝突の影響が大きい用途ではより強い対策を取るべきとしています。だからこそ DB 側の一意制約が最終防衛線になります。

UUIDの重複はなぜ起きるのですか？

実務で起きる UUID 重複の多くは、規格そのものの問題ではなく、規格が前提にしている生成条件を実装や運用で壊しているケースです。典型パターンは、固定 seed や弱い PRNG で UUID を自作する、fork・VM snapshot・コンテナ複製後に生成器の状態を巻き戻す、UUIDv3 / v5 を「毎回新しい ID」と誤解して使う、時刻系 UUID や UUIDv8 を自前実装して clock rollback や counter を雑に扱う、UUID を途中で切り詰めて一意性を捨てる、DB に一意制約を置かず重複が静かに混入する、の 6 つです。

UUIDv3やUUIDv5を使うと重複するのですか？

UUIDv3 / v5 は衝突しにくいランダム ID ではなく、同じ名前から同じ ID を再生成できる決定論的 ID です。RFC 9562 では、同じ namespace と同じ canonical name から生成した UUID は等しくなければならないと定められているため、同じ入力から同じ UUID が出るのは事故ではなく仕様どおりの動きです。したがって新規採番用途に使うのは誤用です。逆に name の canonicalization がぶれると、同じ対象なのに別 UUID になります。namespace 設計と name の正規化ルールを仕様として明文化することが重要です。

UUIDの重複を防ぐには何をすればよいですか？

まず UUID を自前生成せず、uuid4() / uuid7() のような標準 API か広く使われた実装に寄せます。使う UUID の version を仕様として決め、fork・worker 再起動・snapshot・clone 後に生成器の状態を引き継がないようにします。保存や比較はフル長の 128 ビットを維持し、prefix 比較や短縮表示を本来のキーとして使わないようにします。そのうえで、本当に重複を許容できないなら DB に UNIQUE / PRIMARY KEY 制約を置き、duplicate key を握りつぶさずにどの generator や node で出たか追えるようにしておきます。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。