GUIDとUUIDの違いは？用途別バージョン選びについて解説

2025年10月27日

その他

UUIDやGUIDは、分散したシステムで重複しないIDを作るための標準です。

用語は違っても中身はほぼ同じで、どの「バージョン」を選ぶかが使い勝手を大きく左右します。

本記事では基本と各バージョンの特徴、そして用途別の選び方を、初心者の方にもわかりやすく解説します。

目次 [ close ]

GUIDとUUIDの違いと基本

UUIDとは

UUIDは「Universally Unique Identifier」の略で、128ビット長の識別子です。

世界中のどこで生成しても、ほぼ重複しないように設計されています。

生成方法がいくつかあり、それを「バージョン」と呼びます。

代表的なものにv1、v3、v4、v5、v7があります。

背景

UUIDは標準仕様に基づいており、現在は更新版の仕様で整理されています。

これにより、互換性を保ちながら新しい生成方式も追加されています。

GUIDとは

GUIDは「Globally Unique Identifier」の略で、主にMicrosoftの文脈やWindowsの開発で使われる呼び方です。

COMのクラスIDやインターフェースIDなどで広く使われています。

実態はUUIDと同じ128ビットの識別子です。

Windowsでの扱い

WindowsのAPIやPowerShellではGUIDという表現が一般的です。

生成ツールや標準APIが用意されており、.NETではSystem.Guid型が提供されています。

違いは名称だけ

UUIDとGUIDは、実質的には同じ概念の識別子で、呼び方が違うだけです。

仕様に沿っていれば相互に扱えます。

Windowsの世界ではGUIDという名称が目立ち、他の多くの言語やライブラリではUUIDという名称が目立ちます。

表記とサイズ

UUID/GUIDは16バイト(128ビット)です。

もっともよく見る表記は16進数とハイフンを使った形式です。

例: 123e4567-e89b-12d3-a456-426614174000
8桁-4桁-4桁-4桁-12桁の合計36文字(ハイフン込み)です
大文字/小文字はどちらも許容されますが、統一した方が扱いやすいです
ハイフンなしの32文字表記や、Base64などで短くする表記もあります

表記の主な性質を表にまとめます。

項目	説明
ビット長	128ビット(16バイト)
代表的な文字列表記	8-4-4-4-12の16進数(例: 550e8400-e29b-41d4-a716-446655440000)
文字数	36文字(ハイフン込み)、32文字(ハイフンなし)
Base64表現	約22文字(URL-safe Base64で短縮可能)
大文字/小文字	どちらも可。小文字に統一するのが一般的

よく使う用途

UUID/GUIDは、データベースの主キー、APIのリソースID、ファイル名、イベントやメッセージのID、分散ジョブの識別など、さまざまな場面で使われます。

中央の採番サーバーを置かずに各ノードで独立に生成できるため、スケールしやすいのが利点です。

UUIDのバージョンと特徴

最初に各バージョンの違いを簡単に整理します。

バージョン	方式の要点	長所	注意点
v1	時刻＋装置情報(主にMACアドレス由来)	ほぼ時系列順で並ぶ、古いシステムとの互換が広い	生成時刻や装置情報がにじむ可能性、時計のズレに影響
v3	名前ベース(MD5)	同じ入力から同じIDを決定的に得られる	MD5は衝突攻撃に弱く、秘密用途は不適
v4	乱数ベース	予測されにくく、オフラインで容易に生成	並び順がランダムで、DBのインデックスに負荷がかかることがある
v5	名前ベース(SHA-1)	v3より妥当性が高い決定的生成	SHA-1は安全目的には不適、秘密用途は不向き
v7	時刻順＋乱数	時系列で並びやすく、DBに向く。装置情報を含まない	ミリ秒単位での順序性、時計の後退で単調増加が崩れる場合あり

新規設計の多くはv7が第一候補、秘密にしたいIDにはv4が第一候補と覚えておくと判断が速くなります。

v1

特徴

生成時刻と装置を表す情報(多くはMACアドレス由来)とシーケンスを組み合わせた方式です。

ほぼ時系列順に増えていきます。

利点と注意点

互換性が広く、古いツールや型(例: 一部のDB型)と相性が良い一方、生成した時刻や装置を推測される可能性があります。

時刻が後退すると順序が乱れたり、極端なズレで重複リスクがわずかに高まることもあります。

使いどころ

既存システムとの互換が最優先のときに選びます。

新規設計ならv7を優先するのが無難です。

v3

特徴

名前空間(UUID)と任意の名前文字列をMD5でハッシュし、同じ入力から必ず同じIDを得る決定的な方式です。

利点と注意点

人やドメイン名などから安定したIDが作れますが、MD5は衝突攻撃に弱いためセキュリティ目的には使いません。

新規ではv5の方が一般的です。

使いどころ

移行や互換の理由でv3が前提のデータを扱う場合に限り選びます。

v4

特徴

暗号学的に安全な乱数から生成します。

予測が非常に難しく、オフラインでも安全に生成できます。

利点と注意点

ほぼ重複しませんが、値が完全にランダムなため、B-Treeなどのインデックスでは挿入位置がバラバラになり、ページ分割やキャッシュ効率の低下を招くことがあります。

大量書き込みの主キーには不利です。

使いどころ

URLに埋める公開ID、推測されたくないID、セキュリティトークン風の用途に適しています。

v5

特徴

v3と同様に名前ベースですが、SHA-1を使います。

同じ入力から同じIDを安定的に得られる点はv3と同じです。

利点と注意点

v3よりは妥当ですが、SHA-1はセキュリティ目的では推奨されません。

秘密性が要らない一意識別の決定的生成用として使います。

使いどころ

「同じURLや同じユーザー名から常に同じIDを得たい」場合に便利です。

