UUIDジェネレーター：v1〜v7対応、無料でユニークIDを生成

UUIDとは？

UUID（Universally Unique Identifier：ユニバーサル一意識別子）は、コンピューターシステムで情報を一意に識別するために使用される128ビットの識別子です。UUIDはRFC 4122で標準化されており、その膨大なエントロピーにより、衝突の可能性は実質的にゼロであることが保証されます。つまり、独立して生成された2つのUUIDは、ほぼ確実に一意になります。

UUIDの標準形式はxxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxxです。ここで、各xは16進数（0-9、a-f）を示し、MはUUIDのバージョンを、Nはバリアントを示します。

UUIDのバージョン

UUID v1 (タイムスタンプ + MACアドレス)

UUID v1は、現在のタイムスタンプとランダムな値（ブラウザではMACアドレスの代わりに）に基づいています。1582年10月15日（グレゴリオ暦）からの100ナノ秒間隔を使用します。

使用例:

• UUIDを時系列で並べる必要がある状況
• デバッグとログ記録（UUIDには作成時刻の情報が含まれる）
• 時間同期を伴う分散システム

例: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

利点:

• UUIDを作成時刻で時系列にソートできる
• 監査やデバッグに役立つ
• タイムスタンプ情報を含む

欠点:

• タイムスタンプを含むため、潜在的なセキュリティリスクがある
• ブラウザでは実際のMACアドレスを含まない（ランダムな値に置き換えられる）
• データベースの局所性が低い（タイムスタンプが下位ビットにあるため）

UUID v3 (MD5ハッシュ)

UUID v3は、ネームスペースUUIDと名前のMD5ハッシュを使用して生成されます。決定論的であり、同じネームスペースと名前からは常に同じUUIDが生成されます。

使用例:

• URL、DNS名、またはその他の識別子をUUIDに変換する
• 再現可能なUUIDが必要な状況
• 異なる識別システム間のマッピング

例: a3bb189e-8bf9-3888-9912-ace4e6543002

利点:

• 決定論的（同じ入力からは常に同じ出力）
• 既知の識別子の変換に最適
• 異なる入力に対して衝突がない

欠点:

• MD5は古いアルゴリズムである（v5を推奨）
• ネームスペースと名前が必要
• 元の入力を復元できない

UUID v4 (ランダム) - 推奨

最も広く使用されているUUIDのバージョンです。UUID v4は、暗号学的に安全な乱数ジェネレーター（crypto.getRandomValues()）を使用して完全にランダムに生成されます。

使用例:

• データベースの主キー
• セッションID
• 一意のファイル名
• APIトークン
• 確実に一意のIDが必要な一般的な目的

例: f47ac10b-58cc-4372-a567-0e02b2c3d479

利点:

• 最大限のエントロピーとセキュリティ
• 時間やシステムパラメータに依存しない
• 最もシンプルな実装

衝突の確率: 1秒間に10億個のUUIDを100年間生成し続けても、衝突の確率は約0.00000006%です。

UUID v5 (SHA-1ハッシュ)

UUID v5はv3と同じですが、MD5の代わりにSHA-1を使用します。v3よりも近代的で安全な代替手段です。

使用例:

• v3と同じですが、セキュリティが向上
• 新しいプロジェクトではv3よりも推奨される
• URL、DNS名、OID、X.500 DNからUUIDを生成する

例: 886313e1-3b8a-5372-9b90-0c9aee199e5d

利点:

• 決定論的
• SHA-1はMD5よりも堅牢
• システム間のマッピングに適している

欠点:

• SHA-1も古いと見なされている（ただしMD5よりは安全）
• ネームスペースと名前が必要

UUID v6 (ソート可能なタイムスタンプ)

UUID v6は、データベースのインデックス作成を改善するために時間ビットが再配置されたv1の改良版です。データベースの局所性に関する問題を解決するために設計されました。

使用例:

• タイムスタンプ順のデータベース主キー
• 時系列順とデータベースパフォーマンスの両方が必要なシステム
• v1のより現代的な代替手段

例: 1ec9414c-232a-6b00-b3c8-9e6bdeced846

利点:

• v1よりもデータベースの局所性が向上（タイムスタンプが上位ビットにある）
• 時系列順にソート可能
• UUID標準と互換性がある

欠点:

• v1/v4ほど広く使用されていない
• 依然として時間情報を含む（セキュリティリスク）

UUID v7 (Unixタイムスタンプ)

UUID v7は、Unixタイムスタンプ（1970年からのミリ秒）とランダムビットを使用します。データベースの局所性が最も優れた最新のUUIDバージョンです。

