ノーコードで詰まらない台帳の作り方：列の分け方とIDの付け方

1つの表に詰め込むと何が起きるか

最初に思いつきやすいのは、予約に関わる情報を1枚の表に並べる形です(説明用の例)。

• 11/05 10:00、顧客名：山田花子、電話：090-0000-0001、メニュー名：カット、料金：5000、担当：佐藤、メモ：
• 11/12 14:00、顧客名：山田 花子、電話：090-0000-0001、メニュー名：カラー、料金：8000、担当：佐藤、メモ：

この形だと、次のような問題が出やすくなります。

• 同じ顧客が来るたびに氏名と電話を入力するため、表記ゆれが起きます(上の例も「山田花子」と「山田 花子」で別人に見えます)。
• 電話番号が変わったとき、その顧客の全行を直す必要があります。
• 「この顧客の予約一覧」を作ろうとしても、氏名の揺れで集計がずれます。
• メニューの料金を直すと、どこまで過去の行も直すのかが曖昧になります。

分けた後の列構成例

同じ情報を3つの表に分けると、次のようになります(説明用の例)。

顧客表

• C0001、氏名：山田花子、電話：090-0000-0001、メール：、状態：有効

メニュー表

• M001、メニュー名：カット、標準料金：5000、所要分：60、状態：有効
• M002、メニュー名：カラー、標準料金：8000、所要分：90、状態：有効

予約表

• R0001、customer_id：C0001、menu_id：M001、開始日時：11/05 10:00、担当：佐藤、適用料金：5000、予約状態：完了、メモ：
• R0002、customer_id：C0001、menu_id：M002、開始日時：11/12 14:00、担当：佐藤、適用料金：8000、予約状態：予約中、メモ：

ポイントは3つです。

1. 予約表に氏名や電話は置きません。顧客IDから顧客表を見に行きます。
2. 予約表の customer_id と menu_id は、他の表のIDを入れる列です。ここは自由入力にせず、選択式にするのが安全です。
3. 「適用料金」は、あえて予約表にも持たせています。標準料金が後で変わっても、過去の予約の金額が動かないようにするためです。これは私の設計上の提案で、料金を常に最新のメニュー料金に合わせたいなら不要です。

IDの付け方ルール

IDは「その行を1件だけ指す名札」です。次のルールを最初に決めておくと、後から詰まりにくくなります。

• 一度付けたら変えない。 氏名の変更や電話番号の変更があっても、IDは触りません。
• 使い回さない。 行を消してもそのIDは再利用しません。消さずに「状態」列で無効にする運用が安全です。
• 意味を詰め込まない。 氏名の読みや日付をIDに入れると、情報が変わったときに困ります。接頭辞(顧客はC、メニューはM、予約はR)と連番程度にとどめます。
• 行番号をIDにしない。 並べ替えや行の削除でずれるためです。

• 氏名、IDに向くか：向かない、理由：同姓同名や表記ゆれが起きます
• 電話番号、IDに向くか：向かない、理由：変わることがあり、家族で共用する場合もあります
• 行番号、IDに向くか：向かない、理由：並べ替えや削除でずれます
• C0001のような連番、IDに向くか：向く、理由：変わらず、人間にも読めます
• ツールが自動で付ける長いID、IDに向くか：向く、理由：重複しにくく、手入力ミスも防げます

スプレッドシートでは連番を自分で管理することになります。新しい行を作るときは、最大の番号に1を足すだけでなく、「使用済みの番号を戻さない」という約束も決めてください。

ノーコードツール側での表現

ツールごとに、表のつなぎ方の用語は違います。今回開いて確認できた公式ページの範囲で整理します(確認日は2026年10月27日)。

Bubble:データの種類(Data type)と、その中の項目(Field)でデータベースを組み立てます。ある種類を別の種類の項目の型として使うことで、両者を結びつけます(Bubbleマニュアル「Data types and fields」)。すべてのデータ種類には、自動で生成され編集できない32文字の英数字のUnique IDが付きます。同じマニュアルのDatabase structureでは、データを重複させずに、関係を項目として持たせる考え方が説明されています。

AppSheet:公式テンプレートの説明によると、各表のキー列は行を一意に識別する必要があります。別の表を参照するRef列には、参照先のキー値が書き込まれます。氏名のように重複しうる列の代わりに、UNIQUEID() の出力をキーにする例が示されています。画面の見やすさのための「ラベル」は、キーとは別に設定できます(AppSheetテンプレート「Row labels and keys」)。

この2つに共通するのは、人が読む名前と、システムがつなぐためのIDを分けるという考え方です。上の例の customer_id と 氏名 の分け方も同じ発想です。なお、GlideやGoogleスプレッドシート単体の細かな設定は、今回の確認範囲に含めていません。お使いのツールの公式ヘルプで、参照(リレーション)の作り方を確認してください。

AIに設計案を作らせる依頼文

AIには、列の分割案とID規則の下書きを任せられます。確認は人が行います。渡す情報は、列名、1行ごとの意味、ダミーの数行です。実際の顧客データは貼らず、氏名や電話は架空の値に置き換えてください。サービスの学習利用の設定と、情報の秘密保持は別の話なので、設定にかかわらず個人情報は渡さないのが無難です。

あなたはノーコード初心者向けの台帳設計の相談役です。
下の1枚表を、複数の表に分ける案を作ってください。

【目的】小さな美容室の予約管理
【現在の列】予約日時, 顧客名, 電話, メニュー名, 料金, 担当, メモ
【ダミーデータ】
11/05 10:00, 山田花子, 090-0000-0001, カット, 5000, 佐藤
11/12 14:00, 山田 花子, 090-0000-0001, カラー, 8000, 佐藤

【お願い】
1. 表の分け方(表名、各表の1行が何を表すか)
2. 各表の列名と、IDでつなぐ列
3. IDの付け方(接頭辞+連番。変更・再利用しない前提)
4. 過去の予約の金額が後から変わらないための列の案
5. この設計で起きそうな入力ミスを3つ
専門用語は使わず、表形式で出してください。

人が確認すること

AIの案が出たら、アプリに入れる前にスプレッドシート上で次の3つを試してください。

1. 顧客1人に予約2件を入れ、顧客IDだけで両方の予約をたどれるか。
2. 顧客の電話番号を1か所だけ変えて、予約表側を直さなくても済むか。
3. メニューの標準料金を変えて、過去の予約の「適用料金」が動かないか(動かしたい設計なら、動くか)。

加えて、各表の1行が「1人」「1メニュー」「1回の予約」のどれか1つだけを表しているかも見てください。1つの予約に複数のメニューを入れたい場合は、「予約」と「メニュー」の間に「予約明細」表を足す必要が出てきますが、まずは1予約1メニューで動かし、必要になってから足すほうが混乱しません。