Base44やBubbleでは限界？やみくもに作り直さず次のリリースを計画する方法

MVPは、顧客が何を求めているかを学ぶ助けになりました。しかし今、ある連携が扱いにくくなっていたり、モバイル体験の重要性が増していたり、コードをもっと自分で管理したくなっていたりするかもしれません。Base44やBubbleからカスタムコードへの移行は、そうした具体的な要件から始めるべきです。ビルダーを使ったという事実だけでは、プロダクトを捨てる理由になりません。

プラットフォームの限界に達したかどうかは、どう判断すればよいか？

構成を変える理由があるのは、検証済みの制約によって、許容できるコストと労力で重要な顧客の成果を実現できない場合です。ひとつの難しい機能に対する不満は調査する理由にはなりますが、それだけで完全な移行要件書にはなりません。

要件は観察可能な結果として書きましょう。たとえば「顧客がドキュメントをアップロードし、後で処理結果を受け取り、そのステータスをスマートフォンで確認できること」です。そのうえで、現在どの部分がうまくいかないのかを特定します。問題は実装の不足かもしれませんし、プランの制限、連携の境界、あるいはプラットフォームの実行モデルかもしれません。それぞれの結論から導かれる解決策は異なります。

アプリをレビューする担当者に、その制約を実際に示してもらい、代替案を説明してもらいましょう。有益なレビューは、影響を受けるワークフローとトレードオフを明示します。既存のプロダクトを確認する前から全面的な書き直しを提案するようでは、重要な疑問があまりにも多く残ってしまいます。

拡張・連携・作り直しのどれを選ぶべきか？

方向性を決める前に、実現可能な最小限の変更と、より大きな置き換えを比較しましょう。最適な選択肢は、要件、利用できるAPI、既存の顧客、そして完成後に誰が保守するかによって変わります。

カスタムサービスを追加すると、デプロイ、エラー処理、認証情報、監視といった運用作業も増えます。この作業も比較に含めてください。同様に、作り直しの場合は、かつて生成したすべての画面ではなく、顧客が実際に使っているワークフローに基づいて、意図的に小さな初期スコープを設定すべきです。

Base44やBubbleから実際に持ち出せるものは何か？

ソースへのアクセス、データへのアクセス、バックエンドへの依存関係は、それぞれ個別に確認しましょう。プロダクトを所有していることやファイルをダウンロードできることは、稼働中のシステム全体が移行できたことを意味しません。

2026年10月時点で、Base44のGitHubに関するドキュメントでは、Builderプラン以上で双方向のコード同期が利用でき、リポジトリの接続・再接続ができるのはアプリのオーナーのみと説明されています。また、開発者ツールのガイドでは、コードが引き続きBase44のインフラストラクチャとAPIに依存することも説明されています。独立したホスティングを約束する前に、実際のプロジェクトを確認してください。

Bubbleのアプリケーションとデータの所有権に関するドキュメントでは、Bubbleの外部で実行するためにアプリケーションコードをエクスポートすることはできないとされています。CSVによるデータのエクスポートとAPIアクセスについては説明されていますが、Bubbleから離れるにはアプリケーションロジックを作り直す必要があります。プラットフォームが提供していないエクスポートを前提に、ソースコード変換の予算を組まないようにしましょう。

現在のアカウントで可能な範囲で、代表的なエクスポートやAPIによる読み取りを開発者に実演してもらいましょう。フロントエンド、バックエンド関数、データベース、ユーザーID、ファイル、連携、スケジュールされたタスクを棚卸しします。再利用できるもの、プラットフォームに依存したまま残るもの、作り直す必要があるものを記録してください。この棚卸しは、あなたのアプリに固有の内容にしておきましょう。

移行要件書には何を盛り込むべきか？

移行要件書には、次のシステムで維持しなければならないプロダクトの挙動とデータの関係を記述します。スクリーンショットはインターフェースの説明には役立ちますが、その背後にあるワークフローまでは表しません。

