UUID生成ツール

ランダムなUUID v4または時系列順のUUID v7を、ブラウザ上で1つから最大1,000個まで一括生成できます。

生成されたUUID

生成結果

RFC 4122バージョン4準拠の128ビットランダム識別子です。

バージョン: -
埋め込みタイムスタンプ: -

一括生成

上記で選択したバージョンを使用します。一度に最大1,000個まで生成可能です。

生成結果一覧

使い方

UUID（汎用一意識別子）とは、中央機関による発行を必要とせずデータを識別するために用いられる128ビットの値です。このツールは、ブラウザの暗号学的に安全な乱数生成機能を使用して、RFC 4122バージョン4（ランダム）またはバージョン7（時系列順）のUUIDを生成します。

バージョンの選択
純粋なランダム性が必要ならv4、作成時刻でソート可能なIDが必要な場合はv7を選択してください。
生成とコピー
新しいUUIDが即座に表示されます。コピーするか、別のUUIDを生成してください。
大量に必要ですか？
一括生成を使用すると、最大1,000件のUUIDを標準、大文字、ハイフンなし、または中括弧形式で生成できます。

UUID v4とUUID v7の違い

UUID v4は一部の固定されたバージョンビットとバリアントビットを除き完全にランダムなため、生成日時や場所に関する情報は含まれません。UUID v7は最初の48ビットにミリ秒精度のUnixタイムスタンプが埋め込まれており、その後にランダムデータが続くため、v7の値は生成順にソートされます。

v4を使用するのは、IDに時間情報をエンコードしたくない場合や、IDからおおよその生成時刻を推測されたくない場合です。
v7を使用するのは、データベースの主キーとして使用し、created_atカラムを別途設けずに時系列に近い挿入を行いたい場合です（これにより、大規模なB-treeインデックスでランダムなv4キーが引き起こすインデックスの断片化を回避できます）。

データがデバイスの外に出ることはありません

すべてのUUIDはWeb Crypto APIのgetRandomValuesを使用してブラウザ上でローカルに生成されます。サーバーへのリクエストは行われないため、非公開または未公開システムの識別子を生成しても安全です。

よくある質問

UUID v4とUUID v7の違いは何ですか？

UUID v4は一部のバージョンビットとバリアントビットを除き完全にランダムであり、順序の保証はありません。UUID v7は最上位ビットにミリ秒精度のUnixタイムスタンプが埋め込まれており、生成されたUUIDを作成時刻順にソートできます。v7はcreated_atカラムを別途設けずに時間順の並べ替えが必要なデータベースの主キーに適しており、v4は時間情報を含めるべきでないIDに適しています。

何もインストールせずにブラウザでUUIDを生成するにはどうすればよいですか？

このページを開き、v4またはv7を選択して「新規生成」をクリックしてください。UUIDが即座に表示され、「コピー」をクリックするとクリップボードに保存されます。まとめて生成する場合は、「一括生成」で最大1,000個まで指定してください。すべての生成処理はブラウザ内のWeb Crypto APIのgetRandomValuesを使用して実行されるため、サーバーへの通信は行われません。

UUID v4の値は暗号学的にランダムで、衝突のリスクはありませんか？

はい。本ツールはブラウザのcrypto.getRandomValuesを使用しており、暗号学的に強力なランダムバイトを生成します。同一のv4 UUIDが生成される理論的な確率は約5.3 x 10^36分の1です。実際には、あらゆるアプリケーションにおいてv4の衝突が問題となることは現実的にありません。

特定のデータベース向けに、ハイフンなしまたは大文字のUUIDを生成するにはどうすればよいですか？

「一括生成」のフォーマット選択を使用してください。オプションには標準（ハイフンあり小文字）、大文字、ハイフンなし、{ブレース}があります。システムによっては特定のフォーマットが必要です。例えばMySQLはパフォーマンス向上のためUUIDをハイフンなしのCHAR(32)として保存することが多く、Windows COM GUIDは通常ブレース形式で表示されます。

PostgreSQLやMySQLでUUIDを主キーとして使用できますか？

はい。ただしv4にはパフォーマンス上の注意点があります。ランダムなv4キーはB-treeインデックスのランダムな位置に挿入されるため、大規模なテーブルでは断片化を引き起こします。UUID v7は時系列順にソート可能であり、ほぼ連続した順序で挿入されるため、この問題を回避できます。PostgreSQLにはネイティブのuuid型があり、MySQLは通常UUIDをCHAR(36)またはBINARY(16)として保存します。