【2026年最新】Bubble 制限事項とは？できないこと・回避策と採用判断をプロが解説
はじめに
「Bubbleでアプリを作りたいけれど、制限がきついと聞いて不安」「大規模開発には向かないって本当？」——導入を検討するほど、こうした技術的な限界が気になってくるものです。
まず結論から先に申し上げます。Bubbleには確かに制限があります。しかし、その大半は設計と運用の工夫で回避でき、SaaSやマッチングアプリ、業務システムといった多くのビジネスアプリは問題なく開発・運用できます。本当に避けるべきなのは、ごく一部の「Bubbleが構造的に苦手な領域」だけです。
重要なのは、制限を「絶対に超えられないハードリミット」と「設計次第で回避できるソフトリミット」に分けて理解することです。この2つを混同すると、本来Bubbleで十分作れるものまで諦めたり、逆に不向きな案件に突っ込んで失敗したりします。
本記事では、Bubble開発を手がけてきた立場から、Bubble 制限事項を公式根拠・回避策・残存リスクの3点セットで整理します。2025年以降にネイティブアプリ対応や料金体系が大きく変わった点も踏まえ、古い情報のまま判断して機会を逃さないよう最新の事情に更新しています。制限値や機能の記述は、2026年10月3日にBubble公式マニュアルと公式サイトで確認した内容です。そのうえで、自社の案件でBubbleを採用すべきか・やめるべきかを判断する目安のフレームまでお渡しします。読み終えるころには、導入前のモヤモヤがクリアになり、自社の案件で次に何をすべきかまで具体的に見えているはずです。
Bubble 制限事項は「ハードリミット」と「ソフトリミット」で考える
Bubble 制限事項を語るとき、多くの記事が「できる・できない」を一覧で並べるだけで終わっています。しかし実務で本当に大切なのは、その制限が「絶対に動かせない壁」なのか「設計で乗り越えられる壁」なのかという区別です。
この2軸で整理すると、Bubbleの制限の見え方が一気に変わります。
| 区分 | 定義 | 性質 | 対処の方向性 |
|---|---|---|---|
| ハードリミット | Bubble公式が定める仕様上の上限 | 原則として超えられない | 要件側を調整、または別ツールと併用 |
| ソフトリミット | 設計・実装の巧拙で生じる実質的な限界 | 工夫次第で回避できる | DB設計・処理分割・外部連携で解決 |
世間で「Bubbleは遅い」「Bubbleは大規模に向かない」と言われるケースの多くは、実はソフトリミット、つまり設計起因です。ソースコードを書き出せない点はハードリミットであり、回避ではなく戦略で受け止める対象になります。
この切り分けができると、過剰に怖がるべき制限と、設計レビューで潰せる制限を分けて判断できます。
パフォーマンスとデータ量の制限（ソフトリミット）と回避策
Bubbleで最も懸念されるのが「動作の重さ」と「データ量の限界」です。ただし、これらの多くはソフトリミットであり、設計を正せば大量のデータでも快適に動かせます。まずは公式が定めるハードリミットを押さえましょう。
| 項目 | 制限値 | 実務での影響 |
|---|---|---|
| テキストフィールド | 1フィールド1,000万文字（空白やBBCode・HTMLの装飾タグも文字数に含む） | 通常の業務データで超えることはほぼない |
| 1レコード（Thing）のサイズ | 20MB | 画像・ファイルは別ストレージ管理のため実質問題なし |
| ソート済み検索結果 | 最大50,000件 | 超える場合はページネーション・絞り込みが必須 |
| リスト型フィールド | 上限10,000件 | 件数が増える関係はリスト型で持たず、検索で取り出す設計にする |
| API Connectorのレスポンス | 50MB | 巨大JSONの一括取得は分割が必要 |
出典: Bubble公式マニュアル「Hard limits」（確認日: 2026年10月3日）
「重い」の正体はデータベース設計にある
パフォーマンス問題の大半は、データの持ち方が原因です。代表的なアンチパターンが、1つのレコードにリスト型フィールドで大量データを抱え込ませる設計です。Bubble公式マニュアルも、リスト型フィールドの上限を示したうえで、性能面では件数の多い関係をリストで持たず検索を使うよう勧めています。
💡 ポイント: 「ユーザー」の中に「注文履歴リスト」を持たせると、注文が増えるたびに読み込みが重くなります。リレーショナルデータベースの原則に従い、「注文」側に「ユーザー」を紐付ける形にすれば、データが増えても検索で必要な分だけを取り出せます。
5分のワークフロータイムアウト
Bubbleのワークフローには5分（300秒）のタイムアウトがあり、公式マニュアルのHard limitsにも明記されています。CSV一括取り込みや全ユーザーへの一斉メールなど、重い処理は途中で強制終了されかねません。回避策は次のとおりです。
- 再帰的ワークフロー：一度に全件処理せず「100件処理したら自分自身を再呼び出し」とループ化し、5分の壁を回避する
- 外部バックエンドへの委譲：極端に重い計算はXanoやSupabase、AWS Lambdaに任せ、結果だけをBubbleで受け取る
- バックエンドワークフロー化：ユーザー操作を待たず、サーバー側で非同期に処理を流す
機能面で「できないこと」と2026年の最新事情
「何でも作れる」と言われるBubbleにも、苦手領域は明確に存在します。一方で、2025年以降のアップデートで状況が変わった項目もあるため、古い情報のまま判断しないことが重要です。
| 領域 | 可否 | 補足 |
|---|---|---|
| Webアプリ・SaaS・管理画面 | ◎ | 最も得意。一般的な機能はほぼ実装可能 |
| ネイティブアプリ | ○ | 2025年6月にReact Nativeベースの公式機能が公開ベータとして登場。プッシュ通知・カメラ・位置情報（GPS）に対応 |
| 高度なハードウェア連携 | △ | AR、LiDAR、高度なBluetooth制御などは依然として苦手 |
| SEO（検索流入主体のサイト） | △ | 動的描画のため難易度が高い。ハイブリッド構成で回避 |
| ゲーム・高負荷グラフィック | × | リアルタイム描画やFPSゲームは不向き |
| 複雑なアルゴリズム・機械学習 | △ | 外部API（OpenAI等）連携で代替するのが定石 |
| ソースコードのエクスポート | × | コードの書き出し・自社サーバー移行は不可（ハードリミット） |
| AWS以外のサーバーでの公開 | × | Bubbleが管理するAWS上で動作。東京など設置地域を選べるのはEnterpriseプランの専用インスタンス（Dedicated） |
出典: Bubble公式ブログ（ネイティブアプリ公開ベータの発表）、Bubble公式マニュアル「Device resources」、Bubble公式マニュアル「Dedicated instance」（確認日: 2026年10月3日）
ネイティブアプリは、かつての「不向き」から「公式機能で作れる」段階へと進みました。ARやLiDARなど深いハードウェア機能が必須なら、今でもネイティブ開発が確実です。
SEOについては、集客用のLPやブログをWordPressで作り、ログイン後のアプリ本体をBubbleで構築するハイブリッド構成が王道です。Bubbleで何が作れるのかの全体像は、ビジネスアプリ開発の解説記事も併せてご覧ください。
ソースコードを書き出せない点はBubble最大のロックイン要素ですが、これは「制限」というより「スピードを優先するための戦略的選択」と捉えるのが実態に即しています。
WU（Workload Unit）による運用コストの制限
意外と見落とされがちなのが、運用コストの制限です。Bubbleは現在、サーバーのリソース消費量に応じて課金される「Workload Unit（WU）」制を採用しています。公式の料金ページでは、プランごとに月間のWU枠が決まっており、枠を超えた分は追加の枠を購入するか従量で支払う仕組みです（出典: Bubble公式「Pricing」、確認日: 2026年10月3日）。非効率な設計のままだと、アクセス増加に伴って請求額が想定以上に膨らむリスクがあります。
これはハードリミットではなく、設計で大きくコントロールできるソフトリミットです。以下のテクニックで消費を抑えられます。
- 検索回数を減らす：同じ「Do a search for」を繰り返さず、結果を再利用する
- フロントエンドで完結させる：単純な計算や絞り込みはサーバーを使わずブラウザ側で処理する
- 不要なバックエンド実行を止める：定期実行や条件分岐を見直し、無駄なワークフローを削る
- リスト処理を最適化する：大量データのループはページ単位に分割して回す
💡 ポイント: WUコストは「アプリの作り方」で大きく変わります。要件定義の段階から消費量を意識して設計できるかどうかが、長期運用での総コストを左右します。
【判断フレーム】Bubbleを採用すべきケース・やめるべきケース
ここまでの制限を踏まえ、自社の案件でBubbleを採用すべきかを判断するフレームをお渡しします。感覚ではなく、しきい値で線引きするのがポイントです。表の数値は公式の上限値ではなく、検討の出発点にする目安です。
| 判断軸 | 採用すべき（向いている） | やめるべき（向いていない） |
|---|---|---|
| 同時接続ユーザー数 | 数千人規模まで（BtoB・社内利用） | 瞬間的に1万人超が集中する |
| 速度要件 | 多少の表示遅延が許容される | ミリ秒単位の応答が必須 |
| 開発予算・スピード | 300万〜2,000万円／2〜6ヶ月で検証したい | 1年以上かけ完成度を極めたい |
| データ保管要件 | 標準のAWS管理で問題ない | 国内サーバー必須かつEnterprise（専用インスタンス）の予算なし |
| 出口戦略 | MVP検証後の作り直しを許容できる | コード資産の自社保有が絶対条件 |
Bubbleがベストなケース
- SaaS（BtoB向けクラウドサービス）：認証・課金・管理画面がそろう最も得意な領域
- マッチングプラットフォーム：ユーザー同士をつなぐモデル全般
- 社内業務システム（DX）：CRM・SFA・在庫・予約・勤怠管理など
- AI活用アプリ：OpenAIやDifyなどのAPIを組み込んだツール
Bubbleをやめるべきケース
- 0.1秒を争うリアルタイム性が必須（高頻度トレーディング、対戦ゲーム）
- ARやLiDARなど特殊なハードウェア機能を多用する
- 検索流入だけで成立させる大規模メディア（SEOが生命線）
- 国内サーバー必須だがEnterpriseプラン（専用インスタンス）の予算が取れない
プロはこう乗り越える：制限を前提にした設計アプローチ
Bubbleの制限は、技術力でカバーできるものがほとんどです。私たちのような専門の開発チームは、最初から制限を前提に置いてアーキテクチャを設計します。
具体的には、データベースを正規化して件数が増えても軽快に動く構造にし、あいまい検索はAlgolia、メール配信はSendGrid、決済はStripeと、Bubbleが苦手な部分は「餅は餅屋」で外部サービスに任せます。スケーラビリティが要る部分だけXanoのような外部バックエンドに切り出すこともあります。AI機能を組み込む案件では、Bubble×DifyによるAIプロダクト開発のように、生成AIと組み合わせて短期間でリリースする構成も増えています。
つまり、Bubbleの制限を感じさせないかどうかは、ツールそのものよりも設計するパートナーの力量で決まります。同じBubbleでも、作り手によってパフォーマンスもコストも大きく変わるのです。
制限を踏まえて外注を検討する段階では、見積もりの前提や契約の範囲によって費用と進め方が変わります。開発会社を比べる観点は、アプリ開発会社の選び方と比較基準・費用・契約のポイントで整理していますので、依頼先を選ぶ前に確認してください。
まとめ
Bubbleには確かに制限があります。しかし本記事で見てきたとおり、その大半は設計と運用で回避できるソフトリミットであり、本当に避けるべきハードリミットはごく一部です。だからこそ、制限を「ハードかソフトか」で切り分けて理解することが、失敗しないツール選定の第一歩になります。
パフォーマンスの重さはデータベース設計で、5分のタイムアウトは再帰的ワークフローで、運用コストはWUを意識した設計で、それぞれコントロールできます。さらに、かつて弱点とされたネイティブアプリ対応も2025年に公式機能が公開ベータとして登場し、苦手領域は着実に狭まっています。一方で、リアルタイム性が生命線のサービスや、特殊なハードウェア連携が必須のアプリは、無理にBubbleで進めず別の手段を選ぶのが賢明です。採用すべきか・やめるべきかを目安のしきい値で線引きできれば、Bubbleの制限を過度に恐れずに済みます。
そして最後に大切なのは、Bubbleで何でもやろうとしないこと、そして制限を熟知したパートナーと組むことです。同じBubbleでも、設計力次第でアプリの完成度・速度・コストは大きく変わります。私たちAI開発ラボでは、あなたのアイデアがBubbleで実現可能か、それとも別の手段を選ぶべきかを、要件整理の段階からフラットな目線でご相談いただけます。Bubbleの制限を正しく理解したうえで、最適な開発の進め方を一緒に考えていきましょう。
費用の目安：生成AI×ノーコードで進む業務システム開発｜費用・期間・失敗回避の型を公開
関連する開発事例：京大生専用の就活サイト
群別サービス：受託開発