Bubbleのセキュリティは大丈夫？開発前に知っておきたい対策と、開発会社に相談すること【2026年版】

Bubbleを使うかどうかは、扱うデータや自社のセキュリティ要件、開発・運用体制を照らして判断する必要があります。Bubble本体の安全対策に加えて、作ったアプリの設定と確認も必要です。この記事では、専門知識がない発注者でも、開発会社に何を確認し、何を受け取ればよいかを整理します。

まず Bubble のセキュリティの基本を押さえ、作りたいシステムによって対策がどう変わるか、開発時に確認したい3つの対策、開発会社に相談するときに伝えることの順に解説します。要件が固まっていなくても、相談できる状態になることがゴールです。ノーコード全般のセキュリティの基本は、「ノーコード セキュリティの基本と実践」で解説しています。

Bubble の土台は Bubble が守りますが、「誰が何を見られるか」は作るときに決める設定です。作りたいシステムが決まったら、この設定をどうするかを開発会社と一緒に考えてください！

※本記事の設定名・プランの条件・規約の内容は、2026年10月8日時点の Bubble の公式マニュアル・公式サイト・利用規約と、公的機関の資料にもとづきます。設定名や条件は変わることがあるため、確認の前に公式ページで確かめてください。

Bubbleのセキュリティは大丈夫？まず知っておきたい基本

Bubble のセキュリティは、土台を AWS と Bubble が守り、アプリの中で「誰が何を見られるか」を作る側が設定する分担です。Bubble の公式マニュアルも、この分担を責任の分け方として書いています。つまり「Bubble は安全か」という問いの答えは、「土台は守られている。アプリの中は、作り方しだい」です。

Bubble本体が守っていること

Bubble の公式サイトとマニュアルには、次の対策が書かれています。

• 外部の監査法人による SOC 2 Type II の監査（対象はセキュリティ）
• AWS の上で運用し、通信は TLS、保存したデータは AES-256 で暗号化
• 利用者のパスワードは、元に戻せない形にして保存（ハッシュ化・ソルト）
• 大量のアクセスでアプリを止める攻撃（DDoS）を、Cloudflare と自社の仕組みで防ぐ
• 年1回以上の侵入テストと、OWASP Top 10 を含む自動テスト・常時監視
• データを過去の時点に戻す仕組み（時点復元）

SOC 2 Type II とは？
米国の会計士協会（AICPA）の基準で、セキュリティの管理が一定の期間きちんと運用されていたかを、外部の監査法人が確かめた報告書のことです。Bubble の報告書の対象は Bubble 本体で、Bubble で作った個々のアプリではありません。

アプリごとに、作るときに決めること

Bubble のマニュアルは、利用者のブラウザに届いたデータは、画面に出していなくても、その利用者から見えると説明しています。画面の表示で隠しても守りにはならず、データ側で「誰に届けるか」を決める設定（プライバシールール）が必要です。ほかにも、外部からデータを読み書きする入口（API）をどこまで開けるか、外部サービスの鍵をどこに置くか、作りかけのテスト版を誰が見られるかは、アプリごとに決めます。

これらは Bubble が自動で決めてくれるものではなく、作る人が「このアプリでは誰が何を扱うか」を考えて設定するものです。だから、自社で Bubble を使えるかは、用途と構成を確かめて判断します。次の章で、作りたいシステムごとに見ていきます。

プライバシールールとは？
Bubble で、データの種類ごとに「誰が、どの項目を見られるか・検索できるか」を決める設定のことです。ブラウザへ届ける前にサーバー側で効くので、画面で隠すのとは違い、届かないデータは見られません。

作りたいシステムによって、必要な対策は変わる

必要な対策は、「誰の、何の情報を、誰が扱うか」で決まります。たとえば社内だけで使う顧客管理と、会員同士が情報を見合うサービスでは、決めることが違います。自社に近い例を見つけてください。

どの例でも、設計の中心は「誰が何を見られるか・変えられるか」の表です。この表は、開発会社と一緒に作れます。外部サービスと役割を分ける構成（決済や大きなデータを別のサービスに持たせるなど）も検討できますが、それだけで Bubble 側の設定が不要になるわけではありません。

