本番向けReact・Flutterプラットフォームを比較する

Lovable、Bolt、Replit、FlutterFlowの中に、一般的な本番向けReact出力と、第一級のネイティブFlutterプロジェクトの両方を提供する製品はありません。Lovable、Bolt、ReplitはReactとWeb開発向けです。FlutterFlowはFlutterを生成します。この境界は、どのデモがどれだけ良く見えるかより重要です。

リリース計画でReactのWebアプリとネイティブFlutterのモバイルアプリが必要なら、現実的な選択肢は2つです。共有バックエンド契約を使って別々のビルダーを組み合わせるか、両方のスタックを明示的にサポートするプラットフォームを選ぶことです。React Native、レスポンシブなWebアプリ、エクスポートしたプロトタイプがFlutterと同等だと考えると、最初のストア向けビルドやネイティブプラグインの失敗まで議論を先送りするだけです。

私は、プロンプト画面を閉じた後に残るものを基準にツールを判断します。別のエンジニアがcloneできるリポジトリ、復旧できるデータベース、正しい理由で失敗するテスト、1社のベンダーのボタンに依存しないリリースです。生成された画面は役立ちます。しかし、それが本番システムそのものではありません。

4つのプラットフォームは仕事の異なる半分を解決する

どれもアプリ開発全体をうたっていますが、製品はReact寄りのWebビルダーとFlutterビルダーに明確に分かれます。

この表は購入契約ではなく、機能の地図として見てください。プランの権利、エクスポートの条件、ホストされたバックエンドの名称、デプロイのパッケージ形式は変わります。支払う前に、実際のリポジトリで現在のプランを確認し、その証拠を残してください。

Lovableは、この中で最も方針が明確なReactビルダーです。よくあるアプリの形に製品が収まるなら、その規約により一貫したWebプロジェクトを素早く作れます。その速さの代償は、独特なビルドシステム、分離したサービス構成、ネイティブモバイルコードが必要になったときに現れます。

Boltは、より広いJavaScriptの作業台を提供します。使いたいフレームワーク、パッケージ、サービス境界が分かっていれば、その自由は役立ちます。一方で、経験の浅いチームは、競合するパターンがいくつも混じった混乱したプロジェクトを作れてしまいます。エージェントは悪い設計にも驚くほど忠実に従います。

Replitは、この4つの中で最も幅広くプログラミングできます。フロントエンドとバックエンドを1つのワークスペースで扱え、特定のUIフレームワークへの依存も比較的少なめです。カスタムサーバー、ワーカー、定期ジョブ、特殊な依存関係を持つアプリには魅力的ですが、その幅広さが洗練されたFlutterリリースパイプラインを生むわけではありません。

FlutterFlowは、分かれ目の反対側から始まります。Flutterプロジェクトを生成し、Flutterウィジェット、アクション、状態、連携を中心にした視覚的なアプリモデルを提供します。Reactソースが契約上の成果物なら、ブラウザ上のWebビルドが正しく見えてもFlutterFlowはその要件を満たしません。

React出力はビルダーの外でも生き残らなければならない

本番向けのReactプロジェクトとは、生成サービスを外した後も、通常のリポジトリ用ツールでビルドと実行ができるプロジェクトです。ブラウザのプレビューが示すのは、現在ホストされているワークスペースが一度描画されたことだけです。再現性、依存関係の整合性、所有権までは証明しません。

Lovableでは、エクスポートしたリポジトリに、理解できるReactコンポーネント、TypeScriptの型、ルート定義、環境変数の扱い、データベース連携コード、通常のパッケージマニフェストがあるか確認してください。Viteらしいなじみのある出力は他所でホストしやすい場合がありますが、生成コンポーネントには状態の持ちすぎ、重複したデータ取得、表示ロジックの混在がたまりがちです。リポジトリが普通のReactのままなら、こうした欠点は直せます。

Boltも同じように確認する必要がありますが、プロンプトで何が選ばれたかには特に注意してください。何気なくReactアプリと説明されたプロジェクトが、Vite、Next.js、Expoの構成、あるいは別のJavaScript構成を使っていることがあります。それぞれ描画モデルとデプロイ要件が異なります。会話ログに頼らず、選んだフレームワークをリポジトリに記録しましょう。

