MiServe DevTools

あなたのステッカー

ツールをここにピン留めできます。このブラウザに保存されます。

UUID・ULID・Nano ID 生成ツール

UUID v4、時系列順に並ぶ UUID v7、ULID、Nano ID をまとめて生成し、ID に含まれるバージョンやタイムスタンプを読み取ります。

種類
バリアント
タイムスタンプ(UTC)
ローカル時刻
Unix 時間(ミリ秒)

ブラウザ内で動作します。貼り付けた内容はアップロードされません。

このツールについて

どの ID を選ぶか

UUID バージョン 4 は 122 ビットのランダム値です。いつどこで作られたかは何も示さず、ID が一意でありさえすればよい場合の定番です。2024 年に RFC 9562 で標準化された UUID バージョン 7 は、ミリ秒単位の 48 ビットの Unix タイムスタンプを 74 ビットのランダム値の前に置きます。新しい ID は古い ID の後ろに並ぶので、まとめて挿入した行はデータベースのインデックス上でも近くにまとまります。その代わり、ID を見た人には作成時刻がわかってしまいます。

ULID は同じ考え方を別の表記で実現したものです。48 ビットの時刻と 80 ビットのランダム値を、大文字と小文字を区別しない Crockford Base32 の 26 文字で、ハイフンなしで表します。Nano ID は、長さと文字セットを自由に選べるランダムな文字列です。デフォルトは URL で安全に使える 64 種類の文字による 21 文字で、ランダム性は 126 ビットです。バージョン 4 の UUID よりわずかに多く、しかも文字列は短くなります。

どのくらい一意で、どのくらい秘密か

ランダムな ID は、理論上は衝突する可能性があります。バージョン 4 では、重複が 1 回でも起こる確率が 2 分の 1 に達するまでに、約 270 京(2.7 × 10^18)個の UUID を生成する必要があります。アプリケーションが UUID を一意なものとして扱うのはそのためです。Nano ID を短くしたり文字セットを小さくしたりすると、その余裕は小さくなります。オプションの下の行に、選んだ設定で何ビットのランダム性が得られるかが表示されます。

ID は識別子であって、秘密ではありません。バージョン 1、6、7 と ULID は作成時刻を明かしますし、RFC 9562 は UUID を権限の証明として当てにしないよう警告しています。パスワードリセットのリンク、セッション、API キーには、128 ビット以上のランダムなトークンを使い、サーバーにはそのハッシュだけを保存してください。

UUID の読み方

通常の形式 xxxxxxxx-xxxx-Vxxx-Nxxx-xxxxxxxxxxxx では、V の桁がバージョン、N の先頭のビットがバリアントを表します。ほぼすべての UUID が使う RFC 9562 のレイアウトでは、N は 8、9、a、b のいずれかです。バージョン 1 と 6 は、1582 年 10 月 15 日からの 100 ナノ秒単位の 60 ビットのカウントと、ノード ID を持ちます。ノード ID は、もともとはネットワークカードの MAC アドレスでした。バージョン 7 は Unix ミリ秒を持ちます。バージョン 3 と 5 は名前のハッシュ、バージョン 4 はランダム値なので、デコードできる情報はありません。

ULID の先頭 10 文字はタイムスタンプです。解析欄は、ハイフンのない UUID、波かっこで囲んだ UUID、urn:uuid: プレフィックス付きの UUID も受け付けます。

このツールでの生成方法

ランダムなビットはすべて、ブラウザの暗号論的乱数生成器である crypto.getRandomValues から得ています。サーバーには何もリクエストせず、何も保存しません。

同じミリ秒内に作られたバージョン 7 の UUID は、タイムスタンプを維持したまま、74 ビットのランダム部分にランダムな増分を加えます。これは RFC 9562 で説明されている単調増加の方式で、一度に生成した ID は常に生成順に並びます。同じミリ秒内に作られた ULID は、ULID の仕様どおりランダム部分に 1 を加えます。この順序が保証されるのは、このページで生成した ID の間だけです。別々のマシンで同じミリ秒内に作られた ID の並び順は決まっていません。Nano ID の文字は、文字セットの範囲外になるランダムバイトを捨てて選ぶため、どの文字も等しい確率で出現します。

よくある質問

データベースの主キーには UUID v4 と UUID v7 のどちらを使うべきですか?

新しい行をインデックス上で近くに配置したく、ID から作成時刻がわかっても構わないなら、主キーにはバージョン 7 が適しています。ID から何も読み取れないようにする必要があるなら、バージョン 4 を選びます。どちらも 128 ビットで、同じ uuid 型の列に収まります。

生成した 2 つの UUID が同じになることはありますか?

可能性はありますが、考慮する必要がないほど低い確率です。バージョン 4 の UUID は 122 ビットのランダム値を持つので、重複が 1 回起こる確率が五分五分になるには約 270 京(2.7 × 10^18)個が必要です。現実のリスクは乱数源が弱いことで、このツールがブラウザの暗号論的乱数生成器を使うのはそのためです。

ULID と UUID v7 は同じものですか?

違いますが、よく似ています。どちらも 128 ビットで、ミリ秒単位の 48 ビットのタイムスタンプで始まるため、ULID のビット列は 128 ビットの UUID 列に収まります。ただし ULID にはバージョンとバリアントのフィールドがないので、RFC 9562 では UUID として定義されていません。また、テキスト表現には、UUID が 16 進数を使うのに対して ULID は Crockford Base32 を使います。

UUID が作成された日時はわかりますか?

UUID のバージョン 1、6、7 と ULID はタイムスタンプを持つので、わかります。値を解析欄に貼り付けると、日時として表示されます。バージョン 4 の UUID はランダムで、時刻は含みません。

ハッシュのほかのツール