Ir para o conteúdo principal

本日 0/3 回使用 · 残り 3 回。Proに移行して制限を解除しましょう。.

アップグレード

UUID v4 ジェネレーター

Web Crypto API · RFC 4122準拠 · 最大1000件を一括生成。

Processado no seu navegador
1
standard
128 bits

生成されたUUID

983140b5-020b-4593-b7a8-ad7072b63598

生成設定

Web Crypto対応。 UUIDはcrypto.getRandomValues()で生成され、暗号学的に安全です。データはサーバーに送信されません。RFC 4122 v4準拠。
Sobre

UUIDとは何か、いつ生成すべきか?

Por Quorify EditorialAtualizado em

QuorifyのUUIDジェネレーターは、一意な識別子を生成します:UUID v1(タイムスタンプ+MACアドレス)、v4(暗号学的ランダム)、v7(ソート可能なタイムスタンプ — 2024年のRFC 9562)。分散データベースの主キー、イベント識別子、キャッシュキー、リクエストID、ログ内の相関IDなどに便利です。計算はブラウザのWeb Crypto APIを使用します。複数のサービスが調整なしに同時にIDを生成する必要のある分散システムにおいて、UUIDは標準的な解決策です — 衝突確率は実質的にゼロです。Quorify開発者ツールキットの一部です:JSON Formatterと組み合わせてペイロードを整形し、Hash Generatorでフィンガープリントを作成し、Slug Generatorで読みやすいURLを作成できます。

Casos

活用シーン

  1. 複数のサービスがデータを挿入するデータベーステーブルの主キー — UUIDは中央集権的なシーケンス調整の必要を排除します。

  2. 分散ログのリクエストID — 各リクエストにUUIDを付与することで、マイクロサービス間でのユーザーの動線を追跡できます。

  3. 決済APIの冪等キー — クライアント側で生成したUUIDを使うことで、リトライ時の二重課金を防げます。

  4. S3のアップロード識別子 — ファイル名にUUIDを使うことで衝突を防ぎ、内部構造も漏らしません。

  5. 招待トークンやパスワードリセットトークン — UUID v4はこれらの用途に十分なランダム性を持つトークンとして機能します。

Método

計算の仕組み

UUID v4(現在最も一般的)は、crypto.getRandomValuesによる128ビットのランダム値から生成され、8-4-4-4-12の16進形式と固定のバージョンビットを持ちます。ランダムに生成された2つのv4 UUIDの衝突確率は極めて低く、実用上はゼロとみなされます。UUID v1は生成マシンのタイムスタンプ+MACアドレスを使用します — 一意ですが、いつ・どこで生成されたかを露呈します。UUID v7(RFC 9562、2024年)は現代版です:Unixタイムスタンプ(ms)+ランダムビットで、時系列順にソート可能 — 完全にランダムでインデックスを断片化するv4よりも、データベースインデックスに適しています。

FAQ

よくある質問

どのUUIDバージョンを使うべきですか?
現代の標準はUUID v7(RFC 9562)です — 時系列順(データベースインデックスに適する)と一意性のための十分なランダム性を兼ね備えています。順序が重要でない場合は、UUID v4も依然として有効です。UUID v1は今日では最良の選択であることはほとんどありません — MACと生成時刻を露呈します。UUID v3/v5は決定論的です(名前空間+名前のハッシュ) — 同じ入力から同じUUIDを生成したい場合に便利です。
UUIDの衝突は起こり得ますか?
理論上は可能ですが、実際にはほぼ不可能です。人類史全体において、ランダム生成された2つのv4 UUIDが衝突する確率は2^-122のオーダーです — 宝くじに連続して何度も当たるのと同等です。タイムスタンプを使うUUID v1とv7では、時系列の一意性が加わるため確率はさらに低くなります。
UUIDは認証トークンとして安全ですか?
128ビットのランダム性を持つUUID v4は、短期間のトークン(招待、パスワードリセット)には十分な強度です — 122ビット相当のエントロピーがあります。長期間のトークン(APIキー、JWT)には、定期的なローテーション、有効期限、失効機能も併用してください。UUID v1やv3はトークンとして絶対に使わないでください — 予測・導出が可能です。
なぜデータベースでUUIDは遅くなることがあるのですか?
UUID v4はランダムなため、B-treeインデックスへの挿入で断片化やキャッシュミスが発生するからです。UUID v7(タイムスタンプ順)はこれを解決します:挿入がインデックスへの追記のみとなり、auto-incrementの整数と同等のパフォーマンスになります。Postgresの最近のバージョンではuuidv7()でネイティブにサポートされています。
UUIDをURL用に短縮できますか?
はい、128ビットをBase62またはBase64URL(URL内で問題のある文字を含む標準Base64ではなく)でエンコードできます。NanoIDやSqidsなどのツールは標準でこれを行い、同じエントロピーで21文字のIDを生成します。ただし、すでに生成済みのUUIDがある場合は、36文字の正規形式のままの方が可搬性が高いです。
UUID v4はオフラインで動作しますか?
はい — UUID v4の生成には中央調整やインターネットは不要で、暗号学的乱数生成器のみが必要です。これこそが分散システムにおけるUUIDの価値です:オフラインのクライアントが有効なIDを生成し、後で衝突リスクなく同期できます。
Fontes

公式情報源

Tabelas, leis e referências consultadas para fundamentar esta ferramenta.

  1. 国際標準RFC 4122 (2005)IETF · Internet Engineering Task Force

    RFC 4122 — A Universally Unique IDentifier (UUID) URN Namespace

    UUID識別子(バージョン1、3、4、5)の仕様、36文字の正規形式、グローバルな一意性を保証する生成ルールを定義。

  2. 国際標準RFC 9562 (2024)IETF · Internet Engineering Task Force

    RFC 9562 — Universally Unique IDentifiers (UUIDs)

    UUID標準の更新版。バージョン6、7、8を追加 — 時系列順で、データベースや現代の分散システムでの利用に最適化されています。

Metodologia — esta ferramenta consulta as tabelas e legislação vigentes nas fontes acima. As regras são atualizadas conforme novas instruções normativas são publicadas pelos órgãos competentes.

Última verificação editorial: junho de 2026.

Compartilhe

関連

関連ツール

toolLayout.related_description