UUID / ULID / Nano ID 生成器無料・登録不要

UUID 生成器が解決する課題

開発・テストデータ作成・DB 移行・モック作成で「衝突しない ID が大量に必要」な場面は頻発します。オンライン UUID ジェネレータは多いですが、UUID v4 だけしか出ない / 大量生成不可 / Nano ID / ULID 未対応 / 用途別の選び方が書いてない、というのが現実。本ツールは UUID v4 / v7 / ULID / Nano ID の 4 種を最大 500 件一括生成 + 用途別選択ガイド付きで、本番システム設計時にもそのまま使えます。

4 つの ID 形式の違い

【UUID v4】完全ランダム 128bit。RFC 4122。一般用途の鉄板だが時刻順序性ゼロ → DB 主キーに使うと B-tree インデックスがフラグメンテーション。

【UUID v7】時刻 48bit + ランダム 74bit + バージョン/バリアント 6bit。RFC 9562（2024 標準化）。時刻順ソート可。新規プロジェクトの主キーは v7 推奨。

【ULID】128bit・Crockford Base32（小文字 lo / 0 O / 1 I 排除）・時刻順。Stripe 等が採用。URL や CLI で読みやすい。

【Nano ID】URL セーフ文字（A-Z a-z 0-9 _ -）。21 文字 ≒ UUID と同等衝突安全性。短い ID が欲しい URL slug / 認証トークン向け。

こんなシーンで使えます

【1. DB シードデータ作成】テスト環境で 100-500 件のユーザー / 注文データの ID を一括生成。

【2. 主キー設計検討】v4 と v7 を比較してパフォーマンステスト用のサンプル ID を準備。

【3. 認証トークン / リフレッシュトークン】サーバーレス関数 / Edge Function で発行する Bearer トークンの形式検討。

【4. URL slug 設計】Nano ID 21 文字で重複なしの URL（YouTube / Notion 形式）を試作。

【5. 分散システム ID 設計】ULID / UUID v7 の時刻順性能を実 ID で比較検証。

【6. SaaS API キー設計】Nano ID + プレフィックス（例: `sk_live_XXX`）で Stripe 形式のキー設計を試作。

用途別 推奨選択

【RDB の主キー】UUID v7 > ULID > UUID v4。v4 はインデックス劣化を覚悟。

【URL slug / 短い ID】Nano ID 12-21 文字。UUID v4 / ULID は長すぎる。

【公開 API のリソース ID】ULID。読みやすさ + 時刻順 + 36 文字以内。Stripe / Vercel が採用。

【内部システム / ログ trace ID】UUID v7。Datadog / Tempo / Honeycomb で時刻順検索が効く。

【セッショントークン / CSRF トークン】Nano ID 32 文字 or crypto.randomUUID()。ハッシュ生成と組み合わせ。

よくある失敗と注意点

1つ目: UUID v4 を主キーにしてインデックス劣化 → 数百万件規模で INSERT 遅延。v7 / ULID に移行。

2つ目: Math.random() で UUID 生成 → 衝突確率が暗号学的に保証されない。<b>必ず crypto.getRandomValues() か crypto.randomUUID() を使う</b>。

3つ目: Nano ID 短くしすぎ → 8 文字だと 1 万件で衝突確率 1% 超。最低 14-16 文字。

4つ目: UUID を Excel に貼り付け → 数値化される / 自動変換される問題。最初に「テキスト形式」に設定。

5つ目: UUID v1 を顧客向け表示 → MAC アドレスが ID に埋め込まれる古い仕様。v1 は新規採用避けるべき（本ツールは v1 提供せず）。

プライバシー・セキュリティ

全 ID 生成は <b>ブラウザ内 crypto.getRandomValues</b> で完結。サーバーへの送信・ログ記録・トラッキングは一切ありません。本番システムで使う ID をそのまま生成可能。crypto API は CSPRNG（暗号学的擬似乱数生成器）を使うため、出力された UUID v4 の衝突安全性は仕様通り保証されます。