Bubble データベース設計入門【2026年版】データ型・Privacy Rules・料金確認
はじめに
Bubbleは、画面、ワークフロー、データベースを同じエディタ上で作れるノーコード開発ツールです。コードを書かずにアプリを作れる一方で、データベース設計を曖昧にしたまま作り始めると、後から画面表示が遅くなる、権限管理が複雑になる、同じ情報が複数の場所に保存されるといった問題が起きます。
Bubbleのデータベース設計で最初に考えるべきことは、どのData typeを作るかではなく、アプリ内で何を管理し、誰がどの情報を見て、どのタイミングで更新するのかです。 たとえば予約アプリなら、User、Reservation、Service、Paymentを分ける必要があります。ECアプリなら、Product、Cart、CartItem、Orderを分けるほうが運用しやすくなります。
2026年9月時点では、Bubbleの料金はworkload unitsやWeb/Mobileプランの考え方を含めて確認する必要があります。また、Data tab、Privacy Rules、Data API、AIによるdata types生成など、初心者が見落としやすい機能も増えています。この記事では、公式情報をもとに、Bubbleで失敗しにくいデータベース設計の手順を整理します。
最初の設計が整っていれば、あとから検索、API連携、権限管理、管理画面を追加するときも大きく崩れません。小さく作る場合でも、Data typeとPrivacy Rulesだけは先に確認しておくことが重要です。
Bubbleデータベース設計で最初に決めること
Bubble公式Docsのデータベース解説では、BubbleのデータベースはData type、Field、Thing、List、Privacy ruleなどの考え方で説明されています。一般的な表計算ソフトのように画面項目を一つに詰め込むのではなく、「もの」「イベント」「固定マスタ」「権限単位」を分けると保守しやすくなります。
| 決める項目 | 例 | 失敗しやすい設計 |
|---|---|---|
| 管理するもの | User、Company、Project、Order | すべてをUserに持たせる |
| 発生するイベント | Reservation、Payment、Message | 履歴をテキストで追記する |
| 固定マスタ | Status、Category、Plan | 毎回自由入力にする |
| 権限単位 | owner、member、admin | 表示条件だけで隠す |
重要なのは、データを「一覧で探すもの」「1件の詳細を見るもの」「履歴として積み上がるもの」に分けることです。注文履歴はOrderを独立したData typeにし、UserやProductを参照すると扱いやすくなります。
最初の設計段階では、画面上の入力フォームから考えるより、業務で発生する名詞から候補を洗い出すほうが漏れを減らせます。顧客、予約、請求、メッセージ、承認履歴のように、1件ずつ区別して管理したいものはData type候補になります。
データ型・フィールド・リストの設計
Bubble公式DocsのData types and fieldsでは、Data typeは情報を入れるコンテナ、Fieldは保存項目として説明されています。Bubbleでは、text、number、date、image、file、yes/no、User、カスタムData typeなどをFieldとして持てます。
複数の値を保存したい場合はlist fieldも使えます。ただし、何でもlistにすると検索、並べ替え、権限管理が難しくなります。リストは少量のタグや選択肢、参照は履歴や明細に使うと決めておくと判断しやすくなります。
| 用途 | 推奨設計 | 理由 |
|---|---|---|
| 商品カテゴリ | Option setまたはCategory type | 入力ミスを防ぎやすい |
| 注文明細 | OrderItem type | 数量、単価、状態を持てる |
| お気に入り | Favorite typeまたはUserのlist | 件数と検索条件で判断できる |
| 住所 | Address type | 複数住所や配送先に対応しやすい |
公式のData tabでは、Data types、Privacy、App dataをData tabで扱うことが示されています。developmentとliveのデータベースは分かれるため、テストデータと本番データを混同しない運用も必要です。
また、2026年9月時点ではBubble AIでdata typesを生成できますが、Generate data types from the Data tabには制限があります。Data tab上の生成機能は新しいData type、Field、Privacy Rulesの作成に使えますが、既存Data typeへの追加や既存Privacy Rulesの編集は対象外です。20 data typesまで、プロンプト400文字までという制限もあるため、AI生成は初期案づくりに使い、業務ルールと権限は人が確認します。
Privacy RulesとData APIの注意点
Bubbleのセキュリティは、画面上で要素を非表示にするだけでは不十分です。Protecting data with privacy rulesでは、Privacy Rulesによりフィールド表示、検索可否、アップロードファイル表示、auto-bindingの変更可否を制御できることが説明されています。個人情報や社内情報を扱うData typeは、作成時点でPrivacy Rulesを設計するべきです。
| 対象データ | 見直す権限 | 注意点 |
|---|---|---|
| User | 本人、管理者、担当者 | Current Userの情報は特に慎重に扱う |
| Project | 所有者、参加者 | Searchで見える範囲を決める |
| File | 閲覧者、アップロード者 | private file設定も確認する |
| API公開データ | 認証済みユーザー、管理者 | API tokenの扱いを分ける |
Data API Privacy Rulesでは、Data APIへのアクセスもPrivacy Rulesの影響を受ける一方、Bubble API tokenで管理者として認証する場合はPrivacy Rulesが無視されると説明されています。外部連携では、ユーザー認証で見せるデータと管理者トークンで扱うデータを分けます。
もう一つの落とし穴は、削除したFieldのデータです。公式Docsでは、Fieldを削除しても保存済みデータが自動削除されるわけではないとされています。不要なFieldを消す前に、機微情報を空にし、Privacy RulesとAPIレスポンスをテストします。
料金・パフォーマンス・運用チェック（2026年9月確認）
Bubble Pricingを2026年9月3日に確認したところ、Web & Mobileの年払い表示ではFree、Starter、Growth、Team、Enterpriseが示されています。プラン別の選び方はBubble 料金プランを徹底比較でも整理していますが、見積時は必ず公式ページを再確認してください。
| プラン | 公式価格 | workload units | server logs | 主な位置づけ |
|---|---|---|---|---|
| — | —: | —: | —: | — |
| Free | $0/月 | 50K WU/月 | 6時間 | 開発中のプロジェクト |
| Starter | $59/月、年払い表示 | 175K WU/月 | 2日 | 公開準備ができたプロジェクト |
| Growth | $209/月、年払い表示 | 250K WU/月 | 14日 | チーム開発・共同作業 |
| Team | $549/月、年払い表示 | 500K WU/月 | 20日 | チームと事業の拡張 |
| Enterprise | 要問い合わせ | カスタム | カスタム | セキュリティ・規模要件が大きい組織 |
上記はBubble公式PricingのWeb & Mobile、年払い表示、米ドル建ての確認結果です。税金、為替、請求条件、追加workload、ファイルストレージ、プラグイン費用は利用条件によって変わります。初期費用や最小契約ユーザー数は、導入時に契約画面またはBubble側の案内で確認します。
料金だけで判断すると、公開後にworkload unitsやログ保持期間が不足することがあります。BubbleのPricingでは、workloadはアプリのhosting、実行、スケールに必要なサーバーリソースをまとめた指標として説明されています。検索、workflow、API、画像処理が増えるアプリでは、公開前に想定利用量を見積もることが重要です。
支援時に確認する設計例
nocoderiでBubbleアプリの設計を支援するときは、画面を作る前に「誰が、何を、いつ、どの権限で扱うか」を確認します。たとえば社内申請アプリなら、User、Department、Request、Approval、Attachmentを分けます。
ECや予約のように履歴が増えるアプリでは、OrderやReservationをUserのFieldにまとめすぎないことが重要です。履歴を独立したData typeとして持たせると、検索条件、集計、CSV出力を扱いやすくなります。
一方で、ノーコードでも設計判断を避けられるわけではありません。公開後のデータ移行や権限修正は負荷が高くなります。MVPでは必要なData typeとPrivacy Rulesを絞って設計し、テストしながら拡張する方法が現実的です。 nocoderiでは、Bubbleアプリの要件整理、データ型設計、Privacy Rules、API連携、管理画面、公開後の改善まで支援できます。
まとめ
Bubbleのデータベース設計は、アプリの使いやすさ、速度、セキュリティ、運用コストを左右します。初心者ほど、画面から作り始める前に、管理するData type、Field、list、reference、Option setを整理することが重要です。最初に「もの」「イベント」「固定マスタ」「権限単位」を分けるだけでも、後から機能を追加しやすくなります。
2026年9月時点では、Bubble公式DocsでData tab、Data types and fields、Privacy Rules、Data API、AI生成の仕様を確認しながら設計する必要があります。特にPrivacy Rulesは、画面の表示/非表示とは別の重要な防御線です。個人情報、社内情報、ファイル、API公開データを扱う場合は、開発初期から権限と検索可否を確認します。
料金面では、Free/Starter/Growth/Teamの価格だけでなく、workload units、ログ保持期間、共同編集者数、Web/Mobileの扱いも見ます。開発中は問題なく動いていても、公開後に検索回数やAPI連携が増えると負荷が変わります。公式価格ページを確認し、公開前に想定利用量を見積もることが大切です。
Bubbleのデータベース設計に不安がある場合は、最初からすべてを作り込むより、MVPに必要なData typeとPrivacy Rulesを絞って設計し、テストしながら拡張する方法が現実的です。nocoderiでは、ノーコード/Bubble開発の初期設計、既存アプリのデータ構造見直し、API連携、運用改善まで相談できます。
費用の目安：生成AI×ノーコードで進む業務システム開発｜費用・期間・失敗回避の型を公開
関連する開発事例：企業情報管理システム
群別サービス：受託開発
