FlowingDev

UUIDとは？：絶対にカブらないユニークID、その仕組みを徹底解説

UUIDは、コンピュータシステムで情報を一意に識別するための128ビットの数値。事実上、二度と同じものが作られることはありません。

ツールを試す: UUIDジェネレーター

一言で言うと

UUIDは、ソフトウェアで考えられるありとあらゆるものに対するユニークなシリアルナンバーとして機能する128ビットの数値で、二度と同じものが作られる可能性はとんでもなく低いです。

UUIDが解決する問題

コンピューティングの黎明期、モノを管理するのはシンプルでした。最初のユーザーはID 1、次は 2、といった具合です。この「自動採番整数」は、レコードを作成するデータベースやサーバーが1つしかない限り、うまく機能していました。

そこにインターネットが登場しました。そして分散システム、マイクロサービス、オフラインファーストのアプリも。

突然、複数のコンピュータが、互いに通信することなく、同時に新しいモノ（ユーザー、投稿、製品、ログエントリ）を作成する必要に迫られました。ダブリンのサーバーと東京のサーバーが両方とも「次の」レコードを作成しようとすると、どちらもレコード #5830 を作ってしまいます。後でデータベースが同期されたとき、衝突が発生。「本物の」#5830 はどちらでしょう？カオスが生まれます。

これこそが、UUID（Universally Unique Identifier、世界で唯一の識別子）が解決する核心的な問題、分散化され、協調不要な、ユニークIDの生成です。カフェでノートPCを開いている開発者が、新しいTo-Doリスト項目のIDを作成したとして、他の誰も、他のどのコンピュータでも、全宇宙の歴史と未来を通じて、まったく同じIDを生成することが絶対にないと統計学的に確信できるのです。これにより、システムは独立してユニークな識別子を作成でき、私たちが今日頼りにしている堅牢な分散ソフトウェアへの道が開かれました。

内部の仕組み

UUIDの核心は、単なるデカい数字です。128ビット長です。これは2の128乗、つまり約340澗（3の後にゼロが37個続く数）もの組み合わせが可能です。ピンとこないかもしれませんが、もし毎秒10億個のUUIDを生成したとしても、すべての可能性を使い果たすのに約100億年かかります。ランダムに生成された2つのUUIDが偶然に衝突する確率は、天文学的に小さいのです。

UUIDの解剖学

UUIDは128ビットの整数ですが、私たちがその形で見ることはありません。ほとんどの場合、32文字の16進数文字列として表現され、ハイフンで5つのグループに分けられています。

典型的なUUID（バージョン4）はこんな感じです: 123e4567-e89b-42d3-a456-426614174000

このフォーマットを分解してみましょう：

  • 構造: 8-4-4-4-12 （32文字の16進数文字を表し、ハイフンを含めると合計36文字）。
  • データ: 各16進数文字は4ビット（「ニブル」）を表します。32文字 × 4ビット/文字 = 128ビット。
  • 魔法の数字: 3番目のグループ（42d3）の先頭にある 4 に注目してください。この 4 はランダムではありません。これはUUIDのバージョン（この場合はバージョン4）を指定しています。4番目のグループ（a456）の最初の文字にも特別な意味があり、それが標準レイアウトに準拠していることを示すバリアントを識別します。あなたが見るほとんどのUUIDでは、8、9、A、Bのいずれかになります。

バージョン巡り

このツールのプロンプトではバージョン4（v4）が指定されていますが、これは最も一般的なタイプです。しかし、それぞれ異なる生成戦略を持ついくつかのバージョンが存在します。

