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とは
UUID v7とは、2024年5月にIETFのRFC 9562で標準化された、時刻順にソート可能な新しいUUID（Universally Unique Identifier）です。従来広く使われてきたUUID v4は128ビットすべてが完全ランダムな値のため生成順を知る手がかりがありませんが、UUID v7は先頭48ビットにミリ秒単位のUnixタイムスタンプを持つため、文字列として並べ替えるだけで生成された順序どおりに並びます。残りのビットはランダム値で埋められており、同じミリ秒内に生成しても一意性は保たれます。
このツールはWeb Crypto APIを使ってブラウザ内でUUID v7を生成し、標準・大文字・ハイフンなし・波括弧付き・URN形式のいずれかで一括出力します。表記は既存のUUID v4向けデータベースカラムと完全互換なため、型変更なしにそのまま保存できるのが特徴です。生成した値がタイムスタンプ順に並ぶかを確かめたい場合は、姉妹ツールのUUID v7デコードツールで埋め込まれた時刻を取り出して確認できます。
UUID v7の生成手順
- 生成件数を指定する 一度に必要なUUID v7の個数を「生成件数」に入力します。まとめてテストデータを作りたい場合は複数件を指定できます。
- 表示形式を選ぶ 保存先のデータベースやシステムの仕様に合わせて、標準・大文字・ハイフンなし・波括弧付き・URN形式から選びます。
- 「生成する」ボタンを押す ブラウザ内のWeb Crypto APIで即座に生成され、結果欄に一覧表示されます。サーバーへの送信は発生しません。
- 結果をコピーする 1件ずつ「コピー」ボタンで、まとめて使う場合は「すべてコピー」ボタンでクリップボードに取得できます。
使いこなすためのヒント
- 生成した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 v7が役立つ場面
データベースの主キー設計
UUID v4より挿入位置が時系列順になりやすいため、B-treeインデックスの断片化を抑えつつ、既存のUUID型カラムをそのまま使い続けられます。
分散システムでのID採番
複数のサーバー・マイクロサービスが中央のシーケンス発行者に頼らず、それぞれ独立して一意かつ時刻順のIDを生成できます。
ログ・イベントの識別子
アクセスログやイベント履歴のIDにUUID v7を使うと、IDの大小関係だけでおおよその発生順序を把握でき、専用のタイムスタンプ列を別途持たなくても済みます。
テストデータ・ダミーレコードの一括作成
開発・検証環境で大量のダミーレコードを投入する際、複数件をまとめて生成しコピーすれば、SQLのINSERT文やAPIのテストペイロードにそのまま使えます。
生成結果の中身を確認したいとき
生成したUUID v7に本当に正しいタイムスタンプが埋め込まれているか確かめたい場合はUUID v7デコードツールで、ランダム生成のUUID v4が必要な場合はUUID生成ツールで対応できます。
UUID v7の関連用語
- UUID v7
- RFC 9562で標準化された、先頭48ビットにミリ秒単位のUnixタイムスタンプを持つUUIDのバージョンです。時刻順にソート可能でありながら、既存のUUID型カラムとの互換性を保っています。
- タイムスタンプ順ソート可能ID
- 値そのものに生成時刻の情報を含み、文字列や数値として並べ替えるだけで発生順に並ぶ識別子のことです。UUID v7・ULID・Snowflake IDなどが該当します。
- UUID v4との違い
- UUID v4は128ビットすべてが完全ランダムで生成順の情報を持たないのに対し、UUID v7は先頭48ビットがタイムスタンプのため生成順が分かります。表記形式（36文字・16進数）自体は両者で共通です。
- 単調性（Monotonicity）
- 値が生成順に単調増加する性質のことです。UUID v7は同一ミリ秒内で複数生成した場合、実装によってはランダム部分の大小関係だけが順序を左右するため、厳密な単調性は仕様上の必須要件ではなく実装依存になります。
- インデックス局所性
- データベースのB-treeインデックスにおいて、新しく挿入される値が既存データの近く（多くは末尾）に集まる性質です。UUID v7はタイムスタンプ順に値が並ぶため局所性が高く、完全ランダムなUUID v4より挿入時のページ分割やキャッシュ効率が改善しやすくなります。
- RFC 9562
- 2024年5月にIETFが公開した、UUIDの仕様を定める標準文書です。従来のRFC 4122を置き換え、時刻順ソート可能なv6・v7、カスタムフィールドを扱えるv8を新たに追加しました。
よくある質問
余談ですが ― 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と並んで急速に採用を広げている理由です。