完全なフロントエンドローカル処理。6 種類の ID format に対応します。

一意識別子ジェネレーター UUID / ULID / Nano ID

無料・インストール不要のオンライン固有 ID 生成ツールです。UUID v4/v7、ULID、Nano ID、CUID2、Short ID の主要 6 形式に対応し、一括生成、重複チェック、衝突確率の推定も利用できます。すべての処理はブラウザー側で完結し、データのプライバシーと安全性を保ちます。

1 最大1,000
ID 長
文字セット
プレフィックス
分離方法
出力 準備完了
生成済み： 0
繰り返し: 0
単体の長さ: 0

ID 形式比較

形式 並べ替え可能 URL セキュリティ 長さ カオス 機能
UUID v4❌✅36 (32+4)⭐⭐⭐⭐⭐完全ランダム、最も広く使用
UUID v7✅✅36 (32+4)⭐⭐⭐⭐⭐時系列順で、DB インデックスに適しています
ULID✅✅26⭐⭐⭐⭐Crockford Base32、ソート可能
Nano ID❌✅変数（デフォルト 21）⭐⭐⭐⭐⭐軽量かつ高効率、64文字のアルファベット
CUID2❌✅約24⭐⭐⭐⭐⭐水平方向の拡張安全域、衝突防止
Short ID❌✅変数（カスタム）⭐⭐⭐短く柔軟で、文字セットをカスタマイズ可能

衝突確率の推定

1 日あたりの ID 生成数と使用期間から ID collision probability を推定します。

≈ 0%

推定衝突確率

まだ計算されていません

よくある質問

UUID、ULID、Nano ID の違いは何ですか？
UUID（v4） 128-bit の汎用一意識別子で、完全にランダムに生成され、データベースの主キーや分散システムで広く使われています。ただし純粋にランダムであるため、B-tree index には不向きで、page split を増やす可能性があります。

ULID こちらも 128 ビットですが、先頭 48 ビットがタイムスタンプ、後半 80 ビットが乱数のため「ソート可能」という特性があります。Crockford Base32 でエンコードされ、長さはわずか 26 文字です。

Nano ID 64 文字の alphabet（A-Za-z0-9_-）を使い、既定の 21 文字長でも UUID v4 に近い十分なランダム性を得られます。短く高速なため、短縮 URL やファイル名などでよく使われます。
UUID v4 ではなく UUID v7 を使うべきなのはどのような場合ですか？
UUID v7 の中心的な利点は「時刻順に並べやすいこと」です。v7 の先頭 48 bits は Unix millisecond timestamp で、生成 ID が時間とともに自然に増加する性質を持ちます。

データベースが B-tree または LSM-Tree をインデックス構造に使用している場合（PostgreSQL、MySQL、SQLite など）、UUID v7 を使うことで index page split とランダム書き込みのコストを大幅に抑えられます。大規模 insert では、条件によって 5～10 倍の性能改善につながることがあります。

UUID v7 が推奨されるシナリオ： database primary key、時系列データ、作成時刻で並べ替える必要がある業務データには UUID v7 が適しています。UUID v4 は、並び順が不要で完全にランダムな識別子が必要な場合に適しています。
なぜ can ULID be sorted のですか？
ULID の先頭 48 bit には Unix ミリ秒タイムスタンプ（UUID v7 と類似）が格納されるため、辞書順の並べ替えが作成時刻順と一致します。この性質により、ULID は完全ランダムな ID よりデータベースインデックスと相性が良くなります。

ULID は Crockford Base32 を使用し、I、L、O、U など紛らわしい文字を除外しています。全長は 26 文字で、36 文字の UUID より簡潔です。先頭 10 文字がタイムスタンプ、後半 16 文字がランダム値を表します。

ULID のもう一つの利点は、同一ミリ秒内でも最大 2^80 個の ID 空間を持ち、非常に高い並行処理環境でも一意性を維持しやすいことです。
Nano ID の人気が高まっているのはなぜですか？
Nano ID が開発者に人気の主な理由は次のとおりです。

1. 本文が非常に短い： 元の code は gzip 後で約 130 bytes しかなく、front-end package size への影響はほとんどありません。
2. 高性能： Node.js の crypto module や browser の Web Crypto API を使うと、UUID より高速に生成できる場合があります。
3. カスタマイズの柔軟性： ID の長さと文字セットは自由に調整でき、「一意性」と「簡潔さ」のバランスを用途に合わせて最適化できます。
4. URL セキュリティ： デフォルトでは URL-safe character set（A-Za-z0-9_-）を使い、追加 encode なしで URL に埋め込めます。
5. 主流プロジェクトで採用： Next.js、Nuxt、Hono をはじめ、多くのオープンソースプロジェクトが Nano ID を標準的な ID 生成手段として採用しています。
system 構築時に適切な ID format を選ぶには？
ID format を選ぶ際は、次のポイントを基準に判断できます。

時系列性と高い安全性が必要 → UUID v7
database primary key に適し、128 bit のランダム性と global uniqueness を備えます。

時系列 sort が必要で、より短くしたい場合 → ULID
26 文字で、並べ替え可能かつ公開識別子に適しています。

純粋なランダム識別で互換性を優先 → UUID v4
最も広く対応されている形式で、API や外部システム連携に適しています。

高性能で軽量なフロントエンド → Nano ID
短く高速で customize しやすく、short-term token、file naming、order number などに適しています。