追加で確認する条件

次に当てはまる場合は、相談のときに伝えてください。確認することが増えます。

• 扱うデータに制限がある：Bubble のデータ処理の取り決め（DPA）は、政府が発行する識別番号、生体情報、カード情報、16歳未満の子どもの個人データなどを、Bubble に処理させないよう求めています。当てはまるか迷うデータは、規約を確かめたうえで専門家に相談します。
• 保存場所に条件がある：Enterprise 以外のプランのデータは米国（AWS のオレゴン）に保存され、場所は変えられません。Enterprise の専用環境なら東京・大阪も選べます。個人情報保護法では、外国のクラウドを使うときも、その国の制度を把握して安全管理の措置をとり、事業者とサーバーのある国などを本人が知り得る状態にする必要があります。
• 取引先から条件を求められる：セキュリティチェックシートや監査資料（SOC 2 Type II の報告書など）を求められるなら、発注前に開発会社へ渡します。Bubble の資料で答えられる所と、自社のアプリの設定として答える所を分けて準備できます。

条件によっては、構成の変更や Bubble 以外の選択肢が必要になります。自社の場合に採用できるかも含めて、開発会社に相談できます。条件が整理できていない段階でも問題ありません。

Bubbleで作りたいシステムについて、相談してみませんか？
「顧客情報を扱いたい」「会員ごとに見られる情報を分けたい」「決済機能を付けたい」など、実現したいことをお聞かせください。Opt.devでは、作りたい業務・利用者・扱う情報をもとに、Bubbleの適性や、開発時に必要な設計・確認事項を一緒に整理します。要件が固まっていない段階でもご相談いただけます。

無料で相談してみる

開発時に確認したい3つのセキュリティ対策

開発を進めるときに確認したい対策は、①データの閲覧・操作の権限 ②公開前の検査 ③公開後の管理、の3つです。どれも開発会社が行う作業ですが、発注する側が「やってほしい」と伝え、結果を受け取ることで、実施内容と未解決の課題を確認できます。

1. データの閲覧・操作の権限

前の章の「誰が何を見られるか・変えられるか」の表をもとに、データの閲覧範囲（プライバシールール）と、作成・変更・削除を実行できる条件を設定します。ここが抜けると、画面が正常に見えていても情報が届いてしまいます。当社が検証用に作ったアプリ（架空のデータだけを入れたもの）で、その差を確かめました。顧客3人分のデータ（氏名・メール・電話番号・社内メモ）を入れ、画面には氏名だけを表示しています。

ログインしていない状態で、ブラウザに届いたデータを開発者ツールで見ると、次のようになっていました（2026年10月8日に確認）。

画面の見た目はどちらも同じで、変わったのは届くデータです。ルールがないと、画面に出していない項目まで、ログインしていない人のブラウザに3人分すべて届いていました。見られる情報だけでなく、変えられる操作（他人のデータの変更）も同じ表で決め、実行できる条件として設定します。

2. 公開前の検査

設定したとおりになっているかを、公開前に確かめます。発注する側ができるのは、シークレットウィンドウで会員ページを開いて中身が見えないことと、一般の利用者のアカウントで管理者向けの情報が見えないことの確認です。開発会社には、その利用者に閲覧を許可していないデータがブラウザに届いていないこと、他人のデータを変更できないこと、外部からの入口（API）のうち公開しているものの一覧を出してもらいます。Bubble 公式の自動チェック（Security dashboard。Starter プラン以上）の結果も、使えるプランなら受け取ります。

納品のときに受け取るものは、次の3つにまとまります。

• 権限の設計表：データの種類ごとに、誰が何を閲覧・作成・変更・削除できるか
• 設定・検査の結果：プライバシールール、API の公開範囲、ファイルの公開範囲、テスト版の保護について確認した結果と、未解決の問題
• 運用の引き継ぎ資料：アカウントの名義、共同編集者の一覧、外部サービスの鍵の管理場所、バックアップと戻し方、事故のときの連絡先

