ID の設計 — 連番を外に出した日から、数えられてしまう

What — ID に求めるものは、場所によって違う

ID は1種類ではありません。同じ値を「主キー」と「URL に出すもの」の両方に使うと、要件が衝突します。

1
2
3
...
48213   ← いま何件目かが分かる

主キー

行を一意に指す値。DB の内部でインデックスの中心になる。

サロゲートキー

業務上の意味を持たない、採番だけのための ID。連番や UUID。

ナチュラルキー

メールアドレスや商品コードのように、業務上の意味を持つ値を鍵にすること。

公開 ID

URL や画面に出す ID。内部の主キーとは別に持つことがある。

ULID

先頭に時刻、後ろに乱数を置いた 128 ビットの ID。生成順に並ぶ。

「主キー」と「外に出す ID」は分けられる

同じ値を両方に使う必要はありません。

orders
  id          BIGINT      主キー（連番、内部だけで使う）
  public_id   CHAR(26)    URL に出す（ULID）

こうすると、インデックスの効率（連番）と推測されにくさ（ULID）を両方取れます。

代償は、テーブルに1列増えることと、外向きの処理で public_id を引くためのインデックスが要ることです。

小さいシステムでは過剰になることもあります。最初から ULID を主キーにしてしまうのも、十分に現実的な選択です。

Why — ID が漏らすもの、ID が縛るもの

連番は「順序」と「量」を漏らす

連番には、値そのもの以外の情報が入っています。

• その時点で何件あるか（値そのもの）
• どれくらいの速度で増えているか（2回観測すれば分かる）
• 誰が先か（顧客 ID が小さければ古参）

冒頭の事故は1つ目と2つ目です。外に出した瞬間に、隠していない情報になります。

URL に /invoices/1 と出れば、「このサービスの請求書は1件目」と分かります。創業直後であることが、見せたくない相手にも分かります。

推測できる ID は、権限の不備を増幅する

連番そのものは脆弱性ではありません。 冒頭の事故の本当の原因は、権限チェックの不足です（security/authorization）。

しかし連番は、その不備を「誰でも簡単に突ける」形に変えます。

• UUID なら、他人の ID を当てるのは実質不可能
• 連番なら、1ずつ減らすだけで全件たどれる

権限を正しく実装するのが本筋です。そのうえで、推測しにくい ID は間違えたときの被害を小さくします。どちらか一方ではなく、両方です。

ランダムな主キーは、インデックスを断片化させる

UUID v4 を主キーにすると、挿入位置がばらばらになります。

影響の大きさは DB と規模によります。数万行なら誤差ですが、数千万行で書き込みが多いテーブルでは効いてきます。

「UUID は遅い」と単純化しないこと。 遅くなるのは「ランダムな値を、クラスタ化されたインデックスの主キーにしたとき」です。条件が揃わなければ問題になりません。

演習 — まず自分で判断する