UUID v4 実践ガイド：生成、保存、よくある落とし穴
UUID v4 の仕組み、他の ID 戦略との使い分け、DB 保存時の注意点、よくある設計ミスを整理します。
UUID v4 は暗号学的に安全な乱数から生成される 128 bit の識別子です。分散システムでは非常に便利ですが、保存効率、可読性、インデックス性能の観点では知っておくべきトレードオフもあります。
UUID の形式と v4 の見分け方
UUID は 8-4-4-4-12 の 16 進文字列で表現されます。たとえば f47ac10b-58cc-4372-a567-0e02b2c3d479 のような形です。
v4 では 3 つ目のグループが常に 4 で始まり、4 つ目のグループは 8、9、a、b のいずれかで始まります。ここを見れば、ランダムベースの UUID v4 かどうかを素早く判定できます。
このセクションで使うツール
データベースで UUID をどう保存するか
文字列のまま VARCHAR(36) に保存する方法は扱いやすい一方で、バイナリ表現より容量効率が悪くなります。PostgreSQL なら native UUID 型、MySQL なら BINARY(16) を使う設計も検討する価値があります。
ただし UUID v4 は完全にランダムなので、B-tree のクラスタ化インデックスでは書き込み位置が散りやすく、断片化が起きやすくなります。高頻度 insert のテーブルでは UUID v7 のような時系列寄りの ID も比較対象に入れるべきです。
このセクションで使うツール
UUID v4 を選ばないほうがよい場面
UUID は一意性に優れますが、36 文字と長く、人間が読んだり入力したりする用途には向いていません。サポート問い合わせや URL 表示で扱いにくいと感じる場面もあります。
可読性や順序性が重要なら、nanoid、CUID2、UUID v7、ULID などの選択肢も検討できます。重要なのは、分散一意性だけでなく、運用時の扱いやすさまで含めて ID 戦略を決めることです。
このセクションで使うツール