バージョン 生成方法 用途
v1 タイムスタンプ + 生成したコンピュータのMACアドレス。 時間ベースの順序が必要な場合。（MACアドレスが漏洩するプライバシー懸念のため、現在では稀）。
v2 v1と同じだが、POSIXのUID/GID情報が追加される。 極めて稀。v1を形式化したもの。
v3 「名前空間」と「名前」のMD5ハッシュ。 決定的。同じ名前空間と名前からは、常に同じUUIDが生成される。（MD5に弱点があるため、あまり一般的ではない）。
v4 純粋なランダム。 デフォルトの選択肢。ただユニークなIDが必要で、他には何も気にしない場合。
v5 「名前空間」と「名前」のSHA-1ハッシュ。 現代的な決定論的UUIDの選択肢。v3と同じ考え方だが、より強力なハッシュ関数を使用。

バージョン4 UUIDの生成

v4 UUIDの生成は、概念的にはシンプルです：

  1. 暗号学的に強力なランダムデータを128ビット生成する。
  2. 標準で要求されているように、特定のビットをいくつか調整して「バージョン」と「バリアント」フィールドを設定する。
  3. 結果の128ビットをハイフン付きの16進数文字列としてフォーマットする。

これが「調整」ステップの疑似コードです：

// `bits`が128個のランダムなビット（0と1）の配列であると仮定

// バージョンを4（0100）に設定
bits[48] = 0;
bits[49] = 1;
bits[50] = 0;
bits[51] = 0;

// バリアントを'10x'に設定
bits[64] = 1;
bits[65] = 0;

実際には、ほとんどのプログラミング言語にはcrypto.randomUUID()のような一行で書ける関数が用意されており、これらすべてを正しく安全に実行してくれます。重要なのは、v4 UUIDとは、要するに122ビットの純粋なランダムデータに、6ビットのメタデータをくっつけたものだということです。

実社会での事例

データベース統合の悪夢

スタートアップの「Acme社」と「WidgetCorp社」が合併することになりました。両社とも成功した製品を持ち、それぞれにユーザー、製品、注文のデータベースがありました。最初の統合ミーティングで、若手開発者が尋ねました。「ユーザーテーブルはどうやってマージするんですか？うちのID 101 のユーザーは『Alice』ですが、向こうのID 101 のユーザーは『Bob』ですよ」。その場は静まり返りました。両社のデータベースのすべてのテーブルが、単純な自動採番整数IDを使っていたのです。それらをマージするには、外部キーを書き換え、すべてのレコードを相互参照し、何も見逃していないことを祈るという、途方もない作業が必要でした。この問題で、合併は数ヶ月遅れました。

教訓: もし最初からUUIDを使っていたら、マージはごく簡単なものでした。Acme社のユーザー f47ac10b-58cc-4372-a567-0e02b2c3d479 は、WidgetCorp社のユーザー 9c68a520-2a83-43a3-b45d-4c86518a28cc と完璧に共存できます。衝突も悪夢もありません。いつか相互作用したりマージされたりする可能性のあるシステムにとって、UUIDは不可欠です。

サクサク動くショッピングカート

ある開発者が、新しいeコマースの「クイック追加」機能を構築していました。ユーザーが商品リストで「カートに追加」をクリックすると、アプリがサーバーでカート項目を作成し、その新しいIDが返ってくるまで1〜2秒間スピナーが表示されました。これでは動作が鈍く感じられます。開発者はひらめきました：アプリが待たなければいいのでは？彼女はコードを変更し、ユーザーがクリックすると、ブラウザが即座に新しいカート項目のためにv4 UUIDを生成し、ローカルの状態に追加し、UIを瞬時に更新するようにしました。アプリは稲妻のように速く感じられるようになりました。バックグラウンドでは、サーバーに「この特定のUUIDでカート項目を作成してください」というリクエストを送信します。もしネットワークが失敗しても、アプリは後で再試行するだけで、同じUUIDを使うことで重複した項目が作られるのを防げます。

教訓: クライアントサイドでのUUID生成は、「楽観的UI（Optimistic UI）」を可能にします。これは、操作が成功すると仮定してインターフェースが即座に更新される手法です。これにより、はるかに高速で応答性の良いユーザー体験が生まれ、オフラインシナリオの処理もずっと簡単になります。

マイクロサービス探偵物語

