Bubbleでマルチテナントアプリを作る方法：テナント分離から実装まで完全ガイド

2025年6月27日

はじめに：マルチテナントアプリの重要性とBubbleでの実現可能性

近年、SaaSビジネスモデルの普及により、マルチテナントアプリケーションの需要が急速に高まっています。特にノーコード開発においても、複数の企業や組織が同じアプリケーションを安全に利用できる仕組みが求められています。

本記事では、人気ノーコードツール「Bubble」を使用して、セキュアで効率的なマルチテナントアプリを構築する方法を、実践的なノウハウと共に詳しく解説します。

この記事で学べること

マルチテナントアーキテクチャの基本概念
Bubbleでのテナント分離の実装方法
Privacy Rulesを活用したデータ保護
パフォーマンスを考慮した設計パターン
実装時の注意点とベストプラクティス

1. マルチテナントアプリとは？基本概念の理解

マルチテナントの定義

マルチテナントアプリケーションとは、単一のアプリケーションインスタンスで複数の顧客（テナント）にサービスを提供するアーキテクチャパターンです。各テナントのデータは論理的に分離され、互いに干渉することなく同じシステムを利用できます。

マルチテナントの3つのモデル

モデル	特徴	Bubbleでの実現性
サイロモデル	テナントごとに独立したデータベース	△（複数アプリが必要）
ブリッジモデル	スキーマレベルでの分離	✕（Bubbleでは非対応）
プールモデル	同一テーブル内での論理分離	◎（推奨方式）

Bubbleでは、プールモデルが最も実装しやすく、効率的です。本記事では、このモデルを前提に解説を進めます。

2. Bubbleでマルチテナントアプリを設計する前の重要な考慮点

なぜ設計段階での検討が重要か

はじめからPrivacyルールの設定を想定した上でデータベースの設計をする必要があります。後からの変更は、データ構造の大幅な見直しを必要とする可能性があり、開発コストが増大します。

Bubbleの制約事項

パフォーマンスの考慮
- 複雑なデータベース結合は処理速度に影響
- 大量データの扱いには工夫が必要
スケーラビリティの限界
- データベース容量の上限（最大50GB）
- 同時接続数の制限
セキュリティ設定の重要性
- 国内外多くのBubbleアプリで、不適切な設定のため、個人情報が漏洩しています。

3. データベース設計：テナント分離の実装方法

基本的なデータ構造

マルチテナントアプリの核となるのは、適切なデータ構造です。以下に、推奨される基本構造を示します。

1. Tenantテーブルの作成

Data Type: Tenant
Fields:
- name (text): テナント名
- subdomain (text): サブドメイン名
- plan (option set): 料金プラン
- created_date (date): 作成日
- is_active (yes/no): アクティブ状態
- admin_users (list of Users): 管理者ユーザーリスト

2. Userテーブルの拡張

Data Type: User (既存)
Additional Fields:
- tenant (Tenant): 所属テナント
- role (option set): ユーザー権限
- is_tenant_admin (yes/no): テナント管理者フラグ

3. 各業務データテーブル

すべての業務データテーブルには、必ずtenantフィールドを追加します。

Data Type: Project（例）
Fields:
- name (text): プロジェクト名
- tenant (Tenant): 所属テナント ← 必須
- created_by (User): 作成者
- ...その他のフィールド

リレーションシップの設計パターン

編集部の実装経験から

LIFキャリア編集部では、複数のマルチテナントアプリを開発した経験から、以下のパターンを推奨しています：

すべてのデータにテナント参照を持たせる
- データの取得時に必ずテナントフィルタを適用
- Privacy Rulesでの二重チェック
階層構造の明確化
- Tenant → User → 各種データという階層を維持
- 横断的なデータアクセスを防ぐ

4. Privacy Rulesによるセキュアな実装

Privacy Rulesの基本設定

Bubbleでは、プライバシーロールを設定するまで、基本的に作成されたデータは誰でも参照することができてしまいます。そのため、Privacy Rulesの設定は必須です。

Tenantデータタイプのプライバシー設定

Data → Privacyタブを開く
Tenantを選択し、「Define a new rule」をクリック
以下のルールを設定：

Rule Name: Tenant Members Only
When: Current User's tenant is This Tenant
設定項目:
✓ View all fields
✓ Find this in searches
✓ View attached files

