概要
IDとKeyは、データベース設計やAppSheetの構築で混同されやすい言葉です。
どちらも「データを識別するもの」として使われるため、同じ意味のように扱われることがあります。
しかし、実務上は分けて考えた方が理解しやすくなります。
短く言えば、IDはデータを識別する値であり、Keyはデータベース上で一意性や関連付けを担う役割です。
ID = データを識別する値
Key = データベース上で一意性や関連付けを担う役割さらに簡単に言えば、IDは値、Keyは役割です。
IDとは
IDとは、あるデータを区別するための識別子です。
user_id = 1001
order_id = A00021
customer_id = C-0058
session_id = S-20260515-001IDの目的は、「どのデータなのか」を特定することです。
ユーザーを区別する。注文を区別する。顧客を区別する。セッションを区別する。
このように、IDは対象を識別するための値です。
ただし、IDという名前が付いているからといって、必ずしもデータベース上の主キーとは限りません。
画面表示用の番号、業務上の管理番号、外部サービスから渡されたIDなど、IDにはさまざまな種類があります。
Keyとは
Keyは、データベース設計における役割です。
Keyは、データを一意にする、検索しやすくする、別テーブルと関連付ける、といった目的で使われます。
代表的なKeyには、Primary Key、Foreign Key、Unique Key、Composite Key、Business Key、Surrogate Keyなどがあります。
つまりKeyは、単なる値ではなく、その列や値がデータベース上でどう使われるかを表す概念です。
IDとKeyの違い
IDとKeyの違いは、値なのか、役割なのかです。
たとえば、次のようなユーザーテーブルがあるとします。
users
- id
- email
- nameこの場合、idはユーザーを識別するIDです。
さらに、データベース上でidが主キーに設定されていれば、idはPrimary Keyでもあります。
IDとしては識別子
Keyとしては主キー同じ列でも、識別子として見ているのか、データベース上の役割として見ているのかで意味が変わります。
IDは「どのデータか」を表します。Keyは「そのデータをどう扱うか」を表します。
Primary KeyとForeign Key
Primary Keyは、テーブル内のレコードを一意に識別するための主キーです。
重複せず、NULLにせず、その行を特定する基準になります。
一方、Foreign Keyは、他のテーブルのデータを参照するためのキーです。
たとえば、注文テーブルにcustomer_idがある場合、そのcustomer_idが顧客テーブルの主キーを参照していれば、注文と顧客を結び付けられます。
orders.customer_id → customers.customer_idPrimary Keyはレコードを特定するためのKeyであり、Foreign Keyはテーブル同士の関係を作るためのKeyです。
Business KeyとSurrogate Key
実務で特に重要なのが、Business KeyとSurrogate Keyの違いです。
Business Keyは、業務上の意味を持つ識別子です。顧客コード、社員番号、商品コード、請求番号、物件番号などが該当します。
人間が見ても意味があり、業務上の管理番号として使われます。
一方、Surrogate Keyは、システム内部で安定して参照するための人工的なIDです。自動採番ID、UUID、AppSheetのUNIQUEID()などが該当します。
Business KeyとSurrogate Keyを分ける理由は、業務上のIDは変わる可能性があるからです。
商品コードのルールが変わる。社員番号を付け直す。顧客コードを統合する。物件番号の採番ルールが変わる。
こうした変更に備えるには、内部的なKeyには意味を持たないIDを使い、業務上の番号は別の列として持つ設計が安定しやすくなります。
AppSheetでも重要になる
AppSheetでも、IDとKeyの違いはかなり重要です。
AppSheetでは、各レコードを一意に識別するKey列が必要です。
このKeyに、業務上の番号をそのまま使うこともできます。しかし実務では、変更や重複の可能性を考える必要があります。
人間が見て分かりやすい番号だからといって、それを内部Keyにすると、後から運用が崩れることがあります。
そのため、AppSheetでも内部的なKeyにはUNIQUEID()のような値を使い、顧客番号、案件番号、物件番号などは別列で持つ方が安定しやすくなります。
Time合同会社では、AppSheetで業務アプリを作る場合でも、単なるスプレッドシートの延長ではなく、RDBMSに近いレコード構造としてデータを蓄積する方針を重視しています。
画面上はノーコードでも、裏側のデータはテーブル、Key、Ref、リレーションを意識して設計した方が、後から修正しやすく、AIや外部システムとも連携しやすくなります。
AI時代にもIDとKeyは重要
AI時代になると、IDとKeyの管理はさらに重要になります。
RAG、ベクトル検索、ナレッジベース、AIエージェントの設計では、Document ID、Chunk ID、Session ID、Memory ID、User ID、Entity IDのような識別子が増えます。
一方で、検索や保存の仕組みでは、Primary Key、Foreign Key、Index Key、Cache Key、Vector KeyのようなKeyも使われます。
ここでも考え方は同じです。
IDは「どのデータか」を表します。Keyは「どう検索し、どう関連付け、どう一意性を保つか」を表します。
AIにデータを読ませる場合でも、元データのIDやKeyが曖昧だと、情報の追跡や更新が難しくなります。
まとめ
IDとKeyは似ていますが、同じ意味ではありません。
ID = データを識別する値
Key = データベース上での役割IDは「どのデータか」を表します。Keyは「そのデータをどう扱うか」を表します。
実務では、業務上の番号と内部参照用のIDを分けることが重要です。
顧客コード、社員番号、請求番号、物件番号のようなBusiness Keyは、人間が使う番号です。一方、UUIDやUNIQUEID()のようなSurrogate Keyは、システムが安定して参照するためのIDです。
IDは値。Keyは役割。
この違いを押さえると、RDBMS、AppSheet、業務システム、AI時代のデータ設計で混乱しにくくなります。