ある顧客から「注文は失敗したのに、カードには課金された」というエラー報告がありました。システムはAuth、Gateway、Orders、Payments、Shippingといったマイクロサービスが複雑に絡み合ったものでした。1つのリクエストが5つか6つのサービス間を行き来することもあります。毎分何百万ものログエントリの中から、障害の正確な箇所を見つけるのは、干し草の山から針を探すようなものでした。リードアーキテクトは変更を命じました：Gatewayへのすべての受信リクエストに「Correlation ID」と呼ばれるUUIDを割り当てること。このIDは、リクエストを処理するすべてのマイクロサービスに引き継がれ、すべてのログメッセージに含まれることになりました。次にエラーが発生したとき、サポートチームはその1つのUUIDをログシステムで検索するだけでした。瞬時に、システム全体にわたるリクエストの旅の完全な時系列の物語が手に入り、障害を起こした正確なサービスを特定できたのです。

教訓: UUIDは、分散アーキテクチャやマイクロサービスベースのアーキテクチャにおいて、リクエストの追跡やデバッグのためのCorrelation IDとして非常に価値があります。

よくある間違いと落とし穴

  • UUIDをデータベースの主キーとして…不用意に使うこと。 ユニークさという点では素晴らしいですが、UUIDは大きく（整数の4バイトや8バイトに対し16バイト）、ランダムです。ランダム性はデータベースのインデックスパフォーマンスにとって最悪の場合があり、データベースがインデックスのB-treeの真ん中に新しい行を挿入しようと奮闘するため、断片化や書き込みの低速化につながります。現代のデータベースや新しいUUIDバージョン（提案中のv7など、時系列順のもの）はこの問題を緩和できますが、知っておくべき重要なトレードオフです。
  • すべてのUUIDがランダムだと決めつけること。 開発者はレガシーシステムでUUIDを見て、それが予測不可能であると仮定してロジックを組むかもしれません。それがv1 UUIDで、タイムスタンプや生成元のマシンのMACアドレスを含んでおり、機密情報を漏洩させる可能性があることに気づかないかもしれません。
  • 単なる文字列として扱うこと。 一部の開発者は、ユニークな文字列なら何でも「UUID」だと考えるかもしれません。"product-123" のようなものを使ったり、弱い乱数生成器でIDを生成したりするかもしれません。真のUUIDは厳格なフォーマットに従い、v4の場合は、ユニークさを保証するために暗号学的に安全なランダムソースで生成されるべきです。
  • 用途に合わないバージョンを使うこと。 よくある間違いは、決定的なIDが必要な場面でv4（ランダム）UUIDを使ってしまうことです。例えば、ファイルの内容に基づいてユニークなIDを生成する必要がある場合、ファイルハッシュを「名前」としてv5 UUIDを使用すべきです。これにより、同じファイルに再度遭遇した場合、全く同じUUIDが生成され、重複排除が容易になります。

なぜ注目すべきか

次のような状況にいるときはいつでも、UUIDジェネレータに手を伸ばすべきです：

  • ユニークな識別子を作成する必要があるが、中央集権的な機関（単一のデータベースシーケンスなど）に頼ることができない場合。
  • 分散システム、マイクロサービス、または複数のインスタンスが独立してデータを作成する必要があるアプリケーションを構築している場合。
  • 楽観的UIの更新やオフライン機能のために、クライアントサイド（ブラウザやモバイルアプリ）でユニークなIDを生成したい場合。
  • 複数のシステムを流れるリクエストを追跡するために、Correlation IDを作成する必要がある場合。
  • データベーステーブルの主キーを選択する際に、生の挿入パフォーマンスよりもグローバルなユニークさを優先し、そのトレードオフを考慮した場合。

現代のソフトウェア開発において、これらのシナリオは例外ではなく、むしろ当たり前です。いつ、どのようにUUIDを使うべきかを知ることは、基本的なスキルです。

もっと詳しく

理論はOK。さあ手を動かそう — 100%ブラウザ内で。

ツールを試す: UUIDジェネレーター