Bubbleのセキュリティは大丈夫？発注者向けチェックリストと実装の要点【2026年】

執筆：Swooo編集部／監修：北浦 聡大（Bubble公式認定デベロッパー・国内初合格／Swooo共同創業者・元CTO）

「Bubbleでシステムを作りたいが、ノーコードのセキュリティは本当に大丈夫なのか」。
Bubble開発の外注を検討する情報システム部門やDX推進担当の方から、最も多くいただく質問のひとつです。

結論を先に言うと、Bubbleというプラットフォーム自体の基盤は堅牢です。リスクが集中するのは「実装」、とくにPrivacy Rules（プライバシールール）をはじめとする設定の品質です。
この記事では、Bubbleのセキュリティに関するよくある不安に答えたうえで、開発者が押さえるべき設定と、発注者が自分の目で確認できるチェックリストまでを解説します。監修は、Bubble公式の開発者認定試験に国内で初めて合格した北浦が担当しています。

まず、よくある不安と実際のところを一覧にまとめます。

「ノーコードだからセキュリティが不安」は正しいのか

Bubbleは、データベース・ワークフロー・UIをブラウザ上で構築できるノーコード開発プラットフォームです（基本機能の全体像はBubbleとは何かを解説した記事を参照してください）。公式発表によると2025年の1年間だけで720万件のアプリが作成され、Bubble上のアプリを通じた取引額は10億ドルを超えています。決済や個人情報を扱う商用サービスが大量に動いているプラットフォームだ、というのがまず前提になります。

基盤の安全性について、BubbleはSOC 2 Type IIに準拠していることを公表しています。
また、アプリケーションが動くインフラはAWS上にあり、AWSはISO 27001をはじめとする多数の第三者認証を取得しています。サーバーの物理的な管理、OSやミドルウェアの脆弱性対応、通信の暗号化といった層は、Bubbleとその基盤事業者が継続的に管理している領域です。
ただし2つの限定条件があります。SOC 2 Type IIの対象範囲は5つの信頼原則のうち「セキュリティ」であること、そして監査レポート自体の開示はEnterpriseプラン契約者向けの位置づけであることです。社内審査で監査書類の提出が必要な場合は、開示可否を個別に確認してください。

では何が問題になり得るのか。答えは「その上に作られるアプリの実装」です。
これはクラウドサービス全般でいう責任共有モデルと同じ構図で、基盤はプラットフォームが守り、アプリ内のデータアクセス制御は開発者が設計する、という分担になっています。スクラッチ開発でも権限制御のバグはアプリ側の責任であるのと同様に、Bubbleでもデータを誰に見せるかの設計は開発者の仕事です。

開発者が設計する領域を具体的に挙げると、①Privacy Rulesによるデータアクセス制御、②ページやワークフローの権限判定、③APIの公開範囲とトークン管理、④「公開情報になる名前や構造」に機密を置かない運用、の4つです。
逆に言えば、この4領域の品質さえ担保できれば、Bubbleは商用サービスの基盤として安心して使えます。本記事の以降の章は、この4領域を順に掘り下げていく構成です。

つまり「Bubbleだから危険」は誤解であり、正確には「Bubbleでも、実装が甘ければ危険」です。そして実装リスクの大半は、次に説明するPrivacy Rulesに集約されます。

Privacy Rulesがすべての土台——「届いたデータは公開済み」と考える

Privacy Rulesは、データベースの各レコードを「誰が読めるか・検索できるか」をサーバー側で制御するBubbleの仕組みです。
ここを設定しないと、画面に表示していないデータでも、検索やAPI経由で外部から読み取れる状態になり得ます。Bubbleセキュリティの議論は、突き詰めればほぼこの一点に帰着します。

deny-by-default：全拒否から始めて必要な分だけ開ける

安全な設計の基本は「まず全員に対して閉じ、業務上必要なアクセスだけを個別に許可する」という考え方です。deny-by-default（デフォルト拒否）と呼ばれます。
非公開にすべきData typeには、少なくとも「ログアウトユーザー」「管理者」「作成者」「特定ロール」それぞれに対するルールを定義し、検索を許可する”Find this in searches”は本当に必要な場合だけ有効にします。逆に「まず全部見える状態で作り、あとで閉じる」進め方は、閉じ忘れがそのまま漏えいポイントになります。

厄介なのは、Privacy Rulesに設定漏れがあってもアプリは一見正常に動くことです。画面表示も検索も期待どおりに見えるため、通常の動作テストでは発見できません。
設定画面の確認に加えて、実際にクライアントへ届くデータの中身まで検証する専用の工程が必要になるのはこのためです。

