1 自然キーの概要
1.1 自然キーの定義
自然キーとは、データベースや情報管理において、属性そのものが持つ性質によって識別根拠になり得るキー（識別情報）を指す。鍵となる値が、その対象を外部の慣習や意味づけの中で区別する能力を備える点に特徴がある。たとえば個人であれば氏名や生年月日、連絡先の番号、あるいは書籍であれば国際的な識別番号のように、対象を説明する情報がそのまま識別に転用される場合がある。
1.2 人工キーとの対比
1.2.1 サロゲートキーの考え方
サロゲートキーは、識別子を運用の都合で新たに作り、対象固有の意味とは切り離して管理する方式である。値の生成は多くの場合システム側で行い、重複しないこと、参照関係を維持しやすいこと、変更の影響を抑えることが主要な狙いになる。自然キーが対象の“意味”に依拠するのに対し、サロゲートキーは“技術的に一意”を確保することに重点が置かれる。
1.2.2 自然キーが選ばれる場面
自然キーは、対象に結び付く情報が直感的で、現場や利用者の理解に近いときに採用されやすい。特に、既に外部で広く一意として扱われる識別番号が存在し、利用者や他システムとの突合が必要な場合に適する。また、データの導入初期で設計を簡潔にし、運用者がキーの意味を把握しやすいことが利点となる。さらに、変更頻度が低い、または変更が起きてもキーを新しい値へ置き換えるだけで整合性を保ちやすい場合も選択理由になり得る。
1.3 自然キーの位置づけ（設計・運用）
自然キーは設計上の選択肢であると同時に、運用ルールの集合でもある。なぜなら、自然キーの有効性はデータ品質、正規化、入力規約、重複判定、変更時の扱いといった運用の徹底に強く依存するからである。したがって自然キーを採用する場合は、キーの一意性を技術的制約で守るだけでなく、登録・更新・照合の手順まで含めて設計に組み込む必要がある。結果として、自然キーは「決めれば終わり」ではなく、継続的な管理対象になる。
2 自然キーの具体例
2.1 人を識別する自然キーの例
2.1.1 氏名・生年月日などの組合せ
人を識別する自然キーとしては、氏名と生年月日を組み合わせるような設計が見られる。単一の項目だけでは同名・同誕生日が起こり得るため、複数属性を組み合わせて一意性を狙う。組合せキーでは、入力の揺れを減らし、同じ表現で登録されるよう規約を設けることが前提となる。加えて、将来の訂正（誤記の修正）や表記変更の扱いが、設計の要点になる。
2.1.1.1 同姓同名への対応
同姓同名への対応では、単に「一意だと信じる」ことを避け、追加属性の併用や照合ロジックを明確化する必要がある。代表的には、生年月日以外に連絡先情報、所属の識別情報、あるいは登録時に付与された参照用の追加情報を組み合わせる方法がある。運用面では、重複疑いが検知された場合の手順（確認、統合、記録の保持）を決めておくことが重要になる。さらに、異なる表記が混在する可能性があるため、表記統一や正規化の仕組みも合わせて整備する。
2.2 モノを識別する自然キーの例
2.2.1 国際標準番号・型番など
モノの自然キーとしては、国際標準に基づく識別番号や、製品ごとに定められた型番のような外部での一意性が期待できる値が候補になる。書籍の識別番号、機器の型式、部品表で扱われるコードなどは、現場で参照されやすく、供給元情報と突合しやすい。自然キーとして機能させるには、正しい書式で取得・保存されること、桁数やチェック機構（ある場合）の検証が行われることが望ましい。
2.2.1.1 表記ゆれ・桁数ルール
表記ゆれ・桁数ルールは自然キーの致命的なズレにつながりやすい。たとえば区切り記号の有無、先頭のゼロの扱い、英数字の大文字小文字、読み取り機器の誤認識などで、同じ対象が別のキーに分かれてしまうことがある。対策としては、入力時に正規化（除去すべき記号の整理、桁の補正、大小の統一）を行い、許容される形式を仕様として明記する。さらに、チェック桁や検証規則がある場合は、整合性検査を登録ゲートに組み込むことで誤入力を抑えられる。
2.3 場所や組織を識別する自然キーの例
2.3.1 住所・部門コードなど
場所や組織の識別では、住所のように意味を伴う属性や、部門を表すコード体系が自然キーとして扱われることがある。ただし住所は表記ゆれが発生しやすく、組織コードは制度や運用ルールの変更に影響を受ける可能性がある。したがって自然キー化するなら、表記の正規化、同一性判定の基準、更新時の参照戦略を先に定義する必要がある。とりわけ、住所や名称は“変更され得る情報”として性格づけられるため、キーとして使うなら不変性をどこまで見込むかが論点になる。
2.3.1.1 改称・移転への追随
改称・移転への追随では、自然キーが変わることを前提にした設計が求められる。単純にキー値を上書きすると、既存の参照関係が途切れたり、監査上の整合が失われたりすることがある。一般に、キー値の履歴を保持する仕組み、参照側がどの時点の属性を参照すべきか（現時点、当時、照会時点）を決めることが重要になる。また、移転前後のデータを同一主体として扱う範囲を明確にし、外部との突合に用いる正規化ルールを一貫させることで運用事故を減らせる。
3 自然キーを設計するための観点
3.1 一意性と重複の扱い
3.1.1 一意制約の設計
自然キーの設計でまず検討すべきは一意性の担保方法である。データベースの一意制約（ユニーク制約）で形式的に守れる場合は、登録時の失敗を早期に表面化できる。ただし複合キー（複数属性の組合せ）にする場合は、各属性の正規化や欠損の許容が一意性の意味に直接影響する。加えて、同じ対象が別の表現で入力される可能性があるため、制約が有効に働く前提として正規化手順をシステム側に組み込むことが望ましい。
3.1.2 重複データの検知方針
重複は、入力の揺れ、誤記、情報の分割登録などにより発生する。検知方針は「完全一致のみで判定する」のか、「近い候補を推定してレビューに回す」のかを決める必要がある。完全一致で運用すると見逃しが増える一方、曖昧一致を広げすぎると誤統合の危険が高まる。現場向けには、重複疑いの閾値、レビュー担当の責任分界、統合時の履歴保持（旧レコードの扱い）を明確化することで、品質と安全性を両立しやすい。
3.2 不変性（変更可能性）の評価
3.2.1 参照整合性への影響
自然キーの値が変わる可能性がある場合、参照整合性に影響が出る。外部キーとして別テーブルが自然キーを参照していると、キー変更は連鎖更新や整合性エラーにつながり得る。変更頻度が低い属性でも、手続き上の訂正や制度変更で変動が生じることがあるため、キーの性格を再確認する必要がある。設計段階では、キー更新が起きたときに、参照関係をどう維持するかを先に決めることが重要になる。
3.2.2 キー変更時の移行手順
キー変更時の移行手順では、まず「更新するのか」「別キーとして扱うのか」を決める。更新する場合は、連鎖的な修正を安全に行うためのトランザクション戦略や、段階移行（旧→新の併用期間）を検討する。別キーとして扱う場合は、同一性を示す対応表や履歴データを用意し、参照側がどの識別情報を採用するかを制御する。いずれの手法でも、更新前後の比較、ロールバック手順、監査ログの保存を揃えることで事故の影響を最小化できる。
3.3 値の欠損・不正入力への対応
3.3.1 未登録時の方針
自然キーは本来、対象を識別できる値であるため、欠損が起きると識別不能になる。未登録時の方針は、入力を拒否するのか、暫定値で登録するのか、もしくは未確定状態として別カテゴリで扱うのかを決める必要がある。識別に必須な属性なら、早期にエラーとする方が整合性を保ちやすい。一方、業務上“後から確定する”ケースがあるなら、確定前データの扱い、後続処理の導線、確定時の再整合を設計に含める。
3.3.2 正規化とバリデーション
正規化とバリデーションは自然キーの品質を左右する。正規化では、表記の揺れを揃える処理（文字種統一、区切り文字の整理、不要な空白の削除など）を行う。バリデーションでは、形式チェック、桁数、チェック機構、文字種制限など、入力が仕様に適合しているかを確認する。これらを登録時のゲートに組み込むことで、誤ったキーがデータベースに定着するリスクを下げられる。
3.4 外部依存（規格・制度）のリスク
3.4.1 規格改定への備え
自然キーが外部規格に依存している場合、規格改定が起きたときに同じ対象が別形式として保存されるおそれがある。対策として、旧形式と新形式を併存して扱える変換規則を用意する、変換結果の正規化後キーを一貫させる、移行期間の運用手順を明確にする、といった考え方が有効になる。また、規格の変更通知を監視し、実装更新の計画を事前に持つことが望ましい。
3.4.2 供給元仕様の変動
供給元（入力元システム、企業内のマスタ管理元、ベンダー等）の仕様が変わると、自然キーの前提が崩れる可能性がある。たとえば書式の変更、区切り記号の追加、コード体系の拡張などが該当する。設計としては、入力の許容範囲を仕様に落とし込み、変換処理を外部仕様に耐える形にすること、さらに仕様変更時のテストケースを整備することが重要になる。加えて、異常値を早期検知する監視指標（受入拒否率、正規化差分率など）も役に立つ。
4 自然キーの運用と実務上の注意
4.1 データ正規化と表記統一
4.1.1 全角半角・大文字小文字
全角半角や大文字小文字の違いは、見た目の一致でも内部では別キーになり得る。したがって入力段階での統一処理が必要である。具体的には、文字幅の正規化、英字の大文字小文字の統一、表現揺れを吸収する変換を行い、保存時には正規化済みの値のみを保持する。これにより、一意制約が意図どおり機能しやすくなり、重複検知も安定する。
4.1.2 空白・区切り記号の扱い
空白や区切り記号の扱いは、自然キーの一致性に直結する。たとえば連続する空白、末尾のスペース、ハイフンやスラッシュの有無などが差異として残ると、同一対象でも別レコードになる。運用では、許容する表現を減らし、保存前に区切り記号を規約どおり処理することが基本方針になる。加えて、ユーザインタフェース側で選択式入力や補助機能を用意すると、入力揺れをさらに抑えられる。
4.2 検索性と性能要件
4.2.1 インデックス設計
検索性能はキーの設計だけでなく、インデックスの構成に左右される。自然キーが長い文字列である場合や複合キーになる場合、インデックスサイズや更新コストが増える。設計では、頻出の検索条件（キー一致、部分一致、複合条件の組合せ）を把握し、必要な列に対して適切なインデックスを設定する。加えて、正規化済み値でインデックスを張ることで、検索時の変換コストと不一致を同時に抑えられる。
4.2.2 クエリ設計の工夫
クエリ設計では、キーの一致条件を基本形として構成し、関数適用や任意の前処理を検索条件側で行いすぎないことが望ましい。理由は、検索条件に変換が入るとインデックスが活用されにくくなるためである。さらに、重複判定や突合のために曖昧検索を組み合わせる場合は、対象範囲を絞り込む順序（まず候補を狭め、その後評価する）を工夫することで、性能と精度のバランスを取りやすい。
4.3 変更履歴の設計（監査）
4.3.1 履歴テーブルの考え方
自然キーに変化が起こり得る場合、履歴テーブルの設計が実務上の保険になる。履歴テーブルでは、変更前後の値、変更時刻、変更理由（可能なら）、変更者または処理系を記録する。これにより、過去の照会に対して当時の識別情報を再現したり、監査要求に応えたりしやすい。履歴粒度（どの属性を記録するか）と保持期間を、要件に合わせて決めることが重要である。
4.3.2 追跡可能性の確保
追跡可能性を確保するには、単に履歴を保存するだけでなく、参照先と更新の関係が追えることが必要になる。たとえば、自然キーが変わったときにどのデータが連鎖的に影響を受けたのか、また利用者が参照する画面や帳票がいつの時点の値を採用しているのかを明らかにする。ログ設計、バッチ処理の実行単位、データ補正の手順を整合させることで、問題発生時の原因究明が現実的になる。
4.4 よくある失敗と回避策
4.4.1 「一意だと思っていた」問題
一意性の誤認は自然キー運用でよく起きる失敗である。初期データでは一致が少なく見えても、登録規模の拡大や入力経路の増加で重複が顕在化することがある。回避策としては、最初から一意制約を設ける、正規化ルールを徹底する、重複疑いを検知するレビュー手順を用意する、といった統制を早期に導入することが挙げられる。さらに、運用開始後の重複率や拒否率を指標化し、改善サイクルを回すことが有効になる。
4.4.2 参照更新漏れの事故防止
参照更新漏れは、自然キーの値を変更したときに関連テーブルの整合が維持されないことで発生する。回避策としては、変更操作を手続きとして一本化し、影響範囲を自動で追跡できる仕組みを整えることが重要である。トリガやバッチ更新の設計、トランザクション制御、テストデータでの連鎖確認などを組み合わせ、ヒューマンエラーの余地を減らす。加えて、更新後に整合性検査を行い、異常を検知したらロールバックできる運用を組むことで事故の拡大を防げる。