UUIDとは｜v1とv4の違い・一意性の仕組み・衝突確率をやさしく解説

APIのレスポンスやデータベースのレコードで「550e8400-e29b-41d4-a716-446655440000」のような、ハイフンで区切られた長い文字列を見たことはないでしょうか。これがUUIDです。一見ランダムに並んだ記号の羅列ですが、実は「世界中の誰が、いつ、どこで作っても重複しない識別子」を作るための、よく設計された仕組みです。本記事では、UUIDとは何か、どんな構造を持ち、なぜ重複しないのかを順を追って解説します。

UUIDとは何か

UUID（Universally Unique Identifier、汎用一意識別子）とは、ソフトウェアの世界でデータやオブジェクトを一意に識別するための128ビットの値です。GUID（Globally Unique Identifier）と呼ばれることもありますが、ほぼ同じものを指します。仕様はRFC 4122として標準化されており、多くのプログラミング言語やデータベースが標準で生成機能を備えています。

UUIDの最大の特徴は、中央の発番サーバーに問い合わせなくても、それぞれの端末やプログラムが勝手に生成して構わない点です。それでいて、生成された値が他と重複する可能性は無視できるほど小さく抑えられています。複数のサーバーやデバイスが同時並行で識別子を作る現代の分散システムにおいて、この「調整なしで一意」という性質は非常に大きな価値を持ちます。

実際にどんな値が生成されるのかは、UUID生成ツールで何度かボタンを押して確かめてみるのが分かりやすいでしょう。押すたびに、まったく異なる値がいくつでも得られることが体感できます。

UUIDの構造：128ビットと表記

UUIDは128ビット（16バイト）の数値です。そのままでは扱いにくいため、通常は16進数に変換し、8-4-4-4-12の桁数でハイフンを挟んだ36文字の文字列として表記します。

550e8400-e29b-41d4-a716-446655440000

ハイフンを除けば32桁の16進数で、これが128ビットに対応します。この文字列の中には、単なるランダムなビットだけでなく、いくつかの意味を持つ領域が含まれています。

• バージョン：3番目のブロックの先頭1桁が、そのUUIDがどの方式で作られたか（バージョン）を示します。上の例では「4」なので、バージョン4のUUIDです。
• バリアント：4番目のブロックの先頭の数桁が、UUIDのレイアウト方式（バリアント）を示します。RFC 4122に従うものは通常8・9・a・bのいずれかで始まります。

つまり、見た目はランダムな文字列でも、特定の桁には決まった意味が埋め込まれています。残りのビットが、識別子としての一意性を担う本体部分です。

v1とv4の違い

UUIDには複数のバージョンがあり、生成方法が異なります。実務でよく使われるのはv1とv4の2つです。

v1（時刻ベース）は、生成した時刻と、端末を識別するノード情報（歴史的にはネットワークカードのMACアドレス）を組み合わせて作られます。時刻が含まれるため、おおまかに「いつ作られたか」という順序を持たせやすい利点があります。一方で、生成元の端末情報や生成時刻がUUIDから推測されうるという側面もあります。

v4（乱数ベース）は、バージョンとバリアントを示す数ビットを除いた122ビットを乱数で埋める方式です。生成に外部情報を必要とせず、値から生成環境や時刻を読み取られにくいため、現在もっとも広く使われています。単に「UUID」と言えばv4を指すことが多く、特別な理由がなければv4を選ぶのが無難です。

このほか、名前から決定的に生成するv3・v5や、時刻順にソート可能で乱数も含む新しいv7なども存在します。用途によっては「時刻順に並ぶ」性質が役立つため、近年はv7が注目される場面も増えています。

なぜ重複しないのか：一意性の理屈と衝突確率

UUIDが調整なしで一意になれる理由は、取りうる値の数が天文学的に大きいことにあります。v4の場合、ランダムに決まるのは122ビットなので、組み合わせの数はおよそ5.3×10の36乗（約53澗）通りに達します。これは、地球上の砂粒の数をはるかに超える規模です。

この広大な空間からランダムに値を選べば、たまたま同じ値（衝突）を引く確率は極端に小さくなります。確率論には「誕生日のパラドックス」という、同じ値が出る確率は直感より高くなるという考え方がありますが、それを踏まえても、現実的な規模では衝突はまず起きません。一説には、毎秒10億個のUUIDを約85年間生成し続けて、ようやく1回の衝突が起きるかどうかという確率だと表現されます。

ここで大切なのは、UUIDの一意性は「絶対に重複しないことが保証されている」のではなく、「重複する確率が無視できるほど小さい」という確率的な一意性だという点です。だからこそ、品質の高い乱数生成器を使うことが重要になります。

• v4の一意性は、乱数の質に依存します。偏った乱数を使えば衝突の確率は上がります。
• v1は時刻とノード情報の組み合わせで一意性を担保するため、同じ端末で同時刻に大量生成する際の扱いに注意が必要です。

実際にいくつもの値を生成して「毎回まったく違う値になる」感覚をつかむには、UUID生成ツールでまとめて発行してみるのが分かりやすいでしょう。

何に使うのか：主キーと分散識別子

UUIDの代表的な用途は、識別子（ID）が必要なあらゆる場面です。中でも次のようなケースで威力を発揮します。

1. データベースの主キー

レコードを一意に識別する主キーにUUIDを使うと、レコードを作る前にアプリケーション側でIDを決められます。データベースに挿入して採番される連番を待つ必要がなく、複数のサービスやデバイスがそれぞれIDを生成してもぶつかりません。これは、サーバーを分けてデータを分散させる（シャーディングする）構成と特に相性が良い性質です。

2. 分散システム・外部公開IDの識別子

マイクロサービスのように複数のシステムが連携する環境では、各システムが独立してIDを発番できることが重要です。UUIDなら中央の発番役を置かずに済むため、システム同士の結合をゆるくできます。また、URLやAPIで外部に見せるIDにUUID（特にv4）を使えば、連番のように「次のID」や「総件数」を推測されにくいという利点もあります。

連番（オートインクリメント）との違い

IDの付け方として、UUIDと並んでよく使われるのが連番（オートインクリメント）です。1、2、3…と順に増えていく、おなじみの方式です。両者には明確な得意・不得意があります。

連番は短く、人間が読み書きしやすく、データベース内で順序を持つため索引（インデックス）の効率も良好です。一方で、生成にデータベースの採番が必要なため、複数拠点で分散して作るのには工夫が要ります。また、IDを見れば「だいたい何件目か」が分かってしまうため、外部公開には不向きな場合があります。

UUIDはその逆で、どこでも生成でき推測されにくい反面、長くて読みづらく、ランダムなv4は索引の局所性が悪化してデータベース性能に影響することがあります。そのため近年は、時刻順に並ぶv7のように「分散で生成でき、かつ順序性も持つ」中間的な選択肢も使われ始めています。どちらが優れているという話ではなく、システムの要件に応じて使い分けるのが正解です。

UUIDは、128ビットという広大な空間と確率的な一意性によって、調整なしで重複しない識別子を実現する基礎技術です。まずはUUID生成ツールで実際に値を生成し、毎回まったく違う文字列が得られる様子や、バージョンを示す桁の位置を確かめてみてください。仕組みを目で見て触れることが、理解への近道です。

なお本記事は一般的な情報の提供を目的としたものです。実際のシステムでどのID方式を採用するかは、性能・セキュリティ・運用要件によって最適解が変わります。最新の公式仕様やドキュメント、必要に応じて専門家の情報も確認したうえで判断してください。