crypto.randomUUID() (Web Crypto API) を使って UUID v4 を 1〜100 個生成します。ハイフンの有無を切り替えられ、処理はブラウザ内で完結します。UUID の設計上の目的は「調整なしで一意な識別子を作れること」だけで、順序も、意味も、短さも持ちません — この 3 つが無いことが、データベースや URL で使うときの問題をほぼすべて生みます。

ケース	何が起きるか	どうする
主キーに使うとデータベースが遅くなる	UUID v4 は完全にランダムなので、挿入される位置がインデックスの中で散らばります。B-tree は末尾に追記するのが最も効率的な構造なので、ランダムな挿入はページ分割を頻発させ、インデックスが断片化します。MySQL の InnoDB は主キーがクラスタ化インデックス — つまり行のデータそのものが主キー順に並んでいる — なので影響はさらに大きく、数千万行の規模になると、連番の主キーと比べて挿入が数倍遅くなり、インデックスのサイズも膨らみます。加えて、`CHAR(36)` で保存すると連番の `BIGINT` (8 バイト) の 4.5 倍の容量を、全ての外部キーとインデックスで消費します。	時刻順に並ぶ UUID v7 を使ってください — 先頭 48 ビットが Unix ミリ秒なので生成順にソートされ、B-tree への挿入が末尾に集中します。UUID の見た目と一意性はそのままで、この問題だけを解決するために設計されたバージョンです (RFC 9562 で標準化されました)。v7 が使えない環境なら、内部の主キーは連番にして、外部に見せる ID だけ UUID を別カラムで持つのが確実です。保存形式も見直してください — `CHAR(36)` ではなく `BINARY(16)` にすれば容量は半分以下になります (PostgreSQL には `uuid` 型があります)。まず「本当に UUID が必要か」を確認してください — 分散生成もオフライン生成も必要ないなら、連番で十分です。
UUID を秘密の値として使ってしまう	UUID v4 のランダム部分は 122 ビットあるので、推測は現実的に不可能です — この点だけを見て「URL に UUID を入れておけば、知っている人しかアクセスできない」という設計が採られることがあります。しかしUUID は識別子であって、秘密として扱う前提の値ではありません — URL に入れれば、ブラウザの履歴・リファラヘッダ・アクセスログ・プロキシのログ・共有されたリンクに残ります。さらに、UUID v1 は MAC アドレスと生成時刻を含んでいるので、そもそもランダムですらありません — v1 をセッション ID やパスワードリセットトークンに使うのは危険です。	「知っていればアクセスできる」設計そのものを避けてください — アクセス制御は認証と認可で行うのが本筋で、URL の推測困難さに頼るのは補助にすぎません。共有リンクのように URL 自体を鍵にする設計が必要な場合は、UUID ではなく専用のトークンを使い、有効期限と失効の仕組みを付けてください — `crypto.getRandomValues()` で 32 バイトの乱数を生成し、Base64url にするのが標準的です。そして、その URL がログに残らないよう、パスではなくフラグメント (`#` 以降) に置くか、POST で送ってください — フラグメントはサーバーに送信されません。UUID は「これは何か」を示すもので、「あなたは誰か」を証明するものではありません。
表記のゆれで同じ ID が別物として扱われる	UUID には表記の選択肢が複数あります — 大文字と小文字 (`A1B2` と `a1b2`)、ハイフンの有無 (36 文字と 32 文字)、そして中括弧で囲む形式 (`{...}`、Microsoft の慣習) です。RFC 4122 は「生成時は小文字、受け入れは大小両方」と定めていますが、文字列として比較すればこれらは全部別物になります。実務では、あるシステムが大文字で返し、別のシステムが小文字で保存していると、同じレコードが重複して作られます — しかもデータベースの照合順序によっては一致したりしなかったりするので、環境ごとに挙動が変わって原因が掴めなくなります。	システムの入口で 1 つの形式に正規化してください — ハイフンあり・小文字が最も一般的で、RFC の推奨にも沿います。API で受け取った値は、比較や保存の前に必ず `toLowerCase()` を通してください。データベースに保存するなら、文字列ではなくバイナリ型または `uuid` 型を使うのが根本的な解決です — バイナリなら表記の問題そのものが存在しません (PostgreSQL の `uuid` 型は入力の表記を吸収して同じ値として扱います)。そして、UUID を受け取る箇所には妥当性検証を入れてください — 形式が違う値が来たときに、黙って別レコードを作るのではなく、その場でエラーにするほうが原因を追いやすくなります。

衝突については、心配しすぎるのも、しなさすぎるのも間違いです。UUID v4 のランダム部分は 122 ビットで、毎秒 10 億個を 100 年間生成し続けても衝突確率は無視できるほど低い — ただしこれは「暗号論的に安全な乱数を使っている場合」に限った話です。Math.random() をもとに UUID を組み立てる実装は実在し、そういう実装では実際に衝突します — とくに組み込み機器や、起動直後のサーバーはエントロピーが不足しがちで、複数台が同じ値を生成した事例があります。ブラウザなら crypto.randomUUID()、サーバーなら各言語の暗号用乱数 API を使ってください。もう 1 点、crypto.randomUUID() はセキュアコンテキスト (HTTPS または localhost) でしか使えません — 社内の HTTP 環境で「なぜか関数が存在しない」というのは、ほぼこれが原因です。

📖 使い方

1

生成数を指定

「生成数」に 1〜100 の値を入力します。テストデータや DB の主キーを一括生成する際に複数指定すると便利です。
2

ハイフンあり / なしを選択して生成

「ハイフンなし」チェックボックスでフォーマットを切り替え、「生成」ボタンをクリックします。crypto.randomUUID() または Web Crypto API で暗号論的に安全な UUID が生成されます。
3

一括コピーして利用

「一括コピー」ボタンで全 UUID を改行区切りでクリップボードにコピーできます。SQL の INSERT や JSON ファイルにそのまま貼り付けられます。

❓ よくある質問

UUID v4 とは何ですか?

UUID v4 は 128 ビットのランダムな識別子です。RFC 4122 で定義され、8-4-4-4-12 の形式で表されます。バージョン 4 はランダム生成であるため、衝突確率は実用上無視できるほど低いです。

衝突（重複）の可能性はありますか?

理論上はあります。しかし 122 ビットのランダム性があり、1 兆個生成して重複する確率は約 0.000000001% 以下です。実用上は無視できます。

UUID はデータベースの主キーとして使えますか?

はい。分散システムや複数サーバー環境での重複回避に有効です。ただし、UUID v4 はランダムなためインデックスの断片化が発生しやすい点に注意が必要です。順序が必要な場合は UUID v7 の使用を検討してください。

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。

UUID v4ジェネレーター

他のオンラインツール

関連記事

📖 つまずきやすいポイント

📖 使い方

❓ よくある質問

ご報告ありがとうございます！