【2026年最新】Bubble 制限事項とは？できないこと・回避策と採用判断をプロが解説

はじめに

「Bubbleでアプリを作りたいけれど、制限がきついと聞いて不安」「大規模開発には向かないって本当？」——導入を検討するほど、こうした技術的な限界が気になってくるものです。

まず結論から先に申し上げます。Bubbleには確かに制限があります。しかし、その大半は設計と運用の工夫で回避でき、SaaSやマッチングアプリ、業務システムといった多くのビジネスアプリは問題なく開発・運用できます。本当に避けるべきなのは、ごく一部の「Bubbleが構造的に苦手な領域」だけです。

重要なのは、制限を「絶対に超えられないハードリミット」と「設計次第で回避できるソフトリミット」に分けて理解することです。この2つを混同すると、本来Bubbleで十分作れるものまで諦めたり、逆に不向きな案件に突っ込んで失敗したりします。

本記事では、100件を超えるBubble開発を手がけてきた立場から、Bubble 制限事項を公式根拠・回避策・残存リスクの3点セットで整理します。2025年以降にネイティブアプリ対応や料金体系が大きく変わった点も踏まえ、古い情報のまま判断して機会を逃さないよう最新の事情に更新しています。そのうえで、自社の案件でBubbleを採用すべきか・やめるべきかを定量基準で判断できるフレームまでお渡しします。読み終えるころには、導入前のモヤモヤがクリアになり、自社の案件で次に何をすべきかまで具体的に見えているはずです。

Bubble 制限事項は「ハードリミット」と「ソフトリミット」で考える

Bubble 制限事項を語るとき、多くの記事が「できる・できない」を一覧で並べるだけで終わっています。しかし実務で本当に大切なのは、その制限が「絶対に動かせない壁」なのか「設計で乗り越えられる壁」なのかという区別です。

この2軸で整理すると、Bubbleの制限の見え方が一気に変わります。

区分	定義	性質	対処の方向性
ハードリミット	Bubble公式が定める仕様上の上限	原則として超えられない	要件側を調整、または別ツールと併用
ソフトリミット	設計・実装の巧拙で生じる実質的な限界	工夫次第で回避できる	DB設計・処理分割・外部連携で解決

世間で「Bubbleは遅い」「Bubbleは大規模に向かない」と言われるケースの多くは、実はソフトリミット、つまり設計起因です。ソースコードを書き出せない点はハードリミットであり、回避ではなく戦略で受け止める対象になります。

この切り分けができると、過剰に怖がるべき制限と、設計レビューで潰せる制限を分けて判断できます。

パフォーマンスとデータ量の制限（ソフトリミット）と回避策

Bubbleで最も懸念されるのが「動作の重さ」と「データ量の限界」です。ただし、これらの多くはソフトリミットであり、設計を正せば数百万件規模でも快適に動きます。まずは公式が定めるハードリミットを押さえましょう。

項目	制限値	実務での影響
テキストフィールド	1フィールド1,000万文字	通常の業務データで超えることはほぼない
1レコード（Thing）のサイズ	20MB	画像・ファイルは別ストレージ管理のため実質問題なし
ソート済み検索結果	最大50,000件	超える場合はページネーション・絞り込みが必須
リスト型フィールド	推奨100件以下（上限10,000件）	100件超で著しく低速化。設計の見直しが必要
API Connectorのレスポンス	50MB	巨大JSONの一括取得は分割が必要

「重い」の正体はデータベース設計にある

パフォーマンス問題の大半は、データの持ち方が原因です。代表的なアンチパターンが、1つのレコードにリスト型フィールドで大量データを抱え込ませる設計です。

💡 ポイント: 「ユーザー」の中に「注文履歴リスト」を持たせると、注文が増えるたびに読み込みが重くなります。リレーショナルデータベースの原則に従い、「注文」側に「ユーザー」を紐付ける形にすれば、データが数百万件でもインデックスが効いて高速に動きます。

5分のワークフロータイムアウト

Bubbleのワークフローには5分（300秒）のタイムアウトがあります。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以外のサーバーでの公開	×	標準はAWS固定。国内リージョンはDedicatedで対応可

ネイティブアプリは、かつての「不向き」から「公式機能で実用レベル」へと進化しました。ARやLiDARなど深いハードウェア機能が必須なら、今でもネイティブ開発が確実です。

SEOについては、集客用のLPやブログをWordPressで作り、ログイン後のアプリ本体をBubbleで構築するハイブリッド構成が王道です。Bubbleで何が作れるのかの全体像は、ビジネスアプリ開発の解説記事も併せてご覧ください。

ソースコードを書き出せない点はBubble最大のロックイン要素ですが、これは「制限」というより「スピードを優先するための戦略的選択」と捉えるのが実態に即しています。

WU（Workload Unit）による運用コストの制限

