要約

  • UUIDv7は先頭48ビットにUnixエポックからのミリ秒を置き、残る使用可能な74ビットを乱数、または任意の細分時刻・カウンタに使う。これはソート可能な識別子の構造であって、出来事の立証方式ではない。
  • RFC 9562は実際の時刻値を変える実装を許し、現実時刻への近さを保証しない。同一ミリ秒内の単調性、時計の逆行、カウンタの管理は実装側の責任である。
  • 監査に必要なのは、UUIDに加えて生成器、永続状態遷移、主体と認可、必要な外部時刻証明、受信側の効果を別々に結び付けることだ。

きれいな列は、共有された履歴ではない

RFC 9562 は128ビットUUIDの形式を定める。UUIDv7の先頭48ビットは、1970年からのUnix時刻をミリ秒で表す。バージョンとバリアントのビットを除く残りは rand_a と rand_b であり、通常は乱数で埋める。実装は、同じミリ秒の中で追加の単調性が必要なら、先にサブミリ秒の部分、次に注意深く初期化したカウンタ、最後に残りの乱数を置いてよい。

この形式が解く問題は具体的だ。UUIDをパースせずバイトとして比較でき、新しい鍵がB-treeなどの近い領域に置かれやすい。ランダムな挿入で索引ページが散るのを抑えられる。RFC 9562はUUIDv6とUUIDv7のソート性とデータベース局所性を明確に利点としている。

しかし、索引上で近いことは、業務上の処理が順に確定したことを意味しない。IDは入力検証の前に発行できる。トランザクションはその後ロールバックできる。outboxは後からメッセージを出し、受信側は同じIDを再試行として複数回見ることができる。UUIDはそれらの記録を横断する索引になる。どの操作が承認され、どの書き込みが確定し、どの通知が反映されたかを、内部のビットは代わりに語らない。

ミリ秒の表示と、時刻の信頼性は別である

UUIDv7の時刻部分を「発生時刻」と表示する画面は多い。しかしRFC 9562はその飛躍をしていない。環境やOSの変更、手動調整、時刻同期の補正で時計が戻る場合、実装は必要条件に合う扱いを決めなければならない、としている。

さらに同RFCは、実装が実際のタイムスタンプを変更してよいと記す。不正確な時計の補正、うるう秒処理、性能上の変換が例であり、埋め込まれた値が実時刻にどれだけ近いかについて要件も保証も置かない。UUIDの共通形式が、各ホストの時刻源、同期状態、smear方針、停止復帰や監視の質を裁定することはできないからである。

同じミリ秒に多数の値が出る場合も、形式だけでは順番を決めない。乱数のままなら相対順は発行順ではない。カウンタを使うなら、ビット数、初期化、再起動時の状態、オーバーフロー処理が重要になる。RFC 9562はオーバーフローをアプリケーションで処理し、前のUUIDより大きくない値を検知することを勧める。時計の逆行やカウンタ問題は、整った文字列の陰に隠れてはいけない。

中央調整を省く選択は、因果の証明を省く選択でもある

UUIDが便利なのは、世界全体の採番係を必要としないからだ。同時にRFC 9562は、共有知識なしに真のグローバル一意性を保証することは不可能だと述べる。多くの用途ではローカルな一意性で足り、UUID自体は共有機構を要求しない。

別々のノードは、別の時刻源、カウンタ、再起動状態、永続化を使いながら互換の鍵を発行できる。これは失敗ではなく、分散運用のための節度ある交換条件である。ただし、その二つの値を文字列で比べても、ある要求が先に受理された、あるメッセージが先に届いた、ある操作が次の効果を生んだとは証明できない。UUIDv7は合意ログの位置でも、複数ホストの因果グラフでもない。

RFC 9562が不要な解析を避け、UUIDを不透明な値として扱うよう勧める理由もここにある。時刻部分の確認は診断に役立つ場合がある。そこから監査結論を借りることは、別の設計行為である。

重要な主張ごとに、別の記録を置く

UUIDv7を監査の接続キーとして使うなら、少なくとも次の記録を分けるべきである。

  1. 生成記録：生成器の版、サービスまたはホスト、時刻源、精度、カウンタ、再起動、異常処理。
  2. 状態遷移記録：検証、永続コミットまたは失敗、メッセージ発行、再送、冪等性、照合。
  3. 権限記録：人またはサービス主体、委任、承認、適用規則、権限範囲。
  4. 外部時刻記録：第三者に対し「このデータはこの時刻までに存在した」と言う必要があるなら、RFC 3161 の別の面を使う。時刻認証局は、特定ポリシーの下でデータのハッシュに署名したトークンを発行し、要求者はハッシュ、署名、証明書、nonceまたは鮮度、ポリシーの適合性を確認する。これは限定された存在時刻の証拠であり、作者、認可、後の成功の証拠ではない。
  5. 効果記録：重要な受信側が、決済、設定適用、アクセス許可、拒否、補償を実際にどう処理したか。

恒路のRunning-Code Primacyを編集上の規律として使うなら、実際に生成・確定・受信・適用したコードと状態が、ソート列の見栄えより優先する。共通の識別子は最小限で可搬な道具として残し、影響を伴う解釈は、結果を見て責任を負える局所の主体に残すべきである。

情報源