UUID・ランダム文字列生成ツール

UUID生成
-
一括生成
ランダム文字列生成
-
長さ

UUIDという仕組みの概要

UUID(Universally Unique Identifier)は、データに重複しない識別子を割り当てるために設計された128ビット長の値で、RFC 9562(旧RFC 4122)として標準化されています。表記は xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx という形の36文字(ハイフン4つを含む)で、Mの位置がバージョン番号、Nの上位ビットがバリアントを表します。本ツールはブラウザ標準の Web Crypto API(crypto.getRandomValues および crypto.randomUUID)を使い、暗号学的に強い乱数を端末側で発生させて生成しています。生成された値はサーバーへ送信されず、ブラウザのコンソールにも残りません。

v4とv7の使い分け

v4は122ビットすべてが乱数で、URL用の短縮IDやトークンの種、ログ追跡用のリクエストIDなど、順序情報が不要な場面で使われます。一方v7は先頭48ビットにUNIXミリ秒タイムスタンプを置き、残り74ビットをランダム化した新しいバージョンで、PostgreSQLやMySQLの主キーに用いるとB+Treeの末尾に追記され続けるため、v4と比べてインデックス断片化が劇的に減ります。Stripe、Discord、Shopifyなど大規模サービスは独自のスノーフレーク系IDを使っていますが、自前で実装する手間を省きたい場合の現実的な選択肢がv7です。

計算式と生成ロジック

バージョン構造得意分野
v4(ランダム)122ビットの乱数 + バージョン4 + バリアント一般的なID、APIキーの一部、テストデータ
v7(時刻順)48ビットUNIXミリ秒 + 74ビット乱数DBの主キー、時系列ソートしたいログ

使い方の流れ

  1. 「UUID生成」セクションでバージョン(v4 / v7)を切り替えます。テストデータ用ならv4、データベース投入用ならv7が無難です。
  2. 大文字表記が必要なシステム(Windowsレジストリの一部など)に貼り付ける場合は「大文字」をオン、URL末尾に置きたい場合は「ハイフンなし」をオンにします。
  3. 「生成」を押すと中央に値が表示されます。「コピー」でクリップボードに転送できます。
  4. テストデータを大量に作りたい場合は「一括生成」で件数(最大1,000件)を指定し、テキストエリアの結果をそのままCSVや投入スクリプトに貼り付けます。
  5. 「ランダム文字列生成」セクションでは長さ・文字種を選んで、APIシークレットや初期パスワードなどを作れます。記号を含めるとより強度が上がります。

こんな場面で使う

  • Webサービス開発:ユーザーIDや注文番号にUUIDを採用すると、複数台のサーバーに分散しても採番衝突が発生しません。
  • テストデータ作成:1,000件のダミーレコードを一括生成して、ローカルDBの動作確認やStripeテスト環境の挙動検証に投入できます。
  • ファイル名の重複回避:S3やCloudflare R2にアップロードする画像ファイル名にUUIDを付与すれば、同名ファイルの上書き事故を防げます。
  • セッショントークンの種:そのまま本番セッションに使うのは推奨しませんが、開発用のダミートークン生成には十分です。
  • 分析イベント追跡:MixpanelやAmplitudeに送るイベントIDとしてUUIDを採用すると、再送時の重複排除(idempotency)に役立ちます。

使う前に知っておきたい注意点

  • UUIDはあくまで「ほぼ確実に一意」な識別子であり、暗号的なシークレットそのものではありません。パスワード代わりに使う、認可トークンとして長期運用するといった用途は避けてください。
  • v4の値からは生成順序が一切わかりません。時系列で並べたい場合はv7を使うか、別途タイムスタンプ列を持たせましょう。
  • MySQLでUUIDを主キーに使う場合、CHAR(36)よりBINARY(16)で格納するとサイズを2.25倍ほど節約できます。MySQL 8には UUID_TO_BIN() 関数も用意されています。
  • 古いブラウザ(IE11など)では crypto.randomUUID が使えないため、本ツールはフォールバックとして crypto.getRandomValues から組み立てる実装にしてあります。Internet Explorerサポートが残っている社内環境でも利用できます。
  • 生成されたUUIDをシェアする際は、内部のテーブル名や顧客名と紐付く運用にしないでください。値そのものに識別性がなくても、流出経路から個人を特定される事故が起こり得ます。

用語の補足

  • 衝突確率:v4で50%衝突するには約2.71×10^18個の生成が必要で、毎秒10億個ペースでも約86年かかります。実務では「ほぼゼロ」と扱って問題ありません。
  • ULID:v7に近い思想で、26文字のCrockford Base32で表現する識別子。文字数を抑えたい場合に検討候補となります。
  • NanoID:URLセーフな短いID(21文字)を作るライブラリ。短縮URLや招待コードなど人間が目にする場面で人気があります。

よくある質問

理論上はゼロではありませんが、v4の場合の衝突確率は2^122分の1です。毎秒10億個生成しても、50%の確率で衝突するまでに約85年かかります。実用上は無視できます。
DBの主キーや時系列で並べたいログIDにはv7が有利です。先頭にミリ秒タイムスタンプが入っているのでインデックスが末尾追記になり、断片化が抑えられます。一方、APIのリクエストIDやテスト用ダミーデータなど、順序情報を出したくない用途ではv4が適切です。判断に迷うときは「DBに保存して並べ替える可能性があるか」を基準にすると決めやすくなります。
ハイフンなしの32文字表記は、URL末尾に短く貼り付けたい場合や、CHAR(32)カラムに格納したいときに便利です。大文字表記はWindowsのレジストリエントリ、一部のCOM/ActiveX識別子、Microsoft系のドキュメントで採用されることが多い書式です。生成後にエディタで一括変換するより、ツール側で出し分けたほうがミスが減ります。
英大文字・英小文字・数字(合計62種)から16文字を選ぶ場合、組み合わせは約47ビット相当です。記号を含めて20文字以上にすると128ビットセキュリティに近づき、APIシークレットや初期パスワードとして実用的な強度になります。短くしたいときは最低でも12文字、長期保存するなら24文字以上を推奨します。
UUIDは0〜9とa〜f(または記号としてハイフン)のみで構成されるため、文字化けは発生しません。コピー後にExcelへ貼り付けたとき頭の0が消えることもありません。CSVに保存する場合はBOM付きUTF-8でエクスポートすると、各種ツールで安全に読み込めます。
本ツールでは一度に最大1,000件まで生成できます。これは画面のフリーズを避けるための上限で、それ以上必要な場合はバッチ処理に分けるか、Node.js側の crypto.randomUUID を使うのが安全です。社内ツールに組み込みたい場合は、ブラウザで生成した1,000件をテキストファイルとして保存し、繰り返し利用すれば十分実用になります。
いいえ、すべての生成はブラウザ上のcrypto APIで完結します。生成されたUUIDが外部に送信されることは一切ありません。