使用例:

• 現代的なデータベース主キー
• パフォーマンスと時系列順の両方が必要なシステム
• 新しいプロジェクトにおけるv1/v6の代替

例: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f

利点:

• 全バージョンの中で最高のデータベース局所性
• Unixタイムスタンプは標準的
• ランダム性と時系列順の利点を組み合わせる

欠点:

• 比較的新しい仕様（RFC 4122bis）
• レガシーシステムでのサポートが少ない

どのUUIDバージョンを使用すべきか？

決定ガイド

最大限のセキュリティとランダム性が必要ですか？ → UUID v4 を使用してください（最も一般的な選択肢）

時系列順とデータベースパフォーマンスが必要ですか？ → UUID v7 (現代的) または UUID v6 (標準) を使用してください

既存の識別子から再現可能なUUIDが必要ですか？ → UUID v5 (SHA-1) または UUID v3 (MD5, レガシー) を使用してください

タイムスタンプと監査証跡が必要ですか？ → UUID v1 (レガシー、DBパフォーマンスが低い) を使用してください

データベース

新しいプロジェクトの場合: UUID v7またはv4

• v7 は時系列順とパフォーマンスに最適
• v4 は時間情報を含まない最大限のランダム性を提供

レガシーシステムの場合: UUID v1またはv6

• v6 はv1よりもデータベースの局所性が向上
• v1 は広くサポートされている

UUIDを主キーとして使用する利点:

• グローバルな一意性 – 異なるデータベースからデータを衝突なく結合できる
• セキュリティ – シーケンシャルID（1, 2, 3…）とは異なり、次の値を推測できない
• 分散システム – 複数のサーバーで調整なしに独立してUUIDを生成できる
• データベースのマージ – 2つのデータベースをマージする際に衝突が発生しない

欠点:

• サイズが大きい（整数型が4-8バイトなのに対し16バイト）
• 一部のデータベースではインデックス作成が遅い（パフォーマンス向上のためにv6/v7を使用）
• 人間にとっては読みにくい

APIとWebサービス

• REST API – リソースの一意の識別子
• GraphQL – ノードのグローバルな識別子
• Webhook – リクエストと応答の追跡
• トークン – セッションID、リフレッシュトークン

ファイルとストレージ

• ファイル名 – アップロード時の衝突防止
• S3/クラウドストレージ – オブジェクトの一意のパス
• キャッシュキー – キャッシュシステム内の識別子

フロントエンドアプリケーション

• React/Vueコンポーネント – リストの一意のキー
• 一時ID – データベースに保存する前のID
• ローカルストレージ – 保存されたデータのキー
• オフラインファーストアプリケーション – サーバーへの接続なしでのID生成

高度なジェネレーター機能

カスタム時間でのUUID生成

時間ベースのバージョン（v1、v6、v7）では、日付/時刻ピッカーを使用して任意のタイムスタンプを選択できます。これは以下の目的で役立ちます。

テスト:

• 過去に作成されたUUIDのシミュレーション
• データベースにおける時系列順のテスト
• デバッグのためのUUIDの再現

データ移行:

• 過去のタイムスタンプを持つUUIDの生成
• 正しいタイムスタンプ値を持つデータのバックフィル
• 異なる期間からのデータのインポート

監査とコンプライアンス:

• 記録作成時刻に基づくUUIDの再構築
• 遡及的な識別子の生成

使用例:

1. v1、v6、またはv7のバージョンを選択します
2. 日付/時刻ピッカーを使用して日付と時刻を設定します
3. 独自のタイムスタンプでUUIDを生成します

ハッシュベースUUID (v3, v5)

決定論的なUUIDには、v3（MD5）またはv5（SHA-1）のバージョンを使用できます。

使用方法:

1. 識別子のタイプに基づいてネームスペースを選択します
2. 名前/値を入力します
3. UUIDを生成します

例:

重要な特性:

• ✅ 決定論的: 同じ入力からは常に同じUUIDが生成される
• ✅ 再現可能: いつでもUUIDを再作成できる
• ✅ 一貫性: 異なるシステム間で同じUUIDを生成できる
• ❌ デコード不可: UUIDから元の名前を復元することはできない
• ℹ️ 単一UUID: v3/v5では、常に1つのUUIDのみが生成される（同じ入力からは同じ出力）

実用的な使用例:

// 例: URLをUUID v5に変換
Namespace: URL
Name: https://example.com/api/users/123
Result: 886313e1-3b8a-5372-9b90-0c9aee199e5d