Replitでは、Reactフロントエンドの横にNode、Python、Goなどのサーバーを置けます。これは適切な構成になり得ますが、各部分をどう起動し、通信し、デプロイするかがリポジトリに明記されている場合に限ります。ワークスペース固有の自動化で全体を起動する開発コマンドは、本番用スクリプトの不足を隠しているかもしれません。

エクスポートしたWebリポジトリは、クリーンなチェックアウトで実行してください。

npm ci
npm test -- --run
npm run build

テストフラグはテストランナーごとに異なるため、無条件にコピーせず、まずpackage.jsonを確認してください。求める証拠には分かりやすい形があります。lockfileから依存関係のインストールが完了し、アサーションを壊すとテストコマンドがゼロ以外のステータスを返し、ビルダーに接続せずにビルドが文書化された出力ディレクトリを作ることです。

Reactの公式ドキュメントは今、新しいアプリでルーティング、データ読み込み、描画戦略、本番向けの規約が必要ならフレームワークを使う方向へ案内しています。これはもっともな助言ですが、社内ダッシュボードのすべてに大きなフレームワークが必要という意味ではありません。別のAPIがサーバー側の振る舞いを担うなら、素のReactとViteのアプリの方が、よりクリーンな本番の選択肢になることがあります。ビルダーにはその判断を明示させてください。

ネイティブFlutterには明確な技術的境界がある

比較した4製品の中で、第一級のネイティブFlutterプロジェクトを提供するのはFlutterFlowだけです。ほかの3つはレスポンシブWebページ、プログレッシブWebアプリ、React NativeやExpoのワークフローを通じてモバイル体験を作れますが、その出力はFlutterではありません。

この違いは、プログラミング言語、パッケージのエコシステム、描画の振る舞い、ネイティブプロジェクトファイル、テストツール、必要なエンジニアに影響します。FlutterはDartを使い、AndroidとiOSのビルドディレクトリを持つプロジェクトを生成します。React Nativeは、ReactのコンポーネントモデルでJavaScriptまたはTypeScriptを使います。Webラッパーはブラウザのコンテンツをネイティブの外枠に入れます。これらは別々の配信方法であり、交換可能なエクスポート形式ではありません。

ExpoのドキュメントはExpoをReact Nativeアプリ用フレームワークと説明しています。FlutterのドキュメントはFlutterを、Dart、Flutterウィジェット、プラットフォーム連携を中心に構築されたマルチプラットフォームフレームワークと説明しています。ベンダーがExpoを通じてモバイル対応をうたう場合、その説明は正しくてもFlutterの要件を満たさないことがあります。

正しいFlutterエクスポートは、サービス外で標準ツールチェーンを通る必要があります。

flutter pub get
flutter analyze
flutter test
flutter build apk

iOSのビルドマシンでは、iOSビルドと署名の確認も加えてください。デバイスプレビューのスクリーンショットで代用してはいけません。リポジトリには、想定どおりのDartソース、アセット宣言、パッケージのロック情報、Android設定、iOSプロジェクトファイル、必要なネイティブプラグイン設定を含める必要があります。

FlutterFlowはその構成をエクスポートできますが、生成されたFlutterコードが自動的に扱いやすいとは限りません。肥大化したウィジェットファイル、重複したアクション、暗黙の状態変更、生成された名前、カスタムコードの境界、依存関係のバージョン、ナビゲーションルールを確認してください。小さな視覚的変更で広い範囲のコードが再生成されることもあるため、上書きされずに手作業の変更を置ける場所を決めておきましょう。

1つのコードベースだと言うために、WebアプリもFlutterで作ろうと提案するチームがあります。構成図が整って見えるため、この提案は人気です。しかし、Web製品がReactパッケージ、サーバーサイドレンダリング、ブラウザ動作の細かな制御、またはReact人材の採用市場に依存するなら、正しい選択ではありません。共有コードは、増やす手間より減らす手間が大きくなければ意味がありません。

2つのクライアントを一貫させるのはバックエンド

