ULID / NanoID / Snowflake 生成ツール
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
使い方
フォーマット（ULID / NanoID / Snowflake）と生成数を選択してください。設定を変更すると自動的に再生成されます。ID をクリックするか、コピーボタンを押すとクリップボードにコピーされます。
どのフォーマットを選ぶべきか
各フォーマットは可読性・ソート可能性・長さが異なります。用途に合わせて選んでください：
- ULID（26文字、Crockford Base32）：生成時刻でソート可能。大文字小文字を区別しないアルファベットで I・L・O・U を除外。UUID 並みのユニーク性と時系列ソートを両立したいときに適する。
- NanoID（21文字、URLセーフ）：ランダムのみ、URLセーフな文字（A-Z a-z 0-9 _ -）で構成。UUID より短いが衝突確率はほぼ同等。短いトークン・共有リンク・外部公開する ID に向く。
- Snowflake（64bit 整数）：Twitter 由来の数値 ID で、ミリ秒タイムスタンプを内包。BIGINT カラムに収まり、時系列順にソート可能。数値の主キーがほしいときに有用。
3 つとも crypto.getRandomValues() を用いてブラウザ上で生成されます。Snowflake の worker ID は呼び出しごとにランダム化されるため、クライアント生成として使う分には十分ですが、厳密なサーバー協調を伴う Twitter のオリジナル実装とは異なります。
フォーマットの仕様
各フォーマットは公開仕様に準拠して生成されます：
- ULID：48bit のミリ秒タイムスタンプ + 80bit のランダム値を Crockford Base32 でエンコード。ulid/spec プロジェクトの仕様準拠。
- NanoID：URL セーフな 64 文字アルファベットから 21 文字を選ぶ。256 / 64 = 4 で割り切れるためモジュロ偏りなし。
- Snowflake：Twitter エポック（2010-11-04T01:42:54.657Z）からの 41bit ミリ秒 + 10bit worker ID + 12bit シーケンスから構成。worker ID とシーケンスは生成ごとに乱数化。
安全性について
生成はすべてブラウザ標準の crypto.getRandomValues() で行われます。サーバーには一切データが送信されません。
よくある質問
ULID・NanoID・Snowflake はどう使い分けますか？
ULID は時系列でソート可能でUUID並みのユニーク性があり、データベースの主キーに向きます。NanoID はURLセーフで短いランダムIDなのでトークンや共有リンク向け。Snowflake はタイムスタンプを内包する64bit整数で、BIGINTカラムに収まる数値主キーがほしいときに適します。
生成したIDはサーバーに送信されますか？
いいえ。IDの生成はすべてブラウザ標準の crypto.getRandomValues() を使ってローカルで行われ、生成結果やシード値がサーバーに送信されることは一切ありません。
一度に何個まで生成できますか？
生成数を指定して複数のIDをまとめて生成でき、設定を変更すると自動的に再生成されます。ブラウザのメモリが許す範囲で実用的な件数を扱えます。
このSnowflakeはTwitterの実装と同じですか？
仕様（41bitミリ秒 + 10bit worker ID + 12bitシーケンス、Twitterエポック2010-11-04起点）に準拠していますが、worker IDは呼び出しごとに乱数化されます。サーバー協調による厳密な一意性保証はないため、クライアント生成用途を想定しています。
ULIDが時系列でソートできるのはなぜですか？
ULIDは先頭48bitに生成時点のミリ秒タイムスタンプを持ち、それをCrockford Base32でエンコードしています。そのため文字列を辞書順に並べるとほぼ生成時刻順になります。