UUID 生成ツール
v4 UUID を一括生成。乱数はブラウザの暗号論的 API から取得します。
優先的に使用 crypto.randomUUID()。ブラウザが対応していない場合は crypto.getRandomValues() 手動で組み立てても、v4 仕様のランダム性要件は満たしています。
使う場面
- テストデータ、CSV、シード用の行に主キーが必要なとき。50 個まとめて生成して INSERT やフィクスチャにそのまま貼れます。uuidgen の導入も、行ごとのコマンド実行も不要です。
- 時刻やマシン情報を漏らさないリクエスト ID、冪等キー、冪等トークンがほしいとき。v4 はすべて乱数ビットで、タイムスタンプや MAC アドレスを埋め込む v1 とは異なります。
使わないほうがよい場面
- 主キーで並べ替えたり、作成時刻でページングしたりする場合。v4 は完全な乱数なので B-tree への挿入が散らばり、ID から前後関係も分かりません。UUID v7、ULID、または自動採番と時刻列の組み合わせを使ってください。
- 同じ名前から常に同じ ID を導きたい場合（冪等なインポート、決定的なテストフィクスチャ）。それは v3（MD5）や v5（SHA-1）の名前空間 UUID です。本ツールは v4 のみなので、押すたびに違う値になります。
生成はすべてブラウザ内で完結し、送信も保存もされません。crypto.randomUUID を優先し、古い環境では getRandomValues でバージョンビットを手動設定して代替します。制限：v4 のみ（v1/v3/v5/v7 は非対応）。1 回最大 100 個。既存データとの重複は確認しません。randomUUID には HTTPS か localhost のセキュアコンテキストが必要です。
よくある質問
v4 が重複することはありますか？
理論上はありますが、確率は無視できます。乱数 122 ビットでは、10 億個生成しても衝突確率はおよそ 10 の -19 乗の桁です。現実の重複は数学ではなく運用から来ます。ホストごとに独立して生成する、書き込みをリトライする、コピペで切り詰める、といった原因です。データベースに一意制約を置き、そこを保証としてください。「たぶん重ならない」に頼るべきではありません。
大文字のまま保存してもいいですか？
保存はできますが、統一が必要です。RFC 9562 は出力を小文字と定め、比較では大文字小文字を区別しません。しかしデータベースの照合順序、Redis のキー、ログ検索は区別するものが多く、混在すると「同じ UUID」が引けなくなります。保存と送信は小文字に統一し、表示や、大文字を要求する古いシステム（一部の Oracle や SAP のインターフェース）向けにだけ変換してください。
UUID から生成時刻やマシンは分かりますか？
v4 では分かりません。バージョンビットとバリアントビット以外は純粋な乱数で、時刻もノード識別子もありません。情報が漏れるのは他のバージョンです。v1 は生成時刻と NIC の MAC アドレス（またはランダムな node）を含み、v7 はミリ秒のタイムスタンプを含みます。本ツールは v4 のみを生成するため、その種の推測はできません。ただし時刻順に並ぶ ID としては使えません。