Bubbleで作ったシステムを移行すべきかは、保守担当者の有無・費用の増加・機能の限界・データ要件という4つのきっかけで判断します。当てはまるきっかけの数だけで機械的に決めるのではなく、必須要件の不足度合いや業務への影響の大きさを見極めることが重要です。1項目だけでも優先的に移行検討が必要な要件がある一方、プラン見直しや保守の引き継ぎで解決できる場合もあります。本記事ではきっかけの整理と乗り換え判断チェックリストを示します。
Bubbleからの移行を検討するきっかけ
Bubbleからの移行を検討するきっかけは、主に次の4パターンに整理できます。
| きっかけ | 典型的なサイン | 対処の入り口 |
|---|---|---|
| 保守担当者の異動・退職 | エディタを触れる社員がいなくなった、外注先との契約が終了した | 保守の引き継ぎ、または作り替えの検討 |
| 費用の増加 | ワークロード（WU）課金の消費量が伸び、WUの追加購入や超過課金が続く | プランの見直し、または費用構造の変更 |
| 機能・性能の限界 | 標準機能・プラグインの組み合わせでは業務フローを表現しきれない | 部分改修、または作り替え |
| セキュリティ・データ所在の要件 | 取引先や社内規程からデータの保管場所・アクセス権限の証跡を求められる | 要件の整理、作り替えの検討材料 |
費用面は特にBubbleの課金構造に起因します。Bubbleはワークロード（WU）課金という使用量ベースの料金モデルで、公式は「サーバー資源の消費量を集約した指標」と説明しています。年払い時の月額は、ブラウザで使う業務システム向けの「Web only」プランでStarterが29ドル、Growthが119ドル、Teamが349ドルです。モバイルアプリも配信する「Web + Mobile」プランでは、それぞれ59ドル・209ドル・549ドルになります。プランごとに含まれる月間WU量も異なります（Bubble公式マニュアル「Pricing and plans」、取得日2026-09-08）。
含まれるWUを使い切ったときの選択肢は2つあります。1つは追加分をまとめ買いするワークロードティアで、公式は「プランを上げる必要はない」と説明しています。もう1つは超過分を1,000WU単位で従量課金するフレキシブル超過で、設定画面でオン・オフを切り替えられます（オンにすると超過課金によりアプリを止めずに使い続けられます。オフにした場合の上限到達後の挙動や制限については、提供資料の範囲では明記されておらず運用前の確認が必要です）。
使用量が75%と100%に達した時点で通知メールが届くため、請求が跳ねる前に手を打てる設計です。（Bubble公式マニュアル「Pricing and plans」、取得日2026-09-08）
仕様書が残っていない状態からコードを読み解いて仕様を再構築したアプローチとしては、事例集の〈CASE 09｜仕様書がなくても、コードが語る〉があります。ただしCASE 09はソースコードを直接閲覧できる環境での事例です。Bubbleでは後述のとおり実行基盤のコードを直接出力できない制約があるため、同一の手順をそのまま適用できるわけではない点に注意が必要です。
乗り換え判断チェックリスト
次の10項目のうち、いくつ当てはまるかを確認してください。
| # | 判断ポイント |
|---|---|
| 1 | Bubbleのエディタを開いて構造を理解できる人が、社内に1人もいない |
| 2 | 保守担当者・外注先への支払いが、何をしているか分からないまま続いている |
| 3 | 直近半年でワークロード（WU）の消費量が増え、プラン変更を繰り返している |
| 4 | 標準機能・プラグインの組み合わせでは実現できない業務フローが複数残っている |
| 5 | 外部システムとの連携を、API連携や自動通知の仕組み（Webhook）では表現しきれない |
| 6 | 取引先や社内の監査から、データの保管場所やアクセス権限の証跡を求められたことがある |
| 7 | 画面表示やレスポンスの遅さについて、現場から声が上がっている |
| 8 | Bubble開発会社への保守移管を検討したが、対応できる先が見つからない |
| 9 | 業務の重要度が上がり、可用性やバックアップの要件が厳しくなった |
| 10 | システムを自社の資産として持ちたいと、経営として考えている |
このチェックリストは、当てはまる項目数だけで機械的に移行の可否を決めるものではありません。たとえばセキュリティ要件やバックアップ要件（項目6や9）は、たとえ該当が1項目だけであっても事業継続上、最優先で検討が必要な場合があります。なお、監査や取引先から質問を受けた事実そのものが直ちに不適合を意味するわけではありません。各項目について「現在の不足」「業務への影響度」「Bubble内での改善案」「他基盤への移行」を対比させて判断材料にしてください。
どの業務からAI化するか当たりをつけたい場合は、無料のAI自動化診断も判断材料になります。
Bubbleを続ける、という選択肢
チェックリストに複数当てはまっても、Bubbleを続ける選択肢が消えるわけではありません。作り替えと対等に検討すべき道が3つあります。
- プランの見直し: ワークロード消費が増えているだけなら、上位プランへの変更や、ワークフロー・検索条件の設計を見直してWU消費を抑える余地があります。
- 保守の引き継ぎ: 担当者の退職や外注契約の終了が理由であれば、適切な管理権限と仕様の把握、引継ぎ体制が整う開発会社を見つけられる場合、Bubble上での保守移管により運用を継続する選択肢があります。
- 部分改修で足りるケース: 機能の限界が特定の画面や外部連携に限られる場合は、プラグインの活用や外部API連携の追加といった部分改修で要件を満たせることもあります。
全体を作り替える前に、この3つの方法で解決できないかを先に検証する価値があります。
Bubble公式は、万一プラットフォームの提供を終了（discontinuation）する事態になった場合にはソースコードをオープンソースライセンスで公開し、ユーザーが自身でホストしたサーバー上でアプリを維持できるようにすると表明しています（Bubble公式マニュアル「Application and data ownership」、取得日2026-09-08）。ただし、これは非常時の方針表明であり、平常時に自社アプリの実行コードをエクスポートできることを意味するものではありません。また、自社運用へ切り替える際の移行作業やサーバー維持のコスト・体制が不要になるわけではない点に留意が必要です。
移行の進め方
作り替えると決めた場合は、データの移行とロジックの再構築を切り離し、次の順序で進めるのが実務的です。
- 1. 現状棚卸しと受入条件の策定 既存のデータ型・ワークフロー・連携を整理し、移行対象とする1業務と合否判定の受入条件を定義
- データ面 2A. データの試験出力と変換検証 CSV/JSON出力やData APIを検証。添付ファイルやリレーション構造の整合性を確認
- 機能面 2B. 業務ロジックの再設計とMVP構築 コード持ち出し不可を前提に、要件から新環境でロジックを再実装し最小試作環境を作成
- 合流 3. 並行運用（正本・同期ルールの確定） 書き込み正本（マスター）を決め、API等の同期方向と差分修正ルールを定めて検証運用
- 判定 4. 受入判定・切替（または切戻し） 受入条件を満たせば本番切替。重大な不整合時は合意済みの基準に沿って旧環境へ切戻し
- 完了後 5. データ保全と旧環境の解約 新環境の安定稼働後に旧環境の最終バックアップを保全し、不要プランの解約・課金停止を実施
データ移行とロジック再構築を並行で進め、受入判定で不整合が生じた場合は旧環境への切戻しルールを適用します。
- 現状の棚卸しと対象・受入条件の決定: 使用中のデータ型、ワークフロー、プラグイン、外部API連携を洗い出します。一度に全移行を目指さず、業務影響が局所的で検証しやすい業務を移行対象として選び、移行完了とみなす受入条件（データの欠損なし、処理結果の一致など）を事前に定義します。
- データの試験出力と検証: Bubbleは管理画面（Data – App data）からCSV・JSON・NDJSON形式での出力や、Data API経由の取得が可能です（Bubble公式マニュアル「Exporting data」）。ただし添付ファイルやリレーション構造、日付インターバルのミリ秒変換仕様などの扱いは事前検証が必要です。また、アプリの所有権規定においてデータとデザインの所有権はユーザーにあると明記されているものの、実行基盤コードはエクスポートできず、移行時はロジックの再構築が必須とされています（Bubble公式マニュアル「Application and data ownership」、取得日2026-09-08）。公式が移行時にデザイン出力の支援（help you export the design）を行うと記載している範囲も、コードとしての完全な移植を意味するわけではないため、画面・ロジックともに要件定義に基づいて新環境で実装します。
- MVP（最小限の試作環境）の構築: 対象業務に絞って新システムを実装し、実データの一部を流し込んで画面操作性や業務ロジックの挙動を検証します。
- 並行運用（正本と同期方向の確定）: 旧Bubbleシステムと新システムを一定期間並行稼働させます。この際、どちらを書き込みの「正本（マスター）」とするか、同期方向（片方向か双方向か）、差分や競合が発生した場合の修正担当者とルールを事前に定めます。BubbleのData APIやWorkflow APIは外部連携口として利用可能ですが、Privacy Rules（アクセス制限）やエンドポイントの公開設定、認証キー管理を含めた安全な連携設計が不可欠です。
- 切替判定と切戻し基準の合意: 受入条件を満たしているかを検証し、本番切り替えを実施します。万一、新システムで致命的な不具合やデータ不整合が生じた場合に備え、旧環境へ安全に運用を戻す「切戻し基準」と手順を事前に合意しておきます。
- 移行完了後のデータ保全と解約確認: 新システムの安定稼働を確認後、旧Bubble環境内の最終データをバックアップ・保全し、監査要件に応じた保管期間を定めたうえで、不要となったBubbleプランの解約や超過課金の停止を行います。
AI駆動開発で作り替えると、何がどう変わるか
Bubbleは汎用のノーコードプラットフォームで、標準プランではBubbleが運用するマルチテナント（共通基盤）上でアプリが稼働します（Enterpriseプランでは専用クラスタの提供が案内されています。Bubble公式マニュアル「Application and data ownership」、取得日2026-09-08）。AI駆動開発とは、生成AIを活用して要件定義から実装・テストまでを効率化する開発手法です。移行先として専用開発を選択する場合、一例として自社の業務フローに合わせた1社1環境の専用システムを構築する構成が採られます（共有型と専用型の違いは業務システムは共有型か専用型か参照）。
支援体制の選択肢としては、業務の分解から実装、定着までを一貫して担うFDE（Forward Deployed Engineer：現場伴走型エンジニア）による支援形態などがあります（詳細はFDE型AI導入支援とはを参照）。費用構造の面では、Bubble特有のWU（ワークロード）課金からは離れるものの、専用システムでも利用するクラウドインフラ費用（AWSやGCP等）、外部API利用料、保守・監視費用などの運用維持費が別途発生します。「AI駆動開発だから固定費だけで従量費が一切不要になる」という意味ではないため、システム全体のインフラ要件と合わせて試算することが重要です（開発費用の目安は開発費用の相場解説を参照）。
プラン変更や保守の引き継ぎだけで運用が安定し、機能面でも困っていない業務は、無理に作り替える必要はありません。
GUI中心のツールで定義ファイルをAIに解析させて不具合調査を迅速化したアプローチについては、事例集の〈CASE 32｜GUI前提の基盤でも、定義ファイルは読める〉が参考になります。なお、CASE 32はFlutterFlow環境での進行中PoC事例であり、Bubbleでの直接の検証記録ではない点をご留意ください。
よくある質問
Bubbleで作ったシステムは、そのままAI駆動開発に移行できますか？
データはCSVエクスポートやBubbleのAPI経由で取得できますが、アプリを動かす実行コードそのものは持ち出せません。画面デザインやワークフローの設計情報を手元で整理し、新環境に合わせて業務ロジックを再構築する形になります。
保守担当者がいなくても、Bubbleを使い続けられますか？
続けられます。管理権限の適切な引き継ぎや仕様の把握が可能で、引継ぎ体制が整うBubble開発会社が見つかる場合は運用を継続でき、作り替えが必須というわけではありません。ただし、引き継ぎ先が確保できない場合などは移行の検討が必要になります。
ワークロード（WU）課金は、必ず上がり続けますか？
プランに含まれるWUの範囲内なら月額は変わりません。超えた分だけ従量課金が発生する仕組みで、超過課金は設定でオフにもできます（ただし上限到達後の挙動やアプリへの影響は事前に確認が必要です）。また、ワークフローや検索の設計見直し、ワークロードティアの事前購入でも消費やコストを抑えられます。
移行はどのくらいの期間・費用がかかりますか？
業務範囲やデータ量で幅があり、断定はできません。まず現状の棚卸しから始め、最初の1業務単位で見積もるのが実務的です。
ノーコードとAI駆動開発の判断軸はBubble・kintone・Power Appsで作るか、AIで開発するか、費用の積み上がり試算はkintone・Bubble・Power Appsの費用はいくら積み上がるか、用語の確認はノーコード・ローコード・AI駆動開発の用語FAQ20問をご覧ください。他プラットフォームの限界はkintoneの限界はどこか、作り替え後の進め方はAI導入はどこから始める？最初の1業務の選び方にまとめています。作り替えを外部に任せるか社内で進めるかで迷う場合は、Power Apps・AppSheetで内製するか、AI駆動開発で外注するかの4象限が判断の入り口になります。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。
参考
執筆時点（2026年9月8日）の各公式サイトの公開情報に基づきます。プラン内容・仕様・料金は予告なく変更される場合があるため、最新情報は公式サイトでご確認ください。
- Bubble Pricing（料金プラン、取得日 2026-09-08）
- Bubble Manual – Account and billing – Pricing plans（取得日 2026-09-08）
- Bubble Manual – Understanding your app’s workload（ワークロード課金、取得日 2026-09-08）
- Bubble Manual – API（Data API・Workflow API、取得日 2026-09-08）
- Bubble Manual – Exporting data（データエクスポート、取得日 2026-09-08）
- Bubble Manual – Application and data ownership（アプリ・データの所有権、取得日 2026-09-08）