v7

特徴

ミリ秒単位の時刻情報を先頭に持ち、残りを乱数で満たす方式です。

時系列でほぼ単調に増え、DBのインデックスと相性が良いのが特徴です。

装置情報を含まず、プライバシー面でも扱いやすいです。

利点と注意点

時刻で並びやすく、クラスタ化されたインデックスでも局所性が高くなります。

一方、同じミリ秒内に大量生成すると順序が入れ替わることがあるため、ライブラリの「モノトニック生成」機能があれば有効化すると安心です。

時刻が大きく後退すると単調性は崩れますが、重複自体は乱数部が避けます。

使いどころ

新規の主キー、ログやイベントID、時系列処理など幅広くおすすめです。

用途別のUUID/GUIDの選び方

データベース主キーは v7

主キーにv4を使うと挿入位置が散らばってインデックスが断片化しやすくなります。

主キーや挿入頻度の高いテーブルにはv7を選ぶと、時系列に近い順序で増えるためストレージの局所性が良くなります。

ソートや時系列で使うなら v7

ログ、イベント、監査証跡など、発生時刻で並べたい場合はv7が自然に並びます。

同じ時刻帯の混在は乱数部が区別してくれるため、重複の心配はほぼありません。

予測されにくいIDなら v4

第三者に推測されたくないIDやURLトークンにはv4が向きます。

v7も乱数を含みますが、先頭に時刻が入るため、秘匿性を最優先する場合はv4を選ぶのが簡単で安全です。

同じ名前から同じIDが欲しいなら v5

ユーザー名、メール、URLなどから決定的に同じIDを作りたいときはv5を使います。

名前空間(UUID)を固定し、同じ入力から常に同じ結果が得られます。

既存システム互換が必要なら v1

一部の既存DB型やツールがv1前提のことがあります。

互換が最優先ならv1を選びます。

ただし、生成時刻や装置情報がにじむ可能性がある点に注意してください。

URLや公開IDには v4 か v7

公開しても問題ないリソースIDならv7が扱いやすいです。

URL自体を秘密にしたいリンクやトークン的な用途ではv4を選びます。

短縮したい場合はURL-safe Base64にエンコードして扱う方法もあります。

オフライン生成なら v4 か v7

どちらも中央サーバーなしで生成できます。

乱数は必ず安全なものを使用し、v7では時刻が極端にずれないようだけ注意します。

WindowsやCOMでは GUIDを使用

WindowsのAPIやCOMではGUIDという名称で統一されています。

PowerShellのNew-GuidやVisual Studioのツールなど、OS標準の生成手段を使うと安全です。

内部的にはUUIDと同じ128ビット識別子です。

実装と運用のポイント

標準ライブラリや実績あるライブラリを使う

自作の乱数や独自フォーマットは避け、言語の標準ライブラリや実績あるライブラリを使います。

新しいv7は外部ライブラリで対応する場合も多いので、公式や信頼できる作者のものを選びます。

表記の統一

小文字に統一し、ハイフンありの標準表記を共通ルールにすると扱いやすいです
ログ、API、DBカラムで表記が混ざらないようにします
ブレースや大文字は受け入れても、保存時に正規化しておくと検索が安定します

保存形式の選択

文字列として保存すると取り回しが簡単です(CHAR(36)やTEXT)
バイナリ16バイトで保存すると省サイズで高速です。MySQLならBINARY(16)、PostgreSQLならUUID型が便利です
Base64で短縮して文字列保存する設計もありますが、実装と運用の手間を考えて選びます

インデックスと並び順

主キーやインデックスにUUIDを使うならv7が有利です。

ほぼ時系列順に挿入され、ページ分割が抑えられます。

v4はランダムなため、頻繁な書き込みがあるテーブルでは断片化やキャッシュ効率の低下に注意します。

重複しにくさの考え方

UUIDの空間は非常に大きく、v4は実質122ビットの乱数です。

目安として、1兆個を生成しても衝突確率は極めて小さいです。

アプリ設計では「衝突は気にせず、生成と検証を正しく行う」方が現実的です。

時刻のズレに注意

v1やv7は時刻の影響を受けます。

NTPなどで大きく時刻が後退した場合、単調増加が崩れることがあります。

ライブラリのモノトニック生成やシーケンス補正機能があれば有効にし、コンテナや仮想環境でも時刻同期を整えておきます。

安全な乱数を使う

暗号学的に安全な乱数源(CSPRNG)を必ず使います。

OSの乱数APIや言語の安全な関数を使用し、Math.randomのような擬似乱数は使用しないでください。

バリデーションとフォーマットチェック

入力を受け取るAPIや設定では形式チェックを行います。

簡易チェックとしては、36文字のハイフン区切りで、バージョンとバリアントが正しいかを確認します。

例えば正規表現の一例は「^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[157][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$」のように、バージョンが1・5・7など決め打ちのケースに合わせて調整します。

一般にはライブラリのパーサーと型で検証するのが安全です。

言語ごとの対応状況を確認

v4は多くの言語で標準サポートがあります。

v7は比較的新しく、外部ライブラリで提供されていることが多いです。

導入前に「標準で何が作れるか」「v7はどのライブラリが安定しているか」を確認しましょう。

言語/環境	標準での典型	v7の入手性(例)
JavaScript/Node.js	crypto.randomUUIDでv4	npmのuuidパッケージなど
Python	uuidモジュールでv1/v3/v4/v5	外部パッケージで対応
Java	java.util.UUIDでv4/name系	外部ライブラリで対応
Go	標準は未整備なことが多い	実績ある外部ライブラリで対応
.NET	System.Guid	NuGetパッケージや新しめのAPIで対応
Rust	crateで幅広く対応	uuidクレートで対応可