クライアントに届いたデータは「公開済み」である

もうひとつの大原則が「ブラウザに送られたデータは、すでに公開されたものと考える」です。
ポップアップの背後に隠す、要素を非表示にする、といった画面上の制御は、ブラウザの開発者ツールを開けば誰でも突破できます。見えていないだけで、データ自体はユーザーの手元に届いているからです。

たとえば有料会員かどうかの判定を考えます。

• 安全な例：Search for Subscription:first item's Status is 'Valid' — 判定のたびにサーバー側でデータベースを参照して評価する
• 危険な例：var - subscription's Status is 'Valid' — ページに読み込み済みのクライアント側変数を参照しており、開発者ツールで書き換え可能

同じ理由で、未課金ユーザーに全画面ポップアップをかぶせて操作を止める、いわゆるpaywallポップアップは実装として成立しません。Escキーで閉じられない設定にしても、検証ツールで要素ごと消せるためです。
ページ単位の保護は、「Page is loaded」イベントにサーバー側の条件を付けた「Go to page」アクションを1つ置いてリダイレクトする、という形が安全な定石です。重要な判定は必ずサーバー側の条件で行う——これがPrivacy Rulesと並ぶBubbleセキュリティの背骨です。

見落とされがちな仕様——Option set名やData type名は誰でも見られる

ここからは、経験のある開発者でも見落としがちな仕様の話です。発注者の方も「こういう落とし穴があるのか」という解像度で読んでいただく価値があります。

Bubbleでは、次の情報がアプリの構成情報としてブラウザに配信されており、閲覧者が誰でも確認できます。Privacy Rulesの保護対象外です。

• Option setの名前と、そこに登録された全データ：Option setは選択肢マスタとして便利ですが、中身はすべて公開情報です。取引先の一覧や社内の管理用情報をOption setに入れると、そのまま外部から見えます
• Data typeの名前・フィールド名・デフォルト値：レコードの中身はPrivacy Rulesで守れますが、テーブル構造そのものは見えます。フィールドのデフォルト値に仮のAPIキーや社内メモを入れておく、といった運用は漏えいに直結します
• ページ名：非公開の管理画面でも、ページ名は推測の手がかりになります。「admin」のような分かりやすい名前は避け、アクセス制御はページ名の隠蔽ではなくサーバー側の権限判定で行います

さらに注意したいのが「削除したつもりの残骸」です。
開発中に作って消したOption setやData typeは、Settingsにある「Optimize application」を実行するまでアプリ内部に残り続けます。命名や中身に問題があるものを消した場合も、Optimizeまで実行して初めて完全に消えます。納品前の必須工程です。

これはBubbleの欠陥というより、画面や検索をブラウザ側で組み立てるために構成情報が配信される、という仕組み上の仕様です。仕様として知っていれば設計段階で完全に回避できますが、知らずに作ってしまうと後から防ぐ手段がありません。

まとめると、「データの中身はPrivacy Rulesで守る。ただしデータの入れ物の名前と構造、Option setの中身は最初から公開情報として扱い、見られて困るものを置かない」。この区別を知っているかどうかが、Bubbleのセキュリティ実装の経験値を測るひとつの目安になります。

URLトリガーとAPIの落とし穴——設定画面で確認できる急所

Privacy Rulesの次にリスクが集まりやすいのが、ワークフローの発火条件とAPI周りの設定です。いずれも設定画面を見れば客観的に確認できる項目なので、後述する発注者向けチェックリストにも直結します。

決済完了をURLで処理してはいけない

ありがちな危険な実装はこうです。Stripeなどの決済ページで支払いが完了すると、ユーザーが /thanks?paid=true のようなURLに戻ってくる。そのページの読み込みイベントで「URLパラメータにpaid=trueがあれば有料プランを有効化する」というワークフローを組む——。
一見自然に動きますが、このURLは決済していない人が手入力でアクセスしても同じワークフローが発火します。つまり無料で有料プランが有効化できてしまいます。

正しい実装は、決済サービスからのWebhook通知をBackend Workflowで受け取り、サーバー側で決済オブジェクトの実在と金額を検証してから権限を付与する形です。ユーザーが戻ってくるURLは「完了画面を表示する」ためだけに使い、権限付与の判断材料にはしません。
決済に限らず、メール認証や申込完了など「状態を変える処理」をURLのパラメータだけで発火させていないかは、検収時に必ず確認したいポイントです。

API周りの5つの確認点

外部サービスと連携するアプリでは、API周りの設定がもうひとつのリスク領域です。開発者向けの要点を5つに絞ります。

