UUID 生成ツール

用途

UUID（または GUID）は 128 bit の識別子で、5 つに区切られた 32 桁の hex 文字列で表記します（例：550e8400-e29b-41d4-a716-446655440000）。システム間で調整なしに衝突なく発行でき、衝突確率は実質ゼロです。DB に問い合わせる前に ID が必要なとき、行数の漏洩を避けたいとき、クライアント側で発行して後から同期したいときなどに有用です。本ツールは RFC 4122 / RFC 9562 準拠の UUID を v4（ランダム）または v7（時刻順）で、ブラウザ内の暗号論的乱数を使って生成します。

使うべきタイミング

• 分散システムのプライマリキーで、DB 往復なしに ID を確定させたいとき。
• API リクエストの冪等性キー（Stripe、決済プロバイダ、キューメッセージ）。
• ファイルアップロード ID、セッショントークン、ログのコリレーション ID。
• オートインクリメント ID を露出させて件数を漏らしたくない場面。
• テストデータ — 100 件のレコードに現実的な識別子をワンクリックで付与。

v4 と v7、どちらを使うか

• v4（ランダム） — 122 bit のランダム値、生成時刻の埋め込みなし。ID と作成順の相関を完全にゼロにしたいときや、ハッシュマップ／非クラスタ化インデックスのように順序が無関係な場面に向きます。
• v7（時刻順） — 先頭 48 bit に Unix ミリ秒タイムスタンプ、残りはランダム。新規 DB プライマリキーには基本これを推奨します。 時刻プレフィックスにより B-tree インデックスの局所性が高まり（最近の挿入が同じページに集中するため、v4 よりキャッシュ効率が大幅に向上）、ID はおおむね時系列順にソートされます。RFC 9562（2024 年 5 月）で定義され、多くのユースケースで ULID や v1/v6 を置き換えています。

よくある注意点

• UUID は秘密ではありません。 v4 は 122 bit のエントロピーを持ち推測不能ですが、フォーマット自体に認可機能はありません。セッションや再設定リンクの token に使う場合、HTTPS のみ・期限付き・使い切りのような扱いをしてください。
• v7 は作成時刻を漏らします。 先頭 48 bit が発行時のミリ秒を表します。内部 ID には問題ありませんが、ユーザに作成時刻を知られたくない場合は v4 を選んでください。
• インデックスサイズに注意。 UUID は 16 バイトで、bigint の 8 バイトの倍。B-tree インデックスは大きくなります。分散・無調整の場面では割に合いますが、シングルサーバーの順序付き ID で済むなら多くの場合得をしません。
• v4 はインデックスを断片化します。 ランダム ID は書き込みをインデックス全体に散らし、ページキャッシュのヒット率と書き込みスループットを下げます。これが v7 を推す根拠です。
• v1 は使わないこと。 旧来の time-and-MAC 方式は生成マシンの MAC アドレスを漏らします。現代的な置き換えが v7 です。
• 暗号論的に安全な乱数を使ってください。 本ツールは crypto.getRandomValues を使用します。Math.random 自前は乱数として弱く、ID が予測可能になります。