共有バックエンドは、認証、認可、検証、業務ルール、データベース変更を担えば、ReactとFlutterの両方を安定して支えられます。クライアントは、それらのルールを個別に作り直すのではなく、バージョン管理された契約を利用すべきです。

Lovableは、多くの場合Supabaseやマネージドクラウドの経路と自然に組み合わせられます。この組み合わせなら、少ない設定でPostgreSQLデータ、認証、ストレージ、関数を扱えます。生成された行レベルアクセス制御ポリシーはすべて確認してください。クライアントが管理者ボタンを隠しても、データベースで同じルールを強制していなければ認可は実装されていません。

Boltはマネージドサービスへ接続することも、フロントエンドと並べてサーバーの振る舞いを作ることもできます。ブラウザ用の認証情報とサーバー用シークレットを分け、サーバー関数が実際にどこで実行されるか確認してください。生成コードが特権SDKを共有モジュールにインポートし、後のバンドル変更でシークレットがブラウザに露出することがあります。

Replitは、同じ開発環境で一般的なサーバーコードとデータベースを実行できるため、カスタムバックエンドの作業に向いています。その柔軟性で明示的なサービスを作り、たまたまデータを問い合わせるフロントエンドのルートの寄せ集めにしないでください。データベースマイグレーション、ヘルスチェック、ワーカーの動作、終了処理をソースで定義します。

FlutterFlowはFirebase、Supabase、HTTP APIと無理なく連携できます。クライアントからの直接連携は初期プロダクトを早く作れますが、本番の権限ルールはサービス側に置く必要があります。ReactとFlutterの両クライアントが同じレコードを書き込むなら、検証を集約してください。そうしないと必須フィールド、タイムスタンプ、状態遷移、エラー処理について食い違います。

Twelve-Factor Appは、設定を環境変数に保存し、バッキングサービスを接続されたリソースとして扱うことを勧めています。生成プロジェクトでも有用な助言ですが、1点注意があります。環境変数だけではシークレット配布の問題は解決しません。開発用と本番用で別の認証情報、ローテーション手順、各シークレットを読める実行環境の記録が必要です。

2つの生成クライアントでバックエンドを共有するなら、OpenAPIのようなAPIスキーマを使ってください。スキーマをコミットし、そこからクライアント型を生成または検証し、互換性のない変更は継続的インテグレーションで拒否します。コンパクトな契約があれば、よくある失敗を防げます。Webエージェントがcustomer_idをcustomerIdに変え、モバイルプロジェクトは古いフィールドを保持し、異なるシードデータを使っているため両方のプレビューが正常に見える、という失敗です。

生成テストは正しく失敗するまで提案にすぎない

テスト支援が意味を持つのは、テストが独立して実行され、意図的に入れた不具合を検出し、リリースを止めるときだけです。エージェント自身が書いた弱いアサーション、実行していないコマンド、本番で使わないモック経路をテストした可能性があるため、エージェントがテストに通ったと報告しても独立した証拠にはなりません。

LovableとBoltは、指示すればリポジトリ内にJavaScriptテストを作れます。決定的なUI動作にはコンポーネントテストを、金銭、権限、取り消せない操作を扱う少数のフローにはブラウザテストを求めてください。そしてアサーションを読んでください。ページに何らかのボタンがあるかだけを確認するテストは、決済ボタンが動かなくなっても通り続けます。

Replitはワークスペースでテストコマンドを実行でき、言語ごとの複数のテストツールをサポートできます。フロントエンドとバックエンドが混在したリポジトリには便利です。npmスクリプト、Makeターゲット、タスクファイルなど、別の環境でも同じスイートを実行できるよう、正式なコマンドをソース管理に置きましょう。

FlutterFlowプロジェクトは、エクスポート後にflutter analyzeとflutter testを通すべきです。ナビゲーション、保存された状態、オフラインからの復帰、ネイティブコードにまたがるプラグインの統合テストも追加してください。ウィジェットプレビューでは、署名、権限、カメラアクセス、通知、バックグラウンド処理、OSのライフサイクル変更を検証できません。

優れた移植性チェックでは、1つの制御された失敗を作ります。テストで期待するHTTPステータスを変え、コマンドが失敗終了することを確認し、元に戻して正常に通ることを確認します。この小さな手順で、空のスイート、無視された終了コード、間違ったディレクトリ、テスト結果に関係なく成功と表示するスクリプトを見つけられます。

