ノーコードツール「Bubble」は、コーディングの知識がなくても、Webサービスを構築できるプラットフォームとして注目されています。しかし、見た目が完成したからといって、プロダクトが完成したわけではありません。これは、私たちが実際にBubbleで開発を進める中で痛感したことです。

Bubble開発における最大の落とし穴はデータベース設計です。後から構造を変更しようとすると、UIとの結合やセキュリティ設定の整合性が崩れ、メンテナンス性が一気に悪化します。この記事では、Bubble特有のデータ構造の理解から実務に即した設計のコツまで、現場の知見をベースに解説していきます。

なぜデータベース設計が大切なの？

アプリやWebサービスを作るとき、「どんな情報をどうやって管理するか？」を決めるのがデータベース設計です。たとえば、ECサイトではユーザーの名前や住所、商品の名前や価格、注文履歴など、たくさんのデータを正しく整理する必要があります。これを無計画に始めてしまうと、後で「どこに何があるかわからない」「変更できない」といった問題が起こります。

データベース設計の5ステップ

1．管理したい“もの（エンティティ）”を洗い出す

まずは、「どんな情報を扱いたいのか」をざっくり洗い出します。これをエンティティと呼びます。エンティティを洗い出す際のコツは、「何を管理したいか」を明確にしながら、“モノ・コト・ヒト”の視点でシンプルに考えることです。以下に、初心者にも分かりやすい形でポイントを整理します。

主語になりうる「名詞」に注目する

エンティティを洗い出す際は、業務の説明や関係者の会話の中に出てくる「名詞」に注目すると、候補を見つけやすくなります。

たとえば「顧客が商品を注文する」という文であれば、「顧客」「商品」「注文」といった名詞がそれぞれエンティティ候補です。文章の主語や目的語になっている名詞は、何らかの管理対象であることが多いため、初期の段階では漏れなく拾っておくのがポイントです。

「管理したいもの・区別したいもの」はすべてエンティティ

業務で「個別に管理したい」「1件ずつ記録を残したい」と考えているものは、すべてエンティティとして定義するのが基本です。たとえば顧客情報は顧客ごとに、商品情報は商品ごとに、個別に区別して管理する必要があります。一方で、送料の固定金額などまとめて管理されるものは、属性やマスターデータで処理したほうがいいかもしれません。いずれにしても判断の軸は「識別が必要かどうか」です。

• 誰が？（ヒト）→ユーザー、社員、顧客、施術者など
• 何を？（モノ）→商品、施設、メニュー、設備など
• どんな行為？（コト）→注文、予約、面談、支払いなど

「繰り返されるもの」に注目する

エンティティは多くの場合、繰り返し発生する対象です。たとえば「注文」は1人の顧客が何度も行うものであり、「請求書」も毎月発行されることがあります。このように繰り返し出現する要素は、それぞれ独立した情報として管理する必要があるため、エンティティとして扱うのが適切です。一方で、一度しか発生しない使い捨ての情報はエンティティにせず、属性として扱うことが一般的です。

1人のユーザーが複数の予約を持つ → 「予約」はエンティティとして分離すべき

属性とエンティティを混同しない

エンティティと属性の混同は、ありがちなミスのひとつです。エンティティは「独立して管理したいもの」、属性は「エンティティの具体的な情報（名前・住所など）」と考えましょう。たとえば「顧客」というエンティティには、「氏名」「メールアドレス」などの属性があります。ここで「メールアドレス」をエンティティにしてしまうと、システム全体の構成が複雑に。情報の粒度に注意する必要があります。

• NG：電話番号ごとに別の「電話」エンティティを作る
• OK：電話番号は「ユーザー」の属性（カラム）にすべき

「業務フロー」や「紙の書類」をベースに考える

慣れないうちは、実際の業務フローや紙の書類を参考にするのも有効な方法です。たとえば「見積書」「請求書」「契約書」などは、それぞれがエンティティの候補になります。書類には日付・金額・相手先などの属性が含まれており、データ構造のヒントになります。業務フローをたどることで「どんなタイミングでどんな情報が生成・参照されるか」もわかり、必要なエンティティを漏れなく洗い出せます。

• 予約表 → 予約エンティティ
• 顧客カード → 顧客エンティティ
• 請求書 → 請求エンティティ

エンティティ洗い出しのチェックリスト

3つ以上がYesであれば、エンティティ化を検討しましょう。