• 内部用のAPI Workflowを公開しない：アプリ内部の処理にしか使わないBackend Workflowは「Expose as a public API workflow」を外します。あわせて「Ignore privacy rules when running the workflow」にチェックが付いたまま残っていないかも確認します
• 公開API Workflowの認証方式を確認する：一時トークン認証（Privacy Rulesが適用される）か、管理者トークンか、認証なしか。認証なしの公開は原則使いません
• APIトークンは管理者権限そのものと理解する：BubbleのAPIトークン認証は、データベース管理者の権限で動作しPrivacy Rulesを無視します。本番の管理者パスワードと同じ重みで保管・共有を管理します
• Data APIは必要最小限に：有効化する場合は必要なData typeだけに絞り、全データに堅牢なPrivacy Rulesを敷いたうえで使います
• Swagger仕様と秘密鍵の扱い：アプリのAPI仕様書（swagger.json）は、「Hide Swagger API documentation access」がオフだと誰でも閲覧できます。アプリの作成時期によって初期値が異なるため、公開設定のままになっていないか必ず確認します。API Connectorに登録する秘密鍵はPrivate指定またはBackend Workflow経由のみとし、秘密鍵を含む呼び出しをブラウザから直接実行する設定にはしません

また、クレジットカード番号のような機密データはBubbleのデータベースに保存せず、StripeやPayPalなど、その保管を専門とする外部サービスに委譲するのが標準的な設計です。データを持たないことが最強の防御になります。

発注者向け——納品前に確認したいセキュリティチェックリスト

ここまでの内容を、発注者が確認できる形に翻訳します。
専門知識がなくても、納品前のレビューで開発会社に画面共有してもらいながら「この画面のこの設定を見せてください」と依頼すれば、一緒に確認できます。Swoooが社内で運用しているセキュリティチェックリスト21項目のうち、発注者側でも確認しやすいものを抜粋したものです。

全項目を発注者だけで判定するのは難しくても、「このリストに沿って説明してほしい」と依頼するだけで、開発会社のセキュリティ意識と実装品質はかなりの精度で見えてきます。

なお、アプリの設定とは別に、Bubbleアカウント自体の管理も確認しておきたいポイントです。
エディタの編集権限を持つアカウントの2要素認証、共同編集者を必要な期間だけ最小権限で追加して作業後に削除する運用など、エディタへのアクセス管理まで含めて初めてセキュリティ体制と呼べます。

セキュリティに強い開発会社の見極め方——契約前に聞くべき質問

セキュリティの品質は、デモ画面や完成イメージには一切現れません。だからこそ、契約前に体制と設計方針を質問しておくことが、納品後に問題が発覚してからの手戻りを防ぐ最も確実な方法です。
実際にSwoooへのご相談の中にも、他社で開発したアプリの作り直しやレスキューのケースがあり、事後の対処は事前の確認より必ず高くつきます。

次の質問をそのまま使ってください。カッコ内は期待したい答えの方向性です。

• 「Privacy Rulesの設計方針を教えてください」（「デフォルトで全部閉じて、必要な分だけ開ける」という趣旨の答えが返ってくるか）
• 「納品前のセキュリティチェックは何項目で、どう検証しますか」（明文化されたチェックリストの有無。Privacy Rulesを設定画面だけでなく実際の挙動で検証しているか）
• 「決済完了の処理はどう実装しますか」（Webhookとサーバー側検証、という答えになるか）
• 「APIトークンや秘密鍵はどう管理しますか」（トークンが管理者権限であることの認識と、保管ルールの有無）
• 「Fluskなどの監査ツールや第三者的なチェック工程はありますか」（人の目に加えてツールでの検出工程があるか）
• 「退会時の個人情報削除はどう設計しますか」（メール・氏名等の削除と、ソーシャルログイン連携の解除まで考慮しているか）

開発会社選び全般の評価軸はBubble開発会社の選び方ガイドで詳しく解説しています。また、検収条件にセキュリティチェックを含める書き方など契約面の押さえどころは開発契約ガイドを参照してください。

Swoooのセキュリティ体制

手前味噌になりますが、この記事で解説した内容は、SwoooがBubble開発の全案件で標準運用している体制をそのまま公開したものです。

• セキュリティチェックリスト21項目：Privacy Rules・API設定・公開情報の扱いなどを、検証手順つきで全案件に適用。Privacy Rulesは設定画面の確認だけでなく、テスト用ページで全Data typeを実際に読み込ませて挙動をダブルチェックします
• Fluskを標準工程に組み込み：Fluskは2024年10月にBubble本体が買収したセキュリティ監査・エラー監視ツールです。単体テスト後のセキュリティチェックと、本番リリース後の監視に組み込み、Privacy Rulesの実効性検証にも活用しています
• リリース前チェックリスト37項目：Privacy Rulesの設定漏れや、開発中に一時的に開けた設定の戻し忘れなど、リリース直前に起きやすい事故を項目化して全件確認します
• deny-by-defaultの設計標準：データベース設計の段階からPrivacy Rulesに必要な情報を織り込み、後付けの穴をつくらない設計を規約化しています