テストデータは本番データから分けてください。生成アプリは、便利だからと単一のプロジェクト、バケット、データベースで始まりがちです。自動テストがレコードを削除したり通知を再送したりすると、その便利さは障害に変わります。テスト環境には専用の認証情報を与え、本番へ到達できない破壊的権限にしてください。

カバレッジ率だけでは悪いテストスイートを救えません。理解できないスナップショットが数百個あるより、認証、請求状態、権限境界、データ移行を対象にした読みやすい12個のテストを引き継ぐ方がよいでしょう。各テストがどの失敗を防ぐかを問い、説得力ある答えがないものは削除または書き直してください。

デプロイボタンは異なる責任を隠している

チームがプラットフォームの責任範囲と自分たちの責任を理解していれば、マネージドデプロイは便利です。公開ボタンはアセットのアップロードとサービスの開始を行えるかもしれませんが、復旧時間を定義したり、失敗したマイグレーションを調査したり、すべての外部認証情報を更新したりはしません。

LovableとBoltは、生成されたWebプロジェクトからホストURLまでの短い経路を提供します。レビュー環境には最適で、サービスがアプリに必要なドメイン、ログ、設定、リージョンの挙動、ロールバック制御を提供するなら、本番にも十分な場合があります。プレビューの挙動から推測せず、デプロイ先の環境で各項目を確認してください。

Replit Deploymentsはワークスペースで作ったアプリをホストできるため、カスタムサーバーを持つプロジェクトに便利です。本番デプロイで明示したビルドコマンドと開始コマンドを使っていること、永続サービスがアプリのファイルシステム外にあること、バックグラウンドジョブに定義済みの実行モデルがあることを確認してください。開発ワークスペースの振る舞いは本番の契約ではありません。

FlutterFlowでは、Web公開とネイティブアプリ配信が分かれます。Web公開はすぐにできます。モバイルリリースには、アプリ識別子、証明書、プロビジョニング、ストア情報、プライバシー宣言、スクリーンショット、審査、バージョン管理が今も必要です。OSベンダーやアプリストアが管理する部分を、どのビルダーも取り除くことはできません。

可能な限り、デプロイの定義はソースの近くに置いてください。外部ホストはlockfileからReactリポジトリをビルドできるべきです。モバイルエンジニアは、文書化された署名用の入力を使いFlutterリポジトリをビルドできるべきです。ビルダーだけがリリース手順を知っているなら、ソースをエクスポートしても材料だけが残り、作り方は失われています。

ロールバックも層ごとに違います。フロントエンドアセットの復元は通常簡単です。データベースマイグレーション後にバックエンドリリースを戻すと、古いサービスが新しいスキーマを読めない場合にデータを壊すおそれがあります。後方互換のあるマイグレーションを使い、安全な順序でアプリコードをリリースし、実際のバックアップからの復元をテストしてください。スナップショット機能は役立ちますが、復元訓練だけが、そこに期待どおりの内容があることを証明します。

ソースの所有には離脱訓練が必要

有用なソースを所有していると言えるのは、別のチームが元のアカウントへアクセスせずに、それをビルド、デプロイ、運用できるときです。ダウンロードボタンはファイルの所持を証明するだけで、運用上の独立性は証明しません。

エクスポートには、アプリのソース、アセット、依存関係マニフェスト、lockfile、データベースマイグレーション、ビルド設定、環境変数名、テストコマンド、ライセンス、デプロイ手順が含まれているか確認してください。FlutterではAndroidとiOSのプロジェクト設定も含めます。サーバーなら、ワーカー定義、定期ジョブ、ストレージの前提、ヘルスエンドポイントも必要です。

GitHub同期は慎重に確認する価値があります。一方向か双方向か、サービスが書き込むブランチ、手動コミットが再生成後も残るか、コミットの作成者と履歴が理解しやすいままかを確かめてください。ビルダー外で小さな変更を加え、エージェントが同じファイルを編集したときに何が起きるかを観察します。

次に、番号付きの離脱訓練を1回行ってください。

