こんにちは、メリ爺です。
「AIを使って自分専用のシステムを作ってみたい！」
そう期待に胸を膨らませて調べ始めた時、真っ先に目の前に立ちはだかる高い壁があります。それが「データベース（テーブル）設計」という、いかにもエンジニア然とした言葉です。
これを聞いただけで「うわ、やっぱりプログラミングの知識がないと無理なんだ……」と、せっかく開きかけたAIの扉を閉じたくなってしまう方も多いのではないでしょうか？
でも、ちょっと待ってください。お茶でも飲みながら、リラックスして聞いてください。実は、あなたがこれまで何年も、何十年もExcelのシートと格闘してきたその経験の中に、テーブル設計の正解はすでに隠されているんです。
今回は、AIでのシステム開発を「一発屋の使い捨て」で終わらせず、10年先もあなたのビジネスを支え続ける「資産」にするための、テーブル設計の基礎を紐解いていきましょう。ここを理解するだけで、あなたの作るシステムは、崩壊を待つだけの「ゴミ」から、頼れる「相棒」へと姿を変えますよ。
1. 実はもうやっている？身近な「テーブル設計」の情景
テーブル設計と聞くと「無理無理無理無理！」と、キーボードを叩く手が止まってしまうかもしれませんが、そんなに身構える必要はありません。あなたは日々の戦場（現場）で、すでにこの設計を嫌というほど経験しているからです。
例えば、こんなシーンを思い出してみてください。夕方の忙しい時間、上司から「至急、今月の商品購入リストをExcelにまとめておいてくれ。過去の履歴もわかるようにね」と頼まれたとします。
あなたは伝票の束を横に置き、手慣れた手つきでExcelの1行目にこんな見出しを作るはずです。
- 会社名
- 名前
- 郵便番号
- 住所
- 電話番号
- 購入日
- 購入商品名
「よし、これで入力準備は完了だ」と一息つく。実は、この「どの項目を横に並べるか」を決めた瞬間、あなたは立派なテーブル設計の第一歩を踏み出しているんです。
どうですか？ いつもやっている当たり前の作業ですよね。「なんだ、その程度のことか」と思えてきませんか？
2. 「1つのデータに魂を込める」という基本
テーブル設計の基本は、「1つのデータ（行）」に対して「必要な情報（列）」を過不足なく付与し、意味を持たせることにあります。データベースの世界ではこれを「レコード」と呼びますが、私たちは「1行＝1つの事実」と捉えれば十分です。
「え？ そんなのExcel職人なら誰でもできるでしょ。わざわざAIに教えてもらうことじゃないよ」
いいですね、その自信！ その心意気こそが内製開発のガソリンになります。
しかし、ここが運命の分岐点です。この「表の作り方」を少し間違えるだけで、将来的に「デジタルスラム（どこに何があるか分からず、触るのも怖いゴミ溜めのようなシステム）」を築き上げてしまうか、それとも120%の力を発揮する一級品のシステムになるかが決まってしまうのです。
3. 【警告】その表、そのままシステムにすると「デジタルスラム」の迷宮へ
さて、先ほどの「商品購入リスト」を使って、新しい営業施策を考えてみましょう。
「新商品の発表に伴い、過去に一度でも買ってくれた顧客全員にDM（ダイレクトメール）を出したい」という指示が飛んできました。
この時、今の購入リストをそのままシステムのデータベースとして使い続けることは可能でしょうか？
ここで「もちろん、オートフィルタで抽出して、コピー＆ペーストすれば簡単だよ！」と即答した方……注意が必要です。あなたは今、デジタルスラムの入り口に立っています。
現場で起きる「データの崩壊」の情景：
同じA社さんが5回買ってくれたら、リストにはA社さんの住所が5回登場します。もしA社さんが引っ越しをしたら？ 5箇所のデータを手作業で直しますか？ もし1箇所でも直し忘れたら、DMは宛先不明で戻ってきてしまいます。データが増えれば増えるほど、どれが「正しい真実」なのか分からなくなり、VLOOKUPすらエラーを吐き出す……。これがシステム崩壊の始まりです。
■ワンポイントうんちく：
こういう「同じ情報が何度も出てきて、直し忘れが起きる現象」は、データベースの世界では「更新異常（こうしんいじょう）」なんて呼ばれます。名前が付いている時点で、世界中の現場が同じ地雷を踏んできたということです。つまり、あなたのせいじゃありません。構造のせいです。
4. 解決策は「番号札」で管理するだけ！
では、どうすればいいのか？
「加工しなきゃ使えないなら、最初から顧客情報だけ別のシートに分けておいて、番号で呼べばいいんじゃないの？」と思えた方。おめでとうございます！ あなたの思考はすでにプロのシステム設計者と同じ領域にあります。
イメージは直感的でいいんです。「情報の種類ごとに表を切り分け、共通の『番号札』で紐付ける」、ただこれだけです。
■ 顧客テーブル（顧客のプロフィール帳）
- 顧客番号（唯一無二の番号札）
- 会社名
- 名前
- 住所
■ 商品購入テーブル（日々の取引の記録）
- 顧客番号（「誰が？」を指し示す番号札）
- 購入日
- 購入商品名
これだけでバッチリです！ お客さんのプロフィールは「顧客テーブル」で一箇所だけ管理。住所が変わっても1箇所直すだけで、すべての購入履歴が自動的に「最新の住所」に繋がります。この清潔な状態を保つことこそが、システムを長持ちさせる秘訣です。
5. なぜAI開発において、人間が「目を光らせる」必要があるのか？
「要件定義でしっかり目的を伝えれば、あとはAIが完璧にやってくれるはずだ」
そう思いたい気持ちはよくわかります。確かに、開発の最初に「要件定義」という名の旗を立て、AIとゴールを共有することは非常に重要です。しかし、どれほど旗を高く掲げても、AIとの意思疎通が100%になる確証はありません。
AIは非常に賢いですが、あなたのビジネスの現場や「将来どうしたいか」という空気感までは見えません。要件定義でどれだけ細かく伝えたつもりでも、AIは時として、あなたの意図とは微妙にズレた「その場しのぎの不完全なテーブル構造」を提案してくることがあります。
だからこそ、人間が目を光らせる必要があるのです。
特にテーブル構造の段階でズレが生じると、その上に積み上がるプログラムはすべて歪んでしまいます。慣れてくると、「あ、ここはAIに任せるより、先にテーブル構造を見せた方が正確に伝わるな」という感覚がわかってきます。要件定義という旗を共有しつつも、現場監督であるあなたが「テーブル設計」という武器を持って厳しくチェックする。この二段構えこそが、失敗しないAI開発の極意です。
6. うんちく章：なぜ「正規化」という考え方が生まれたのか？
「番号札で分ければいい」――ここまで来ると、話はだいぶスッキリしてきました。
ここで、記事のテーマにピッタリ噛み合う、うんちくを一つ差し込みます。
データベースの世界には、表をキレイに分けるための考え方として「正規化（せいきか）」という言葉があります。難しく聞こえますが、やっていることはまさに本記事の「同じ情報を何度も書かないように、表を切り分ける」です。
なぜ、わざわざそんな言葉が生まれたのか？
理由は単純で、世界中の現場で「更新異常」「二重管理」「直し忘れ」「どれが正しいの問題」が爆発してきたからです。
ここが大事なポイントで、正規化って「エンジニアの儀式」ではありません。
データを“事実として扱う”ための、現場の生存戦略なんです。
そしてAI開発においては、この正規化の発想がとても効きます。AIは放っておくと、都合よく一枚の表に詰め込みがちです。目の前の要件だけなら動いてしまうからです。けれど運用が始まって、住所変更や担当者変更や商品名変更が発生した瞬間に、システムが「直し忘れ地獄」に落ちます。
だから人間がやるべきことは、難しいSQLを暗記することではなく、「この情報、何回出てくる？ それ、別テーブルに逃がすべきじゃない？」と、現場目線でツッコミを入れることです。これができるだけで、AIが作る成果物の寿命が一気に伸びます。
まとめ：設計の知識はAIという翼を操る「手綱」
テーブル設計は、決して苦行ではありません。AIが出してきた案が「資産」になるか「ゴミ」になるかを判断し、必要なら軌道修正をかけるための、プロデューサーの視点です。
- 要件定義でAIとゴール（旗）を共有する
- 出てきた案に対して、「番号札（紐付け）」が正しいか目を光らせる
- 確実性を高めるために、人間側からテーブル構造を提示する
この「目を光らせる」ステップがあるだけで、AIはあなたの意図を完璧に具現化し、プロ顔負けの頑強なシステムを組み上げてくれます。コードはAIに任せましょう。でも、「データの整合性」という一線だけは、現場を知り尽くしたあなたが守り抜いてください。
それが「開発の重力」から解放され、AIという翼でビジネスを次のステージへ進めるための最短ルートなのです。
さて、次回はこの「目を光らせる」技術を使いながら、実際にAIへどう指示を出し、出てきた案をどう添削すればいいのか。具体的な「対話術（プロンプト）」の実践編をお届けします。お楽しみに！
メリ爺のAI内製開発万歳：
「欲しい機能を日本語で定義できれば、システムは作れる。安全に、賢く、資産になる開発を。」
コメント