alltools.one
Development•
2025-07-03
•
7 min
•
alltools.one Team
UUIDIdentifierDatabaseAPIDevelopment

UUIDガイド：バージョン、フォーマット、ベストプラクティス

UUID（Universally Unique Identifier）は、中央管理機関なしで空間的にも時間的にも一意になるように設計された128ビットの識別子です。独立して — 調整なしに — IDを生成する必要がある分散システムにおいて、標準的な選択肢です。

UUIDのフォーマット

UUIDは128ビットの数値で、ハイフンで区切られた5つのグループの32桁の16進数として表示されます：

550e8400-e29b-41d4-a716-446655440000
^^^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^^^^^^^
time-low  mid  hi   clk   node
              +ver  +var
  • 合計: 128ビット（16バイト）
  • 文字列長: 36文字（16進数32文字 + ハイフン4つ）
  • バージョン: 13番目の文字にエンコード（「hi」ニブル）
  • バリアント: 17番目の文字にエンコード

当サイトのUUIDジェネレーターでUUIDを即座に生成できます。

UUIDのバージョン

UUID v1：時間ベース

現在のタイムスタンプとマシンのMACアドレスから生成されます。

// 構造: timestamp (60 bits) + clock sequence (14 bits) + node (48 bits)
6ba7b810-9dad-11d1-80b4-00c04fd430c8

メリット: 作成時間で自然にソート可能、マシンごとの一意性が保証される。 デメリット: MACアドレスが露出する（プライバシーの懸念）、作成時間が判明する可能性がある。 使用場面: 時間順序が必要で、管理された環境にいる場合。

UUID v4：ランダム

暗号学的に安全な乱数から生成されます。最も広く使用されているバージョンです。

// 122ランダムビット（バージョンとバリアントに6ビット予約）
f47ac10b-58cc-4372-a567-0e02b2c3d479

メリット: シンプル、情報漏洩なし、調整不要。 デメリット: ソート不可、大きなテーブルでシーケンシャルIDよりデータベースインデックスのパフォーマンスがやや劣る。 使用場面: 汎用 — ほとんどのアプリケーションでのデフォルトの選択肢。

UUID v7：時間順ランダム（新標準）

最新バージョン（RFC 9562、2024年）で、Unixタイムスタンプとランダムデータを組み合わせています。

// 構造: timestamp (48 bits) + random (74 bits)
018e7b50-4a00-7000-8000-000000000001

メリット: 自然に時間順でソート、優れたデータベースインデックスパフォーマンス、ミリ秒精度以上の情報漏洩なし。 デメリット: 新しいため、一部のライブラリではまだサポートされていない可能性がある。 使用場面: 時系列でソートされる一意のIDが必要な場合 — データベースの主キーに最適。

その他のバージョン

  • UUID v3: 名前空間と名前のMD5ハッシュ。決定論的。
  • UUID v5: 名前空間と名前のSHA-1ハッシュ。決定論的でv3より推奨。
  • UUID v6: ソートしやすいように並べ替えたv1。v7に置き換えられた。
  • Nil UUID: すべてゼロ（00000000-0000-0000-0000-000000000000）。センチネル値として使用。

衝突確率

ランダムに生成された2つのUUID（v4）が衝突する確率はどれくらいでしょうか？122ランダムビットの場合：

  • 10億個のUUIDを生成した後：確率 ≈ 10^18分の1
  • 50%の衝突確率に達するには：約2.7 × 10^18個のUUIDが必要
  • 毎秒10億個のUUIDを生成した場合：約86年かかる

実用上、UUID v4の衝突は起こりません。ハードウェア障害の方がはるかに起こりやすいです。

UUID vs 他のIDフォーマット

フォーマット長さソート可能一意URL安全
UUID v436文字いいえはいはい
UUID v736文字はいはいはい
ULID26文字はいはいはい
nanoid21文字いいえほぼ確実はい
オートインクリメント可変はいテーブル内はい
Snowflake ID18-19文字はいシステム内はい

ULID（Universally Unique Lexicographically Sortable Identifier）

ULIDはコンパクトな代替手段です：48ビットタイムスタンプ + 80ビットランダム、26文字のCrockford Base32でエンコード。作成時間で辞書順にソートされます。

オートインクリメントIDを使うべき場合

シーケンシャルIDは単一データベースアプリケーションにおいてよりシンプルで効率的です。以下の場合にUUIDを使用しましょう：

  • 複数のシステムが独立してIDを生成する必要がある
  • 外部ユーザーに挿入順序を明かしたくない
  • 分散データベースのマージに対応するIDが必要

データベースのパフォーマンス考慮事項

ランダムUUID（v4）はランダムな位置に挿入されるため、B-treeインデックスの断片化を引き起こします。これにより、大きなテーブルではシーケンシャルIDと比較して書き込みパフォーマンスが2〜5倍低下する可能性があります。

解決策:

  1. UUID v7を使用: 時間順のUUIDはシーケンシャルに挿入され、オートインクリメントと同等のパフォーマンス
  2. バイナリで保存: CHAR(36) の代わりに BINARY(16) を使用してストレージを55%節約
  3. ULIDを使用: ソート可能でUUIDよりコンパクト
-- PostgreSQL: ネイティブUUID型（16バイト、効率的）
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL
);

-- MySQL: パフォーマンスのためBINARY(16)で保存
CREATE TABLE users (
  id BINARY(16) PRIMARY KEY,
  name VARCHAR(255) NOT NULL
);

UUIDの生成

コマンドライン

# macOS/Linux
uuidgen

# Python ワンライナー
python3 -c "import uuid; print(uuid.uuid4())"

JavaScript

// ビルトイン（Node.js 19+、モダンブラウザ）
crypto.randomUUID();

// UUID v7の場合（uuidパッケージを使用）
import { v7 } from 'uuid';
const id = v7();

Python

import uuid
uuid.uuid4()  # ランダム
uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')  # 名前ベース

コードなしで素早く生成するには、当サイトのUUIDジェネレーターでブラウザ上で即座にv4 UUIDを作成できます。

FAQ

データベースの主キーにはUUIDとオートインクリメント整数のどちらを使うべきですか？

単一データベースアプリケーションでは、オートインクリメント整数の方がシンプルで高速です。分散システム、マイクロサービス、またはデータベース挿入前にクライアント側でIDを生成する必要がある場合は、UUID（できればv7）がより適した選択肢です。PostgreSQLを使用している場合、ネイティブUUIDサポートによりパフォーマンスの差はほぼ無視できます。

UUIDはセキュリティトークンとして使用できますか？

UUID v4は暗号ソースからの122ビットのランダム性を使用しており、良好なエントロピーを提供します。ただし、セキュリティトークン（APIキー、セッションID）には、チェックサム、有効期限のエンコード、プレフィックス識別などの追加プロパティを持つ、専用のトークン形式を使用する方が望ましいです。UUIDはアイデンティティのためであり、認証のためではありません。

関連リソース

Published on 2025-07-03
← Back to Blog
UUID Guide: Versions, Formats, and Best Practices | alltools.one