• 複数のデータを持つ（一覧にできる）？
• 個別に識別する必要がある？（IDで管理）
• 他のデータと関連を持つ？
• 将来的に検索や集計をする可能性がある？

2．それぞれに必要な“項目（属性）”を考える

次に、各エンティティにどんな情報を含めるかを考えます。これは**カラム（列）**とも呼ばれます。各エンティティの「属性（カラム）」を考えるときは、「それぞれのデータをどう識別し、どう使うか？」を意識することが重要です。以下に、初心者向けにわかりやすく7つのコツに整理してご紹介します。

「ID（識別子）」を必ず用意する

すべてのエンティティにはuser_id、reservation_id、product_id など、一意に識別できる「ID（識別子）」を必ず設定しましょう。IDは、他のデータと区別し、関連付けるための“鍵”となります。たとえば「顧客ID」や「商品ID」など、システム内で重複しないユニークな値を用いることで、データの整合性が保たれ、検索や更新処理もスムーズに行えます。IDは通常、数値やUUIDなど機械的に生成される値が推奨され、人間が意味を読み取ることは前提としていません。

「管理に必要な情報」を洗い出す

属性は「そのエンティティを管理するために必要な情報」で構成されます。たとえば「顧客」であれば、氏名・住所・メールアドレスなどが基本的な属性になります。業務に必要な情報を漏れなく洗い出すためには、実際の業務フローや使用している帳票、ヒアリング内容などをもとに「あとで何を見たいか」「どの条件で検索・分析したいか」を考えることが大切です。必要最低限に絞りつつも、将来の利用目的も見据えて設計しましょう。

「データ型（型）」も一緒に意識する

属性を設計する際は、名前や中身だけでなく「データ型」も明確にすることが重要です。たとえば、「氏名」は文字列型、「生年月日」は日付型、「売上金額」は数値型といった具合に、それぞれのデータに最適な型を選定します。これにより、データの入力制限・整合性チェック・ソートや演算処理が正しく行えるようになります。データ型を意識しない設計は、後々のバグやシステムトラブルの原因にもなり得ます。

• 数値（integer）：年齢、金額、在庫数など
• 文字列（text）：名前、メールアドレスなど
• 日付（date）：登録日、予約日など
• 真偽値（boolean）：有効かどうか、同意済みか

「分けるべき」属性は分ける

ひとつの属性に複数の意味が含まれている場合は、きちんと分割することが大切です。たとえば「住所」を1項目で持つのではなく、「都道府県」「市区町村」「番地」「建物名」などに分けておくと、地域ごとの集計や検索が容易になります。同様に、「氏名」も「姓」と「名」に分けることで、表示形式の変更や並び替えが柔軟になります。将来的な拡張性や運用効率を考えると、属性の分割は非常に重要な設計判断です。

• NG：住所 というカラムに「東京都渋谷区1-2-3ビル5F」
• OK：都道府県 / 市区町村 / 番地・建物名 に分ける

 将来的に「検索・集計したくなる」項目は残しておく

今すぐに使わなくても、将来的に「検索条件に使いたい」「集計して傾向を分析したい」と考えられる情報は、あらかじめ属性として残しておくのが望ましいです。たとえば、「予約経路」「顧客の年代」「来店目的」などは、初期段階では活用機会が少なくても、後になってマーケティングや施策の改善に役立つことがよくあります。

ただし、何でもかんでも入れるのではなく、「意思決定や改善に使える情報か？」という視点で選別し、可能であれば入力負荷を抑えつつ収集する方法（選択式、初回のみ入力など）を工夫しましょう。データは「使える状態」で蓄積しておくことが、のちのち大きな資産になります。

• 顧客の「登録経路（例：SNS、広告、紹介）」
• 注文の「ステータス（未処理／処理中／完了）」
• 「タグ」「カテゴリ」「都道府県」などで分類

 計算結果は原則「保存しない」

計算によって得られる値は、原則としてデータベースに保存しない方が望ましいです。たとえば「売上金額」は「単価 × 数量」から算出できるため、元データを保存しておけば都度計算で導出できます。もし計算結果を保存してしまうと、元データが変わった際に整合性が崩れるリスクがあります。ただし、過去の状態を保持したい場合や、パフォーマンスを優先するケースでは、例外的に保存することもあります。

• NG：年齢
• OK：生年月日（年齢は必要なときに計算）

1つの属性に「複数の値」を入れない