// 同じ入力からは常に同じUUID
Namespace: DNS
Name: google.com
Result: google.comに対しては常に同じUUIDが生成される

UUIDを安全に使用する方法

暗号学的セキュリティ

当社のジェネレーターは、暗号学的に安全な乱数ジェネレーターであるcrypto.getRandomValues()を使用しています。予測可能でありセキュリティ目的に適さないMath.random()とは異なり、crypto.getRandomValues()は以下に適した真のエントロピーを提供します。

• セキュリティトークンの生成
• セッションID
• APIキー
• 暗号化アプリケーション

UUIDバージョンの比較

UUIDと他の識別子の比較

各種言語での実装

JavaScript/TypeScript

// UUID v4 - 最も簡単な方法 (モダンブラウザ)
const uuid = crypto.randomUUID();

// UUID v4 - 手動実装
function generateUUIDv4() {
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, (c) => {
    const r = (crypto.getRandomValues(new Uint8Array(1))[0] & 0x0f) >> (c === 'x' ? 0 : 2);
    const v = c === 'x' ? r : (r & 0x3) | 0x8;
    return v.toString(16);
  });
}

// UUID v7 - データベース向け推奨
function generateUUIDv7() {
  const timestamp = Date.now();
  const timeHi = (timestamp >> 16).toString(16).padStart(8, '0');
  const timeLow = (timestamp & 0xFFFF).toString(16).padStart(4, '0');

  const randomBytes = crypto.getRandomValues(new Uint8Array(10));
  const randomHex = Array.from(randomBytes)
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');

  return `${timeHi}-${timeLow}-7${randomHex.substr(0, 3)}-${randomHex.substr(3, 4)}-${randomHex.substr(7)}`;
}

Python

import uuid

# UUID v4
uuid_v4 = str(uuid.uuid4())
# Output: '6ba7b810-9dad-11d1-80b4-00c04fd430c8'

# UUID v1
uuid_v1 = str(uuid.uuid1())

Java

import java.util.UUID;

// UUID v4
String uuidV4 = UUID.randomUUID().toString();

PHP

// UUID v4 (PHP 7+)
function generateUUID() {
    return sprintf('%04x%04x-%04x-%04x-%04x-%04x%04x%04x',
        mt_rand(0, 0xffff), mt_rand(0, 0xffff),
        mt_rand(0, 0xffff),
        mt_rand(0, 0x0fff) | 0x4000,
        mt_rand(0, 0x3fff) | 0x8000,
        mt_rand(0, 0xffff), mt_rand(0, 0xffff), mt_rand(0, 0xffff)
    );
}

C#

using System;

// UUID v4
Guid uuid = Guid.NewGuid();
string uuidString = uuid.ToString();

ベストプラクティス

データベースへのUUIDの保存

PostgreSQL:

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

MySQL 8.0+:

