UUID生成

UUID v4を生成できます。テストデータや識別子の作成に便利です。

完全無料ブラウザ完結登録不要安全

生成されたUUID

このツールについて

UUIDはブラウザ内のみで生成されます。サーバーには送信されません。
ブラウザ標準の crypto.randomUUID() を使用したUUID v4形式で生成されます。
セキュリティトークンやパスワード代替としての利用には、別途適切な設計が必要です。

使い方

1「UUIDを生成」ボタンをクリックすると、UUID v4が1件生成されます。
2「コピー」ボタンをクリックすると、表示中のUUIDをクリップボードにコピーできます。
3コピーしたUUIDをアプリケーションの設定ファイル、テストデータ、データベースの識別子などに貼り付けてご利用ください。
4新しいUUIDが必要な場合は「UUIDを生成」ボタンを再度クリックします。

よくある利用シーン

テストデータやモックAPIのIDを素早く生成したいとき
データベースの主キー用UUIDをその場で用意したいとき
環境変数や設定ファイル用の一意な識別子を作成したいとき
ローカル開発で一意なIDを気軽に確認したいとき
コードレビューやドキュメント作成でUUID形式のサンプル値が必要なとき

よくある質問

UUID生成ツールは無料で使えますか？

はい、完全無料です。ユーザー登録やログインも不要です。

生成したUUIDはサーバーに送信されますか？

いいえ。UUIDの生成はすべてブラウザ内で完結します。生成した値が外部に送信されることはありません。

どのバージョンのUUIDを生成しますか？

UUID v4（ランダムUUID）を生成します。UUID v4はランダムな128ビットの値で構成され、Web開発では最も広く使われる形式です。

生成されるUUIDはどの程度安全ですか？

ブラウザ標準の crypto.randomUUID() を使用しており、暗号学的に安全な乱数でUUIDを生成します。理論上の衝突確率は非常に低く、識別子としての用途では実用上問題ありません。

本番システムのデータベースIDなどに利用できますか？

はい、UUID v4は本番システムの識別子（データベースのID、リソースキーなど）として一般的に利用できます。ただし、セキュリティトークンやCSRFトークンなど高度なセキュリティが必要な用途では、専用ライブラリを用いた適切な設計を別途ご検討ください。

複数のUUIDをまとめて生成できますか？

現在は1件ずつの生成に対応しています。「UUIDを生成」ボタンを繰り返しクリックすることで、必要な数を順番に生成できます。

スマートフォンでも使えますか？

はい、スマートフォンのブラウザからもご利用いただけます。アプリのインストールは不要です。

UUIDを正しく選び・使うためのガイド

UUID（Universally Unique Identifier）は「中央で採番しなくても、ほぼ確実に重複しないID」を作るための仕組みです。データベースの主キーやリソースの識別子として広く使われます。ここでは、UUIDの構造とバージョンの違い、「本当に衝突しないのか」、そして主キーに使うときの注意点を整理します。

UUIDの構造を読む

UUIDは128ビットの値を、16進数で 8-4-4-4-12 の形に区切って表します。例：f47ac10b-58cc-4372-a567-0e02b2c3d479。

3番目のブロックの先頭がバージョン番号です。上の例では 4 なので UUID v4（ランダム）だと分かります。本ツールが生成するのもこの v4 で、Web開発で最もよく使われる形式です。

v1・v4・v7 の違い

v1（時刻ベース）：生成時刻とMACアドレスから作る。順序性はあるが、MACアドレスが漏れるプライバシー懸念がある。
v4（ランダム）：122ビットの乱数。最も手軽で用途を選ばない。順序はバラバラ。
v7（時刻＋ランダム、新しい規格）：先頭にミリ秒精度の時刻を含むため、生成順にほぼソートされる。データベース主キーに向く新定番として注目されている。

「とりあえず一意なIDが欲しい」なら v4、「DBの主キーで挿入性能も気にする」なら v7 が近年の選択肢です。

衝突確率は本当に無視できるのか

v4 の乱数部分は122ビット。組み合わせは約 5.3×10³⁶ 通りあります。直感的には想像しにくい大きさですが、「10億個のUUIDを毎秒生成し続けても、1つでも衝突するまでに約85年かかる」という桁感です。

本ツールはブラウザ標準の crypto.randomUUID()（暗号学的に安全な乱数）を使うため、実用上、重複を心配する必要はまずありません。ただし「絶対に0」ではないので、金融取引の一意性保証など極端に厳しい要件では、DB側のユニーク制約と併用するのが定石です。

UUIDを主キーにするときの注意

UUIDを主キーにすると、採番サーバなしで分散生成でき、IDから件数が推測されない利点があります。一方でデメリットもあります。

サイズ：整数の連番より大きい（16バイト）。インデックスもその分ふくらむ。
挿入性能：v4 は順序がバラバラなので、B-treeインデックスの断片化を招きやすい。大量挿入するテーブルでは v7 や、時刻順にソートできるIDの方が有利。

読みやすさ・URLでの扱いやすさを重視するなら、UUIDに近い代替（時刻順にソートできる短めのID）を検討するのも一手です。

セキュリティ用途に流用しない

v4 UUID は暗号学的に安全な乱数から作られますが、「識別子」であって「秘密トークン」ではありません。URLやログに載ることが前提の値なので、パスワードリセットのトークンやセッションIDのような「推測されると困る秘密」には、専用の設計（十分な長さのランダムトークン＋有効期限＋サーバ側の検証）を用意してください。用途を分けることが安全につながります。