Go標準ライブラリへのUUIDパッケージ追加提案

 (github.com/golang)
1 ポイント 投稿者 GN⁺ 2026-03-08 | 1件のコメント | WhatsAppで共有
  • Go言語にUUIDの生成およびパース機能を標準ライブラリに含めるという提案がGitHubで議論された
  • 提案者は、現在ほとんどのGoサーバー・DBプロジェクトがgithub.com/google/uuidのような外部パッケージに依存していることを根拠として示した
  • C#、Java、Pythonなどの主要言語では、すでに標準ライブラリレベルでUUIDサポートが提供されている
  • 議論の過程では、UUIDv7などの最新仕様とRFC 9562準拠の可否、パース機能の含有範囲、APIの一貫性などが主要な論点として扱われた
  • この提案はその後、**crypto/randパッケージへのUUIDv4・UUIDv7サポート追加提案（#76319）**に統合されて進行中である

提案概要

  • Go標準ライブラリにUUID生成およびパースAPIを追加する案を提示
    • 対象バージョンはUUID v3、v4、v5
    • 主な根拠は、外部パッケージへの依存度と他言語における標準サポートの事例
  • UUIDはRFC 4122（のちにRFC 9562）で定義された国際標準である
  • 提案者は、Goが主要言語の中でUUIDの標準サポートがない例外的なケースだと指摘した

初期反応と議論

  • 一部の参加者は、過去にも類似提案があったが却下された前例に言及した（#23789、#28324）
    • 理由は、外部パッケージの利用が十分に簡単であり、標準ライブラリよりもリリースサイクルが柔軟である点
  • 提案者は「ほとんどのプロジェクトが毎回外部パッケージをインポートしなければならないなら、いっそ標準に含める方がよい」と主張
  • 多くの言語がUUIDをcrypto関連の標準ライブラリに含めている点が支持根拠として示された

最新UUIDバージョンとRFC反映

  • 一部の意見では、UUID v1〜v5は古く、v7が最新かつ有望なバージョンだと指摘された
    • v7にはさまざまな実装オプションがあり、適用結果を見守る必要がある
  • RFC草案では、UUIDを不必要にパースせず不透明な識別子として扱うことが推奨された
  • その後RFC 9562が正式発行され、関連議論はUUIDv7サポート中心へと移行した

提案の修正と統合

  • 2025年、RFC 9562が正式化されると、PostgreSQL 18がUUIDv7をサポートしたことへの言及があった
  • その後Go側では、crypto/randパッケージにUUIDv4・UUIDv7生成機能のみを追加する別提案（#76319）を開始
    • パース機能はRFCの勧告に従って除外
  • 元の提案（#62026）は**重複（duplicate）**として処理されてクローズされた

API設計の議論

  • uuid.New()のデフォルト動作をv4にするか、将来変更の余地を残すかが議論された
    • 一部は「バージョン変更時に互換性問題が生じうる」として、常にv4に固定すべきだと提案
  • Compare、MustParse、Parseなどのメソッドを提供するかどうかも議論された
    • CompareはRFC定義に従い、ソート可能なUUIDサポートのために必要だという意見
    • MustParseは標準内の他のMust*関数との一貫性を保つために含めるという意見
  • IsZero()メソッドはUUID型には不要という結論になった
  • Generator構造体の導入、バージョン別型の分離（UUIDv4、UUIDv7など）など、さまざまな設計案が提示された
  • 一部ではNew()関数の曖昧さを指摘し、**明示的なバージョン関数（NewV4、NewV7）**のみを提供すべきだという意見も示された

主な技術的論点

  • UUIDのソート定義がv6・v7にのみ明確に存在するのかどうかが議論された
  • UUIDv7生成時の時間ベース順序保証および**並行実行時の衝突防止（counter方式）**の実装方法が検討された
  • バージョンごとの意味の違い（例: v1はMACアドレスを含み、v7は時間ベース）により、単一型設計の限界が指摘された
  • 一部ではバージョン別型の分離と明示的な変換メソッド（AsV4(), AsV7()など）の導入が提案された

結論と現状

  • Goコミュニティは、UUID標準サポートの必要性には概ね同意している
  • ただし、標準ライブラリの単純性維持とRFC勧告の順守のため、
    • パース機能は除外
    • UUIDv4・UUIDv7生成機能のみをcrypto/randに追加する方向で整理された
  • 元の提案（#62026）は**#76319提案に統合されて進行中であり、
    Go言語の    UUID標準サポートが正式化段階に近づいている**状態である

関連記事