Swoooは、東証グロース上場の株式会社アイビス（証券コード9343）が運営するBubble開発サービスです。アイビスは世界累計5億ダウンロード超のペイントアプリibisPaintの開発・運営会社であり、SwoooはBubble公式のGoldパートナー（日本1位）として累計50件以上の開発を支援してきました。
個人情報や決済を扱うシステム、社内の情報セキュリティ基準への適合が求められる案件など、セキュリティ要件のあるBubble開発はお問い合わせフォームからご相談ください。

よくある質問

Bubbleで作ったアプリで個人情報を扱っても大丈夫ですか？

Privacy Rulesを正しく設計すれば扱えます。氏名やメールアドレスなどはPrivacy Rulesでアクセス制御し、クレジットカード番号のような機密性の高いデータはBubbleに保存せずStripe等の専門サービスに委譲するのが標準です。あわせて、退会時にメール・氏名・住所などを確実に消す削除設計まで含めて要件化することをおすすめします。
なお、医療情報のように特に規制の強いデータについては、Bubble自体が利用を推奨していない領域もあるため、該当する場合は個別にご相談ください。

Bubble自体は安全性の認証を取得していますか？

BubbleはSOC 2 Type IIへの準拠を公表しています（対象は信頼原則のうち「セキュリティ」。監査レポートの開示はEnterpriseプラン向けの位置づけのため、書類提出が必要な審査では開示可否を個別に確認してください）。インフラはAWS上で運用されており、AWSはISO 27001をはじめとする第三者認証を取得しています。基盤層の管理はプラットフォーム側が担い、アプリ内のデータアクセス制御は開発者が設計する、という責任分担です。

Privacy Rulesは後から設定できますか？

技術的には後からでも設定できます。ただし、ルールの判定に使う情報（所有者やロールなど）がデータベースに入っていないと適切なルールが書けないため、後付けは設計変更を伴いがちです。データベース設計の段階でPrivacy Rulesに必要な情報を含めておくのが定石で、開発会社に設計方針を確認する価値があるのはこのためです。

ノーコードとスクラッチ開発でセキュリティに差はありますか？

守るべき層が異なります。スクラッチ開発では、クラウドを使っていてもアプリ層より下の設定・運用まで自分たちの管理範囲に入りますが、Bubbleでは基盤層をプラットフォームが管理するため、その分の運用負担は小さくなります。一方、アプリ層のアクセス制御の品質が実装者に依存する点はどちらも同じです。「どちらが安全か」ではなく「どちらも実装品質次第」というのが正確な答えです。

発注者側に専門知識がなくてもセキュリティを確認できますか？

できます。本記事のチェックリストにある項目は、開発会社に画面共有してもらいながら一緒に確認できるものです。加えて、契約前に「Privacy Rulesの設計方針」「納品前チェックの項目数と検証方法」「決済処理の実装方式」を質問すれば、体制の有無は回答の具体性から判断できます。

まとめ——Bubbleのセキュリティは「実装品質」で決まる

最後に、この記事の要点を回収します。

• Bubbleの基盤はSOC 2 Type II（セキュリティ原則）準拠の公表・AWS上での運用という水準にあり、「ノーコードだから危険」は誤解。リスクは実装に集中する（監査レポートの入手可否はプランにより異なる）
• 土台はPrivacy Rules。全拒否から始めて必要な分だけ開けるdeny-by-defaultが基本で、ブラウザに届いたデータは公開済みとみなし、重要な判定は必ずサーバー側で行う
• Option set名とその全データ、Data type名・フィールド名・デフォルト値は公開情報。見られて困るものを置かず、削除後はOptimize applicationまで実行する
• 決済完了などの状態変更をURLパラメータで発火させない。Webhookとサーバー側検証が正解
• 内部API Workflowの公開設定・APIトークンの権限・Swagger非公開化など、API周りは設定画面で客観的に確認できる
• 発注者もチェックリストと質問で実装品質を確認できる。契約前の質問が、納品後の手戻りを防ぐ最も安い保険になる

セキュリティは開発の最後に足すものではなく、データベース設計の段階から織り込むものです。要件定義の時点で不安な点があれば、チェックリストごと持ち込んでSwoooにご相談ください。