Snowflake ID・ObjectID・UUID生成時刻デコード
IDを貼り付けると形式を自動判定し、生成時刻（UTC・JST・ISO 8601・UNIXミリ秒）とworker・sequenceなどの構成要素を表示します。IDを作りたい場合は UUID生成 や ULID・NanoID生成、時刻の変換は UNIXタイムスタンプ変換 をご利用ください。
🔒 ブラウザ内で完結・入力データはサーバーに送信されません
結果
IDを入力すると、ここに結果が表示されます。
使い方
- IDを「ID（1行に1件）」の欄に貼り付けます。複数ある場合は1行に1件ずつ入力します。
- 数値のIDは「数値IDのエポック」でTwitter / X・Discordのどちらかを選びます。別のサービスなら「カスタム」にしてエポックを指定します。
- 形式の判定結果と生成時刻、構成要素が表示されます。「結果をコピー（TSV）」で一覧をまとめて取り出せます。
注意事項
- 数値のIDは、サービスごとに異なるエポック（起点時刻）を足して時刻にします。選択を誤ると数年単位でずれるため、IDの出どころに合わせて選んでください。
- Snowflake形式は上位41bitが時刻、続く10bitがマシンID、下位12bitがシーケンスという共通の並びを前提にしています。この並びと違う独自形式のIDでは正しく読み取れません。
- ObjectIDの時刻は秒単位、UUID v1・v6は100ナノ秒単位の値をミリ秒に丸めて表示します。
- UUID v4・v5などランダムまたはハッシュ由来のIDには時刻が含まれません。ULIDやUUID v7、Snowflakeは作成時刻がそのまま読み取れるため、作成日時を隠したい用途には向きません。
用語解説
Snowflake ID
Twitter（X）が考案した64bitの連番風ID。時刻・マシンID・シーケンスをビットで詰めており、数値の大小がほぼ生成順になります。DiscordやInstagramなども似た形式を使っています。
エポック
IDの時刻部分が数え始める起点の時刻です。Twitterは2010-11-04、Discordは2015-01-01が起点です。
ObjectID
MongoDBが使う12バイト（24桁の16進）のID。先頭4バイトが秒単位の時刻、続く5バイトがランダム値、末尾3バイトがカウンタです。
UUID v7
先頭48bitにUNIXミリ秒の時刻を持つUUIDです。生成順に並べやすく、データベースの主キーに向いています。
よくある質問
TwitterとDiscordのSnowflake IDは何が違いますか？
ビットの並び（上位41bitが時刻、10bitがマシンID、12bitがシーケンス）は同じですが、時刻の起点（エポック）が異なります。Twitterは1288834974657（2010-11-04）、Discordは1420070400000（2015-01-01）です。エポックの選択を間違えると生成時刻が数年ずれます。
19桁の数値IDを正確に扱えますか？
はい。内部では64bit整数（BigInt）で計算するため、JavaScriptの数値で丸められる2の53乗を超えるIDでも下位のビットまで正確に読み取れます。
UUIDのどのバージョンから生成時刻が分かりますか？
v1・v6・v7です。v1・v6は1582年10月15日からの100ナノ秒単位、v7はUNIXミリ秒を持っています。v4はランダム、v3・v5は名前のハッシュなので、時刻は含まれません。
ObjectIDの時刻はミリ秒まで分かりますか？
分かりません。ObjectIDの時刻は先頭4バイトの秒単位で、ミリ秒の情報は含まれていません。続く5バイトはプロセスごとのランダム値、末尾3バイトはカウンタです。
独自のSnowflake形式のIDも読み取れますか？
時刻が上位41bit、下位22bitが機械・連番という一般的な並びで、エポックが分かっていれば「カスタム」で時刻を読み取れます。ビット幅が異なる形式（Sonyflakeなど）には対応していません。
このページをシェア