UUIDジェネレーター｜v4・v7の違いとDB主キーでの使い分けを解説
公開日：2026年7月14日 対象ツール：UUID ジェネレーター
UUID（Universally Unique Identifier）は、128ビットの一意な識別子です。550e8400-e29b-41d4-a716-446655440000 のようにハイフンで区切った32桁の16進数で表記し、中央付近にバージョンとバリアントの情報が埋め込まれています。中央のサーバーに採番を問い合わせなくても、各端末やプロセスが勝手に生成した値がまず重複しない——この「調整なしで一意になる」性質こそがUUIDの最大の価値です。
UUIDはどこで使うのか
- DBの主キー: 連番を採番するために中央へ問い合わせる必要がなく、複数DBやシャードでIDを事前生成してから書き込めます。
- 分散システム: 別々のサービスが独立して発行したIDを、後から突き合わせても衝突しません。
- ファイル名・オブジェクトキー: アップロードされたファイルに一意な名前を付けられ、上書き事故を防げます。
- APIのリクエストID・トークンの種: ログ追跡や冪等キーとしても使えます。
v4とv7の違いと使い分け
v4は122ビットが完全ランダムなUUIDです。値に順序がなく推測されにくいので、公開URLに載る識別子やトークンのように「並び順に意味がなく、むしろ推測されたくない」用途に向きます。
v7は先頭48ビットにUnixミリ秒のタイムスタンプを埋め込む新しい方式です。生成順がそのまま時刻順になるため、辞書順でソートすれば作成順に並びます。DBの主キーやインデックスにはこのv7が向いています。本ツールのv7は、同一ミリ秒内に複数生成してもRFC 9562の単調増加カウンタ方式で厳密に増加します。
迷ったら、外部に露出するランダムなIDはv4、DBに保存して並べ替えたいIDはv7、と覚えておけば大きく外しません。
なぜ衝突が事実上ゼロなのか
v4のランダム部分は約2^122通り——10進で約5.3×10^36通りあります。仮に1秒あたり10億個を100年間生成し続けても、重複が一度でも起きる確率は無視できるほど小さいままです。数学的に「絶対ぶつからない」保証ではありませんが、実運用では衝突対策を考えなくてよい水準だと言えます。
連番IDと比べた長所・短所
AUTO_INCREMENTのような連番IDは、短く人が読みやすく、インデックスも素直です。一方で「1つ前のID」が簡単に推測でき、発行済みの件数が外部から見えてしまいます。UUIDはこの推測を防げる代わりに、128ビットと長く、そのままでは並び順を持たないのが弱点です。v7はこの「並ばない」弱点を時刻順ソートで補った折衷案と言えます。
DBキーにするときの注意と失敗例
UUIDを主キーにする際にもっとも多い失敗が、v4をそのまま主キーにしてしまうことです。v4はランダムなので挿入位置がインデックス全体に散らばり、B-treeのページが頻繁に分割されて断片化します。データ量が増えるほど挿入が遅くなり、インデックスも肥大化していきます。
これを避けるには、DBの主キーには時刻順に並ぶv7を選びます。挿入が末尾付近に集中するため断片化が起きにくく、連番に近い効率が得られます。さらに、外部に見せる表示用IDと内部の主キーを分ける設計も有効です。
このツールでの生成方法
- バージョン（v4 / v7 / NIL）を選びます。
- 生成したい個数（1〜100）を指定します。
- 必要に応じて「ハイフン有無」「大文字/小文字」を切り替えます。
- 「生成」を押すと一覧が出るので、各行の「コピー」または「すべてコピー」で取り込みます。
生成は crypto.getRandomValues（暗号学的に安全な乱数）を使い、すべてブラウザ内で完結します。外部サーバーには送信されないため、業務で扱う識別子も安心して量産できます。用途に迷ったら、まずはv4かv7を選んで試してみてください。