UUID（v4）をワンクリックで生成できる無料オンラインツールです。 時系列ソート可能なv7やULIDの発行、ハイフンなし・大文字への変換、既存UUIDのバージョン判定にも対応しています。
生成する識別子の種類
フォーマット（切り替えても値は変わりません）
発行ボタンを押すとIDが表示されます。
// ブラウザ・Node.js 19以降
const id = crypto.randomUUID();
// Node.js（crypto モジュール）
import { randomUUID } from "node:crypto";
const id2 = randomUUID();Security & Privacy
暗号学的乱数（crypto.getRandomValues / crypto.randomUUID）を使用し、生成も解析もデバイス内で完結します。入力したUUIDが外部へ送信されることはありません。
Sortable ID
時計アイコンの付いた UUID v7 と ULID は先頭に時刻を含むため、文字列のまま時系列に並びます。DBの主キーに使うとインデックスの断片化を抑えられます。
UUID生成ツールとは？v4・v7・ULIDを使い分けて発行できる開発者向けツール
本ツールは、RFC 4122／RFC 9562に準拠したUUIDを即座に発行できる開発者向けのオンラインツールです。最も一般的なv4（完全ランダム）に加え、時系列順にソートできるv7、時刻ベースのv1、同じ入力から常に同じ結果になるv5（名前空間＋SHA-1）、さらにULIDとNanoIDまで、同じ画面から切り替えて生成できます。
標準的なハイフン形式だけでなく、ハイフンなし32文字・大文字・中括弧付き・引用符付きといった開発現場のフォーマットへワンクリックで変換でき、切り替えてもUUIDの値自体は変わりません。最大1,000件の一括生成と、テキスト・CSV・JSONでのダウンロードにも対応しています。
さらに、既存のUUIDを貼り付けてバージョン・バリアントを判定し、生成時刻の復元やBase64・バイト配列への変換を行う解析機能も搭載。生成から検証まで、UUIDにまつわる作業をこの1ページで完結できます。すべての処理はブラウザ内で行われ、入力内容が外部に送信されることはありません。
こんなシーンで便利です
データベースの主キー（PK）設計
連番IDを使いたくない分散DBや、推測不可能なIDが必要なMySQL・PostgreSQLのテストデータ作成に。書き込み性能を重視するならv7やULIDを選べます。
受け取ったUUIDのバージョンを確認したい時に
ログやDBに記録されたUUIDを貼り付けるだけで、v4なのかv1・v7なのかを判定。v1・v7であれば生成時刻も復元して表示します。
ハイフンなし・大文字などの形式を揃えたい時に
既存のUUIDを貼り付けて、必要な形式へまとめて変換。DBのCHAR(32)への格納やC#のToString("B")形式など、仕様に合わせた表記をそのままコピーできます。
テスト用ダミーデータの大量生成
JSONやSQLのINSERT文に貼り付けるユニークキーとして、最大1,000件を一括発行。引用符・カンマ付きのフォーマットでそのまま配列に流し込めます。
使い方は簡単 5ステップ
- 生成したい識別子の種類（UUID v4／v7／v1／v5／ULID／NanoID）を選択します。
- 「生成数」から必要な個数（1件〜1,000件）を選びます。
- 「ハイフンなし」「大文字」など、用途に合わせてフォーマットを切り替えます（値そのものは変わりません）。
- 個別コピー・すべてコピー、またはテキスト・CSV・JSONでダウンロードします。
- 既存のUUIDを調べたい場合は「UUIDを解析・変換」タブに貼り付け、バージョン判定と変換結果を確認します。
※発行ボタンを押すたびに、ブラウザの暗号学的乱数生成器を用いて新しい識別子が発行されます。
ご利用時の注意点
- UUIDの衝突について：バージョン4のUUIDが重複する確率は天文学的に低いため、事実上「唯一無二」として安心してご利用いただけます。
- RFC準拠：UUIDの仕様はRFC 4122で定義され、2024年にRFC 9562へ更新されました。本ツールはこれらに準拠した形式で発行します。
- UUID v1のノードIDについて：ブラウザからはMACアドレスを取得できないため、RFCが認める方法に従いランダム値（マルチキャストビットを立てた値）を使用しています。
- UUID v5について：同じ名前空間と名前からは常に同じUUIDが生成されます。複数件を発行する場合は、名前の末尾に連番を付与して区別しています。
- フォーマット保持：大文字変換やハイフン削除は、コピーやダウンロードの際にもそのまま維持されます。
UUIDの各バージョンと他規格の比較早見表
UUIDのバージョンごとの違いや、開発でよく比較されるGUID、ULID、NanoIDとの仕様差をまとめました。
| 規格・バージョン | 生成原理 | 文字数 | 時系列ソート | 主な用途・特徴 |
|---|---|---|---|---|
| UUID v1 | 時刻 + ノードID | 36文字 | 不可（時刻が分割配置のため） | 生成元の端末や時刻を追える。プライバシー面の懸念あり |
| UUID v4 | 完全ランダム | 36文字 | 不可 | 最も一般的。衝突確率が極めて低く予測不能 |
| UUID v5 | 名前空間 + SHA-1 | 36文字 | 不可 | 同じ入力からは常に同じUUID。URLやドメインの写像に |
| UUID v7 | Unix時刻(ms) + ランダム | 36文字 | 可能 | DBの主キー向き。インデックスの断片化を抑えられる |
| GUID | UUIDのMicrosoft版 | 36文字 | バージョンによる | WindowsやSQL Server、C#開発で標準的に利用 |
| ULID | 時刻 + ランダム | 26文字 | 可能 | UUIDより短く、Crockford Base32でURLに使いやすい |
| NanoID | ランダム（短縮版） | 21文字 | 不可 | 最も短い。URLフレンドリーだがUUID型には非対応 |
【UUID v4の重複・衝突確率について】
UUID v4は128ビット（うち122ビットがランダム値）で構成されており、生成可能な総数は約340澗（3.4×10の38乗）個です。仮に1秒間に10億個のUUIDを100年間生成し続けたとしても重複が発生する確率は極めてゼロに近く、実務上は「唯一無二」として扱えます。
【GUIDとUUIDの違い】
技術的にはほぼ同一ですが、GUID（Globally Unique Identifier）は主にMicrosoft環境での呼称です。本ツールで生成したUUIDは、Windows開発やSQL Serverのuniqueidentifier型としてもそのまま利用でき、中括弧付き形式への変換にも対応しています。
※本ツールはRFC 4122／RFC 9562に準拠したアルゴリズムを採用しており、ハイフンなし（32文字）や大文字フォーマットへの変換、既存UUIDのバージョン解析も標準サポートしています。
ソフトウェアアーキテクチャにおける識別子の選択と最適な活用方法
一意の識別子をシステムへ導入する際に開発者が考慮すべき設計指針や、他規格との使い分け、セキュリティを踏まえた運用の応用知識を解説します。
結論：外部公開用はv4、DBの主キーはv7かULIDを選ぶ
識別子の選定は「推測されたくないか」と「時系列に並んでほしいか」の2軸で判断できます。
URLやAPIレスポンスに露出させる識別子は、生成順や生成時刻が漏れないv4が適しています。一方、書き込み性能が重要なデータベースの主キーには、挿入順とインデックス順が揃うv7またはULIDが有利です。
両立させたい場合は、内部の主キーにv7、外部公開用に別途v4を持たせる二本立ての設計が定石です。
分散システムやマイクロサービスでランダムベース識別子を採用すべき理由
マイクロサービスアーキテクチャでは、複数の独立したノードやサービスが個別にIDを採番するため、中央集権的なオートインクリメント（連番）のID管理ではコンフリクトが発生します。
ランダムベースのUUIDを採用することで、中央サーバーとの同期処理（オーバーヘッド）を一切挟むことなく各ノードが独立して一意な識別子を発行できるため、並行処理性能とスケーラビリティを最大化できます。
UUID v1を避けるべきケースと、v7へ移行する判断基準
UUID v1は本来MACアドレスをノードIDに用いるため、生成元の端末が特定できてしまうプライバシー上の懸念があります。加えて、タイムスタンプがフィールドに分割配置されているため文字列としてはソートできません。
時刻情報を活かしたいのであれば、先頭に時刻をそのまま持つv7への移行が推奨されます。v7はソート可能でありながらノードIDを含まないため、v1の弱点を両方とも解消できます。
認証トークンやセッション管理におけるUUIDの利用限界とセキュリティ対策
UUIDは「一意であること」を保証しますが、それ自体に暗号学的な署名や有効期限を内包していません。
そのため認証トークンとしてそのまま発行すると、サーバー側でセッション状態を完全に保持・管理する必要が生じ、分散環境での検証負荷が高まります。
ステートレスな認証を構築する場合は、UUID単体ではなくペイロードの一部にUUID（jti）を埋め込んだJWT（JSON Web Token）を併用し、リプレイ攻撃やセッションジャックのリスクを低減させる設計が推奨されます。
URLに組み込む識別子の短縮とユーザーフレンドリーな設計
パブリックAPIやマイページのURLにUUIDをそのまま露出させると、36文字という長さが利便性を損なうことがあります。また、文字数制約の厳しいシステムではストレージも圧迫します。
対策として、内部ではUUIDの堅牢性を維持しつつ、ルーティング用にはBase62などへエンコードして短縮するか、より短いULID（26文字）やNanoID（21文字）をインターフェース層に限定して採用するハイブリッド設計が有効です。
よくある失敗と対策
ハイフンの有無や大文字・小文字のフォーマット不一致によるバグ・設計ミス
MySQLやPostgreSQLでUUIDを格納するデータ型を文字列（CHAR/VARCHAR）にするか専用のUUID型にするかで必要な書式が異なります。ハイフンを含む36文字かハイフンなしの32文字か、さらに大文字・小文字の仕様がプログラム側とデータベース側でズレていると、検索クエリの不一致や型エラーの原因になります。
💡 対策・解決策を見る▼
MySQLの主キーにUUID v4を採用してDBパフォーマンスが著しく低下する
UUID v4は完全なランダム値であるため、MySQL（InnoDB）の主キーやインデックスに割り当てると、挿入時にB-treeインデックスの再構築（ページスプリットや断片化）が頻発します。データ量が増えるにつれて書き込み・検索速度が急激に悪化し、サーバー負荷が高まります。
💡 対策・解決策を見る▼
一意性を過信し、Math.randomなどの安全でない乱数で自作生成してしまう
JavaScriptのMath.randomなどの標準的な乱数生成機能は、暗号学的に安全ではない疑似乱数です。これをベースにUUID風の文字列を自作すると衝突確率が跳ね上がり、大規模な本番環境や分散処理で予期せぬデータ上書きやセキュリティ上の脆弱性を引き起こします。
💡 対策・解決策を見る▼
UUID v4から生成日時を逆算しようとして詰まる
ログ調査やデータ復旧の場面で「UUIDから作成時刻を割り出したい」と考えたものの、対象がv4であったため時刻情報がまったく含まれておらず、調査が行き詰まるケースです。設計段階でバージョンを検討していないと後から取り返しがつきません。
💡 対策・解決策を見る▼
UUID v1を採用したまま公開APIに露出させ、生成環境の情報を漏らしてしまう
UUID v1は本来MACアドレスと時刻から構成されるため、外部に公開すると生成元の端末や生成タイミングを推測される可能性があります。加えて連続発行したIDは規則性が見えるため、他のリソースIDを推測される危険もあります。
💡 対策・解決策を見る▼
一括生成したテストデータの部分コピー漏れや、文字数制限による切り捨て
APIの疎通確認やモックデータ作成のために画面から手動でドラッグコピーした際、末尾が1文字欠けたりハイフンを拾い忘れたりして構文エラーが発生するケアレスミスです。貼り付け先の文字数上限に引っかかって一部が切り捨てられることもあります。
💡 対策・解決策を見る▼
よくある質問（FAQ）
Q.ハイフンなしの32文字や大文字表記でコピーすることはできますか
A. はい、可能です。フォーマットのトグルを切り替えることで、標準的な36文字の形式からハイフンを除去した32文字、大文字表記、中括弧付き、引用符付き、末尾カンマ付きへ瞬時に変換できます。重要な点として、フォーマットを切り替えてもUUIDの値そのものは変わらないため、同じIDのまま表記だけを整えてコピーできます。
Q.すでにあるUUIDのバージョンを調べたり、形式を変換したりできますか
A. できます。「UUIDを解析・変換」タブに既存のUUIDを貼り付けると、バージョン（v1〜v8）とバリアントを自動判定し、標準形式・ハイフンなし・大文字・中括弧付き・Base64・バイト配列への変換結果を一覧表示します。ハイフンの有無や大文字小文字、中括弧の有無はどの形式で貼り付けても自動で認識します。
Q.UUID v7とは何ですか、v4とどう使い分ければよいですか
A. UUID v7は先頭48ビットにUnixミリ秒のタイムスタンプを持つ新しい形式で、文字列のまま時系列順に並ぶという特徴があります。完全ランダムなv4をデータベースの主キーにするとインデックスの断片化で書き込み性能が落ちますが、v7なら挿入順とインデックス順が揃うためその問題を避けられます。外部に露出させる推測困難な識別子にはv4、DBの主キーにはv7という使い分けが目安です。
Q.UUIDから生成された時刻を逆算することはできますか
A. バージョンによります。v1とv7はタイムスタンプを内包しているため、本ツールの解析機能で生成時刻を復元して表示できます。一方、v4は完全なランダム値であり時刻情報を一切含まないため、生成日時を逆算することは原理的に不可能です。時刻を後から知りたい要件がある場合は、設計段階でv7やULIDを選択してください。
Q.同じ入力から毎回同じUUIDを作ることはできますか
A. UUID v5を使えば可能です。名前空間UUID（DNS・URL・OID・X.500のプリセットまたは任意のUUID）と名前の文字列をSHA-1でハッシュ化して生成するため、同じ組み合わせからは常に同じUUIDが得られます。URLやドメイン名など既存の一意な文字列をUUIDへ写像したい場合や、複数システムで同じIDを再現したい場合に有効です。
Q.開発時のテストデータ作成用に一度に大量のUUIDを発行できますか
A. はい、1件から最大1,000件までワンクリックで一括発行できます。生成結果は個別コピー・すべてコピーのほか、テキスト・CSV・JSON形式でファイルとしてダウンロードできます。引用符付きや末尾カンマ付きのフォーマットを組み合わせれば、ソースコードの配列やSQLのINSERT文へそのまま貼り付けられます。
Q.Windows開発で使われるGUIDとしてこのまま流用できますか
A. はい、そのまま利用できます。GUIDはMicrosoft環境におけるUUIDの呼称であり、技術的な仕様や128ビットのデータ構造は同一です。本ツールで生成した文字列は、C#のGuid型やSQL Serverのuniqueidentifier型に対して完全に互換性があります。C#のToString("B")に相当する中括弧付きの形式にもワンクリックで変換できます。
Q.生成されるUUIDのバージョンと準拠している標準規格は何ですか
A. UUIDの仕様はRFC 4122で定義され、2024年に後継となるRFC 9562へ更新されました。本ツールはこれらに準拠したv4（完全ランダム）、v7（Unix時刻ベース）、v1（時刻ベース）、v5（名前空間とSHA-1）を生成します。ランダム値には暗号学的に安全な乱数生成器（CSPRNG）を使用しているため、推測困難な識別子として信頼して利用できます。
Q.ULIDやNanoIDはUUIDと何が違いますか
A. ULIDは26文字のCrockford Base32で表現され、先頭に時刻を持つため時系列ソートが可能かつUUIDより短い識別子です。NanoIDは21文字のURLセーフな文字列で、さらに短くURLやファイル名に埋め込みやすいのが特徴です。いずれも標準のUUID型カラムには収まらないため、文字列カラムで扱う前提での採用となります。本ツールではどちらも同じ画面から生成できます。
Q.このツールで生成したUUIDは商用利用や業務システム開発に使えますか
A. はい、商用プロジェクトや個人利用を問わず、業務システムや製品開発に無料で自由に利用できます。著作権の制限や利用報告の義務はなく、生成された識別子は権利フリーのデータとしてそのままソースコードやデータベースに組み込めます。
Q.入力したUUIDや生成結果が外部に漏洩したり悪用されたりしませんか
A. いいえ、漏洩のリスクはありません。本ツールは完全ローカル処理型の設計で、生成も解析もブラウザ内だけで完結します。入力したUUIDや生成結果が外部サーバーへ送信・保存されることは一切なく、ページを閉じれば即座にメモリ上から消去されます。
あなたの声で、
このツールをより鋭く。
「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。