絶対に知っておきたい
データベースの基礎と「キー」
AppSheetは見た目はノーコードですが、内部では常にデータ構造の上で動いています。
この章では、初心者が最もつまずきやすい行・列・レコード・キーの関係を整理し、
「なぜキーが重要なのか」を本質から理解できるようにします。
この章のゴール
AppSheetの元データを「ただの表」ではなく、 アプリが読み取るための構造化データとして見られるようになることです。
最重要テーマ
キーは、1件1件のデータを取り違えないための土台です。 ここを曖昧にしたまま進むと、後の章で必ず苦しくなります。
よくある誤解
「名前で識別すればいい」「行番号で十分」「見えている表とAppSheetの認識は同じ」。 これらは初心者が持ちやすい危険な思い込みです。
なぜ最初にデータ構造を学ぶのか
AppSheetでは、画面づくりや自動化の前に、まず元データの形が正しく整っている必要があります。 どれだけ画面がきれいでも、裏側のデータ構造が曖昧だと、更新・削除・参照のすべてが不安定になります。
特に第2章で学ぶ「キー」は、後のRef、SELECT、Actions、Automationにまで影響する中心概念です。
データベースの基本構造
AppSheetは、GoogleスプレッドシートやExcelの表を読み込み、それをアプリの元データとして扱います。
ただし、AppSheetはその表を人間のように「なんとなく」見ているわけではありません。
列の意味、行のまとまり、どの値が識別子かを明確に定義してデータを理解しています。
そのため、表を見る時も「上から順に書いてある一覧」としてではなく、 1列ごとに意味を持ち、1行ごとに1件の情報がまとまっている構造として見ることが、アプリ開発の第一歩です。
データ全体の器です。スプレッドシートやExcel、外部DBがこの役割を担います。
1つのテーマ（社員、案件、申請）ごとにまとまった「表」のことです。
情報の種類です。氏名、部署など、縦の並びで「何の値か」を表します。
レコードとも呼ばれます。社員1人や申請1件など、1セットのデータ単位です。
初心者向けのイメージ
たとえば「従業員テーブル」なら、1行が1人の従業員で、1列がその社員に関する特定の情報（氏名、部署など）です。
AppSheetは「従業員というまとまり」を行単位で認識して扱うため、どの行が誰なのかを一意に判別できる「目印」が必要になります。
【最重要】キーの概念
キー（Key）とは、テーブル内の各行を一意に特定するための値です。 「この1行は誰の情報か」「どのレコードを更新するのか」をAppSheetが判断するための唯一の基準になります。
名前や部署のような「人が読むための値」と違って、キーは「システムが迷わないための値」です。 したがって、重複しないこと、途中で変わらないことが絶対条件になります。
キー（Key）が正常な状態
a1b2c3d4 の従業員を編集すると、AppSheetは迷わずその1件だけを確実に更新できます。
- 同姓同名がいても絶対に取り違えない
- データの並び替えをしても関係が壊れない
- 他テーブルからも正確に参照（Ref）できる
キー（Key）が不適切な状態
- 全く関係ない行を誤って上書き・削除してしまう
- 参照（Ref）していたデータが迷子になる
- アプリの同期エラーが頻発する原因になる
なぜ「氏名」をキーにしてはいけないのか
一見すると「氏名」をキーにできそうに思えますが、実務では同姓同名が起こり得ます。 また、表記揺れや改姓、入力ミス修正などによって値が変わる可能性もあります。
人間にとって「わかりやすい値」と、システムにとって「安全な値（キー）」は別物であることを理解しましょう。
推奨キー UNIQUEID() vs NGキー Row Number
AppSheetでは、キーを自分で明示しないと、行番号である Row Number が暫定的なキーとして使われることがあります。
しかし、実運用でこれをキーにするのは非常に危険です。
基本方針として、新規レコードには UNIQUEID()
で生成された専用IDを持たせるのが鉄則です。
なぜ Row Number を使ってはいけないのか
スプレッドシートで行を削除したり、並び替えたりすると、行番号は簡単にズレてしまいます。
すると、AppSheetが裏側で覚えていた「この行がこのレコード」という紐付けが狂い、「Aさんのデータを更新したつもりが、Bさんのデータが書き換わった」という致命的なトラブルの原因になります。
キーは「見た目の位置」ではなく、レコードそのものに「一生固定された目印」でなければなりません。
正しい設定の基本：UNIQUEID() を使う
専用のID列を作り、その列の Initial value に UNIQUEID() という式を設定します。
これにより、データが新しく追加されるたびに、AppSheetが重複のないランダムな文字列（例: 8a4b2cde）を自動で生成してくれます。
| 比較項目 |
推奨: UNIQUEID()
|
非推奨: Row Number
|
|---|---|---|
| 生成タイミング | レコード作成時に一度だけ生成 | スプシ上の位置で動的に決まる |
| 値の安定性 | 一度決まれば一生変わらない | 行の追加・削除で簡単に変わる |
| 安全性 | 非常に高い | 極めて危険 (データ破損リスク) |
| 推奨度 | 事実上の標準。迷わずこれ | デバッグ以外での使用は厳禁 |
UNIQUEID() の良さ
人間には読みにくい値でも、システムにとっては安定した識別子になります。 見た目の分かりやすさより、安全性を優先するのがキー設計です。
補足：自然キーという考え方
社員番号や商品コードのように、もともと重複せず変わらない値が存在するなら、それをキーに使える場合もあります。 ただし「本当に変わらないか」を厳しく確認する必要があります。
実際の設定の考え方
第2章ではまだ複雑な式や参照関係までは扱いませんが、キー列をどう作るかの考え方はここで押さえておく必要があります。 まずは「専用のID列を用意する」という型を覚えてください。
元データ（スプレッドシート等）にID列を作る
スプレッドシートの1列目に、ID や 従業員ID のような列を追加します。
この列は「名前」とは別に、システムが確実にレコードを識別するために使用します。
AppSheet側でその列を Key に指定する
作成したID列の Key 設定をオンにします。
これにより、AppSheetはこの列の値を「レコードの唯一の索引」として扱うようになります。
Initial value に UNIQUEID() を入れる
新しいデータが追加される際、自動でユニークな値が入るように設定します。
手動入力を避けることで、ヒューマンエラーによるID重複を根本から防ぎます。
「表示する名前」は Label で設定する
ID自体は「Key」として扱い、画面に表示する名前などは「Label」に任せます。 「識別（Key）」と「表示（Label）」の役割を分けるのがAppSheet設計のコツです。
実務で役立つ視点
後で Ref を使って別テーブルとつなぐ時も、Automation で対象レコードを特定する時も、土台にあるのはキーです。 第2章は地味に見えますが、後半の学習の理解度を大きく左右する章です。
この段階で避けたい設計
氏名やメールアドレスのような「意味のある値」を安易にキーにすること、 また Row Number に頼ることです。見た目では問題なく見えても、後で壊れやすい設計になります。
AppSheetで安全にデータを扱うために、キー（Key）の理解は避けて通れません。 キーは人に見せるための値ではなく、システムが迷わずレコードを識別するための「一生変わらない背番号」です。
重複やズレが起こりやすい値（Row Numberなど）ではなく、UNIQUEID() などの安定した識別子を設計の土台に据えましょう。
この正しい土台があるからこそ、次章で学ぶ「データ構造の変更」や「高度なリレーション」を安全に行うことができるようになります。