UUID / ULID / Nano ID 生成器無料・登録不要
UUID v4（ランダム）/ v7（時刻順ソート可）/ ULID / Nano ID を最大 500 件一括生成。crypto.getRandomValues 完結でブラウザ内処理・サーバー送信ゼロ。
ID タイプを選択
どれを使えばいい？選択ガイド
- UUID v4: 一般用途の鉄板。完全ランダム 128bit。順序性なし。RDB の主キーには インデックスフラグメンテーションの懸念あり。
- UUID v7: 時刻順ソート可能。Postgres / MySQL の主キーに最適。RFC 9562 で 2024 標準化。新規プロジェクトは v4 より v7 推奨。
- ULID: 128bit・時刻順・Crockford Base32（小文字/数字混在なし）。URL 表示も読みやすい。v7 と類似だが Base32 で短い。
- Nano ID: URL セーフな短い ID。21 文字 = UUID と同等の衝突安全性（10^7/秒 100 年で衝突確率 1%）。URL slug 向き。
良いUUID / ULID / Nano ID 生成器の判断基準
テストデータの ID や新システムの識別子が必要になったら、本ツールで生成した結果を使う前に、下の判断基準で「用途に合った形式・長さか」を確認してください。ID は一度設計に組み込むと後から変えにくいため、生成より選定が本番です。
用途に合った形式を選んだか
データベースの主キー・URL に入れる短い ID・認証用のトークンでは、適した形式が異なります。「どこで・誰の目に触れて・何件くらい使うか」を先に決めてから形式を選びます。
DB 主キーなら時刻順に並ぶ形式を検討したか
完全ランダムな ID を主キーにすると、件数が増えた時にインデックスの効率が落ちやすいという特性があります。新規設計なら、時刻順にソートできる形式（UUID v7 や ULID）を候補に入れて比較します。
短い ID の衝突リスクを考えたか
ID は短くするほど見た目はきれいになりますが、衝突（偶然の重複）の確率が急激に上がります。発行する総件数を見積もり、それに見合った文字数を確保してから短さを追求します。
生成方法は暗号学的に安全か
推測されて困る ID（トークンなど）は、暗号学的に安全な乱数で生成されている必要があります。簡易な乱数関数による自作生成で代用しないでください。本ツールはブラウザの暗号用乱数 API で生成します。
既存システムの形式と揃っているか
同じシステム内で UUID と独自形式が混在すると、検索・連携・デバッグの全部で混乱の元になります。既に使われている形式があるなら、まずそれに合わせるのが原則です。
コピー先で形式が崩れないか確認したか
生成した ID を表計算ソフトなどに貼ると、自動変換で数値扱いされたり末尾が変わったりすることがあります。貼り付け後に何件か目視で照合し、元の文字列のままかを確認します。
ありがちな失敗例（NG → 改善）
NG見た目を優先して 8 文字程度まで短くした ID を、数万件規模で発行する。
改善発行する総件数を見積もり、衝突確率が無視できる文字数（短い ID 形式でも十分な長さ）を確保する。
→ ID の衝突確率は文字数を減らすほど急増します。衝突は発生した時の調査・復旧コストが非常に大きい障害です。
NG簡易な乱数関数で自作した ID を、セッション管理などのトークン用途に使う。
改善暗号学的に安全な乱数で生成された ID（本ツールの生成結果や各言語の暗号用 API）を使う。
→ 簡易な乱数は出力の予測が可能な場合があり、推測されたトークンはそのまま不正アクセスにつながります。
NG生成した ID 一覧を表計算ソフトに貼り、数値に自動変換されて末尾が壊れたまま配布する。
改善貼り付け先の列を先にテキスト形式に設定してから貼り、貼り付け後に数件を元データと照合する。
→ 表計算ソフトの自動変換は黙ってデータを書き換えます。壊れた ID は照合不能になり、原因の特定も困難です。
UUID / ULID / Nano ID 生成器の使い方
- 1テキストを入力またはペーストします
- 2「変換する」ボタンをクリックします
- 3結果を確認してコピーします
よくある質問
UUID / ULID / Nano ID 生成器は無料ですか？
はい、完全無料でご利用いただけます。会員登録も不要です。
スマートフォンでも使えますか？
はい、スマートフォン・タブレット・PCなど、ブラウザがあればどのデバイスでもご利用いただけます。
入力したコードやデータは安全ですか？
はい、入力データはブラウザ上で処理され、サーバーに送信されません。安心してご利用ください。
関連ツール
UUID / ULID / Nano ID 生成器について
衝突しない ID を大量に用意したい場面
開発・テストデータ作成・DB 移行・モック作成で「衝突しない ID が大量に必要」な場面は頻発します。オンライン UUID ジェネレータは多いですが、UUID v4 だけしか出ない / 大量生成不可 / Nano ID / ULID 未対応 / 用途別の選び方が書いてない、というのが現実。本ツールは UUID v4 / v7 / ULID / Nano ID の 4 種を最大 500 件一括生成 + 用途別選択ガイド付きで、本番システム設計時にもそのまま使えます。
4 つの ID 形式の違い
【UUID v4】完全ランダム 128bit。RFC 4122。一般用途の鉄板だが時刻順序性ゼロ → DB 主キーに使うと B-tree インデックスがフラグメンテーション。
【UUID v7】時刻 48bit + ランダム 74bit + バージョン/バリアント 6bit。RFC 9562（2024 標準化）。時刻順ソート可。新規プロジェクトの主キーは v7 推奨。
【ULID】128bit・Crockford Base32（小文字 lo / 0 O / 1 I 排除）・時刻順。Stripe 等が採用。URL や CLI で読みやすい。
【Nano ID】URL セーフ文字（A-Z a-z 0-9 _ -）。21 文字 ≒ UUID と同等衝突安全性。短い ID が欲しい URL slug / 認証トークン向け。
ID 生成が役立つ開発・設計シーン
【1. DB シードデータ作成】テスト環境で 100-500 件のユーザー / 注文データの ID を一括生成。
【2. 主キー設計検討】v4 と v7 を比較してパフォーマンステスト用のサンプル ID を準備。
【3. 認証トークン / リフレッシュトークン】サーバーレス関数 / Edge Function で発行する Bearer トークンの形式検討。
【4. URL slug 設計】Nano ID 21 文字で重複なしの URL（YouTube / Notion 形式）を試作。
【5. 分散システム ID 設計】ULID / UUID v7 の時刻順性能を実 ID で比較検証。
【6. SaaS API キー設計】Nano ID + プレフィックス（例: `sk_live_XXX`）で Stripe 形式のキー設計を試作。
用途別 推奨選択
【RDB の主キー】UUID v7 > ULID > UUID v4。v4 はインデックス劣化を覚悟。
【URL slug / 短い ID】Nano ID 12-21 文字。UUID v4 / ULID は長すぎる。
【公開 API のリソース ID】ULID。読みやすさ + 時刻順 + 36 文字以内。Stripe / Vercel が採用。
【内部システム / ログ trace ID】UUID v7。Datadog / Tempo / Honeycomb で時刻順検索が効く。
【セッショントークン / CSRF トークン】Nano ID 32 文字 or crypto.randomUUID()。ハッシュ生成と組み合わせ。
ID 設計でやりがちな失敗パターン
1つ目: UUID v4 を主キーにしてインデックス劣化 → 数百万件規模で INSERT 遅延。v7 / ULID に移行。
2つ目: Math.random() で UUID 生成 → 衝突確率が暗号学的に保証されない。<b>必ず crypto.getRandomValues() か crypto.randomUUID() を使う</b>。
3つ目: Nano ID 短くしすぎ → 8 文字だと 1 万件で衝突確率 1% 超。最低 14-16 文字。
4つ目: UUID を Excel に貼り付け → 数値化される / 自動変換される問題。最初に「テキスト形式」に設定。
5つ目: UUID v1 を顧客向け表示 → MAC アドレスが ID に埋め込まれる古い仕様。v1 は新規採用避けるべき（本ツールは v1 提供せず）。
プライバシー・セキュリティ
全 ID 生成は <b>ブラウザ内 crypto.getRandomValues</b> で完結。サーバーへの送信・ログ記録・トラッキングは一切ありません。本番システムで使う ID をそのまま生成可能。crypto API は CSPRNG（暗号学的擬似乱数生成器）を使うため、出力された UUID v4 の衝突安全性は仕様通り保証されます。
実処理結果（v4 を2回生成した）
実測条件から書きます。既定設定（ID タイプ = UUID v4、生成数 = 10）のまま「生成する」ボタンを 2 回押しました。1 回押すと「生成結果（10 件）」という見出しとコピーボタンが現れ、その下に 10 件の UUID が 1 行 1 件の改行区切りで縦に並びます。2 回目に押して返ってきた 10 件は、次のとおりです。
``` 2c86116d-96bd-4c38-80d4-1ac44480ddda c5b93128-6756-4b72-94f3-29f0558059b2 774a5cad-555b-4cc7-a97b-313ffcf72f90 e5b300de-c0a7-4b3d-b917-724fd67306c2 3759d51b-633d-4e33-9cea-cfaf47e49fe8 d94ac36b-203d-4a1a-85ef-09e846cfef53 d872c819-b28f-4828-9f5d-55ec7c953b46 07222cde-a626-4b6d-afec-1da8194b144f 87b323dd-4953-4d65-b003-9614595070d4 7afcb8ce-4e9f-4c06-899a-986ea07175c1 ```
分かったクセはこうです。1 回押すごとに、既定では 10 件の UUID がまとめて生成されます。ひとつだけでなく、指定した生成数ぶんが改行区切りで一度に出ます。2 回目に押すと、10 件すべてが 1 回目とは別の値になり、2 回の結果は 1 件も一致しませんでした。先頭を控えると、1 回目は 3197e70a-4de0-4aef-8738-f1b34e3079fa、2 回目は 2c86116d-96bd-4c38-80d4-1ac44480ddda で、まったく別の並びです。押すたびに毎回別の ID がまとめて返り、同じ結果は再現されません。これは ID 生成器として当然の挙動で、不具合ではありません。ただしこれは今回の 2 回で観測しただけで、すべての生成で必ずこうなることを保証するものではありません。気になる方は自分でも何回か押して、値が毎回変わることを確かめてください。
今回の生成で崩れた点・崩れなかった点
今回の2回では、生成が途中で崩れたり空になったりする現象は観測されませんでした。毎回きちんと ID 形式の文字列が返っています。ただし構造上の限界はここにあります。値が毎回変わるため、いったん画面から消してしまった ID を、あとで同じものとしてもう一度取り出すことはできません。生成は「その場限り」で、履歴も残りません。必要な ID はその場で控えておくのが前提になります。
この生成器が向かない使い方
同じ入力から毎回同じ ID を得たい、決まった ID を再現したい、という用途には向きません（毎回変わるため）。また、すでにどこかで発行済みの ID を、このツールで復元・再取得することもできません。用途に対して形式が合っているかは自分で選ぶ必要があり、たとえば時刻順に並べたい主キーに完全ランダムな v4 を選ぶ、といった選定を本ツールが止めてくれるわけではありません。形式選びは上の「4 つの ID 形式の違い」「用途別 推奨選択」を基準に、自分の要件に合わせて判断してください。
生成した ID を採用するときの判断基準
生成した ID は、その場でコピーして保存してください。今回試した範囲では毎回すべて別の値が返り、同じ ID を後からもう一度得ることはできませんでした。本番のシステムに組み込む前には、選んだ形式の桁数と衝突の可能性が、発行予定の件数に見合っているかを自分の環境で一度検証しておくと安全です。表計算ソフトに貼る場合は、先に列をテキスト形式にしてから貼り、貼り付け後に元の文字列のままか数件を目視で照合してください。