Bubbleで作ったシステムの移行ガイド — AI駆動開発への乗り換え判断チェックリスト

Q: Bubbleで作ったシステムは、そのままAI駆動開発に移行できますか？

データはCSVエクスポートやBubbleのAPIで持ち出せますが、 アプリのロジックはコードとして取り出せない ため、業務要件を洗い出して作り直す形になります。

Q: 保守担当者がいなくても、Bubbleを使い続けられますか？

続けられます。Bubble開発会社への保守移管や、プランの見直しを挟めば運用を継続でき、 作り替えが必須というわけではありません 。

2026 9/09

2026年9月9日

著者: Walkers編集部監修: 渡辺敦司（株式会社Walkers 代表取締役）公開: 2026年9月9日監修者: AI駆動開発・FDE型AI導入支援の実務家

Bubbleで作ったシステムを移行すべきかは、保守担当者の有無・費用の増加・機能の限界・データ要件という4つのきっかけで判断します。複数のきっかけが同時に重なるときが、作り替えを検討する目安です。1つだけなら、プラン見直しや保守の引き継ぎで対応できる場合が多く、本記事ではきっかけの整理と乗り換え判断チェックリストを示します。

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）。

乗り換え判断チェックリスト

次の10項目のうち、いくつ当てはまるかを確認してください。

#	判断ポイント
1	Bubbleのエディタを開いて構造を理解できる人が、社内に1人もいない
2	保守担当者・外注先への支払いが、何をしているか分からないまま続いている
3	直近半年でワークロード（WU）の消費量が増え、プラン変更を繰り返している
4	標準機能・プラグインの組み合わせでは実現できない業務フローが複数残っている
5	外部システムとの連携を、API連携や自動通知の仕組み（Webhook）では表現しきれない
6	取引先や社内の監査から、データの保管場所やアクセス権限の証跡を求められたことがある
7	画面表示やレスポンスの遅さについて、現場から声が上がっている
8	Bubble開発会社への保守移管を検討したが、対応できる先が見つからない
9	業務の重要度が上がり、可用性やバックアップの要件が厳しくなった
10	システムを自社の資産として持ちたいと、経営として考えている

「はい」に当てはまる項目が多いほど、作り替え（AI駆動開発への移行）を検討する材料が増えます。1〜2個だけなら、プラン見直しや部分改修で対応できる可能性が高いという目安です。断定はできないため、最終判断は自社の業務の重要度と照らして行ってください。

どの業務からAI化するか当たりをつけたい場合は、無料のAI自動化診断も判断材料になります。

Bubbleを続ける、という選択肢

チェックリストに複数当てはまっても、Bubbleを続ける選択肢が消えるわけではありません。作り替えと対等に検討すべき道が3つあります。

プランの見直し: ワークロード消費が増えているだけなら、上位プランへの変更や、ワークフロー・検索の設計を見直してWU消費を抑える方法があります。
保守の引き継ぎ: 担当者の退職や外注先との契約終了が理由なら、Bubble開発を手がける別の開発会社へ保守を移管すれば、システムを止めずに運用を続けられます。
部分改修で足りるケース: 機能の限界が特定の画面・業務に限られる場合は、プラグインや外部の連携サービスを追加する部分改修で足りることもあります。

全体を作り替える前に、この3つで解決しないかを先に検討する価値があります。

移行の進め方

作り替えると決めた場合は、次の順序で進めるのが実務的です。

現状の棚卸し: 使用中のワークフロー・データ構造・外部連携を一覧化し、業務単位で重要度を整理します。
データのエクスポート: Bubbleはエディタの「Data – App data」からCSV・JSON・NDJSONの3形式でのエクスポート、またはBubble APIを使った自動エクスポートに対応しています。ただし公式は、エクスポート処理がAPIワークフローと同じ待ち行列で動くため、混雑時は完了までに待ち時間が生じる場合があると注意しています（Bubble公式マニュアル「Exporting data」、取得日2026-09-08）。また、ユーザーが「データ・アプリの設計の所有権」を持つ一方、「アプリを動かす基盤コードはBubbleが保有し、コードとしてエクスポートする方法はない」とも説明しています（同マニュアル）。公式も、移行時はロジックの作り直しが必要な一方でデザインのエクスポートは支援すると述べています（同マニュアル）。移行できるのはデータと画面デザインまでで、業務ロジックは要件として洗い出して作り直す前提になります。
最初の1業務を選ぶ: 影響範囲が小さく、効果を検証しやすい業務から着手します。
MVP（最小限の試作システム）をつくる: 最初の1業務に絞った小さな専用システムを作り、実務で使いながら検証します。
並行運用: 旧Bubbleシステムと新システムを一定期間並行稼働させ、データの整合性と運用の問題を洗い出します。BubbleにはData API（外部システムからデータを読み書きする窓口）とWorkflow API（外部から処理を呼び出す窓口）があり、外部システムからの呼び出しを受け付けられます。認証を行う場合はBearerトークンという方式を使うと公式は説明しています。並行運用中のデータ連携にも使えます（Bubble公式マニュアル「API」、取得日2026-09-08）。
切り替え: 並行運用で問題が出ないことを確認してから、業務ごとに順次切り替えます。

AI駆動開発で作り替えると、何がどう変わるか

Bubbleは汎用のノーコードプラットフォームで、標準のプランではBubbleが運用する共通基盤の上でアプリが動きます（公式はEnterpriseプランに限り、自社アプリ専用のクラスタを提供すると説明しています。Bubble公式マニュアル「Application and data ownership」、取得日2026-09-08）。AI駆動開発で作り替えると、作るものがワークロード課金の枠にある汎用の仕組みから、自社の業務フローに合わせた1社1環境の専用システムに変わります。

体制は、担当エンジニア（FDE）が要件整理から運用の定着まで業務に伴走する形が中心です（FDE型AI導入支援とは）。進め方は業務の棚卸し→最初の1業務→小さく作る（MVP）→拡張の順で、Bubbleでの並行運用と同じ考え方です。費用は月額のワークロード課金ではなく初期開発費用と保守費用という構造になり、具体的な金額は要件次第のため本記事では扱いません（開発費用の相場解説を参考にしてください）。

プラン変更や保守の引き継ぎだけで運用が安定し、機能面でも困っていない業務は、無理に作り替える必要はありません。