UUID 生成ガイド：v4 の一括生成と正しい使い方

UUID が本当に必要な場面

複数の場所が、中央に問い合わせずに ID を発行したいときに UUID は効きます。オフラインで下書きを作るブラウザ、電波の悪い場所で記録を溜めるスマホ、同じテーブルに書き込む複数のサービス、5 つのログをまたぐトレース ID、取引先に渡す推測されにくい識別子などです。共通するのは、誰もデータベースに次の番号を聞きに行きたくない、あるいは行けない状況だという点です。

一方、単一のデータベースで書き込み量が多くないなら、自動採番の bigint のほうが小さく、索引も速く、問い合わせ対応でも読みやすいです。注文番号や追跡番号のように人が読み上げる番号にも向きません。36 文字を電話で正確に伝えるのは無理があります。

• 向いている：分散主キー、オフライン生成、トレース ID、冪等キー、テストデータ
• 向かない：人が読む番号、短縮 URL、招待コード
• 使ってはいけない：パスワード、API キー、セッショントークン

生成と保存でつまずかないために

v4 は 8-4-4-4-12 の 32 桁の 16 進数です。13 文字目は必ず 4（バージョン）、17 文字目は 8・9・a・b のいずれか（バリアント）になります。この 2 か所が違えば、標準の v4 ではありません。

大文字と小文字は同じ値を指しますが、保存前にどちらかに統一してください。大文字小文字を区別する照合順序の列に混在させると、同じ ID が 2 行に分かれて永遠に一致しなくなります。小文字が無難です。Postgres の uuid 型や多くのライブラリの出力が小文字だからです。

• 保存はネイティブの uuid 型、次に binary(16)、最後に char(36)
• 索引のために md5() や substring() で包まない。一意性を性能と引き換えることになります
• 手作業での重複排除は不要です。実際に問題になるのは文字列を切り詰めた場合です
• サービス間でハイフンの有無を揃えてください。揃わないと結合が黙って 0 件になります

限界：順序がばらばら、推測しにくいことは安全ではない

v4 は完全にランダムなので、挿入位置もランダムになります。索引のページ分割が増え、書き込みの多いテーブルでは追記型のキーより遅くなります。UUIDv7 は先頭にミリ秒のタイムスタンプを持ち、ULID も同じ考え方で短い表記に収めています。どちらも作成時刻で並べられます。

もうひとつの誤解は、推測しにくければ安全だというものです。UUID は失効せず、無効化もできず、発行の記録も残りません。パスワード再設定用のトークンや API キーには向きません。それらには有効期限つきで 1 回限り、サーバー側で無効化できる値が必要です。