1. 一度もビルダーを開いたことがないアカウントへ、リポジトリをエクスポートまたはcloneします。
2. 空のデータベースを用意し、ソースからマイグレーションを適用します。
3. 文書化されたコマンドでWebまたはモバイルプロジェクトをビルドし、テストします。
4. 一時的なドメインまたはアプリ識別子でデプロイします。
5. 元の認証情報をローテーションし、独立したデプロイが引き続き動くことを確認します。

この演習で、欠けた生成アセット、隠れた環境設定、ビルダー専用パッケージ、文書化されていないデータベース状態、会話履歴にしかないデプロイ手順が見つかります。得られた手順をリポジトリに保存し、大きな更新やアーキテクチャ変更の前に訓練を繰り返してください。

ソースの所有にはライセンスも含まれます。生成された依存関係、アイコンセット、フォント、サンプルデータ、コピーしたスニペットのライセンスを確認してください。エージェントは義務や保守状況を説明せずに、数秒でパッケージを追加できます。依存関係の一覧を保ち、理解できる数行のコードと重複するパッケージは取り除きます。

ソースへのアクセスとデータの移植性を混同してはいけません。データベースレコード、オブジェクトストレージ、移転が許される場合の認証ID、ドメイン設定、監査記録、アプリのシークレットもエクスポートできる必要があります。最もつらいロックインは、Reactコンポーネントより状態と運用にあることがほとんどです。

本番対応は障害時の経路に表れる

生成アプリが本番対応になるのは、部分的な障害の最中にチームがその挙動を予測し、制御できるときです。正常系だけを扱うプロンプトでは、トークン期限切れ、重複リクエスト、遅延したジョブ、中断されたアップロード、スキーマのずれ、1年間インストールされたままのモバイルクライアントはほとんど扱われません。

ReactをWebに、Flutterをモバイルに使い、PostgreSQLバックエンドを1つ持つ予約アプリを考えてみましょう。両方のクライアントから予約を送信します。遅いネットワークのため、モバイル利用者が2回タップします。最初のリクエストは確定しましたが、レスポンスは消えます。クライアントが予約成功を知る前に、再試行が2つ目のサーバーインスタンスへ届きます。

エージェントがPOST /bookingsハンドラーだけを生成したなら、データベースは予約を2件作り、二重請求するかもしれません。Flutterでボタンを無効にしても、OS、プロキシ、画面を開き直すせっかちな利用者からの再試行は防げません。バックエンドには冪等性の値、操作に結び付く一意性ルール、同じリクエストを再び受けたときに元の結果を返すレスポンスが必要です。

ここに古いモバイルリリースを加えます。バックエンドが、新しいReactクライアントは常に送る必須フィールドを導入しましたが、インストール済みのFlutterバージョンはその存在を知りません。厳格でバージョンなしのエンドポイントは、モバイルからの予約を拒否し始めます。本番向けの設計では、移行期間はフィールドを任意にする、サーバー既定値を用意する、互換性のあるAPIバージョンを導入する、といった対応が必要です。

認証でも別の差が生まれます。Webセッションはバックグラウンドで更新される一方、停止していたモバイルアプリは期限切れのトークンと途中まで入力したフォームの状態で再開します。Flutterクライアントは安全なローカル状態を保持し、認証情報を1回更新して、処理を再開するか失敗を説明しなければなりません。盲目的な再試行は操作を重複させることがあります。

これらは珍しい端のケースではありません。2つのクライアント実行環境と分散したバックエンドがあれば、直接起こり得ます。再試行ルール、互換性ポリシー、冪等性の振る舞い、エラーコードをAPI契約に書いてください。公開前に両方のクライアントからテストします。

セキュリティレビューも同じ作業に含まれます。各サービス境界での認可、生成されたデータベースポリシー、ファイルアップロードの検証、レート制限、管理操作、ログのマスキングを確認してください。特権データベース認証情報をReactやFlutterのコードに入れたまま公開してはいけません。ブラウザやモバイル端末に配信するものは、利用者に観察され得るものとして扱うべきです。

配信トポロジーに合わせて選ぶ

