ULIDとは何か｜26文字で時系列ソートできるIDの仕組みと使い分け
公開日：2026年9月10日 更新日：2026年9月1日 運営：シルギア（Analyzegear, Inc.） 対象ツール：ULID生成
ULID（Universally Unique Lexicographically Sortable Identifier）は、UUIDの代替として設計された128bitの識別子です。最大の特徴は「文字列としての並び順が、生成時刻の順番とほぼ一致する」こと。UUIDv4のように完全ランダムではなく、先頭に時刻を埋め込むことで「並べ替えるだけでおおよその作成順に並ぶ」性質を持ちます。このツールは仕様に忠実にブラウザ内でULIDを生成し、構造やデコード結果まで確認できます。この記事では、その仕組みと使いどころを具体的な数値例で解説します。
128bitの中身 ― 48bitの時刻と80bitの乱数
ULIDの本体は128bitで、内訳ははっきり決まっています。
- 先頭48bit … UNIXミリ秒タイムスタンプ（1970年1月1日からの経過ミリ秒）
- 残り80bit … 乱数。このツールでは暗号的乱数 crypto.getRandomValues で生成します
48bitでミリ秒時刻を表せる範囲は 2の48乗 − 1 ＝ 281,474,976,710,655 ミリ秒で、西暦にすると10889年ごろまで対応できます。当面枯渇の心配はありません。乱数部の80bitは、同じミリ秒に生成しても衝突する確率が極めて低くなるだけの空間を確保するための部分です。UUIDv4の乱数量が122bitなのに対しULIDは80bitとやや少なめですが、これは先頭に時刻を持つことと引き換えの設計です。
Crockford Base32で26文字になる理由
128bitをそのまま16進で書くと32文字になりますが、ULIDはCrockford Base32という32種類の文字で表現します。使う文字は「0123456789ABCDEFGHJKMNPQRSTVWXYZ」で、0〜9とA〜Zの計36文字から、見間違えやすい I・L・O・U の4文字を除いた32文字です。IとL、Oと0などの取り違えを避けるための工夫です。
1文字が5bitを表すので、128bitは5bitずつ区切って 128 ÷ 5 ＝ 25.6、切り上げて26文字になります。内訳は先頭10文字がタイムスタンプ部（48bit。10文字×5bit＝50bitのうち上位2bitは常に0）、後ろ16文字が乱数部（80bit＝16文字×5bit）です。記号を含まないためURLやファイル名にそのまま使え、大文字小文字を区別しない設計になっています（正規表記は大文字）。このツールの「小文字で表示」オプションは見た目を変えるだけで、意味やデコード結果は変わりません。
先頭10文字は生成時刻に戻せる ― 具体例で確認
タイムスタンプ部は、各文字が表す数値（0〜31）を先頭から t ← t × 32 ＋ 桁の値 と積み上げるだけでミリ秒に戻せます。実際に計算してみます。2026年9月10日 10:00:00（日本時間）を生成時刻とすると、UNIXミリ秒は 1789002000000 です。これを32進の要領で10文字にエンコードすると、先頭10文字は 01M24D89M0 になります。
逆にこの10文字をデコードすると 1789002000000 ミリ秒に戻り、UTCでは 2026-09-10 01:00:00、日本時間で 2026-09-10 10:00:00 と、元の生成時刻にぴったり一致します。ツールの「先頭ULIDの構造」では、この「デコードした時刻＝生成時刻」の一致をその場で確認できます。時刻が先頭に来て桁の重みも先頭ほど大きいため、文字列を辞書順に並べるだけで時系列順に並ぶ、というのがULIDの肝です。
UUIDv4との違いと使い分け
同じ「衝突しにくいID」でも、ULIDとUUIDv4は性格が異なります。ツール内の比較表と同じ観点で整理します。
- 長さ：ULIDは26文字、UUIDv4は36文字（ハイフン込み）
- 並び替え：ULIDは生成順＝辞書順で時系列ソート可、UUIDv4は順序性なし
- 時刻情報：ULIDは先頭に生成時刻を内包、UUIDv4は時刻を持たない
- 乱数量：ULIDは80bit、UUIDv4は122bit
- 文字と扱い：ULIDは記号なしでURLセーフ・大文字小文字を区別しない、UUIDv4は16進＋ハイフンで通常小文字
使い分けの目安はシンプルです。並び順に意味を持たせたい、短く扱いたい、URLやファイル名にそのまま載せたい、という場面ではULIDが向きます。一方で、作成時刻を他人に知られたくない用途では、先頭を読めば時刻が復元できてしまうULIDは不向きで、時刻情報を持たないUUIDv4やランダムなトークンが適します。純粋な乱数量の多さを最優先するならUUIDv4の122bitも判断材料になります。
データベースの主キーやログでの使いどころ
ULIDが実務でよく選ばれるのが、データベースの主キーです。多くのDBは主キーにB木インデックスを使いますが、UUIDv4のような完全ランダムなキーを挿入し続けると、木のあちこちに割り込みが発生してページ分割や断片化が起きやすくなります。ULIDは新しいレコードほど大きい値になるため挿入位置が末尾付近に集中し、断片化が起きにくいという利点があります。連番の主キーと違って採番の中央集権が不要なので、複数のサーバーやクライアントで採番しても衝突を避けつつ、おおよその時系列を保てます。
ログやイベントのIDにも便利です。IDを見るだけで発生順が分かり、時刻でソートしなくても並べ替えできます。ファイル名やオブジェクトストレージのキーに使えば、名前順に並べるだけで新しいものが後ろに来ます。ただしULIDの一意性は確率的に極めて高いという設計であって、数学的に絶対とは限りません。厳密なグローバル一意性が要件なら、DB側の一意制約と併用するのが安全です。
同一ミリ秒で順序を保つ「モノトニック生成」
ここまでの「時系列ソートできる」は、ミリ秒が違う場合の話です。同じミリ秒内で複数のULIDを一気に生成すると、乱数部はそれぞれ独立なので、たまたま先に作ったものの乱数が大きく、後のものが小さいと並びが前後することがあります。これを防ぐのが「モノトニック（昇順を保証）」オプションです。
仕組みは単純で、同じミリ秒では前回の乱数部を捨てず、その乱数部に＋1した値を次のULIDの乱数部として使います。Base32の各桁を下位から繰り上げるので、たとえば乱数部が「0000000000000000」なら次は「0000000000000001」、末尾がZの「000000000000000Z」なら桁上がりして「0000000000000010」になります（Crockford Base32ではZの次で桁が繰り上がる）。こうして同一ミリ秒内でも必ず単調増加になり、生成順＝並び順が保証されます。ミリ秒が進めば通常どおり新しい乱数から生成されます。大量のレコードを一括生成して確実に生成順で並べたいときはこのオプションを有効にしてください。
使い方と注意点
ツールの使い方はかんたんです。生成する個数（1〜100、既定5件）を入れ、必要なら「小文字で表示」「モノトニック」にチェックして「ULIDを生成」を押すだけ。各行の「コピー」で1件ずつ、「全件コピー」で改行区切りの全件をコピーできます。「ULID と UUIDv4 の違い」の比較や、「先頭ULIDの構造」でのデコード確認もその場で行えます。
注意点を最後にまとめます。第一に、先頭10文字から生成時刻（ミリ秒）が誰でも復元できます。時刻を秘匿したい用途には使わないでください。第二に、小文字表示はあくまで見た目で、正規表記は大文字です。システム間で照合するときは大小を区別しない比較にしておくと安全です。第三に、生成・エンコード・デコードのすべてがブラウザ内（お使いの端末内）で完結し、入力や生成結果はどこにも送信されません。オフラインでも利用できます。なお、識別子の設計は用途によって最適解が変わります。厳密な一意性や機微な要件がある場合は、この記事を目安として、最新の仕様やチームの設計方針も併せて確認してください。