1. 顧客ジャーニー： ローンチ時に動作しなければならない最小限のエンドツーエンドのフローを示します。空の状態、エラー、通知も含めてください。
2. データマップ： エンティティ、安定した識別子、リレーション、必須フィールド、ファイルの保存場所、想定されるレコード数を一覧にします。
3. アクセスルール： 顧客、チームメンバー、管理者がそれぞれ何を閲覧・変更できるかを説明します。招待とアカウント復旧も含めてください。
4. 外部システム： 決済、メール、分析、API、Webhook、バックグラウンド処理を一覧にし、それぞれのアカウントの管理者を記載します。
5. 受け入れと引き継ぎ： リリースをどのように検証するか、誰が運用するか、どのようなドキュメントとソースへのアクセスを受け取るかを定義します。

最初の置き換えリリースでは意図的に不要とする機能のリストも追加しましょう。これにより、移行がすべてのワークフローを再設計する機会になってしまうのを防げます。必須の互換性対応と新しいプロダクトのアイデアを区別しておけば、労力がどこに費やされているかを把握できます。

推測に頼らずに顧客データを移行するには？

本番の移行日程を決める前に、安全なコピーを使ってエクスポート、変換、インポート、検証をリハーサルしましょう。ダウンロードが成功したのは、最初の一歩にすぎません。

Base44のデータ管理に関するドキュメントではCSVエクスポートについて説明されており、有効なフィルターによってエクスポートされるレコードが制限される場合があると記載されています。意図したデータセット全体をエクスポートできたかを確認してください。Bubbleのドキュメントに記載されたCSVとAPIによる方法でも同様に、リレーションを維持し、データの完全性を確認するための計画が必要です。

1. リンクされたオブジェクト、長文テキスト、日付、任意フィールド、ファイル参照を含む代表的なレコードをエクスポートします。
2. 識別子とリレーションが新しいシステムにどう対応付けられるかを文書化し、インポートの前後で行数を数えます。
3. インポートしたコピーに対して、権限やレコードの更新を含め、実際のプロダクトの挙動を検証します。
4. 認証とユーザーへの連絡は別途計画します。パスワードやアクティブなセッションがプロバイダー間で引き継がれるとは想定しないでください。
5. リハーサルから切り替えまでの間にレコードが失われないよう、最終エクスポートと書き込みを制御する期間について合意します。

アプリを段階的に置き換えることはできるか？

既存のアプリが適切なインターフェースを提供している場合、段階的な置き換えによって各リリースの規模を小さくできます。ただし、その場合でも、ID、データの書き込み、ロールバックについて明確な境界が必要です。

架空の例として、Bubbleアプリですでに顧客と予約を管理している予約ビジネスを考えてみましょう。新しいモバイルアプリは、最初に承認済みのAPIを通じて空き状況を読み取り、予約を作成するところから始められるかもしれません。それらのインターフェースで必要な権限や挙動をサポートできない場合は、より踏み込んだバックエンドの変更が必要になる可能性があります。モバイルアプリの開発に着手する前に、その点を確認してください。

Base44のプロジェクトであれば、カスタムインターフェースが当初はBase44のサービスを引き続き利用する構成も考えられます。利用できるAPI、アカウントの利用規約、運用上の要件が合致するなら、それは妥当なアーキテクチャです。ただし、フロントエンドが別の場所にあるからといってプラットフォームを完全に置き換えたと主張するのではなく、拡張として正確に説明してください。

開発を始める前に何を合意しておくべきか？

開発を始める前に、最初のリリース、完了の根拠、データ移行、所有権、継続的な運用について合意しておきましょう。信頼できる価格とスケジュールを出すには、アクセスと移行に関する不明点を解消する必要があります。

提案書では、調査フェーズと実装、そしてサードパーティの費用を区別してもらいましょう。リポジトリ、ホスティング、ドメイン、データベース、各プロバイダーのアカウントを誰が管理するのかを明確にします。リハーサルの結果、エクスポートの欠落、サポートされていない連携、手作業でのクリーンアップが必要なレコードが見つかった場合にどうするかも書き留めておきましょう。

リリースの受け入れ基準を定義するには、AI MVPローンチチェックリストを活用してください。本当の目的がBase44アプリをスマートフォンで使えるようにすることなら、作り直しを決める前にBase44アプリのApp Store公開ガイドをお読みください。選択肢のレビューをご希望の場合は、Base44アプリまたはBubble MVPについての相談を予約してください。実現できていない顧客の成果と、すでに動いている部分のウォークスルーをご用意ください。