Webサービスやアプリを使っているとき、あるいはデータベースの設計に関わっているとき、「123e4567-e89b-12d3-a456-426614174000」のような、英数字とハイフンで構成された長い文字列を目にしたことはないでしょうか。
これは「UUID」と呼ばれる識別子の一種で、現代のシステム開発においては欠かせない重要な技術となっています。
しかし、いざ「UUIDとは何か？」と聞かれると、「とにかく被らないIDでしょ？」と漠然と捉えている方も多いかもしれません。
この記事では、UUIDの基本的な仕組みから、従来の連番IDとの違い、複数の種類（バージョン）による使い分け、そして近年注目を集めている最新の動向までを分かりやすく解説していきます。
システム設計の現場でUUIDを採用する際のメリットや、注意すべきデメリット（パフォーマンスへの影響など）といった実践的な内容も盛り込んでいますので、ぜひ最後まで目を通してみてくださいね。
UUID（汎用一意識別子）の基本的な仕組み
UUIDとは「Universally Unique Identifier」の頭文字をとったもので、日本語では「汎用一意識別子」と呼ばれます。
簡単に言えば、「世界中のどこで、誰が、いつ生成しても、決して他のものと重複しない（一意である）ID」を作るための規格です。
UUIDのフォーマットと特徴
UUIDは、全体で128ビットの数値として定義されています。
ただ、コンピューターが扱う2進数のままだと人間には長すぎて読めないため、一般的には「16進数（0〜9とa〜f）」の文字列に変換し、見やすくするためにハイフンで区切って表現されます。
具体的には、以下のような「8桁-4桁-4桁-4桁-12桁」の合計32文字（ハイフンを含めると36文字）のフォーマットが標準的です。
- UUIDの例：
550e8400-e29b-41d4-a716-446655440000
なぜ「絶対に被らない」と言えるのか？
「適当に生成して、本当に他のシステムと重複しないの？」と疑問に感じる方もいらっしゃるでしょう。
UUID（特に現在主流のバージョン4）は、乱数（ランダムな数値）をベースに作られています。
128ビットの組み合わせは、計算上「2の128乗」通り存在します。これは約「340のあとに0が36個続く（340澗）」という天文学的な数字です。
例えるなら、地球上のすべての砂粒にひとつずつUUIDを割り当てたとしても、まだまだ余裕があるほどの途方もない数と言えます。
そのため、数学的に「絶対に重複しない」とは言い切れないものの、現実世界のシステムにおいて偶然重複する確率は「隕石が自分に何度も直撃する確率」よりも低く、実質的には「被らない」と見なして問題なく運用できるというわけです。
なぜ今、UUIDが必要とされているのか？（背景と文脈）
かつてのシステム開発では、データベースのIDと言えば「1, 2, 3…」と順番に増えていく「連番ID（オートインクリメント）」が主流でした。では、なぜ今になってUUIDがこれほどまでに重宝されているのでしょうか。
そこには、現代のIT業界が抱えるシステム構造の変化と、セキュリティへの高い要求が背景にあります。
従来の「連番ID」が抱える限界
1つのデータベースサーバーだけで動いている小規模なシステムであれば、連番IDは非常に効率的です。データベースが自動で「次は4番ね」と管理してくれるため、簡単に重複のないIDを発行できます。
しかし、サービスが成長してデータ量が膨大になると、1台のサーバーでは処理しきれなくなります。
分散システムとマイクロサービスの台頭
現代の大規模なWebサービスでは、複数のサーバーやデータベースを連携させる「分散システム」や、機能ごとにシステムを分割する「マイクロサービスアーキテクチャ」が一般的になっています。
複数のデータベースがそれぞれ独立して動いている環境で連番IDを使おうとすると、「サーバーAで発行したIDの3番」と「サーバーBで発行したIDの3番」が衝突してしまうという問題が発生します。
かといって、「今何番まで発行したか」をすべてのサーバーで毎回確認し合う仕組みを作ると、それがシステム全体の大きなボトルネック（渋滞の原因）になってしまいます。
そこで、「中央で管理しなくても、各サーバーが勝手に発行するだけで絶対に被らないID」が必要になり、UUIDが主役に躍り出たのです。
セキュリティ観点での要求（推測されにくさ）
連番IDには、セキュリティ上のリスクも潜んでいます。
例えば、自分のユーザーページのURLが https://example.com/user/105 だったとします。これを見た悪意のあるユーザーは、「数字を106に変えれば、他人のページが見られるのではないか？」と推測できてしまいます。
もしシステムの権限チェックに不備があった場合、URLの数字を変えるだけで他人の個人情報を盗み見られてしまうリスク（IDOR：安全でない直接オブジェクト参照）が生じます。
UUIDであればランダムな文字列になるため、次のIDを推測することが極めて困難になり、セキュリティリスクを大きく下げることが可能です。
UUIDの種類（バージョン）とそれぞれの仕組み
ひとくちにUUIDと言っても、実は生成の仕組みによっていくつかの「バージョン」に分かれています。
用途によって最適なバージョンは異なるため、それぞれの違いを把握しておくことが重要です。
| バージョン | 生成のベースとなる情報 | 主な特徴・用途 |
| バージョン1 (v1) | 時刻 ＋ MACアドレス | 生成時刻と機器情報に依存。プライバシーの懸念から現在は非推奨。 |
| バージョン3 (v3) | 名前空間 ＋ MD5ハッシュ | 同じ入力値からは常に同じUUIDが生成される。古い規格。 |
| バージョン4 (v4) | 完全な乱数（ランダム） | 現在最も広く使われている主流のバージョン。予測が不可能。 |
| バージョン5 (v5) | 名前空間 ＋ SHA-1ハッシュ | v3のセキュリティを強化したもの。同じ入力から同じIDを作りたい時に使用。 |
| バージョン7 (v7) | タイムスタンプ ＋ 乱数 | 【最新動向】 時間順に並べ替え可能。データベースの主キーに最適。 |
バージョン1とプライバシー問題
初期に作られたバージョン1は、IDを生成した瞬間の「時間」と、生成したコンピューターのネットワーク機器に割り当てられた固有の番号（MACアドレス）を組み合わせて作られていました。
確実に一意になるメリットはありましたが、「いつ、どの端末で作られたIDか」が逆算できてしまうため、プライバシー保護の観点から現在ではほとんど使われていません。
最も標準的なバージョン4
現在、多くのプログラミング言語やライブラリでデフォルトとして採用されているのが「バージョン4」です。
これは特定の情報に依存せず、完全にランダムな数値（乱数）を生成してUUIDとします。情報漏洩のリスクがなく、どの環境でも簡単に生成できるため、迷ったらバージョン4を使っておけば間違いありません。
【最新動向】注目を集めるバージョン7
長らくバージョン4が主流でしたが、2024年5月に新しい規格（RFC 9562）として「バージョン7」などが正式に標準化されました。
バージョン4は完全にランダムであるがゆえに、「新しく作られた順に並べ替える」といった処理ができませんでした。
バージョン7は、「生成した時間のデータ（タイムスタンプ）」と「乱数」を組み合わせた画期的な仕組みです。これにより、UUIDでありながら「作成日時順に並べ替え可能」という連番IDのメリットを取り入れることに成功しました。
現在、データベースの主キー（Primary Key）として採用するなら、バージョン7が最有力候補として業界内で大きな注目を集めています。
GUIDやULIDといった類似規格との違い
システム開発の現場では、UUIDと似たような文脈で「GUID」や「ULID」といった言葉を耳にすることがあるはずです。これらとの違いもすっきりと整理しておきましょう。
UUIDとGUIDの違い
GUID（Globally Unique Identifier）は、主にMicrosoft社がWindowsや.NETなどの自社製品で採用している識別子の名称です。
成り立ちには歴史的な経緯がありますが、現在の規格において「UUIDとGUIDは実質的に同じもの」と考えて差し支えありません。
マイクロソフト系の技術（C#やSQL Serverなど）を触っているときはGUIDと呼ばれ、Web全般やLinux系の技術ではUUIDと呼ばれることが多い、という認識で大丈夫です。
UUIDとULIDの違い
ULID（Universally Unique Lexicographically Sortable Identifier）は、UUIDの弱点を克服するために有志によって作られた別の規格です。
以下の点でUUID（バージョン4）よりも扱いやすいとされ、近年採用例が増えています。
- 文字数が短い：UUIDが36文字なのに対し、ULIDは26文字です。
- ソート（並べ替え）が可能：生成時刻の情報を含んでいるため、時間順に並べられます（UUIDバージョン7に近い発想です）。
- 見間違いを防ぐ工夫：小文字やハイフンを使わず、人間が見間違えやすい「I（アイ）」と「1（イチ）」、「O（オー）」と「0（ゼロ）」などを除外した文字セット（Base32）を採用しています。
UUIDバージョン7の正式化によってULIDの優位性はやや薄れましたが、文字列の短さや視認性の高さから、依然として人気のある規格です。
開発現場でUUIDを採用するメリット
ここまで仕組みや種類を見てきましたが、システム設計においてUUIDを導入することで、具体的にどのような恩恵があるのでしょうか。
発番処理のボトルネックを解消できる
最大のメリットは、データベースにアクセスしなくても、アプリケーション側（Webサーバーやスマホアプリなど）で独立して一意のIDを生成できる点です。
「IDを発行するためだけにデータベースと通信する」という待ち時間がなくなるため、大量のデータを高速で保存したい場合や、オフライン環境で動作するアプリのデータ同期などで絶大な威力を発揮します。
システム間のデータ移行や統合がスムーズになる
例えば、会社が合併して「システムA」と「システムB」の顧客データベースを統合することになったとします。
もし両方とも連番IDを使っていたら、「顧客IDの1番」が両方のシステムに存在するため、片方のIDを全て振り直すという地獄のような作業が発生します。
最初から両方のシステムでUUIDを採用していれば、IDが衝突することは絶対にないため、そのままデータをガチャンと合わせるだけで統合が完了します。
外部に公開しても安全性が保たれる
前述の通り、UUIDは推測が不可能です。
パスワードリセット用のURL、限定公開の動画リンク、APIのアクセスキーなど、「知っている人だけがアクセスできる、推測されては困るリソース」の識別子として非常に適しています。
UUIDを採用する際のデメリットと注意点
万能に見えるUUIDですが、特にデータベースと組み合わせて使う際には、システムに悪影響を及ぼす致命的なデメリットも存在します。導入前には以下の点に必ず注意を払いましょう。
データベースのパフォーマンス低下（ページ分割問題）
これが、システムエンジニアを最も悩ませるUUIDの最大のデメリットです。
多くのリレーショナルデータベース（MySQLのInnoDBなど）では、主キー（Primary Key）の順番に従ってデータを物理的に整理して保存します（クラスタ化インデックスと呼ばれます）。
連番IDであれば、データは常に一番後ろに綺麗に追加されていきます。
しかし、UUIDバージョン4のような完全ランダムな文字列を主キーにすると、新しいデータが来るたびにデータベースは「このIDはAとCの間だから、真ん中に隙間を作って保存しなきゃ」と、データの物理的な並べ替え（ページ分割）を頻繁に行うことになります。
これが積もり積もると、データベース内部が虫食い状態（フラグメンテーション）になり、書き込み速度が劇的に低下してしまうのです。
※この問題を解決するために登場したのが、前述した「時間順に並ぶ」UUIDバージョン7やULIDです。
ストレージとメモリの圧迫
連番ID（INT型やBIGINT型）は通常4バイト〜8バイトのデータ量で済みますが、UUIDは128ビット（16バイト）、文字列としてそのままデータベースに保存するとハイフン込みで36バイトもの容量を消費します。
「たかだか数十バイトの違い」と思うかもしれませんが、数億件のレコードが保存されるテーブルや、それを検索するためのインデックス（索引）においては、このサイズの大きさがメモリを圧迫し、システム全体のレスポンス悪化を招く原因となります。
人間にとっての扱いづらさ
システムにとっては一意で便利でも、人間にとっては「長くて意味不明な文字列」でしかありません。
カスタマーサポートで「お客様のIDを教えてください」と電話でやり取りすることは不可能ですし、ログを見てデバッグをする際も、パッと見でどのデータか識別しにくいという運用上のストレスがあります。
メリットとデメリットを踏まえ、実際のWebサービスやアプリでUUIDがどのような場面で使われているのか、代表的な用途をいくつか紹介します。
- セッションIDの管理：ユーザーがログインした状態を保持するための「セッションCookie」には、推測不可能なUUID（v4）がよく使われます。
- 限定公開URLの発行：ファイル転送サービスやオンラインストレージで「このURLを知っている人だけダウンロード可能」とするためのURLパスとして利用されます。
- 分散システムでのトランザクション追跡：マイクロサービスにおいて、1つのユーザーリクエストが複数のサーバーをまたいで処理される際、一連の処理を追跡するための「トレースID」としてUUIDが発行されます。
- スマホアプリのローカルデータ保存：電波の届かないオフラインでアプリ内にデータを作成し、後からクラウドに同期する際のIDとして利用されます。
UUIDに関するよくある疑問（FAQ）
最後に、UUIDに関してよく耳にする疑問にお答えします。
Q. UUIDの重複確率は本当にゼロなのでしょうか？
数学的な意味での「完全なゼロ」ではありません。しかし、UUIDバージョン4の場合、1秒間に10億個のUUIDを約85年間生成し続けて、ようやく1つ重複する確率が50%になるというレベルです。
私たちが生きている間に、一般的なシステム規模で自然に重複が起こることは「実質的にあり得ない」と考えて問題ありません。
Q. データベースの主キー（Primary Key）として使っても良いですか？
要件によりますが、安易に「バージョン4」を文字列型（VARCHAR等）で主キーにするのは、先述したパフォーマンス低下のリスクがあるため慎重になるべきです。
もし主キーとして採用したい場合は、バイナリ型（BINARY(16)）に変換して容量を節約するか、最新規格である「バージョン7」や「ULID」などの時間順ソート可能な識別子を採用していくのが、今後のベストプラクティスと言えるでしょう。
UUIDは適材適所で活用しよう
UUIDは、分散化が進む現代のシステム開発において、データの独立性と安全性を担保するための非常に強力なツールです。
「連番ID」のボトルネックを解消し、URLに含めても推測されにくいという素晴らしいメリットを持つ一方で、データベースのパフォーマンスやストレージ容量に対する影響という無視できないデメリットも抱えています。
- 推測されたくないキーや一時的なIDにはUUID（バージョン4）
- データベースの主キーとして長期保存・検索するものにはUUID（バージョン7）やULID
- 小規模なシステムや、人間が直接目視・管理する番号には従来の連番ID
このように、それぞれの特性と最新の動向を正しく理解し、適材適所で技術を選択していくことが、高品質なシステムを作るための第一歩となります。
次に長い文字列のIDを見かけたときは、「これはどのバージョンのUUIDだろう？」と少し背景事情に思いを馳せてみてはいかがでしょうか。
コメント