1つの属性に複数の値（カンマ区切りや改行など）を入れるのは避けましょう。たとえば「対応サービス：整体、美容、鍼灸」のように1つのセルにまとめて記録すると、検索・集計・条件分岐が非常に困難になります。このような場合は、「サービス」という別エンティティを用意し、「顧客とサービスの関係」を別テーブルで管理するのが適切です。正規化の基本は「1セル＝1値」。データの再利用性と拡張性を高めるための鉄則です。

•  NG： タグ = 「美容,整体,ダイエット」
•  OK： タグテーブルを作って、ユーザーごとに複数タグを紐付ける

データベース設計は最初に7～8割の精度を目指し、運用しながら見直すのが現実的です。
Bubbleなどノーコード環境であれば、プロトタイプを動かしながら属性を調整していくアプローチも有効です。

属性設計のチェックリスト

• 一意に識別できるIDがあるか？
• 利用者にとって必要な情報か？
• 将来的に検索・集計したくなるか？
• 情報を無理に1セルに詰め込んでいないか？
• 他のテーブルの情報を重複して書いていないか？

3．エンティティ同士の関係（リレーション）を考える

データ同士はつながっています。たとえば、「予約」は「ユーザー」と「店舗」に関係しますよね。その関係は下記のようにあらわすことができます。

• ユーザー1人が複数の予約をする（1対多）
• 1つの店舗にも複数の予約がある（1対多）

これを「リレーション（関係性）」と呼びます。 ノーコードツール（Bubbleなど）でも、この関係を「関連フィールド」で設定します。

エンティティ同士の関係（リレーション）を設計するときのコツは、「現実の関係性を正確にモデル化し、将来的な運用・検索・集計を見据えて構造をシンプルに保つ」ことです。初心者でも迷わないように、以下のように6つのコツに分けてご説明します。

「1対1」「1対多」「多対多」の3種類を意識する

関係は必ずどのような数の関係性か（カーディナリティ）を判断します。

• 1対1：ユーザーとプロフィール→同じIDで相互に参照
• 1対多：ユーザーと予約（1人が複数予約）→予約にユーザーIDを入れる（外部キー）
• 多対多：ユーザーとタグ（複数タグ、複数ユーザー）→中間テーブルを作る（ユーザー×タグ）

Bubbleでは「List of [型]」で「1対多」や「多対多」が表現可能ですが、パフォーマンスを考えると中間エンティティを設けたほうが管理しやすいです。

「どちらが親か」「どちらが従属か」を判断する

現実の関係を考えると、従属関係（親→子）があることが多いです。

「1人のユーザーが複数の予約をする」
→ 親：ユーザー、子：予約
→ 予約にユーザーIDを持たせる

この関係は、「削除時に一緒に消す（カスケード削除）」などの運用にも影響します。

「リレーションの方向」は一方通行で設計するのが基本

両方のエンティティに相互参照を持たせると管理が煩雑になり、Bubbleなどノーコード環境ではパフォーマンスにも影響します。

• NG：ユーザーが予約リストを持ち、予約がユーザーを参照する（双方向）
• OK：予約だけがユーザーを参照する（一方向）

多対多なら「中間エンティティ」を作る

多対多の関係はそのままだと管理できないため、中間テーブル（エンティティ）を必ず作ります。

• ユーザー×タグ → UserTag
• 生徒×講座 → Enrollment（受講登録）

この中間エンティティには、追加情報（登録日、優先度など）も持たせることができます。

「関係性」だけでなく「関係の属性」も設計する

リレーションそのものに意味のあるデータ（日時、役割、状態）が存在する場合は、それ専用のエンティティを作るべきです。

「誰が、いつ、どこで、どのくらいの時間施術したか」
→ 「施術」という中間エンティティにすべての情報を集約

ER図やカードで関係を“見える化”する

リレーションの誤設計を防ぐには、紙・ホワイトボード・draw.ioなどでER図を描いて視覚化するのが最も有効です。

リレーション設計のチェックリスト

• この関係は「1:1」「1:多」「多:多」のどれか？
• 関係に属性（日時、状態など）は必要か？
• どちらが親（主）で、どちらが子（従）か？
• 双方向参照になっていないか？
• 中間エンティティを導入すべきか？

4．データの正規化（整理整頓）

データの正規化とは、データベース内の情報を「重複なく、整然と」整理するための設計手法です。言い換えれば、データの「整理整頓」です。たとえば、同じ顧客の名前や住所が複数の場所に散らばっていると、修正や集計の際にミスや不整合が生まれやすくなります。正規化では、こうした情報を「顧客」テーブルにまとめ、他のテーブルからはIDで参照することで、重複をなくし、データの一貫性を保ちます。

