UUID v7 生成
RFC 9562で標準化された、先頭48ビットにミリ秒タイムスタンプを持つ時刻順ソート可能な新しいUUID「UUID v7」をブラウザ上で一括生成します。標準・大文字・ハイフンなし・波括弧付き・URN形式にも対応し、既存のUUID型カラムにそのまま保存できます。
UUID v7・UUID v4・ULIDの比較
| 形式 | 長さ | 生成順に並べ替え可能か | 既存UUID型カラムとの互換性 | 説明 |
|---|---|---|---|---|
| UUID v7 | 36文字（ハイフン4個含む） | はい（先頭48ビットがミリ秒タイムスタンプ） | あり（標準のUUID型・16進数表記のまま） | RFC 9562で標準化。Unixタイムスタンプ + ランダム値で構成され、時刻順ソートと既存UUID資産との互換性を両立する。本ツールが生成する形式。 |
| UUID v4 | 36文字（ハイフン4個含む） | いいえ（完全ランダム） | あり（標準のUUID型） | RFC 9562で標準化された完全ランダムな128ビットの識別子。生成元の情報を含まず、最も広く使われている形式。 |
| ULID | 26文字 | はい（先頭10文字がタイムスタンプ） | なし（Base32のため別途型変換が必要） | UUID標準（RFC 4122/9562）とは独立したCrockford Base32形式の規格。UUID v7より短いが、既存のUUID型カラムには直接保存できない。 |
使い方のヒント
- 生成したUUID v7はブラウザ内のJavaScript（Web Crypto API）で処理され、toolbase.ccのサーバーには一切送信されません。
- UUID v7は先頭48ビットがミリ秒単位のUnixタイムスタンプのため、生成した順に文字列としてソートするだけで時系列順に並び替えられます。
- 既存のUUID v4用データベースカラム（CHAR(36)やPostgreSQLのuuid型など）にそのまま保存できるため、アプリケーション側の型変更なしに移行できます。
- 「ハイフンなし」形式はURLのパスセグメントやファイル名として使う際に便利です。「波括弧付き」形式はWindowsのCOM/レジストリ関連（GUID）で使われる形式と同じです。
- ULID（Crockford Base32・26文字）とどちらを使うか迷ったら、既存システムがUUID型カラムを前提にしているならUUID v7、短い文字列を優先するならULIDを選ぶとよいでしょう。
よくある質問
余談ですが ― UUIDに「時刻」を取り戻したUUID v7
UUID v7は2024年5月にIETFのRFC 9562として標準化されました。これはUUIDの元となる仕様であるRFC 4122（2005年）以来約20年ぶりの大規模改訂で、時刻順にソート可能なv6・v7、そしてカスタムフィールドを扱えるv8が新たに追加されました。背景には、UUID v4の完全ランダム性がデータベースのインデックス効率にとって不利であるという、長年指摘されてきた課題があります。
UUID v7の設計は本サイトの姉妹ツールであるULIDと非常によく似ています。どちらも先頭にミリ秒単位のタイムスタンプを持ち、残りをランダム値で埋めるという構造は共通していますが、決定的な違いは表記形式です。ULIDはUUID標準とは独立した規格として26文字のCrockford Base32を採用しているのに対し、UUID v7はRFC 4122以来の36文字・16進数表記を維持しています。この違いにより、UUID v7は既存のUUID型カラム・ライブラリ・API仕様をそのまま使い続けられるという大きな利点があります。
実際、UUID v7は登場から間もなく主要なデータベース・言語ランタイムでのサポートが広がりました。PostgreSQLはバージョン18でuuidv7()関数を標準搭載し、他の主要言語・ORMでもv7生成に対応するライブラリが急速に増えています。「時刻順にソートできる」という利便性と「既存のUUID資産を壊さない」という保守性を両立できる点が、UUID v7がULIDと並んで急速に採用を広げている理由です。