データベースとは?非エンジニアが知っておくべき最小限のこと
Excelの表が何枚もある、というイメージで十分です。「同じ情報が繰り返されるなら表を分ける」という判断基準と、なぜ画面で隠すだけでは守れないのかを説明します。
AIに頼めばアプリは作れます。でも「データベースの設計をどうしますか」と聞かれたとき、答えられないと困ります。この記事を読めば、その質問に答えられるようになります。 専門的な用語は使わず、Excelにたとえながら説明します。
まず結論
データベースとは、情報を整理して保存しておく場所です。Excelの表が何枚もある、と考えるのがいちばん近いイメージです。
そして、非エンジニアが知っておくべきことは3つだけです。
- 1
何を、どういう単位で保存するか
「予約」と「お客さん」は別の表に分ける、といった判断です。ここを間違えると後で作り直しになります。
- 2
誰が見られるか
保存されたデータを、誰が読めて誰が読めないか。ここが安全性の中心です。
- 3
後から変えられるか
作った後に項目を足せるか。最初に決めておくと楽になる部分があります。
データベースは「表の集まり」
Excelを思い浮かべてください。1枚のシートに、1行1件でデータが並んでいます。
データベースも同じです。表(テーブル)があり、行があり、列がある。 これだけです。
予約サイトなら、こんな表になります。
| id | 予約者名 | 電話番号 | 希望日時 | 人数 |
|---|---|---|---|---|
| 1 | 山田太郎 | 090-xxxx | 10/20 10:00 | 2 |
| 2 | 鈴木花子 | 080-xxxx | 10/20 10:30 | 1 |
いちばん左の id は、その行を見分けるための番号です。 これがあることで「1番の予約を取り消して」といった指定ができます。
Excelとの違い
では、なぜExcelではダメなのか。違いは3つです。
| Excel | データベース | |
|---|---|---|
| 同時に使う | 複数人が同時に編集すると壊れる | 同時に何百人が使える |
| 探す速さ | 件数が増えると遅くなる | 何万件でも一瞬 |
| 権限 | ファイル単位でしか分けられない | 行ごとに「誰が見られるか」を決められる |
3つ目が決定的です。 「自分の予約だけ見える」という制御は、Excelではできません。
「どういう単位で分けるか」が最重要
ここが、非エンジニアが判断すべきいちばん大事な部分です。
悪い例:全部を1つの表に入れる
| id | 予約者名 | 電話番号 | 日時 | 担当者名 | 担当者の電話 |
|---|---|---|---|---|---|
| 1 | 山田太郎 | 090-xxxx | 10/20 | 佐藤 | 070-yyyy |
| 2 | 鈴木花子 | 080-xxxx | 10/20 | 佐藤 | 070-yyyy |
担当者の情報が繰り返し入っています。 佐藤さんの電話番号が変わったら、全部の行を直さなければなりません。1000件あれば1000箇所です。
良い例:分けて、つなげる
予約の表
| id | 予約者名 | 電話番号 | 日時 | 担当者id |
|---|---|---|---|---|
| 1 | 山田太郎 | 090-xxxx | 10/20 | 1 |
| 2 | 鈴木花子 | 080-xxxx | 10/20 | 1 |
担当者の表
| id | 名前 | 電話 |
|---|---|---|
| 1 | 佐藤 | 070-yyyy |
これなら、佐藤さんの電話番号を変えるのは1箇所だけです。
判断の基準はシンプルです。「同じ情報が繰り返し出てくるなら、別の表に分ける」。 これだけ覚えておけば十分です。
SQLとは
SQLは、データベースに命令するための言葉です。
たとえば「10月20日の予約を全部見せて」は、こう書きます。
SELECT * FROM 予約 WHERE 日時 = '10/20'
SELECT(選ぶ)、FROM(どの表から)、WHERE(条件)。英語の文とほぼ同じ構造です。
書けるようになる必要はありません。 ただ「AIはこういう命令を作ってデータを出し入れしている」と知っておくと、後で説明する危険性が理解できます。
誰が見られるか:ここが安全性の中心
データベースには、「この行は、この人だけが読める」という制限をかけられます。
Supabase(無料で始められるデータの保存先)では、これを RLS(行レベルセキュリティ) と呼びます。「行ごとの制限」という意味です。
なぜこれが重要なのか
画面の作りだけで守ろうとすると、簡単に突破されます。
あなたが打つ
Claude Code の動き
これだけだと、URLの番号を書き換えるだけで他人の予約が見えてしまうことがあります。画面が「表示しない」だけで、データベースは求められれば返してしまうからです。
保存側で止めていれば、URLを直接叩かれても拒否されます。
実際に出す指示
データベース側で、ログインした本人のデータしか読み書きできないように
設定してください。
Supabase を使っているなら RLS を有効にして、ポリシーを設定してください。
画面側で隠すだけの対応にはしないでください。
URLを直接叩かれても、データベースが拒否する状態にしてください。
この指示を出すかどうかで、公開できるかどうかが決まります。
最初に決めておくと楽なこと
後から変えるのが大変な項目があります。作り始める前に決めておいてください。
- 個人情報(氏名・電話・住所)を保存するかどうかここが該当したら公開しない
- 誰が見られるか(本人のみ / 管理者も / 全員)ここが該当したら公開しない
- データをいつまで保存するか
- 削除は「消す」のか「消したことにする」のか
- 1人が複数の記録を持つか(1対多になるか)
4番目は補足が要ります。 予約を取り消したとき、行ごと消すのか、「キャンセル済み」の印を付けるだけにするのか。後で「先月の取り消し件数を知りたい」となったとき、消していると答えられません。
迷ったら、消さずに印を付けるほうが安全です。
AIに設計させるときの指示
自分で全部決める必要はありません。AIに案を出させて、判断だけすればよいです。
◯◯を作るために、データベースの設計を提案してください。
保存したいもの:
・(項目を思いつくまま書く)
次の形で答えてください。
・どういう表に分けるか、その理由
・各表にどんな項目を持たせるか
・個人情報を含む項目はどれか
・誰が読み書きできるようにすべきか
同じ情報が繰り返し出てくる部分があれば、表を分ける提案をしてください。
後から項目を足したくなりそうな箇所も教えてください。
最後の2行を入れてください。 これがあると、将来の変更に強い形を提案してくれます。
この記事で扱っていない部分
ここまでは「何が起きるか」「どう判断するか」です。実際の設定手順は扱っていません。
具体的には、Supabase で RLS を有効にしてポリシーを書く手順、.env と .gitignore の設定、認証と認可の実装、本番公開前の8項目を1つずつ確認する方法などです。
これらは手を動かして覚える領域なので、Claude Code Camp のカリキュラムで扱っています。 記事だけで完結させると中途半端になるため、あえて踏み込んでいません。
よくある質問
Q. データベースの知識は、どこまで必要ですか? A. この記事の内容で十分です。 設計はAIに任せ、「同じ情報が繰り返されていないか」「誰が見られるか」だけ自分で確認してください。
Q. Excelやスプレッドシートではダメですか? A. 自分だけで使うなら十分です。他人に使ってもらうなら、権限の制御ができないので不向きです。
Q. Supabase以外の選択肢は? A. あります。ただし初めてなら Supabase が扱いやすいです。無料で始められ、行ごとの権限設定が標準で用意されています。
Q. データが消えたらどうなりますか? A. 戻せません。バックアップが有効になっているかを必ず確認してください。Supabase の有料プランでは自動で取得されます。
Q. 設計を間違えたら作り直しですか? A. 項目を足すのは簡単です。表の分け方を変えるのは大変です。だから最初に「同じ情報が繰り返されていないか」だけ見てください。
まとめ
- データベースは「表の集まり」。Excelのシートが何枚もあるイメージ
- Excelとの決定的な違いは、行ごとに「誰が見られるか」を決められること
- 判断基準は**「同じ情報が繰り返し出てくるなら、別の表に分ける」**
- SQLは書けなくてよい。 ただし仕組みは知っておく
- 画面で隠すだけでは守れない。保存側(RLS)で止める
- 後から変えにくいのは、個人情報の有無・権限・削除の方式