Bubble データベース設計入門【2026年版】データ型・Privacy Rules・料金確認

はじめに

Bubbleは、画面、ワークフロー、データベースを同じエディタ上で作れるノーコード開発ツールです。コードを書かずにアプリを作れる一方で、データベース設計を曖昧にしたまま作り始めると、後から画面表示が遅くなる、権限管理が複雑になる、同じ情報が複数の場所に保存されるといった問題が起きます。

Bubble データベース設計で最初に考えるべきことは、どのデータ型を作るかではなく、アプリ内で何を管理し、誰がどの情報を見て、どのタイミングで更新するのかです。たとえば予約アプリなら、User、Reservation、Service、Paymentを分ける必要があります。ECアプリなら、Product、Cart、CartItem、Orderを分けるほうが運用しやすくなります。

2026年時点では、Bubbleの料金はworkload unitsやWeb/Mobileプランの考え方を含めて確認する必要があります。また、Data tab、Privacy Rules、Data API、AIによるdata types生成など、初心者が見落としやすい機能も増えています。この記事では、公式情報をもとに、Bubbleで失敗しにくいデータベース設計の手順を整理します。

最初の設計が整っていれば、あとから検索、CSVインポート、API連携、権限管理、管理画面を追加するときも大きく崩れません。逆に、初期設計を急ぎすぎると、公開後に作り直す範囲が広がります。小さく作る場合でも、データ型とPrivacy Rulesだけは先に確認しておくことが重要です。

Bubbleデータベース設計で最初に決めること

Bubbleのデータベースは、Data typeとFieldで構成します。Bubble DocsのData types and fieldsでは、Data typeは情報を入れるコンテナ、Fieldは保存項目として説明されています。画面項目を一つに詰め込まず、「もの」と「イベント」を分けるほうが保守しやすくなります。

決める項目	例	失敗しやすい設計
管理するもの	User、Company、Project、Order	すべてをUserに持たせる
発生するイベント	Reservation、Payment、Message	履歴をテキストで追記する
固定マスタ	Status、Category、Plan	毎回自由入力にする
権限単位	owner、member、admin	表示条件だけで隠す

重要なのは、データを「一覧で探すもの」「1件の詳細を見るもの」「履歴として積み上がるもの」に分けることです。注文履歴はOrderを独立したData typeにし、UserやProductを参照すると、注文日、支払い状態、配送状態を扱いやすくなります。

データ型・フィールド・リストの設計

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年時点ではBubble AIでdata typesを生成できますが、Generate data types from the Data tabには、既存Data typeへの追加や既存Privacy Rulesの編集は対象外という制限があります。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が無視されると説明されています。外部連携では、ユーザー認証で見せるデータと管理者トークンで扱うデータを分けます。API連携の実装手順はアプリ開発 API連携の基本と実践も参考になります。

もう一つの落とし穴は、削除したFieldのデータです。公式Docsでは、Fieldを削除しても保存済みデータが自動削除されるわけではないとされています。不要なFieldを消す前に、機微情報を空にし、Privacy RulesとAPIレスポンスをテストします。

料金・パフォーマンス・運用チェック

Bubbleの現行料金は、Bubble Pricingで確認します。2026年8月時点の公式ページでは、Free、Starter、Growth、Teamが示され、workload units、サーバーログ保持期間、アプリ編集者数、Web/Mobile対応がプラン差になります。見積時は必ず公式価格ページを確認します。

観点	確認内容	設計への影響
workload units	検索、workflow、API、画像処理	重い検索や一括処理を見直す
server logs	Free 6時間、Starter 2日、Growth 14日、Team 20日	障害調査やデバッグ方針に影響
editor数	共同編集者数	開発体制に合わせる
Web/Mobile	同じbackend/databaseを共有	モバイル公開時の設計を先に確認

パフォーマンス面では、Repeating Groupで大量データを一度に表示しない、検索条件を絞る、必要なFieldだけを表示する、履歴データを明細Data typeへ分けることが基本です。デバッグ時はBubble デバッグガイドのように、Debugger、server logs、Privacy Rulesを組み合わせて確認します。

デメリットは、ノーコードでも設計判断を避けられないことです。作りながら直せる反面、公開後のデータ移行や権限修正は負荷が高くなります。nocoderiでは、Bubbleアプリの要件整理、データ型設計、Privacy Rules、API連携、管理画面、公開後の改善まで支援できます。

まとめ

Bubbleのデータベース設計は、アプリの使いやすさ、速度、セキュリティ、運用コストを左右します。初心者ほど、画面から作り始める前に、管理するData type、Field、list、reference、Option setを整理することが重要です。最初に「もの」「イベント」「固定マスタ」「権限単位」を分けるだけでも、後から機能を追加しやすくなります。

2026年時点では、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連携、運用改善まで相談できます。