ToolDeck の UUID ツール群は、主要な一意識別子フォーマットをすべて一か所に集めています。コレクションには、ランダムな暗号学的に強い ID を生成する UUID v4 Generator、タイムスタンプ順に並べ替え可能な主キーを生成する UUID v7 Generator、時刻と MAC アドレスに基づく識別子を生成する UUID v1 Generator、レガシー DCE システム向けの UUID v2 Generator、MD5 ベースの決定論的 ID を生成する UUID v3 Generator、コンパクトなソート可能文字列を生成する ULID Generator、短い URL セーフなトークンを生成する NanoID Generator、衝突耐性のある元祖フォーマットの CUID Generator、その現代的後継である CUID2 Generator、そして既存識別子を検査する UUID Decoder が含まれます。すべてのツールは Web Crypto API を使ってブラウザ上で完結します——データはいかなるサーバーにも送信されず、アカウントも不要です。
UUID・一意 ID ツールとは？
UUID（Universally Unique Identifier）は RFC 9562（旧 RFC 4122）で標準化された 128 ビットの識別子です。8-4-4-4-12 形式の 32 桁の 16 進数文字列で表され、例えば 550e8400-e29b-41d4-a716-446655440000 のようになります。標準では複数のバージョンが定義されており、それぞれが一意性を保証するための異なる戦略（乱数、タイムスタンプ、決定論的ハッシュ）を採用しています。
UUID は、分散システムが中央コーディネーターなしに識別子を生成できるように設計されました。PostgreSQL で主キーを割り当てる場合も、Web アプリでセッショントークンを生成する場合も、オブジェクトストレージでファイルに名前を付ける場合も、UUID を使えば各ノードが独立してグローバルに一意な ID を生成できます。衝突確率は実用上無視できるほど低いです。
UUID 標準の枠を超えて、特定の制約に対処するための代替一意 ID フォーマットも登場しています。ULID と UUID v7 はデータベースインデックス効率のための辞書順ソート可能性を追加し、NanoID は URL や Cookie 向けにサイズを削減し、CUID2 はクライアントサイドの大量生成における指紋ベースの衝突耐性を優先します。
なぜ ToolDeck の UUID ツールを使うのか？
ToolDeck の UUID ツールはすべてブラウザ上で動作します。API 呼び出しなし、サーバーサイド処理なし、データのログ記録なし。各ジェネレーターは Web Crypto API（crypto.getRandomValues）を使用して暗号学的に強いエントロピーを提供します——ブラウザが TLS 鍵材料に使用するのと同じ源です。
🔐暗号学的に強いエントロピー
ランダムベースのジェネレーター（UUID v4、NanoID、CUID2）はすべて Math.random ではなく crypto.getRandomValues を使用します。出力はセッショントークンや API キーなど、セキュリティが重要なユースケースに適しています。
📦主要な ID フォーマットをすべて一か所に
UUID v1〜v7、ULID、NanoID、CUID、CUID2——開発者が必要とするすべてのフォーマットを、一括生成やワンクリックコピーのオプションとともに提供します。
🔍既存 ID のデコードと検査
UUID Decoder はあらゆる UUID からバージョン、バリアント、タイムスタンプ、ノードフィールドを抽出します。コードベース内のレガシー ID のデバッグ、監査、理解に役立ちます。
⚡セットアップ不要、オフラインでも動作
インストール不要、登録不要、実行時依存なし。ページを開いて生成するだけです。すべてのツールはページ読み込み後にオフラインでも動作します——エアギャップ環境や制限されたネットワークでも有用です。
UUID ツールのユースケース
一意識別子はスタックのあらゆる層に登場します。様々なロールが UUID 生成ツールをどのように活用しているかを紹介します。
データベースの主キー
バックエンドエンジニアは PostgreSQL、MySQL、MongoDB の主キーとして UUID v4 または UUID v7 を使用します。UUID v7 のタイムスタンププレフィックスにより行がディスク上で物理的に整列し、挿入が多いワークロードでのページ分割を回避できます。
フロントエンドの状態とコンポーネント ID
フロントエンド開発者は NanoID または UUID v4 を使って、動的に生成されるリストアイテムの安定した React キー、ARIA アクセシビリティ属性のダイアログ ID、フォーム送信の冪等性トークンを生成します。
分散イベントストリーム
イベント駆動システムでは各イベントにグローバルに一意でソート可能な ID が必要です。DevOps やプラットフォームエンジニアは ULID または UUID v7 を使用し、Kafka コンシューマー、ログアグリゲーター、監査証跡がセカンダリタイムスタンプフィールドなしに作成時刻でソートできるようにします。
テストデータ生成
QA エンジニアは UUID を一括生成して、現実的な非連続 ID でテストデータベースを埋めます。決定論的な UUID v3 または v5 を使えば既知の入力から同じ ID を再生成でき、再現可能なテストフィクスチャに役立ちます。
マイクロサービスの相関 ID
受信する各 HTTP リクエストに UUID を付与してサービス呼び出し間で伝播させる（X-Request-ID ヘッダー）ことで、分散トレーシングシステムがサービスをまたいでログを相関できます。UUID v4 はリクエスト相関のデファクトスタンダードです。
アセットとリソースの命名
オブジェクトストレージ（S3、GCS、Cloudflare R2）のキーや CDN アセットのファイル名には、キャッシュ衝突や URL 推測を防ぐために UUID が埋め込まれることがよくあります。NanoID のコンパクトな 21 文字形式は、完全な 36 文字 UUID と比べて URL の長さを短縮できます。
UUID バージョン・フォーマット リファレンス
下の表はすべての UUID バージョンと最も広く使われている代替フォーマットを比較しています。要件に合うフォーマットを素早く特定するのに活用してください。
| 識別子 | アルゴリズム | ソート可能 | 決定論的 | 最適な用途 |
|---|
| UUID v4 | ランダム（CSPRNG） | — | — | 汎用 ID・セッショントークン・主キー |
| UUID v7 | Unix ミリ秒タイムスタンプ + ランダム | ✓ | — | ソート可能な主キー・分散イベント ID（RFC 9562） |
| UUID v1 | タイムスタンプ + MAC アドレス | ✓ | — | 時刻順 ID・単一ノードシステム・レガシー互換性 |
| UUID v3 | ネームスペース + 名前 + MD5 | — | ✓ | 既知の入力（DNS・URL）から再現可能な ID |
| UUID v5 | ネームスペース + 名前 + SHA-1 | — | ✓ | v3 と同じだがハッシュが強い。v3 より v5 を推奨 |
| UUID v2 | タイムスタンプ + DCE UID/GID | ✓ | — | レガシー POSIX/DCE 環境。新規プロジェクトでは非推奨 |
| ULID | タイムスタンププレフィックス + ランダム | ✓ | — | ソート可能・URL セーフ・ハイフンなし（26 文字） |
| NanoID | ランダム（CSPRNG）・URL セーフ文字セット | — | — | URL・Cookie・HTML 属性向けの短い ID（21 文字） |
| CUID2 | フィンガープリント + タイムスタンプ + ランダム | — | — | 大量クライアントサイド生成・衝突耐性 |
UUID v3 と v5 は決定論的です。同じネームスペース + 名前は常に同じ UUID を生成します。その他のフォーマットは呼び出しごとに新しい値を生成します。
適切な UUID ツールの選び方
適切な識別子はソート可能性・サイズ・決定論性の要件によって異なります。この決定ガイドを活用してください。
- 1
もし 特別な要件のない汎用の一意 ID が必要な場合 → UUID v4 Generator - 2
もし 時系列でソートでき UUID 標準に準拠した ID が必要な場合 → UUID v7 Generator - 3
もし 単一ノードや低並列性システム向けにタイムスタンプ埋め込みの時刻順 ID が必要な場合 → UUID v1 Generator - 4
もし URL セーフでハイフンなしのソート可能な ID が必要な場合 → ULID Generator - 5
もし 完全な UUID より短いコンパクトな URL セーフ ID が必要な場合 → NanoID Generator - 6
もし クライアントサイドで大量に ID を生成し強い衝突耐性が必要な場合 → CUID2 Generator - 7
もし オリジナル仕様に基づく既存システムとの互換性のために CUID v1 フォーマットが必要な場合 → CUID Generator - 8
もし ネームスペースと名前から決定論的に同じ ID を再現する必要がある場合 → UUID v3 Generator - 9
もし v2 識別子を必要とするレガシー DCE または POSIX システムを使用している場合 → UUID v2 Generator - 10
もし 既存の UUID のバージョン・バリアント・タイムスタンプを検査したい場合 → UUID Decoder
UUID v7 と ULID はどちらもミリ秒精度のタイムスタンププレフィックスと辞書順ソート可能性を備えています。重要な違いは、UUID v7 が標準 UUID フォーマット（8-4-4-4-12、36 文字）を使用してエコシステムとの互換性を最大化するのに対し、ULID はカスタム Base32 エンコーディング（26 文字、URL セーフ、ハイフンなし）を使用する点です。データベース・ORM・フレームワークが UUID カラムをネイティブサポートしている場合は UUID v7 を推奨します。フレームワークの制約なしに短い ID が必要な場合は ULID がよりコンパクトです。
よくある質問
UUID とは何ですか？
UUID（Universally Unique Identifier）は RFC 9562 で標準化された 128 ビットの値です。32 桁の 16 進数をハイフンで区切った 5 つのグループで表されます：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。標準では複数のバージョンが定義されており、それぞれ異なる一意性戦略を採用しています——ランダム（v4）、タイムスタンプベース（v1、v7）、名前ベースの決定論的（v3、v5）。
UUID v4 と UUID v7 の違いは何ですか？
UUID v4 は固定でない 122 ビットすべてを暗号学的に安全なソースのランダムデータで埋めます。UUID v7 は最初の 48 ビットに 48 ビットの Unix ミリ秒タイムスタンプをエンコードし、その後にランダムビットが続きます。その結果、UUID v7 は単純な文字列として時系列にソートでき、データベースの B-tree インデックスを挿入時に整列した状態に保ちます。UUID v7 は RFC 9562（2024 年 4 月）で追加され、新しいデータベース主キーに推奨される選択肢です。
UUID v4 の値は暗号学的に安全ですか？
UUID v4 は暗号学的に安全な疑似乱数生成器（CSPRNG）を使って生成されます。セッション ID やパスワードリセットリンクなど、推測不可能なトークンとして適しています。ただし、UUID 自体は秘密ではありません。HMAC も有効期限も特定ユーザーへの紐付けもないため、UUID は不透明な識別子として扱い、認証情報として使用しないでください。
異なる 2 つのシステムが同じ UUID を生成することはありますか？
UUID v4 の衝突確率はペアあたり約 1/2^122 です。何らかの衝突が 50% の確率で発生するには、約 2.7 × 10^18 個の UUID を生成する必要があります——実際のシステムがはるかに超えた量です。UUID v1 と v7 はさらにタイムスタンプやランダムビットを埋め込んでおり、偶発的な衝突はさらに起こりにくくなっています。すべての実用的な目的において、別々のシステムから生成された UUID が衝突することはありません。
UUID はなぜ 36 文字なのですか？
UUID は 128 ビット = 16 バイトです。16 進数でエンコードすると 32 文字になります。UUID フォーマットは可読性を高め、バージョンとバリアントビットを視覚的に識別しやすくするために、固定位置（8・4・4・4 桁の 16 進数グループの後）に 4 つのハイフンを追加し、合計 36 文字になります。ハイフン自体にはデータは含まれていません。
ULID とは何ですか？UUID とどう違いますか？
ULID（Universally Unique Lexicographically Sortable Identifier）は Crockford Base32 でエンコードされた 128 ビットの識別子です（26 文字、大文字小文字を区別しない、ハイフンなし）。最初の 48 ビットで Unix ミリ秒時刻をエンコードし、残りの 80 ビットはランダムです。ULID は単純な文字列として正しくソートでき、UUID よりコンパクトです。UUID RFC の一部ではなく、異なるエンコーディングを使用し、UUID のバージョン/バリアントフィールドを持ちません。
UUID と自動インクリメント整数、どちらを主キーとして使うべきですか？
自動インクリメント整数は順次的・コンパクト・インデックス効率が良いですが、割り当てに中央コーディネーター（データベース）が必要で、分散システムでは機能せず、行数が漏洩します。UUID（特に v7 や ULID）はデータベースへの往復なしにクライアントサイドで生成でき、楽観的インサートや分散書き込みを可能にします。トレードオフはストレージ（16 バイト対 4–8 バイト）とランダム UUID（v4）のインデックス局所性がやや低い点です。UUID v7 と ULID はタイムスタンププレフィックスによってインデックス局所性の問題を解消します。
UUID v3 と UUID v5 の違いは何ですか？
UUID v3 と v5 はどちらも決定論的です。同じネームスペース + 名前のペアに対して常に同じ UUID を生成するため、DNS エントリ・URL・オブジェクト識別子などの再現可能な ID 生成に有用です。唯一の違いはハッシュアルゴリズムで、v3 は MD5（128 ビット、レガシー）を、v5 は SHA-1（160 ビット、128 ビットに切り詰め）を使用します。新規プロジェクトでは UUID v5 を推奨します——どちらのバージョンも暗号ハッシュとして使用されるわけではありませんが、SHA-1 は MD5 より強固です。