UUID v4 生成機能の仕様
このページは、122 ビットの乱数から構成される UUID v4 識別子を、標準の 36 文字（8-4-4-4-12 の 16 進形式）で生成します。生成はすべてブラウザ内の暗号論的擬似乱数生成器 (CSPRNG) で行われ、サーバーにデータが送られることは一切ありません。デフォルトの出力は小文字・ハイフンありですが、大文字への切り替えとハイフンの有無を個別に制御できます。一度に生成できる ID 数は 1 ～ 100 です。出力オプション（大文字/小文字、ハイフンあり/なし）を変更すると、その場で全 ID が再生成されます。
UUID v4 が他と決定的に異なる点
UUID v4 はタイムスタンプを埋め込まないため、122 ビットすべてがランダム性に使われます。これにより生成順序にまったく相関がなく、データベースのプライマリキーとして使うとインデックスが断片化しやすい（B-tree のページ分割が頻発する）という特性があります。一方、UUID v7 や ULID は時間情報を含むため時系列でソート可能ですが、推測困難性は v4 より低くなります。このページでは v4 以外に v7、ULID、NanoID も選択できますが、v4 を選んだ場合のみ大文字・ハイフンのトグルが有効になります（他の形式ではこれらのオプションが異なる場合があります）。
乱数品質と衝突確率
ブラウザの crypto.getRandomValues() は OS レベルのエントロピー源（Intel SGX の RDRAND やハードウェア乱数生成器など）を利用するため、予測不能性は十分高いです。UUID v4 の衝突確率は、2^122 分の 1 のオーダーであり、毎秒 10 億個の ID を生成しても 36 年間で衝突確率が 50% に達するという計算になります（誕生日問題の近似）。実用上は事実上ゼロとみなせます。
入力項目と出力動作
入力
- フォーマット: UUID v4, UUID v7, ULID, NanoID から選択。この記事は v4 固定。
- 個数: 1 ～ 100 の整数。範囲外の値は入力不可。
- 大文字: オフ（デフォルト）→ 小文字。オン → 大文字（例:
3B06FB72-...）。 - ハイフンを含める: オン（デフォルト）→ 8-4-4-4-12 形式。オフ → 32 桁の連続16進文字列。
出力
- 生成された ID がリスト表示され、上部に「IDs count: N」と表示。
- 初期状態は「Ready.」、生成後は「Generated.」、全コピー後は「Copied all!」。
- 各 ID をクリックすると個別コピー、下部の「Copy all」ボタンで全 ID をクリップボードにコピー。
オプション変更時の動作
個数、大文字、ハイフンのいずれかを変更するたびに、すべての ID が即座に再生成されます。これは、変更前の ID が有効でなくなることを意味します。たとえば、個数を 5 から 10 に増やしたとき、以前の 5 個の ID は破棄され、新たに 10 個の ID が生成されます。
実装上の注意点とよくある誤解
- ブラウザ依存性:
crypto.getRandomValuesはすべてのモダンブラウザで利用可能ですが、古いブラウザ（IE 11 以前）や制限の厳しいポリシー環境では動作しない場合があります。このページは最新の Chrome/Firefox/Safari/Edge での動作を前提としています。 - 大文字・小文字の区別: UUID v4 の標準仕様（RFC 4122）では大文字小文字を区別しませんが、システムによっては大文字のみを要求する場合があります。このページでは表示形式を切り替えるだけで、内部のビットパターンは変わりません。
- ハイフンを外すとどうなるか: 32 文字の連続16進文字列になり、データベースのカラム型によっては VARCHAR(32) などで格納できます。ただし、標準的な UUID 表現ではないため、アプリケーション側でパース処理が必要になる場合があります。
- 個数上限の理由: 100 以上にするとブラウザのクリップボード API が一度に処理できるデータ量を超える可能性があります。また、表示領域が長くなりすぎるため、実用的な上限として 100 が設定されています。
ユースケースと代替選択
UUID v4 が適している場面
- セキュリティトークン（パスワードリセットリンクの ID、OAuth の state パラメータなど）
- セッション ID（サーバーで推測される可能性を極力減らしたい場合）
- 外部公開識別子（ユーザー ID を隠したいが、ソート不能でも問題ない場合）
- 匿名化データのキー（タイムスタンプを付与すると個人特定の手がかりになるのを避けたい場合）
UUID v4 が不適切な場面
- データベースのプライマリキー（特に InnoDB のクラスタ化インデックスを使う場合）。挿入順にランダムになるため、ページ分割が頻発し書き込み性能が著しく低下します。代わりに UUID v7 や ULID、または連番を検討すべきです。
- 時系列でソートして表示する必要があるデータ。v4 では生成時刻が分からないため、別途タイムスタンプカラムが必要になります。
よくある質問 (FAQ)
Q1: 生成された UUID は本当に重複しないのですか？
A: 数学的には 2^122 分の 1 の確率で衝突しますが、現実的な使用ではまず起こりません。たとえば 10 億個の ID を生成したときの衝突確率は約 1.1×10^(-19) です。ただし、ブラウザの乱数生成器に偏りがあったり、同じシステム時刻を使う複数のプロセスが同じ乱数源を共有する場合など、極めて稀な状況では理論上の確率を上回る可能性はあります。
Q2: 大文字と小文字、どちらを使うべきですか？
A: システムの要件次第です。RFC 4122 では大文字小文字を区別しませんが、一部の DB や API で大文字が強制される場合があります。このページでは自由に切り替えられるので、出力先の仕様に合わせてください。内部的には同じ 128 ビット値です。
Q3: ハイフンなしの 32 文字は有効な UUID ですか？
A: 標準的にはハイフンを含む 36 文字が UUID 表現ですが、ハイフンを除いた 32 文字も、元のバイナリ表現に復元可能なため、多くのシステムで UUID として扱えます。ただし、UUID としての文字列表現は 36 文字が正式です。
Q4: 生成された ID はそのままデータベースに保存できますか？
A: 可能です。ただし、プライマリキーとして使う場合は前述のインデックス断片化に注意してください。また、カラム型は VARCHAR(36)（ハイフンあり）または BINARY(16) で格納するのが一般的です。VARCHAR(32) でハイフンなしの文字列を保存すると、ライブラリによってはパースに失敗する可能性があるため、事前に形式を統一しておきましょう。
Q5: 一度に 100 個以上生成したい場合はどうすればいいですか？
A: このページでは 100 までしか生成できません。複数回に分けて生成し、自分で結合するか、別のツール（コマンドラインの uuidgen、Python の uuid モジュールなど）を使ってください。ただし、ブラウザで大量生成する場合はメモリ使用量に注意が必要です。