Bubbleは、画面のデザイン・データベース・処理の流れを、コードを書かずに1つのエディタで組み立てるWebアプリ開発基盤です。この記事では2026年10月時点の公式ドキュメントと料金ページをもとに、データ型とプライバシールールを設定する手順、外部システムとつなぐData APIのリクエスト例、ワークロードユニット(WU)で決まる料金の試算方法を順に追います。そのうえで、コードを書き出せない・1回の処理は300秒までといった制約を一覧にし、Bubbleを採る条件とスクラッチのコード実装へ移す判断まで言い切ります。
まとめ:Bubbleは画面とDBと処理をノーコードで一体に作るWebアプリ基盤
Bubbleで作るものの中心は、会員登録・データの一覧と編集・決済などを備えた、利用者が外から使うWebアプリです。デザイン・データ・ワークフローの3つの画面を行き来して部品を置き、条件と処理をつなげば動きます。React Nativeで動くネイティブのモバイルアプリも同じエディタで作れます。
料金はプランの月額に加え、サーバーの処理量を表すWUで決まります。検索1回0.3WU、レコード1件の書き込み0.5WUといった単価が公開されているので、画面の使われ方から月の消費量を見積もれます。
採ってよいのは、仕様が固まっていない新規サービスを数週間で出して反応を見たいときです。ソースコードは書き出せないため、利用者数と処理量が増え、性能や監査の要件が厳しくなった時点で、コードで作り直す計画を最初から持っておきます。
Bubbleのノーコード開発でデザイン・データ・ワークフローを組む仕組み
Bubbleのエディタは、見た目・データ・動きを別々のタブで定義し、それを式で結ぶ作りです。この分け方を押さえると、ノーコードで届く範囲が見えてきます。
Design・Data・Workflowの3タブでアプリを組み立てる基本の流れ
Designタブでは、テキスト・入力欄・ボタン・繰り返し表示のリストといった部品をページに配置します。Dataタブで定義するのは、「注文」「顧客」のようなデータ型と、その中に持たせる項目(フィールド)です。Workflowタブには「ボタンが押されたら注文を1件作り、確認ページへ移る」という、イベントと処理の組み合わせを並べます。
3つを結ぶのは、画面上の値やデータベースの検索結果を指す式です。入力欄の値をそのまま新しいレコードの項目に入れる、ログイン中のユーザーが作った注文だけを一覧に出す、といった指定をプルダウンで組み立てます。プログラミング言語の文法は出てきません。
ワークフローには、ブラウザで動く処理と、サーバーで動くバックエンドワークフローの2種類があります。定期実行や外部からの呼び出しを受ける処理を組む場所は、後者のバックエンドワークフローです。ノーコードとローコードの線引きや向き不向きの全体像は、ノーコードとローコードの違いと限界で整理しています。
BubbleでWebアプリとネイティブモバイルアプリを作れる範囲と用途
Bubbleが得意とするのは、会員制のマッチングサービス、予約受付、社外の取引先が使う受発注の窓口、社内の申請と承認の画面などです。ログイン機能とデータベースが最初から付いているため、こうしたアプリの土台を自分で用意する手間がかかりません。
モバイルアプリについては、公式の料金ページに、ネイティブアプリはReact Nativeで動くと書かれています。Freeプランでもモバイル用のエディタと実機での確認は使えますが、App StoreやGoogle Playへの公開は有料プランが前提です。ストアへ提出できるビルドの回数は、Starterで月5回、Growthで月10回、Teamで月20回となっています。
反対に、重い計算を伴うデータ処理や、ミリ秒単位の応答が要る画面は苦手です。これは後述する処理時間の上限とWU課金の両方に関わる話なので、制約の章で数字を示します。
Bubbleの使い方:データ型の定義からプライバシールール設定までの手順
ここからは、新しいアプリを作ってデータを守り、外部とつなぐまでの作業を追います。手順は公式マニュアルの記述に沿っています。
無料プランで新規アプリを作りデータ型とフィールドを定義する手順
アカウントを作ると、Freeプランのまま新しいアプリを始められます。最初の数時間は、画面よりもデータ型の設計に充てます。
- アプリを新規作成し、Dataタブで「注文」「顧客」などのデータ型を追加する
- 各データ型にフィールドを足し、文字列・数値・日付・他のデータ型への参照といった型を選ぶ
- Designタブで一覧と入力フォームを置き、入力欄の値をフィールドへ割り当てる
- Workflowタブで、登録ボタンを押したときにレコードを作る処理をつなぐ
- プレビューで動きを確かめ、Dataタブのアプリデータ画面で登録内容を見る
Freeプランの項目は開発版(Development version)で、本番公開用のライブ版やカスタムドメインは有料プランの項目に並んでいます。設計の段階で決めておくのは、「注文に顧客を参照させる」のか「顧客に注文のリストを持たせる」のかという点です。この持たせ方によって、後の検索とWUの消費が変わります。リストを持たせる方式は、後述の1万件の上限にも関わるため、件数が伸びるデータは参照で持たせます。
プライバシールールで他人のレコードを見せない設定と既定の公開状態
Bubbleで最初に確認すべき設定は、プライバシールールです。公式のプライバシールールの解説によると、ルールはDataタブのPrivacy欄でデータ型ごとに設定し、サーバー側で評価されます。ルールを付けていないデータ型は、左の一覧に「Publicly visible」と表示されます。
ルールは禁止ではなく許可を足していく方式です。注文データなら「作成者が現在のユーザーと等しい」という条件のルールを作り、その条件に合う人にだけ、検索で見つける権限・各フィールドを見る権限・添付ファイルを見る権限を与えます。条件に合わない人には何も許可しないままにしておけば、他人の注文は検索結果に出ません。
画面で非表示にするだけでは守れません。公式も、利用者の端末に届いたデータはもう安全ではないと注意しています。見せたくない項目は、画面の表示条件ではなくプライバシールールで送らない設定にしてください。権限の棚卸しや野良アプリへの対策まで含めた全体像は、ローコード開発のセキュリティリスクと権限設計にまとめています。
Data APIとAPI Connectorで外部システムとデータをやり取りする設定例
外のシステムとつなぐ入口は2つあります。Bubbleから外部のAPIを呼ぶのがAPI Connector、外部からBubbleのデータベースを読み書きするのがData APIです。Data APIを有効にすると、設定画面にアプリのルートURLが表示されます。公式のエンドポイントの解説では、開発版は/version-test/api/1.1/obj、ライブ版は/api/1.1/objで始まり、データ型名は空白を除いた小文字で指定します。
次の例は、ライブ版の注文データから、状態が「未出荷」のものを取り出すリクエストです。認証は公式の認証の解説どおり、Settings タブのAPI欄で発行したトークンをBearer形式でヘッダに入れます。
# 状態が「未出荷」の注文を取得する(myapp は自分のアプリ名に置き換える)
curl -G "https://myapp.bubbleapps.io/api/1.1/obj/order" \
-H "Authorization: Bearer ${BUBBLE_API_TOKEN}" \
--data-urlencode 'constraints=[{"key":"status","constraint_type":"equals","value":"未出荷"}]' \
--data-urlencode 'cursor=0' \
--data-urlencode 'limit=100'
応答には件数と残りの件数が入るため、残りが0になるまでcursorを進めて取り直します。公式のリクエストの解説によると、1回のGETで扱えるのは5万件までです。基幹システムから注文をまとめて流し込むときは、一括作成のエンドポイントを使います。
# orders.ndjson:1行に1件のJSONを書く
{"customer_name":"山田商店","status":"未出荷","amount":12800}
{"customer_name":"佐藤物産","status":"未出荷","amount":5400}
# 開発版へ一括作成する(Content-Type は text/plain にする)
curl -X POST "https://myapp.bubbleapps.io/version-test/api/1.1/obj/order/bulk" \
-H "Authorization: Bearer ${BUBBLE_API_TOKEN}" \
-H "Content-Type: text/plain" \
--data-binary @orders.ndjson
一括作成は1回1,000件までで、4分以内に処理を終える必要があります。もう1つ見落とせないのは、管理者用のAPIトークンがプライバシールールを無視する点です。このトークンを渡した連携先は、エディタの管理者と同じ範囲のデータに触れます。連携先のサーバー以外には置かず、漏えいを疑ったらすぐに作り直してください。
Bubbleの料金プランとワークロードユニット課金で月額が増える仕組み
Bubbleの見積もりは、プランの月額とWUの消費量の2段で考えます。プランの単価だけを比べると、運用を始めてから桁が変わることがあります。
Free・Starter・Growth・Team・Enterpriseの料金・WU比較
公式の料金ページを2026年10月21日に確認した内容です。Web and Mobileの表示で、年払い時の月額を並べています。
| プラン | 月額 | WU(月) | ライブ版 | ログ保持 |
|---|---|---|---|---|
| Free | 0ドル | 5万 | 開発版のみ | 6時間 |
| Starter | 59ドル | 17.5万 | 3 | 2日 |
| Growth | 209ドル | 25万 | 5 | 14日 |
| Team | 549ドル | 50万 | 8 | 20日 |
| Enterprise | 個別見積 | 個別 | 個別 | 個別 |
国内の紹介記事には、Starter 29ドル・Growth 119ドル・Team 349ドルという以前の価格が残っているものがあります。稟議には公式ページの最新の数字を使ってください。エディタを同時に使える人数はGrowthで2人、Teamで5人です。WUが足りなくなったときは、公式のワークロード料金ページにある追加ティアを契約するか、超過分を従量で払います。最小のTier 1は20万WUで月26ドル、その超過単価は1,000WUあたり0.15ドルです。FreeプランはWUの追加も超過も選べません。
保守や改修の人件費まで含めた総額の考え方は、ローコード開発の費用相場とスクラッチの5年総額比較で扱っています。
検索1回0.3WU・書き込み1件0.5WUから月のワークロードを試算する方法
公式のWUの内訳には、処理ごとの単価が並んでいます。よく使うものを抜き出すと次のとおりです。
| 処理 | WU |
|---|---|
| ページの読み込み1回 | 0.15 |
| データベースの検索1回 | 0.3 |
| 検索結果1件あたり | 0.015 |
| レコード1件の書き込み・変更 | 0.5 |
| サーバー側のワークフローのアクション1回 | 0.6 |
| 外部APIの呼び出し1回 | 0.1 |
社員50人が1日20回、50件ずつの一覧を開く画面で考えます。検索1回は0.3+50件×0.015で1.05WU、1日1,000回で1,050WU、月22日で約2.3万WUです。ページの読み込みが月に約3,300WU、1日200件の注文登録を書き込みとサーバー側のアクション1回で処理すると月に約4,800WUが加わり、合計は約3.1万WUになります。検索結果の文字数にも1文字0.000003WUがかかるため、実際はこれより少し増えます。
この規模ならStarterの17.5万WUに収まります。消費が跳ねるのは、自分自身を予約し直す再帰ワークフローの回し過ぎや、一覧のたびに数千件を読み込む検索です。公開前にApp metricsでどの処理がWUを使っているかを確かめ、通知の閾値を設定しておきます。
Bubbleの限界:コード出力不可・処理300秒など実装前に知る制約
Bubbleを採るかどうかは、できることより、できないことの側で決まります。ここに挙げる制約は、後から設定で外せるものではありません。
ソースコードを書き出せずセルフホストもできない依存の実態と退避手段
公式サポートの回答は、コードの書き出しとオンプレミスでのセルフホストに対応していないと明記しています。書き出せるのは、別のBubbleアプリへ取り込むためのJSONと、エディタから出力するCSVのデータです。
つまり、Bubbleの外で同じアプリを動かすには、画面もワークフローも作り直しになります。データはCSVかData APIで取り出せますが、プライバシールールやワークフローに埋め込んだ業務ルールは移りません。採用の時点で、業務ルールを文書として別に残しておくことが、将来の移行費を下げる唯一の手段です。
データの置き場所を自社で決めたい場合は、Enterpriseプランでホスティング場所を選べます。ただしこれもBubbleが運用するサーバーの範囲での話で、自社のデータセンターに置けるわけではありません。ローコード全般に共通する弱点は、ローコード開発のデメリットとスクラッチとの使い分けで比較しています。
処理300秒・検索5万件・リスト1万件など公式ハードリミットの一覧
公式のハードリミット一覧から、設計に響くものを抜き出します。表のAPI要求数は、Data APIとWorkflow APIが受け付けるリクエスト数を指します。
| 項目 | 上限 |
|---|---|
| ワークフロー1回の処理時間 | 300秒 |
| ソート付きの検索結果 | 5万件 |
| リストに対するAPIワークフローの予約 | 未ソート10万件・ソート済み5万件 |
| 1つのフィールドに持てるリスト | 1万件 |
| API要求数の上限(Starter) | 1分あたり15,000件 |
| API要求数の上限(Growth) | 1分あたり25,000件 |
| API要求数の上限(Team) | 1分あたり35,000件 |
| アップロードできるファイル | 5GB(ブラウザでは約2GBが実用上の上限) |
| API Connectorの応答サイズ | 50MB |
夜間に数十万件の在庫を突き合わせる処理や、月末に全取引を集計し直すバッチは、300秒と5万件の壁にすぐ当たります。容量の上限に近づくとBubbleが処理を絞るため、上限より手前でタイムアウトする可能性にも注意が必要です。こうした処理は外部のサーバーで動かし、結果だけをData APIで書き戻す構成に分けます。
Bubbleを採用する条件と、スクラッチのコード実装へ移す判断基準
採否の分かれ目は、機能の多さではありません。仕様がどれだけ固まっているか、処理量がどこまで伸びるか、監査や性能の要件がどれだけ厳しいかで判断します。
新規サービスのMVP検証ならBubbleを採ると判断できる3つの条件
Bubbleを選んでよいのは、次の3つがそろうときです。1つ目は、事業の仮説を検証する段階で、画面の仕様が週単位で変わること。2つ目は、利用者が数百人規模までで、1回の処理が数秒で終わる業務であること。3つ目は、決済・会員管理・データの一覧と編集といった、Bubbleが部品として持つ機能で中身の大半が埋まることです。
典型例は、新規事業のマッチングサービスや予約サービスの初期版です。エンジニアを採用する前に、企画担当が画面を動かして利用者の反応を測れることが、この段階でBubbleを使う利点です。検証の範囲の決め方はMVP開発の進め方と範囲の決め方で解説しています。データ設計やプライバシールール、既存システムとのAPI連携まで含めた構築の相談は、ノーコード・ローコードアプリ開発で受け付けています。
WU超過と性能要件と監査要件でコード実装へ移す境界線と移行の進め方
反対に、次のどれかに当てはまったらコードでの実装へ移ります。月のWUがTeamの50万を超えて追加ティアが毎月要る状態、300秒や5万件の上限を避けるために処理を細切れにする工夫が増えた状態、そして取引先や監査から、ソースコードの開示やサーバーの設置場所の指定を求められた状態です。サーバーログの保持はTeamでも20日なので、長期の操作記録を求められる業務も対象になります。
移行は一度に切り替えません。最初の作業は、Data APIでデータを外部のデータベースへ定期的に複製し、重いバッチから順に外部のサーバーへ移すことです。次に、Bubbleに残した画面の業務ルールを仕様書に起こし、それをもとにスクラッチで作り直して、最後に利用者を新しい画面へ移します。作り直す範囲と発注の進め方はスクラッチ開発とパッケージ・ローコードの違いで整理しています。
よくある質問
Bubbleの検討段階でよく出る疑問に、公式の料金ページとマニュアルの記述をもとに答えます。
Bubbleは無料で使えますか?
Freeプランがあり、月5万WUまでなら無料でアプリを作れます。ただし項目は開発版で、本番公開用のライブ版やカスタムドメインは有料プランからです。サーバーログの保持は6時間、エディタは1人で、WUの追加購入もできません。画面とデータ設計の試作には十分で、利用者に公開する段階で月59ドル(年払い)のStarter以上を検討します。
Bubbleで作ったアプリをスマホアプリとしてストアに公開できますか?
公開できます。Bubbleのネイティブアプリは、公式の料金ページによるとReact Nativeで動きます。Freeプランでもモバイル用のエディタと実機確認は使えますが、App StoreとGoogle Playへの公開には有料プランが必要です。ストアへ提出できるビルドは、Starterで月5回、Growthで月10回、Teamで月20回まで、配信後の更新を届けるOTAはいずれも無制限です。
Bubbleから他のツールやスクラッチ開発へ移行できますか?
データは移せますが、アプリ本体は移せません。公式サポートの回答でも、コードの書き出しとセルフホストは非対応という説明です。データはエディタからCSVで、または外部からData APIで取り出せます。画面とワークフロー、プライバシールールは移行先で作り直しになるため、業務ルールを仕様書として残しながら運用することが、後の移行費を左右します。
BubbleとRetoolはどちらを選べばよいですか?
使う人が社外か社内かで分かれます。会員登録や決済を備えた、顧客や取引先が使うWebアプリを作るならBubbleです。社員が使う管理画面を、既存のデータベースにSQLで直接つないで量産したいならRetoolが向いています。Retoolの料金や権限設計はRetoolの構成とDB直結の権限設計で解説しています。
Bubbleで作ったアプリのセキュリティは大丈夫ですか?
設定しだいです。プライバシールールを付けていないデータ型は、エディタ上で「Publicly visible」と表示される状態です。公開前に、すべてのデータ型でルールが付いているかを確かめてください。もう1つの落とし穴は、管理者用のAPIトークンがプライバシールールを無視する点です。トークンは連携先のサーバー以外に置かず、担当者が替わったときは作り直します。
関連記事
- ノーコードツール比較|業務アプリ・Web・EC用途別の代表製品と選び方:BubbleとGlide・FlutterFlowなどの用途別の比較。
- ノーコードとは?ローコードとの違い・できること・限界を実務目線で解説:ノーコード全体の位置づけと限界。
- ローコードツールとは?用途別の比較と選定基準・スクラッチ開発との使い分けを解説:コードで拡張できる製品を選ぶ場合の比較先。
- ローコード開発会社の選び方|内製と外注の判断基準と発注前の確認項目:Bubbleでの構築を外注する際の確認項目。
- ローコード開発の費用相場|初期費・ライセンス費の内訳とスクラッチ5年総額比較:WU課金を含めた総額の比較。