意外と見落とされがちなのが、運用コストの制限です。Bubbleは現在、サーバーのリソース消費量に応じて課金される「Workload Unit（WU）」制を採用しています。非効率な設計のままだと、アクセス増加に伴って請求額が想定以上に膨らむリスクがあります。

これはハードリミットではなく、設計で大きくコントロールできるソフトリミットです。以下のテクニックで消費を抑えられます。

検索回数を減らす：同じ「Do a search for」を繰り返さず、結果を再利用する
フロントエンドで完結させる：単純な計算や絞り込みはサーバーを使わずブラウザ側で処理する
不要なバックエンド実行を止める：定期実行や条件分岐を見直し、無駄なワークフローを削る
リスト処理を最適化する：大量データのループはページ単位に分割して回す

💡 ポイント: WUコストは「アプリの作り方」で数倍変わります。要件定義の段階から消費量を意識して設計できるかどうかが、長期運用での総コストを左右します。

【判断フレーム】Bubbleを採用すべきケース・やめるべきケース

ここまでの制限を踏まえ、自社の案件でBubbleを採用すべきかを判断するフレームをお渡しします。感覚ではなく、定量的なしきい値で線引きするのがポイントです。

判断軸	採用すべき（向いている）	やめるべき（向いていない）
同時接続ユーザー数	数千人規模まで（BtoB・社内利用）	瞬間的に1万人超が集中する
速度要件	多少の表示遅延が許容される	ミリ秒単位の応答が必須
開発予算・スピード	300万〜2,000万円／2〜6ヶ月で検証したい	1年以上かけ完成度を極めたい
データ保管要件	標準のAWS管理で問題ない	国内サーバー必須かつDedicated予算なし
出口戦略	MVP検証後の作り直しを許容できる	コード資産の自社保有が絶対条件

Bubbleがベストなケース

SaaS（BtoB向けクラウドサービス）：認証・課金・管理画面がそろう最も得意な領域
マッチングプラットフォーム：ユーザー同士をつなぐモデル全般
社内業務システム（DX）：CRM・SFA・在庫・予約・勤怠管理など
AI活用アプリ：OpenAIやDifyなどのAPIを組み込んだツール

Bubbleをやめるべきケース

0.1秒を争うリアルタイム性が必須（高頻度トレーディング、対戦ゲーム）
ARやLiDARなど特殊なハードウェア機能を多用する
検索流入だけで成立させる大規模メディア（SEOが生命線）
国内サーバー必須だがDedicatedプランの予算が取れない

プロはこう乗り越える：制限を前提にした設計アプローチ

Bubbleの制限は、技術力でカバーできるものがほとんどです。私たちのような専門の開発チームは、最初から制限を前提に置いてアーキテクチャを設計します。

具体的には、データベースを正規化して数万件でも軽快に動く構造にし、あいまい検索はAlgolia、メール配信はSendGrid、決済はStripeと、Bubbleが苦手な部分は「餅は餅屋」で外部サービスに任せます。スケーラビリティが要る部分だけXanoのような外部バックエンドに切り出すこともあります。AI機能を組み込む案件では、Bubble×DifyによるAIプロダクト開発のように、生成AIと組み合わせて短期間でリリースする構成も増えています。

つまり、Bubbleの制限を感じさせないかどうかは、ツールそのものよりも設計するパートナーの力量で決まります。同じBubbleでも、作り手によってパフォーマンスもコストも大きく変わるのです。

まとめ

Bubbleには確かに制限があります。しかし本記事で見てきたとおり、その大半は設計と運用で回避できるソフトリミットであり、本当に避けるべきハードリミットはごく一部です。だからこそ、制限を「ハードかソフトか」で切り分けて理解することが、失敗しないツール選定の第一歩になります。

パフォーマンスの重さはデータベース設計で、5分のタイムアウトは再帰的ワークフローで、運用コストはWUを意識した設計で、それぞれコントロールできます。さらに、かつて弱点とされたネイティブアプリ対応も2025年以降の公式機能で実用レベルに達しており、苦手領域は着実に狭まっています。一方で、リアルタイム性が生命線のサービスや、特殊なハードウェア連携が必須のアプリは、無理にBubbleで進めず別の手段を選ぶのが賢明です。採用すべきか・やめるべきかを定量基準で線引きできれば、Bubbleの制限はもう怖くありません。

そして最後に大切なのは、Bubbleで何でもやろうとしないこと、そして制限を熟知したパートナーと組むことです。同じBubbleでも、設計力次第でアプリの完成度・速度・コストはまるで変わります。私たちノーコード総合研究所では、あなたのアイデアがBubbleで実現可能か、それとも別の手段を選ぶべきかを、フラットな目線で診断します。Bubbleの制限を正しく理解したうえで、最適な開発の進め方を一緒に考えていきましょう。