業務データのプライバシー設定

各業務データ（Project、Task等）にも同様の設定を行います：

Rule Name: Same Tenant Only
When: Current User's tenant is This Project's tenant
設定項目:
✓ View all fields
✓ Find this in searches
✓ Allow auto-binding（必要に応じて）

役割ベースのアクセス制御（RBAC）

より細かな権限制御が必要な場合は、ユーザーの役割に応じたルールを追加します。

Option Setsでの役割定義

Option Set: UserRole
Options:
- admin（管理者）
- editor（編集者）
- viewer（閲覧者）

役割別のPrivacy Rules

Rule Name: Admin Access
When: Current User's role is admin AND Current User's tenant is This Data's tenant
設定項目:
✓ すべての項目にチェック

Rule Name: Editor Access
When: Current User's role is editor AND Current User's tenant is This Data's tenant
設定項目:
✓ View all fields
✓ Find this in searches
✓ Make changes to this（特定フィールドのみ）

5. 実装手順：ステップバイステップガイド

Step 1: 初期設定とOption Setsの作成

新規アプリケーションの作成
- 「Create a new app」から開始
- 適切な名前を設定（例：multi-tenant-saas）
Option Setsの定義
- UserRole（admin, editor, viewer）
- TenantPlan（free, basic, premium）
- その他必要な選択肢

Step 2: データ構造の構築

Tenantテーブルの作成 Data → New Type → "Tenant"
Userテーブルの拡張
- tenantフィールドの追加
- roleフィールドの追加
業務データテーブルの作成
- 必ずtenantフィールドを含める

Step 3: サインアップフローの実装

テナント作成を含むサインアップフローの実装例：

サインアップページの作成
- 会社名入力フィールド
- ユーザー情報入力フィールド
Workflowの設定 When Button Sign up is clicked: 1. Create a new Tenant - name = Input Company Name's value - plan = free 2. Sign the user up - email = Input Email's value - password = Input Password's value 3. Make changes to Current User - tenant = Result of step 1 - role = admin - is_tenant_admin = yes

Step 4: データ表示の実装

Repeating Groupでのテナントフィルタリング

Type of content: Project
Data source: Search for Projects
Constraints:
- tenant = Current User's tenant

編集部のTips

検索処理では、必ず最初の制約条件としてテナントフィルタを設定することで、パフォーマンスを最適化できます。

Step 5: Privacy Rulesの適用

各Data Typeに対してPrivacy Rulesを設定
Data APIの無効化（必要に応じて） Settings → API → Enable Data APIのチェックを外す

6. 実装時の注意点とベストプラクティス

セキュリティのベストプラクティス

二重のセキュリティ層
- UIレベルでの制約（Constraints）
- データベースレベルでの保護（Privacy Rules）
定期的な監査
- Privacy Rulesの設定確認
- Data APIの公開設定確認
テスト環境での検証
- 異なるテナントのユーザーでテスト
- Run as機能を活用した動作確認

パフォーマンス最適化のテクニック

1. 検索の最適化

良い例：
Search for Projects:
- tenant = Current User's tenant ← 最初に配置
- status = active
- created date > Current date/time - days: 30

悪い例：
Search for Projects:
- created date > Current date/time - days: 30
- status = active
- tenant = Current User's tenant ← 最後だと非効率

2. データ取得の工夫

必要なデータのみを取得
ページネーションの活用
キャッシュの利用（Custom States）

編集部の体験談：よくある落とし穴

LIFキャリア編集部でマルチテナントアプリを開発した際、以下の点で苦労しました：

Privacy Rules設定忘れ
- 新しいData Typeを追加するたびに設定が必要
- チェックリストの作成を推奨
テナント間のデータ混在
- Workflowでtenantフィールドの設定忘れ
- デフォルト値の設定で回避可能
パフォーマンスの劣化
- 大量データでの検索速度低下
- インデックスとなるフィールドの適切な設計が重要

7. 高度な実装パターン

サブドメインによるテナント識別

各テナントに独自のサブドメインを提供する実装：

URLパラメータの活用 app.example.com?tenant=tenant-name
Page loadでのテナント識別 When Page is loaded: - Get data from page URL (parameter: tenant) - Search for Tenants (subdomain = URL parameter) - Set custom state: current_tenant