Bubbleのようなノーコードツールでも、正規化の考え方を取り入れることで、アプリのパフォーマンスが向上し、メンテナンス性も大きく向上します。データが散らかってから整理するのではなく、最初から「1つのことは1か所で管理する」ルールを意識することが、開発をラクにするコツです。

5．テーブル設計書 or ER図にまとめる

最後に、テーブル一覧やER図を作成します。

• PK（Primary Key）：主キー、一意に識別

主キーとは、テーブル内の各レコードを一意に識別するための項目です。たとえば「顧客ID」「商品ID」などがこれに該当します。主キーには「重複しない」「空欄にならない（NOT NULL）」というルールがあり、1つのテーブルにつき1つだけ設定できます。主キーを正しく設定することで、データの重複や整合性の崩れを防ぎ、検索や更新のパフォーマンスも大幅に向上します。特にアプリや業務システムでは、内部的にIDを使ってデータを管理するケースが一般的です。

• FK（Foreign Key）：外部キー、他テーブルを参照

外部キーとは、他のテーブルの主キーを参照するための項目です。たとえば「注文テーブル」にある「顧客ID」は、「顧客テーブル」の「顧客ID（主キー）」を参照する外部キーとなります。外部キーを使うことで、異なるテーブル間に「どの顧客がどの注文をしたか」といった関係性（リレーション）を明確にし、データの整合性を保つことができます。また、外部キーを適切に設定することで、「存在しないデータを参照しない」といったチェックも自動化できるため、信頼性の高いデータベース構築が可能になります。

Bubbleのデータ構造は「見かけ以上に柔軟で、意外と罠が多い」

Bubbleでは、各データベース（＝「データタイプ」）に対してフィールド（＝カラム）を設定していきます。このときの最大の特徴は下記の3点です。

• オブジェクト指向的な「関連づけ（Reference）」が可能
• フィールドに「リスト（List）」を持たせられる
• 型の指定が厳密ではない（自由に追加・削除できてしまう）

この自由度の高さは、試作段階では非常にありがたい反面、「きちんとした設計図なしで開発すると、破綻する」ことを意味します。

① ロールとセキュリティを前提に構造を分ける

Bubbleでデータベースを設計する際には、最初に「誰がどのデータにアクセスできるか」というロール（役割）とセキュリティの考慮が欠かせません。たとえば、ユーザー、管理者、企業担当者など、立場によって閲覧・編集できる情報は異なります。そのため、ユーザー種別ごとにデータタイプを分けたり、フィールドレベルでのプライバシー設定を使ったりして、情報漏洩や誤操作のリスクを防ぎます。最初に「誰が何を使うのか」を明確にしておくと、後々の実装や保守が格段にスムーズになります。

② 関連構造は「方向」と「数」に注意

Bubbleでは、データ同士の関係性（リレーション）を簡単に作れますが、「どちらの方向に関連を持たせるか」「1対1か、1対多か」などの設計は慎重に行うべきです。たとえば、「会社」に「従業員（リスト）」を持たせるのか、それとも「従業員」に「所属会社」を持たせるのかによって、検索性やパフォーマンスが大きく変わることがあります。特に1つのデータタイプに大量のリストを保持させると、読み込みが重くなるため、リレーション設計はBubbleの特性を理解した上で設計することが重要です。

③ 将来の拡張を見据え、スキーマに余白を残す

Bubbleでの開発はスピーディに進められる反面、一度公開すると後からの構造変更が難しくなる場合もあります。そのため、初期段階から「将来的に増えそうなフィールド」や「オプション的に使われる可能性のある情報」について、ある程度の余白を持たせておくことが大切です。たとえば、タグ機能や補足メモ、拡張用のJSONフィールドなど、柔軟に使える属性を1つ用意しておくだけでも、将来の仕様変更に対応しやすくなります。必要以上に詰め込みすぎず、変化に耐えうるスキーマ設計を意識しましょう。

UIよりも先に、DBを設計せよ

Bubble開発では、「まず見た目をつくりたくなる」気持ちになりがちですが、データベース設計はその何倍も重要です。構造が整理されていれば、Bubbleは非常に強力なツールになります。これからノーコードでサービス開発を検討される方は、ぜひ設計段階で「データの流れ」「ユーザーのロール」「将来的な拡張性」に一度立ち止まってみてください。