【変更されにくい！使っても良いナチュラルキーの候補一覧】
山崎講師【ナチュラルキーは使うべき？新人エンジニアが知っておくべきデータベース設計の基礎】
こんにちは。ゆうせいです。
今回は「ナチュラルキーは使うべきではないのか？」というテーマでお話しします。
データベース設計において「キー（Key）」の使い方はとても重要な考え方です。特に新人エンジニアの方からよく聞かれるのが、「ナチュラルキーって使っていいの？」という疑問。
この記事では、ナチュラルキーとは何か、代わりに何を使うのか、使うとどうなるのか、例え話を交えながら丁寧に解説していきます！
そもそも「ナチュラルキー」って何？
まず用語の意味から押さえておきましょう。
ナチュラルキー（Natural Key）とは、既に現実世界で意味のあるデータを主キーとして使うことを指します。
たとえば：
- マイナンバー
- 社員番号
- メールアドレス
- ISBN（本の番号）
- 国際電話番号
こういったものは、すでに現実世界に存在し、一意であることが多いため、データベースでも「識別子」として使いたくなりますよね。
ですが、実はこれが落とし穴になることもあるんです。
一方で「サロゲートキー」とは？
ナチュラルキーとよく比較されるのがサロゲートキー（Surrogate Key）です。
これは、データベースが自動生成する一意の識別子です。よくある例がオートインクリメントのIDです。
たとえば：
- 1
- 2
- 3
- 4
- 5
…というふうに、登録された順に番号が振られます。
この番号自体には意味がありません。ただの識別用番号です。
じゃあ、ナチュラルキーを使っちゃダメなの？
ダメとまでは言いません。ただし、注意点が多いんです。
ここからは、ナチュラルキーのメリットとデメリットを比較してみましょう。
| 項目 | ナチュラルキー | サロゲートキー |
|---|---|---|
| 現実のデータと一致 | ○ | × |
| 可読性 | ○（わかりやすい） | ×（ただの番号） |
| メンテナンス性 | ×（変更の可能性あり） | ○（変更不要） |
| 拡張性 | △（仕様変更に弱い） | ○（柔軟） |
| 処理効率 | △（文字列などは重い） | ○（整数が軽い） |
デメリットをわかりやすく例えると？
例えば、社員のメールアドレスをナチュラルキーに使ったとします。
「メールアドレスなんて一意だし、完璧なキーじゃん！」と思うかもしれません。
でも…社員がメールアドレスを変更したら？
→ すべての関連テーブルを更新しなければなりません。
これは、「家の住所を本人の名前にしたら、引っ越すたびに看板も地図も作り直さなきゃいけない」ようなものです。大変ですよね？
ナチュラルキーが向いているケースはあるのか？
もちろんあります！
以下のように変更されないことが保証されているキーなら、使っても問題ないケースがあります。
- 国コード（例：JP, US）
- ISOコードなど国際規格で定められたコード
- 書籍のISBN（ただしバージョンに注意）
ただし、「本当に絶対に変わらないか？」を事前に検討することが大前提です。
実務的にはどうするべき？
結論として、実務では「サロゲートキー + ナチュラルキーには一意制約」という設計が最も一般的です。
つまり、
- サロゲートキー（ID）を主キーとして使う
- ナチュラルキー（社員番号やメールアドレスなど）には一意制約（UNIQUE）をつける
このように設計することで、「変更に強く」「データの意味も保つ」柔軟な構造になります。
数式で表現するなら？
例えば、主キーの設計方針を数式的に考えると次のようになります。
ナチュラルキー方式：
（主キー = ナチュラルキー）
サロゲートキー方式：
（主キー = サロゲートキー、かつ ナチュラルキーには一意制約）
この設計が一般的なベストプラクティスです。
図で理解する
以下のような構成を図で示すと、よりイメージがしやすくなります。
※ご希望があれば図を生成しますので、お気軽にお申し付けください。
まとめ：ナチュラルキーは“使ってはいけない”のか？
いいえ、絶対に使ってはいけないわけではありません。
ただし、次のようなポイントをしっかり押さえて判断する必要があります。
- 将来的に変更の可能性があるか？
- 文字列か数値かなど、性能への影響はないか？
- 現実世界のビジネス要件がナチュラルキーの仕様変更に左右されないか？
今後の学習のヒント
次のステップとして、以下のテーマを学ぶことをおすすめします！
- 「正規化」と「非正規化」の違いと使い分け
- 外部キーと参照整合性制約
- ER図（エンティティ・リレーションシップ図）の読み方
- DB設計におけるパフォーマンスチューニング
少しずつ知識を積み重ねていけば、設計の判断力もどんどん鍛えられていきますよ！
知識は武器。迷ったら、まずは「柔軟性」と「保守性」を重視する考え方から始めましょう！
今回は「実務で使っても比較的安全なナチュラルキーの候補一覧」をお届けします。
前回のお話では「ナチュラルキーは危険な場合もある」と説明しましたね。ただし、すべてのナチュラルキーがダメというわけではありません。
ここでは、“変更されにくく、一意性が保たれやすい”ナチュラルキーを中心にリストアップしていきます！
使っても良いとされるナチュラルキーの条件
まず、ナチュラルキーとして採用しても大きなリスクにならないのは、次のような特性を持つものです。
- 意味を持っている
- 現実世界で一意である
- 変更される可能性が非常に低い
- 国際的に標準化されている
- 人為的に生成されないか、強い管理体制がある
使っても良いナチュラルキー候補 一覧
以下の表に、「使ってもよい（＝リスクが比較的小さい）」と考えられるナチュラルキーの候補をまとめました。
| 種別 | 例 | 説明 | 安全度 |
|---|---|---|---|
| 国コード | JP, US, DE | ISO 3166準拠で変更がほぼない | ◎ |
| 通貨コード | JPY, USD, EUR | ISO 4217の通貨コード | ◎ |
| 空港コード | HND, JFK, CDG | IATAが管理する世界一意のコード | ◎ |
| 書籍ISBN | 978-4-00-000000-0 | 国際的に一意だが再利用の可能性も | ◯ |
| 郵便番号 | 100-0001 | 国・地域で一意。ただし変更あり | △ |
| 商品JANコード | 4901234567894 | 日本のバーコード規格。一意性高い | ◯ |
| 税率コード | R8, R10 | 国税庁などが定めた固定コード | ◯ |
| 規格型番 | USB-A, HDMI-1.4 | 工業規格で定義された型番 | ◯ |
| ISO国名略称 | JPN, USA, FRA | ISO 3166-1 alpha-3コード | ◎ |
| 銀行コード | 0001（三菱UFJ銀行） | 金融機関コードは一意かつ安定 | ◎ |
| 駅コード | A01, JY28 | JR・私鉄の管理コード（変更可能性あり） | △ |
使うときの注意点
どんなに「安全そうに見える」ナチュラルキーであっても、以下のポイントは確認しておく必要があります。
- バージョン管理はあるか？
例：ISBNには版が存在するので、完全な一意性には注意が必要です。 - 組織・国の裁量で変わる可能性があるか？
例：郵便番号や駅コードなどは、再編により変わることもあります。 - 人が自由に決めるものでないか？
メールアドレスや社員番号などは、ルール次第で変更・重複のリスクがあります。
数式で表す「安全なナチュラルキーの特性」
以下のような関係式で考えることができます。
（安全なナチュラルキー = 一意性 ∩ 安定性 ∩ 標準性）
まとめ
ナチュラルキー＝悪ではない！
ただし「変更されにくく、現実に一意性が保証されているもの」に限って、安全に利用できます。
以下のようなものは比較的安心です：
- ISOやIATAなどの国際標準に基づいたコード
- 国や公共機関が管理しているコード
- 工業規格で定められた識別子
今後の学習のヒント
次はこんなテーマにもチャレンジしてみてください！
- 「一意性」と「整合性制約（UNIQUE, PRIMARY KEY）」の違い
- ENUM型とナチュラルキーの関係
- データマイグレーション時の主キー戦略
- ドメイン駆動設計における識別子の扱い方
ナチュラルキーとサロゲートキーのバランス感覚を持てば、より堅牢なデータベース設計ができるようになりますよ！
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
- 代表取締役
-
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。
