UUIDとは？v4の仕組みと使いどころ

UUID(Universally Unique Identifier)は、世界中で重複しないことを目的に設計された 128 ビットの識別子です。データベースの主キー、ファイル名、API のリクエスト ID など、「他とかぶらない ID がほしい」場面で広く使われます。この記事では、最もよく使われる v4 を中心に、その仕組みと使いどころを解説します。

UUID の形式

UUID は 16 進数を 8-4-4-4-12 の 5 グループに区切ったハイフン区切りの文字列で表されます(例: 123e4567-e89b-42d3-a456-556642440000)。全体で 32 桁の 16 進数、つまり 128 ビットの情報を持ちます。バージョンやバリアントを示す一部のビットは固定されています。

v4 は「ほぼ乱数」

v4 UUID は、バージョン・バリアントを示すビットを除いた 122 ビットをランダムに決めます。良質な乱数(暗号学的乱数)を使えば、現実的な生成量では衝突(重複)の確率は無視できるほど小さくなります。当サイトの UUID 生成ツールはブラウザの crypto.randomUUID() を使い、暗号学的に安全な v4 を生成します。

連番IDとの違い

• 連番(1,2,3…)は短く読みやすいが、全体で採番を調整する必要があり、分散システムでは衝突しやすい
• UUID は事前調整なしに各所で独立生成でき、分散環境やオフライン生成に強い
• UUID は長く、連番のように「件数」や「順序」を推測されにくい(情報が漏れにくい)
• 一方で UUID は長く、そのままだと URL やログが読みづらくなる

使いどころと注意点

UUID は、複数のサーバーやクライアントが独立して ID を発行する場面、推測されにくい ID がほしい場面に向いています。ただし v4 は乱数ベースのため並び順に意味がなく、データベースのインデックス効率の観点では連番より不利なことがあります。用途に応じて使い分けるとよいでしょう。UUID はランダムな識別子であって秘密情報ではないため、認証トークンの代わりには使わないでください。

新しい標準 RFC 9562 と v7

UUID の仕様は 2024 年 5 月に RFC 9562 として更新され、従来の RFC 4122 を置き換えました。新たに v6・v7・v8 が標準化され、これまでの v1・v3・v4・v5 は引き続き有効です。中でも実用面で注目されているのが v7 です。

v7 は、先頭に 48 ビットの Unix 時刻（ミリ秒）を置き、残りをランダムにした「時間順に並ぶ」UUID です。v4 が完全なランダムで並び順に意味を持たないのに対し、v7 は生成した順にほぼ整列するため、データベースの主キーに使ったときのインデックス効率が良くなります。RFC 9562 では v1 や v6 より v7 の利用が推奨されていますが、すべての用途で v4 を v7 に置き換える必要はない、ともされています。

• v4 … 完全ランダム。推測されにくく、順序の情報が漏れない。分散生成やオフライン生成向け。
• v7 … 時間順にソート可能。挿入順に並ぶと効率が良いデータベース主キーなどに向く。先頭に生成時刻の情報を含む点には留意。

実際に生成するには UUID 生成ツールが便利です。まとめて複数個作ることもでき、すべてブラウザ内で処理されます。データの同一性チェックやフィンガープリントには、あわせてハッシュ生成ツールも役立ちます。

参考: RFC 9562（Universally Unique IDentifiers (UUIDs)、2024 年）。バージョンの仕様に関する記述はこの標準に基づいています。