UUID v7タイムスタンプ抽出
UUID v7の先頭48ビットに埋め込まれたミリ秒単位のタイムスタンプを、UUID文字列を貼り付けるだけでUTC日時に復元します。v7以外のバージョンやvariant異常も検出し、姉妹ツール「UUID v7生成」の逆変換として使えます。
UUID v7のビットレイアウト
| ビット範囲 | フィールド | 説明 |
|---|---|---|
| 0-47 | unix_ts_ms | Unixエポックからのミリ秒数をビッグエンディアンで格納。本ツールが抽出する値。 |
| 48-51 | version | UUIDのバージョン番号。v7なら固定値0111（16進数で7）。 |
| 52-63 | rand_a | 12ビットのランダム値。同一ミリ秒内での順序保持に使われる実装もある。 |
| 64-65 | variant | RFC 4122/9562のvariantを示す固定値10。16進数では先頭が8/9/a/bになる。 |
| 66-127 | rand_b | 62ビットのランダム値。衝突回避のためのエントロピー。 |
使い方のヒント
- 解析処理はすべてブラウザ内のJavaScriptで完結し、入力したUUIDがtoolbase.ccのサーバーに送信されることはありません。
- データベースの主キーにUUID v7を採用している場合、レコードにcreated_atカラムが無くても、主キーを本ツールに貼り付けるだけでそのレコードが作成された時刻を復元できます。
- v7以外のUUID（v4など）を入力すると警告が表示されますが、先頭48ビットから機械的に抽出した参考値は引き続き表示されるため、フォーマットの違いを学ぶ目的にも使えます。
- UUIDを生成したい場合は姉妹ツールの「UUID v7生成」を使うと、本ツールでそのまま逆変換できる形式のUUIDが得られます。
- ログファイルやAPIレスポンスに含まれるUUID v7を1件ずつ貼り替えることで、外部システムのイベント発生時刻を推定するデバッグにも活用できます。
よくある質問
UUID v7はRFC 9562で標準化されており、128ビットのうち先頭48ビットにミリ秒単位のUnixタイムスタンプがビッグエンディアンで固定的に埋め込まれています。そのため先頭12桁の16進数を数値に変換し、ミリ秒として解釈するだけで生成時刻を復元できます。
UUID v4は完全ランダムな値のため、抽出された「タイムスタンプ」は実際の生成時刻とは無関係な意味のない数値になります。本ツールはバージョン桁を検査して警告を表示しますが、参考として先頭48ビットの機械的な抽出結果自体は引き続き表示します。
UUID v7の仕様上、精度はミリ秒単位です。同じミリ秒内で複数のUUID v7が生成された場合、先頭48ビットの値は同一になり、区別はrand_a・rand_bのランダム値に委ねられるため、それらの生成順序までは復元できません。
RFC 4122/9562準拠のUUIDは4番目のグループの先頭16進数字が8・9・a・bのいずれかになるよう定められています。この値がそれ以外（0-7・c-f）の場合、独自仕様のID生成ロジックやビット破損の可能性があるため警告を表示します。
余談ですが ― UUIDが「時計」を内蔵するということ
UUID v7が画期的なのは、識別子自体が生成時刻という情報を恒久的に保持する点です。従来のUUID v4では「いつ作られたレコードか」を知るには別途created_atのようなタイムスタンプカラムが必須でしたが、UUID v7を主キーに使っていれば、そのID文字列だけから生成時刻を機械的に復元できます。本ツールはその復元処理を、姉妹ツールであるUUID v7生成ツールの逆変換として提供しています。
この性質は障害調査やデータ移行の現場で特に役立ちます。例えば、古いログに残された注文IDや、外部システムから受け取ったイベントIDがUUID v7形式であれば、専用のタイムスタンプカラムを参照しなくても「このレコードは何時ごろ作られたものか」を即座に確認できます。created_atカラムが欠落している旧システムの調査や、他社が発行したUUID v7の解析にも応用できます。
一方で、この仕組みには注意点もあります。UUID v7のタイムスタンプはあくまで生成側のクロックに依存するため、生成元のサーバー時刻がずれていれば抽出結果もずれます。また本ツールがUUID v4のような他バージョンの値からも「タイムスタンプらしきもの」を機械的に抽出してしまうのは、あくまでビット位置の解釈にすぎず、意味のある値であることを保証するものではない点も踏まえて利用してください。