1件のコメント

 
GN⁺ 2026-03-08
Hacker Newsの意見

  • UUID バージョン 1〜5 がすでに時代遅れだという話は興味深かった
    ただし v4 は依然として最もランダム性が高く、分散 DB で ホットスポット問題とプライバシーの問題 を避けるために主キーとして推奨されている
    参考リンク: CockroachDB UUID ドキュメント, Google Cloud Spanner UUID ガイド

    • 自分もその表現はおかしいと思った。v7 は単調性が必要なときには良いが、タイムスタンプがシステム情報を露出する可能性がある。だから v4 は今でも有効だ
    • “outdated” という表現は不適切だと思う。問題は 要件との不一致 であって、古さではない
      各 UUID バージョン（v4 を含む）は特定の状況では欠点がある。実際、多くの組織は標準 UUID の代わりに 純粋な 128 ビット値 を独自定義して使っている
      結局のところ、UUID の設計上の限界を超える複雑な要件が増えてきた
    • v4 がデフォルトの選択で、特に 順序保持 が必要なときだけ別のバージョンを使う
    • 本当に 128 ビットのランダム性が必要なら、ただ 128 ビット乱数を使えばよい。UUID フォーマットに無理に合わせる必要はない
    • ただし v4 は B-Tree 挿入 をめちゃくちゃにすることがある。カーネルのページキャッシュ効率のため、v7 のほうがずっと速いと学んだ

  • 今日 HN にこういう ちょっとした Go 関連ニュース が上がっていたのはうれしい
    最近はプログラミングの未来や AI の話ばかりなので、こういう技術トピックは新鮮だ

    • 久しぶりに 掘り下げた技術議論 を見られて気分がいい
    • AI 関連の恐怖煽り（FUD）からしばらく離れられて気が楽になった。以前は HN を開いても不安にならなかったのに、最近はみんな「終わりだ」みたいな話ばかりだった
    • 見た目は小さな技術課題だが、実際には Go 言語のアーキテクチャとリーダーシップの方向性 を左右する大きな決定だ
      完璧主義者、実務開発者、そして crypto コミュニティ がそれぞれ異なる立場を取っている
      関連文書: RFC 9562
      Go が正しい決定をしてくれることを願っている。特に TinyGo はマイクロコントローラ向けとして本当にすばらしい
    • Go を嫌う人たちの様子が面白い。今はもう AI がコードを見る時代 で、言語批判の面白さも薄れてしまったように感じる

  • Go が UUID 生成をサポートすること自体はあまり気にしないが、標準 UUID 型 ができるのは本当に重要だ
    JSON、Text、database/sql などで一貫したマーシャリングが可能になる
    最近の Go 依存関係分析では google/uuid が 2 番目に多く使われるパッケージだった
    関連分析: The most popular Go dependency

    • dec128 型も標準に入ってほしい。uint128 へ変換しやすい構造体形式で提供されるのが理想だ

  • Go の魅力は 派手な機能より実用性 にある
    言語が崩れるほど複雑にはならず、必要な機能だけを追加している

    • 自分も最近いくつかのバージョンを飛ばしてアップグレードしたが何の問題もなかった
      互換性保証 のおかげで安心して使える。変化は遅いが着実に良くなっていく言語だ

  • Google の uuid パッケージが非アクティブになっていることよりも、gofrs/uuid が新しい標準に従い活発に保守されている点のほうが重要だと思う
    gofrs/uuid リポジトリ

    • 外部依存のないライブラリを作るのは楽しい。今回の変更でそうした作業がもっとやりやすくなる
    • ただし google/uuid には 2024 年以降リリースがなく、2025 年 6 月にも関連 issue が開かれている
      issue #194
    • この提案はすでに 3 年前から 議論されていた

  • UUID は本当に嫌いだ。人間にやさしくない識別子 だ
    デバッグやクエリ結果で長すぎて扱いづらい。
    もちろん完全に分離されたシステム間で一意な ID が必要なときには役立つが、たいていは乱用されている
    一般的なケースでは 集中型の番号発行器 のほうがずっとよい。
    たとえば DB の GetNextId のような手続きのほうが人間的で効率的だ

    • 以前会社で 6 桁コードでプロジェクトを管理していたのに、誰かがそれを UUID に変えてしまった
      結果として 人が読めないコード になってしまい、しかも自前実装だったので妙に連番っぽかった。完全にひどい決定だった
    • 実際、ほとんどの場合は 整数カウンタ で十分だ
      Postgres でカウンタテーブルを使えば毎秒数万件の ID を生成できる
      こうすると メモリ節約、圧縮効率、ハッシュマップ性能 まで良くなる
      UUID は便利だが性能を壊す
    • 人が読みやすい要素があればいいのにと思う
      例: BASKETBALL-...-FISH のような形で 単語ベースのチェックサム を付ければ覚えやすい
    • 「決定的ランダム化」に触れていたが、自分も LFSR（線形帰還シフトレジスタ） のような方式は悪くないと思う

  • Go に UUID が本当に追加されるのか気になっていた

    • 現在は 「Likely accept」 状態だ。Go プロジェクトボード で確認できる
      特別な反対がなければ含まれる可能性が高い
    • はい、追加される予定だ

  • Kotlin も最近 2.3 バージョンで RFC 9562 ベースの UUID バージョン対応 を標準ライブラリに追加した
    JVM、JS、WASM、Native をすべてサポートしている。
    IETF RFC が安定化した以上、Go もそれに続くのは妥当だ

  • Go にこうした 基本機能のサポート不足 があるのは惜しい

    • こういう点をもっと標準化できている言語は何だろう。Java くらいだろうか。Python や Rust も似たような状況だ
    • 「バッテリー同梱」の意味はこの 20 年で大きく変わった。たぶん Google 内部で必要とされなかった機能なのかもしれない
    • UUID は結局 16 バイト配列 にすぎない。v4 生成は数行で終わる。大ごとではない
    • 何の機能が足りないと感じているのか気になる
      個人的には Go の ロギングシステム があまりに単純で、自分で実装しなければならなかった
      slog モジュールは遅くて使いづらい。エンタープライズ環境だけを考えているように見える
    • それでも Go の 標準ライブラリの品質 は最高水準だと思う。日常開発で最もよく使う stdlib だ

  • v7 の DB クラスタリング効率 と v4 の ランダム性 を同時に得る方法はないかと考えた
    内部では v7 を使い、外部に出すとき XOR や AES でスクランブル すれば実現できそうだ

    • 実際にそういう試みはある: uuidv47 プロジェクト
    • プライバシーが目的なら、単に 整数キーを暗号化 するほうがよいと思う
      たとえば Feistel 暗号 を使えば UUID の性能問題なしに不透明な公開 ID を作れる