Security dashboard とは？
Bubble 公式の自動チェック機能のことです。プライバシールールの漏れ、公開されたままの API、ブラウザから見える鍵、保護されていないテスト版などを見つけ、高・中・低で指摘します。Starter プラン以上で使え、「この人にこのデータを見せてよいか」までは判定できません。

社内で AI ツールを使ってアプリを作り、公開前に自分で確かめたい場合の手順は、「バイブコーディングのセキュリティ対策」で解説しています。

3. 公開後の管理

公開後も、担当者や開発会社が替わったとき、機能を足したとき、AI で変更したときに、権限と設定を見直します。アプリの持ち主（オーナー）と外部サービスの契約は自社の名義にし、共同編集者は必要な人だけにします。外部サービスの鍵の一覧と作り直す手順、バックアップから戻せる期間（プランで異なります）も、引き継ぎ資料で受け取ります。

契約での責任の分担、事故が起きたときの連絡先と動き方も、開発の段階で決めておくことです。外注しても、利用者や国への対応の責任はアプリを運営する会社に残ると、総務省のガイドラインと個人情報保護法の考え方が示しています。漏えいが起きたときの報告の決まりは、個人情報保護委員会の資料で確かめられます。

開発会社に相談するとき、何を伝えればよい？

相談のときに伝えることは、作りたい業務、使う人、扱う情報、取引先から求められる条件の4つです。すべてが決まっている必要はありません。決まっていないことも、相談の対象です。

相談の中で、開発会社の答え方からも分かることがあります。「誰が何を見られるか」の表を作って納品に含めるか、公開前にどんな検査をして結果をどう渡すか、公開後の見直しをどこまで担当するか、を聞いてみてください。回答の具体性は、依頼先を判断する材料になります。実施する検査と納品する資料は、見積もりや契約でも確認しましょう。Bubble の開発会社の選び方は、「Bubble開発会社おすすめ10社比較」で解説しています。

Bubbleで作りたいシステムは、Opt.devにご相談ください

Opt.dev は、Bubble でのシステム開発を行っている会社です。代表は Bubble の公式アンバサダー（2025年〜）で、この記事のように公式の資料と自分たちの検証をもとに情報を発信しています。相談では、前の章の4つを伺い、次のことを一緒に整理します。

開発をお任せいただく場合は、権限の設計表を設計の段階で確定し、公開前の検査の結果と運用の引き継ぎ資料を納品に含めます。公開後の見直しも、ご希望に応じて保守として承ります。Bubble の開発の流れと費用の目安は「Bubble開発とは」、料金プランは「Bubbleの料金プラン完全ガイド」で解説しています。

本記事の情報は2026年10月8日時点のものです。Bubble の設定名・プランの条件・規約は変わることがあるため、確認の前に公式ページで確かめてください。

Bubbleで作りたいシステムについて、相談してみませんか？
「顧客情報を扱いたい」「会員ごとに見られる情報を分けたい」「決済機能を付けたい」など、実現したいことをお聞かせください。Opt.devでは、作りたい業務・利用者・扱う情報をもとに、Bubbleの適性や、開発時に必要な設計・確認事項を一緒に整理します。要件が固まっていない段階でもご相談いただけます。

無料で相談してみる

引用元

• Bubble（責任分担・本体の対策）：Security ／ Security（bubble.io） ／ SOC 2 Type II ／ How is Bubble hosted? ／ Dedicated instance
• Bubble（設定・点検）：Client-side and server-side ／ Protecting data with privacy rules ／ Planning app security ／ Security checklist ／ Collaborators ／ Security dashboard plan features
• Bubble（規約・料金）：利用規約 ／ DPA ／ Pricing ／ 公式ブログ「How to Answer a Vendor Security Questionnaire」
• 公的機関：総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」概要 ／ 個人情報保護委員会「漏えい等の対応とお役立ち資料」 ／ 個人情報保護委員会 Q&A（Q10-25・Q12-3）