security と horizontal scaling が必要 → CUID2
horizontal expansion 専用に設計され、collision protection mechanism を内蔵しています。

短く、人が読みやすい → Short ID
invitation code、coupon code、short URL slug に適しています。
the chances of an ID collision? Is it really not going to happen again とは何ですか？
これは「不可能」かどうかではなく、確率の問題です。UUID v4 を例にすると、有効ビット数は 122 bit です。理論上、衝突確率が 50% に達するには約 2.71 × 10^18 個の ID を生成する必要があります（誕生日のパラドックス）。

直感的な感覚に換算すると：
• UUID v4 を毎秒 10 億個生成し続けても、衝突確率が約 50% へ達するまで約 85 年かかります。
• UUID v4 を毎秒 100 万個生成しても、生涯のうちに衝突へ遭遇する可能性はほぼ 0 に近い水準です。

ULID と Nano ID も同程度の安全性を持ちます。このツールの「collision probability estimation」機能を使えば、実際の利用量に応じた具体的な衝突リスクを計算できます。
これらの ID は完全にフロントエンドだけで生成されます。本当に安全ですか？
はい。このツールの ID 生成ロジックはすべてブラウザの Web Crypto APIcrypto.getRandomValues / crypto.randomUUID は、OS の基盤が提供する暗号学的に安全な乱数生成器（CSPRNG）を利用します。HTTPS 暗号化と同等レベルの乱数ソースを使用します。

すべての計算はブラウザー内で行われ、生成した ID がネットワーク経由で送信されたり、サーバーへ保存されたりすることはありません。インターネット接続を切った後でもこのツールを利用できます。

より高い security が必要な ID（機密情報に関係する場合など）には、専用 library を使ってローカル生成することを推奨します。

Unique Identifier を詳しく理解する：UUID から Nano ID までの完全ガイド

現代のソフトウェア開発では、Unique Identifier はシステムを構成する重要な要素です。データベースの主キー、API リソース識別子、ユーザー ID、注文番号、ファイル名など、さまざまな場面で一意な識別子を確実に生成する仕組みが必要になります。

UUID：最も広く使われる標準

UUID（Universally Unique Identifier）は 128 bit の識別子規格（RFC 4122）です。中央の調整機構を使わずに世界規模で一意性を確保できるよう設計されています。最も一般的な UUID v4 は完全に乱数へ依存し、新しい UUID v7 はタイムスタンプと乱数を組み合わせることで時系列に並べやすい性質を備えています。

UUID の強みは標準化の度合いが非常に高く、ほぼすべてのプログラミング言語やデータベースで標準的に扱えることです。そのため、システムや言語をまたぐ用途に適しています。一方、36 文字という長さは用途によっては冗長で、完全にランダムな v4 はデータベースインデックスとの相性があまり良くありません。

ULID：ソート可能な ID の現代的な代替手段

ULID（Universally Unique Lexicographically Sortable Identifier）は、UUID が時系列に並べにくい問題を解決するため、Alizain Feerasta によって 2016 年に提案されました。ULID も 128 bit ですが、26 文字の Crockford Base32 文字列として表現されます。先頭のタイムスタンプにより辞書順ソートが作成時刻順と一致し、同一ミリ秒内でも最大 2^80 通りの一意な値を生成できます。

Crockford Base32 は I、L、O、U など見間違えやすい文字を除外しているため、人が読む場合や手入力する場合の誤りを減らせます。ULID は大文字・小文字を区別しないため、URL で扱う場合にも使いやすい形式です。

Nano ID：軽量で効率的な solution

Nano ID は Andrey Sitnik（PostCSS と Autoprefixer の作者でもあります）が開発した、フロントエンド分野で非常に人気の高い ID ジェネレーターです。UUID や ULID と異なり、Nano ID は固定形式の標準ではなく、カスタマイズ可能な実装です。中心的な設計思想は「最小のサイズで十分な一意性を提供する」ことです。

Nano ID は A-Z、a-z、0-9、-、_ を含む 64 文字の URL セーフなアルファベットを使用し、標準の 21 文字で UUID v4 と同程度の 126 bit のランダム性を確保します。length パラメータを変えることで、安全性と短さのバランスを柔軟に調整できます。

CUID2：水平方向に拡張された衝突回避方式

CUID2 は Eric Elliott が開発した CUID の第 2 世代で、Horizontal Scaling を前提に設計されています。CUID2 は内部で増分カウンター、ランダムなフィンガープリント、ハッシュ関数を組み合わせ、中央の調整役が存在しない分散システムでも衝突しにくい ID を生成します。

CUID2 の既定長は約 24 文字で、エンコードされた fingerprint 情報を含みます。そのため、2 台のサーバーが同じミリ秒内に ID を生成しても、結果は完全に異なります。こうした性質から、CUID2 はマイクロサービス構成や serverless アプリに適しています。

どう選ぶ？実用的な提案

新しい PostgreSQL または MySQL table を作成し、UUID を primary key として使う場合、UUID v7 を選択することを強く推奨します, index fragmentation を大幅に減らせます。ID を外部公開し、さらに短くしたい場合は、ULID または Nano ID より適した選択肢です。非常に高い security requirement がある horizontal scaling scenario では、CUID2 collision に対する追加保護を提供します。

どの形式を選んでも、ToolHub の ID Generator ですばやくテストデータを生成し、衝突確率 Calculator を使ってその選択が業務要件に合うか確認できます。

操作に成功しました