適切なプラットフォームは、提供すべき成果物、それを保守する人、アプリに必要なバックエンド制御の度合いで決まります。機能数は、そのトポロジーの代わりになりません。

主な成果物が一般的なReactのWebアプリで、速度が重要で、その方針のあるプロジェクト形状がチームに合うならLovableを選びます。特に、対応するマネージドバックエンドを使えるダッシュボード、ポータル、データベース駆動のプロダクトには合理的です。コンポーネント境界の整理と認可確認には、エンジニアリング時間を確保してください。

Reactを使いつつJavaScriptプロジェクトとパッケージをより自由に扱いたいならBoltを選びます。悪いフレームワーク選択を見分け、パッケージ変更を確認し、クライアントとサーバーの責任分担をエージェントに正確に伝えられる開発者に向いています。成功したプレビューはすべて公開可能だと思う創業者にとっては、その自由はあまり役立ちません。

アプリにカスタムバックエンド、複数言語、ワーカー、スクリプト、あるいは汎用的なホスト開発環境が必要ならReplitを選びます。特化したUIビルダーより、アプリの多くを扱えます。ワークスペースがアプリを動かせる唯一の場所にならないよう、本番コマンドと外部サービスの依存関係を早めに定義してください。

ネイティブFlutterが絶対条件で、視覚的ビルダーが画面、状態、連携を速く作れるならFlutterFlowを選びます。React出力はその役割の外だと受け入れてください。カスタムDartコードは分離し、定期的にエクスポートし、ストア提出よりずっと前にAndroidとiOSの両方をビルドします。

ReactのWebクライアントとFlutterのモバイルクライアントには、React寄りのプラットフォームとFlutterFlowを組み合わせる方法が使えます。バックエンドスキーマ、OpenAPI契約、認証モデル、リリース方針が共有の土台になります。プロジェクト間で業務ルールをコピーして、それをコード共有と呼んではいけません。

費用比較には、生成後の作業も含めてください。ソースエクスポートの権利、ホストされたデータベースの利用量、ビルド時間、モバイル署名、可観測性、バックアップ、独自ドメイン、エンジニアによる整理、移行の手間です。生成の変更をするたび手作業で直す必要があるなら、安いサブスクリプションも高くつきます。

両方のリポジトリが実在して初めて、1つのプラットフォームで両方を扱える

ReactとFlutterの両方に対応すると主張するプラットフォームが検討に値するのは、各スタック向けに独立した一般的なプロジェクトと、両者で共有できるバックエンドを生成するときだけです。技術名の横にチェックボックスがあるだけでは足りません。

Koder.aiは、ReactのWebアプリ、PostgreSQLを使うGoサービス、Flutterのモバイルプロジェクトを中心に構築され、ソースエクスポート、ホスティング、独自ドメイン、スナップショット、ロールバック、プランニングモードを本番向けの制御として掲げています。この要件に直接対応する単一プラットフォームの候補ですが、同じ離脱訓練は必要です。

小さな縦切りの機能を生成するよう依頼してください。認証、1つのロール保護された操作、1つのデータベースマイグレーション、1つのReact画面、1つのFlutter画面です。すべてエクスポートします。クリーンな環境でReactビルド、Goテスト、データベースマイグレーション、Flutterの静的解析、Flutterテストを実行してください。

両クライアントが同じAPI動作を使うこと、Goサービスがどちらの画面も信用せずに権限を強制することを確認します。Webアプリとバックエンドは別々にデプロイし、生成アカウントなしでモバイルアプリをビルドしてください。データベースを空の環境へ復元し、アプリのリリースを1つロールバックします。

FlutterをReact Nativeに置き換える、Webラッパーだけをエクスポートする、ネイティブプロジェクトファイルを省く、バックエンドスキーマを隠す場合は、そのプラットフォームを採用しないでください。手動で編集したソースが警告なく消える場合や、本番ビルドが文書化されていないワークスペース状態に依存する場合も採用しないでください。

勝者は、最初の画面を最も印象的に作るサービスではありません。元のチャットが意味を失った後も、チームが出力をテスト、リリース、修正、移管できるサービスです。プロダクトを任せる前に、自分たちのリポジトリでそれをベンダーに証明させてください。