「Windowsのデバイスマネージャーで見かけた謎の文字列」「データベースの主キーにGUIDを使うべき?」——GUIDという言葉を聞いたことはあっても、正確な仕組みや使い方を知らない方は多いです。
GUID(Globally Unique Identifier:グローバル一意識別子)とは、世界中で重複しないことを保証するために設計された128ビットの識別子です。データベースの主キー・ソフトウェアのコンポーネント識別・APIのリソース管理など、あらゆるIT環境で活用されています。
本記事では、GUIDの仕組み・形式・バージョンの違い・用途・UUIDとの違い・セキュリティ上の注意点・コード例まで初心者にもわかりやすく解説します。
GUIDとは?
GUID(Globally Unique Identifier:グローバル一意識別子)とは、世界中のどこで生成されても重複しないことを保証する128ビットの識別番号です。「ジーユーアイディー」と読みます。

GUIDの形式と構造
GUIDは128ビットの数値で、通常は以下の形式(8-4-4-4-12の16進数)で表記されます。
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
例:550e8400-e29b-41d4-a716-446655440000
| セグメント | 桁数 | ビット数 | 内容 |
|---|---|---|---|
| 1番目 | 8桁 | 32ビット | タイムスタンプ(低位) |
| 2番目 | 4桁 | 16ビット | タイムスタンプ(中位) |
| 3番目 | 4桁 | 16ビット | バージョン番号+タイムスタンプ(高位) |
| 4番目 | 4桁 | 16ビット | バリアント+クロックシーケンス |
| 5番目 | 12桁 | 48ビット | ノード識別子(MACアドレス等) |
GUIDとUUIDの違いは?
GUIDとUUID(Universally Unique Identifier)はほぼ同じものです。
| 項目 | GUID | UUID |
|---|---|---|
| 正式名称 | Globally Unique Identifier | Universally Unique Identifier |
| 主な使用環境 | Microsoft・Windows環境 | Linux・Mac・オープンソース環境 |
| 規格 | Microsoftが定義 | RFC 4122で標準化 |
| 形式 | 同じ(128ビット・ハイフン区切り) | 同じ(128ビット・ハイフン区切り) |
| 互換性 | 相互に互換性あり | 相互に互換性あり |
「GUID」はMicrosoft(Windows・COM)の文脈で使われ、「UUID」はLinux・Macやオープンソース・RFC規格の文脈で使われる傾向があります。どちらも同じ形式・同じアルゴリズムで生成されます。
GUIDのバージョン(v1〜v5)の違い
GUIDには用途に応じて複数のバージョンがあります。
| バージョン | 生成に使う情報 | 特徴・用途 |
|---|---|---|
| v1 | MACアドレス+タイムスタンプ | 時系列に並べ替えが可能。MACアドレスが含まれるためプライバシー上の懸念あり |
| v2 | DCE Security(ユーザーID等) | DCE RPC環境で使用。一般的ではない |
| v3 | 名前空間+名前のMD5ハッシュ | 同じ入力から常に同じGUIDを生成。URL→GUIDの変換などに使用 |
| v4 | 完全ランダム(122ビット) | 最も一般的。予測不可能な一意IDの生成に最適。データベース主キーなどに使用 |
| v5 | 名前空間+名前のSHA-1ハッシュ | v3のSHA-1版。v3よりセキュリティが強い |
一般的なユースケースではv4(完全ランダム)が最も広く使われています。セキュリティ用途や予測不可能性が重要な場面ではv4を選択してください。同じ入力から同じIDを生成したい場合はv5(またはv3)を使います。
GUIDの主な用途
データベースの主キー(Primary Key)
GUIDはデータベースの主キーとして広く使われます。特に分散データベース・マイクロサービス・複数拠点のシステム統合では、各サーバーが独立してIDを生成できるGUIDが整数型(AUTO_INCREMENT)より有利です。
v4のGUIDはランダムなため、B-Treeインデックスの断片化が発生しやすくパフォーマンスが低下する場合があります。大規模なデータベースでは「Sequential GUID(順序付きGUID)」または「ULID」の採用を検討してください。
Windowsのソフトウェア・コンポーネント識別
WindowsのCOM(Component Object Model)では、すべてのコンポーネント・インターフェース・クラスをGUIDで識別します。レジストリの「HKEY_CLASSES_ROOT\CLSID」以下に多数のGUIDが格納されています。
WebアプリケーションのリソースID
REST APIのリソースURL・セッションID・一時的なダウンロードリンクなどにGUIDが使われます。整数型IDと比べてURLからのレコード数推測(例:/users/1, /users/2…)を防止できます。
クラウドストレージ・ファイル識別
AWS S3・Azure Blob Storageなどのクラウドストレージでは、ファイルやオブジェクトの識別子としてGUIDが使われています。
GUIDのメリットとデメリット
メリット
- 世界規模の一意性:中央管理なしに、世界中で重複しないIDを独立して生成できる
- 分散システムへの適合:異なるサーバー・システムが同時にIDを生成してもID衝突が発生しない
- 統合の容易さ:異なるデータベースやシステムをGUIDで統合する際にID衝突を心配しなくてよい
- セキュリティ向上:連番IDと比べてURLやAPIからレコード総数・存在を推測されにくい
デメリット
- サイズが大きい:128ビット(16バイト)は整数型ID(4〜8バイト)の2〜4倍のストレージを消費する
- 人間が読みにくい:「550e8400-e29b-41d4-a716-446655440000」を人間が記憶・入力するのは困難
- インデックス効率の低下:v4のランダムGUIDはB-Treeインデックスの断片化を引き起こしやすい
- デバッグが難しい:ログ・エラーメッセージに含まれるGUIDは視認性が低い
各言語でのGUID生成コード例
Python
import uuid
# v4(ランダム・最も一般的)
print(uuid.uuid4())
# 出力例: 550e8400-e29b-41d4-a716-446655440000
# v5(名前空間+名前からSHA-1ハッシュ)
print(uuid.uuid5(uuid.NAMESPACE_URL, ‘https://example.com’))
JavaScript(Node.js)
const { randomUUID } = require(‘crypto’);
console.log(randomUUID());
// 出力例: 550e8400-e29b-41d4-a716-446655440000
Java
System.out.println(UUID.randomUUID());
// 出力例: 550e8400-e29b-41d4-a716-446655440000
C#(.NET)
Console.WriteLine(Guid.NewGuid());
// 出力例: 550e8400-e29b-41d4-a716-446655440000
SQL Server
— 出力例: 550E8400-E29B-41D4-A716-446655440000
GUIDとセキュリティ

v1 GUIDのMACアドレス漏洩リスク
GUID v1はMACアドレスとタイムスタンプから生成されます。v1のGUIDが公開されると、そこからMACアドレスと生成時刻が推測できます。これにより、ネットワーク上の機器を特定されるプライバシーリスクがあります。セキュリティが求められる用途ではv4を使用してください。
予測可能なGUIDのセキュリティリスク
GUIDが疑似乱数(予測可能な乱数)で生成されている場合、攻撃者がGUIDを推測して他のユーザーのリソースへ不正アクセスする可能性があります。特にセッションIDや一時ダウンロードリンクにGUIDを使う場合は、暗号論的に安全な乱数生成器(CSPRNG)を使ったv4 GUIDが必須です。
JavaScriptのMath.random()は暗号論的に安全ではありません。セキュリティが必要な場面では必ずcrypto.randomUUID()(Node.js)やcrypto.getRandomValues()(ブラウザ)を使ってください。
GUIDに関連する被害・注意事例2選
事例1:推測可能なID情報を悪用した不正アクセス
愛知県警らは2022年1月、他人のSNSアカウントに不正アクセスし、内部データを不正閲覧していたとして50代男性を逮捕しました。報道によると、男性はアカウント名やIDなど公開されている情報からパスワードを類推し、写真共有アプリのアカウントへ不正アクセスしていたとされています。
この事例は、IDや識別子が推測可能な形で使われることの危険性を示しています。GUIDは連番IDより推測されにくい識別子として有効ですが、セッションIDや一時URL、認証トークンのようなセキュリティ上重要な用途では、単にGUID形式にするだけでは不十分です。暗号論的に安全な乱数生成器(CSPRNG)を使ったv4 GUIDを採用し、認可チェックや有効期限、アクセス制御を必ず組み合わせる必要があります。
事例2:ID管理不備による不正アクセス・情報流出
自動運転技術の開発などを行うZMPでは、ダイレクトメール送付に登録していた顧客情報の一部がインターネット上に流出したことを公表しました。記事では、過去にIDやパスワードの管理不備により、ダイレクトメール送信システムへ不正アクセスを受け、同社の意図しないメールが送信される事案が発生していたと説明されています。
GUIDは、システム内のユーザー、ファイル、APIリソース、セッションなどを一意に識別するために便利な仕組みです。しかし、識別子を安全に生成していても、IDやパスワードの管理、認可チェック、ログ監視が不十分であれば、不正アクセスや情報流出を防ぐことはできません。GUIDは「重複しにくい識別子」であり、認証・認可そのものの代替にはならない点に注意が必要です。
よくある質問(FAQ)
Q. GUIDは本当に世界中で重複しないのですか?
理論的には重複の可能性はゼロではありませんが、v4 GUIDの場合は2の122乗通り(約5.3×10の36乗)の組み合わせがあるため、実用上の重複確率は無視できるほど小さいです。毎秒10億個のGUIDを生成し続けても、重複が発生するまでに宇宙の年齢の何百倍もの時間がかかります。
Q. データベースの主キーにGUIDを使うべきですか?
メリット(分散システムでのID衝突防止・URLからの情報推測防止)とデメリット(ストレージ増加・インデックス断片化)があります。単一サーバーで小〜中規模のシステムなら整数型のAUTO_INCREMENTの方がパフォーマンスが優れています。分散システムや複数DB統合が必要な場合はGUIDが適しています。
Q. GUIDとUUIDはどちらを使えばいいですか?
技術的には同じものなので、どちらでも問題ありません。Windowsや.NET環境ではGUID、Linux・MacやNode.js・Pythonなどのオープンソース環境ではUUIDと呼ぶのが一般的です。生成アルゴリズムも形式も同じです。
Q. GUIDをデータベースに保存するときの推奨形式は?
データベースによって最適な形式が異なります。SQL ServerはUNIQUEIDENTIFIER型(ネイティブ対応)、MySQLはBINARY(16)型(バイナリ保存でストレージ効率が良い)またはCHAR(36)型(文字列保存・可読性高いが効率は低い)を状況に応じて使い分けます。
Q. GUIDを短くする方法はありますか?
GUIDをBase64エンコードすると22文字に短縮できます(例:VQ6EAOKbQdSnFkRmVUQAAA==)。また、ULID(Universally Unique Lexicographically Sortable Identifier)はGUIDと同様の一意性を持ちつつ26文字で時系列にソート可能なIDとして注目されています。
まとめ
GUID(Globally Unique Identifier)は128ビットの識別子で、世界中で重複しないことを保証する仕組みです。形式は「8-4-4-4-12」の16進数でハイフン区切りで表現されます。技術的にはUUIDと同一であり、Microsoft環境ではGUID、それ以外ではUUIDと呼ばれることが多いです。
バージョンはv1〜v5があり、最も広く使われるのはv4(完全ランダム)です。データベースの主キー・Windowsコンポーネントの識別・WebアプリケーションのリソースID・クラウドストレージのオブジェクト識別など、IT環境のあらゆる場面で活用されています。
セキュリティの観点では、v1 GUIDにMACアドレスが含まれることへの注意と、セッションIDなどセキュリティが重要な用途では暗号論的に安全な乱数生成器(CSPRNG)を使ったv4 GUIDを使用することが重要です。Math.random()などの非暗号的な乱数でGUIDを生成することは避けてください。


























![中小企業の情報瀬キィリティ相談窓口[30分無料]](/wp-content/uploads/2023/07/bnr_footer04.png)



マイナンバーは日本国内で一人一番号が割り当てられ、重複しません。GUIDはそれを世界規模にしたようなもので、異なる会社・異なる国・異なるシステムで同時に生成しても重複しないよう設計されています。システム同士が「これは同じものだ」「別のものだ」と判断するための世界唯一の名前票です。