CREATE TABLE users (
    id BINARY(16) PRIMARY KEY DEFAULT (UUID_TO_BIN(UUID())),
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

ヒント: MySQLでは、スペースを節約し、より高速なインデックス作成のために、UUIDをCHAR(36)ではなくBINARY(16)として保存してください。

UUIDの検証

function isValidUUID(uuid) {
  const regex = /^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
  return regex.test(uuid);
}

UUIDの変換

// ハイフンの削除
const compact = uuid.replace(/-/g, '');

// ハイフンを再度追加
function formatUUID(compactUuid) {
  return [
    compactUuid.substring(0, 8),
    compactUuid.substring(8, 12),
    compactUuid.substring(12, 16),
    compactUuid.substring(16, 20),
    compactUuid.substring(20, 32)
  ].join('-');
}

トラブルシューティング

UUID v3/v5が動作しない場合

問題: v3またはv5を選択しても何も生成されない

解決策:

1. ✅ 「名前」フィールドが入力されていることを確認してください - 必須です！
2. ✅ 入力のタイプに応じて正しいネームスペースを選択してください
3. ✅ 有効な入力の例:
   • DNS: example.com, google.com
   • URL: https://example.com/page
   • 任意のテキスト: my-application-v1

ヒント: まずはtestのような単純な値とDNSネームスペースを試してみてください。

時間ベースのUUID (v1, v6, v7) の時刻がおかしい場合

問題: 生成されたUUIDが予期しないタイムスタンプを持っている

解決策:

1. ✅ 日付/時刻ピッカーを確認してください - 正しい時刻が設定されていますか？
2. ✅ 日付/時刻ピッカーはあなたのローカルタイムゾーンを使用します
3. ✅ 現在の時刻を使用するには、日付/時刻ピッカーを空のままにしてください

UUIDがコピーできない場合

問題: 「すべてコピー」ボタンが機能しない

解決策:

1. ✅ UUIDが生成されていることを確認してください（空ではないことを確認）
2. ✅ 一部のブラウザでは、Clipboard APIにHTTPSが必要です
3. ✅ または、テキストエリア内のテキストを選択して手動でコピーしてください (Ctrl+C)

よくある質問 (FAQ)

UUIDの代替案

ULID (Universally Unique Lexicographically Sortable Identifier)

• 128ビットID（UUIDと同様）
• 作成時刻に基づいて辞書順にソート可能
• よりコンパクトな表現（36文字の代わりに26文字）
• 大文字と小文字を区別しないBase32エンコーディング

例: 01ARZ3NDEKTSV4RRFFQ69G5FAV

NanoID

• UUIDよりも小さいサイズ（標準で21文字）
• URLフレンドリー（特殊文字なし）
• より高速な生成
• 長さとアルファベットを設定可能

例: V1StGXR8_Z5jdHi6B-myT

Snowflake ID (Twitter)

• 64ビットID（UUIDよりも小さい）
• 時系列順にソート可能
• ワーカーIDとシーケンス番号を含む
• 一元化された構成が必要

例: 1234567890123456789

パフォーマンスと最適化

生成速度

当社のジェネレーターは以下を生成できます。

• 1 UUID: < 1 ms
• 100 UUID: 約10-20 ms
• 1000 UUID: 約100-200 ms

パフォーマンス向上のヒント

1. バッチ生成 – 多数のUUIDが必要な場合は、1つずつではなく一度に生成してください
2. DBへの保存 – 高速検索のためにUUID列にインデックスを作成してください
3. 圧縮 – UUIDを文字列（36バイト）ではなくバイナリ形式（16バイト）で保存してください
4. キャッシュ – 場合によっては、UUIDを事前に生成してキャッシュすることができます

開発者向け

UUID v4の構造

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
|        |    |    |    |
|        |    |    |    └─ 48ビットのランダムデータ (node)
|        |    |    └────── 16ビットのランダムデータとバリアント (clock_seq)からの4ビット
|        |    └─────────── 12ビットのランダムデータ + 4ビットのバージョン (time_hi_and_version)からの4ビット
|        └──────────────── 16ビットのランダムデータ (time_mid)
└───────────────────────── 32ビットのランダムデータ (time_low)

• バージョン (4ビット): 常に0100 (バイナリ) = 4 (16進数)
• バリアント (2-3ビット): RFC 4122では常に10 (バイナリ)

UUIDのテスト

// Jestテスト
describe('UUID Generator', () => {
  test('valid UUID v4を生成する', () => {
    const uuid = generateUUIDv4();
    const regex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
    expect(regex.test(uuid)).toBe(true);
  });

  test('一意のUUIDを生成する', () => {
    const uuid1 = generateUUIDv4();
    const uuid2 = generateUUIDv4();
    expect(uuid1).not.toBe(uuid2);
  });
});

セキュリティの側面

UUIDでしてはいけないこと

❌ 機密性の高いアプリケーションにUUID v1を使用しないでください – タイムスタンプが含まれており、セキュリティリスクとなる可能性があります

❌ UUIDの生成にMath.random()を使用しないでください – 暗号学的に安全ではありません

❌ 承認のためにUUIDに依存しないでください – UUIDは推測される可能性があります（極めて低い確率ですが）

❌ UUIDを暗号化せずにCookieに保存しないでください – 署名付きCookieまたはJWTを使用してください

するべきこと

✅ ほとんどの場合、UUID v4を使用してください – 最高の乱数性とセキュリティ

✅ UUIDを他のセキュリティ対策と組み合わせてください – セッション管理にはHTTPS、HttpOnly Cookie、短い有効期限を使用してください

✅ サーバー側でUUIDを検証してください – 常にUUIDの形式とバージョンを確認してください

✅ 暗号学的に安全な乱数源を使用してください – ブラウザではcrypto.getRandomValues()、Linuxでは/dev/urandom

豆知識

• 可能なUUID v4の数: 2^122 ≈ 5.3 × 10^36 (340ウンデシリアン)
• 衝突に必要な数: 衝突の確率が50%になるには、2.71 × 10^18個のUUID（2.71クインティリオン）を生成する必要があります
• 可能なすべてのUUIDのサイズ: 各UUIDを16バイトとして保存した場合、全空間は85ゼタバイト（850億テラバイト）を占めます
• 起源: UUIDは1990年にDCE（Distributed Computing Environment）の一部として標準化されました