UUID 一括生成のガイド：主キーには使えるが、トークンには使えない
UUID が解くのは「複数の場所がそれぞれ ID を作っても衝突しない」ことです。「誰にも推測できない秘密を作る」ことではありません。この2つはよく混同されます。
一括生成の用途
テスト用データベースへの投入、ログへのトレース ID 付与、オフラインで作った下書きへの主キー、複数サービス間の冪等キー。共通するのは、データベースに採番を聞きに行かずに、重複だけは避けたいという点です。
数十個をまとめて生成し、SQL や JSON に貼れば完了です。生成順は作成時刻と無関係なので、生成結果と投入行を突き合わせるときは注意してください。生成順を業務順と取り違えないようにしてください。
- テストデータ、シードデータの主キー
- ログのトレース ID、リクエストの関連付け
- オフライン下書き、複数ライターの冪等キー
形式、バージョン、保存
v4 は16進数32文字とハイフン4つです。13文字目は必ず 4 でバージョン、17文字目は 8、9、a、b のいずれかでバリアントを表します。出力は小文字です。乱数は crypto.randomUUID() を使い、利用できない場合は crypto.getRandomValues() に切り替えます。
保存はネイティブの uuid 型が第一、次が binary(16)、char(36) は最後の手段です。大文字小文字は投入前に統一してください。大文字小文字を区別する照合順序では、同じ ID が別の行になります。
- 8-4-4-4-12、13文字目は 4
- 投入前に小文字へ統一
- uuid 型、binary(16)、char(36) の順
境界：ランダム、無秩序、非機密
v4 は完全にランダムなので、挿入位置もばらけます。書き込みの多い表ではインデックスのページ分割が増え、連番主キーより遅く、容量も増えます。一意性と緩やかな順序の両立なら、時刻を先頭に置く UUIDv7 や ULID が候補です。
セキュリティトークンでもありません。有効期限も失効も発行者もなく、漏れても無効化できません。招待コード、パスワード再設定リンク、API キーには、サーバが発行する単回・期限付きの乱数が必要です。
- ランダム主キーは書き込みを遅くし、容量も増やす
- 緩やかな順序が必要なら UUIDv7 か ULID
- 期限も失効もない。トークンには使えない
よくある質問
一括生成で重複しますか
122ビットの乱数があるため、工学的には起こらないと考えて構いません。実際の重複は、文字列の切り詰めや時刻と連番の組み合わせによるものがほとんどです。
パスワードや招待コードに使えますか
使えません。期限も失効も監査記録もなく、漏れたら取り消せません。36文字は人間が入力するにも長すぎます。サーバ発行の単回トークンを使ってください。
UUID で並べ替えできないのはなぜですか
v4 のビットは完全にランダムで、辞書順と作成時刻が無関係だからです。時刻順が必要なら UUIDv7 や ULID を使うか、作成日時の列を別に保存してください。
関連ツール：UUID一括生成ツール