1つのAIアプリビルダーでReactとFlutterを扱えるか

ReactのWebクライアントとFlutterのモバイルクライアントを別々のAIツールで作る方法は、最初の共通ルールが変わるまでは合理的に見えます。そこで一方のツールはブラウザのフローを更新し、もう一方は昨日の前提を保ち、データベースは両方のバージョンを受け入れます。分業に見えたものが、統合作業に変わる瞬間です。

小規模なチームの多くには、1つのAIアプリビルダーが適しています。ただし、React、Flutter、バックエンドを別々のコードベースとして生成でき、ソースコードを取り出せて、各クライアントを独立してリリースできることが条件です。「1つのビルダー」とは、計画の文脈とシステム契約が1つという意味です。巨大なアプリケーションが1つ、リリース工程が1つ、あるいはTypeScriptとDartでUIコードを共有するという意味ではありません。

もう一方の選択肢も成立します。Webとモバイルの担当チームがすでに分かれ、API契約を両方のツールの外で管理し、組織が調整コストを受け入れるなら、2つの専門ツールには意味があります。この条件がなければ、2つ目のツールは製品が続く限り誰かが監視すべき境界を増やします。

AIアプリビルダーは1つ必要か、2つ必要か

同じ製品、バックエンド、データモデル、IDシステムが両方のクライアントを支えるなら、1つを選びます。プラットフォームへの特化が共通の文脈より重要で、その境界を保守する担当者がいる場合に限り、2つを選びます。

次の採点は、創業者または小規模な製品チーム、1つのGo API、1つのPostgreSQLデータベース、ReactのWebクライアント、Flutterのモバイルクライアントを前提にしています。5点は、その項目を手作業でほとんど調整せず扱えることを示します。1点は、足りない接続をチームが自分で作り、監視する必要があることを示します。

この点数は意思決定の補助であり、製品ベンチマークではありません。ソースをエクスポートできない、実際のバックエンドを構築できない、Webとモバイルを同時にデプロイさせる候補は、大幅に減点します。一方、成熟したプラットフォームチームがAPI契約、IDサービス、リリースポリシー、互換性テストを所有するなら、2ツール構成の点数は上がります。

画面数やプロンプト数を数えてはいけません。権限の所在を数えます。ビジネス上の事実ごとに1つの決定元、1つのAPI契約、1つのIDポリシー、1つの移行順序が必要です。ReactとFlutterは、その決定を利用する側です。

共通のビジネスロジックは両クライアントの背後に置く

権限、価格ルール、ワークフローの遷移、利用上限、保存データを守る検証はバックエンドに置きます。ReactとFlutterは素早いフィードバックのために軽い検査を繰り返してもかまいませんが、最終判断はAPIが行います。

チームは異なる2つの意味で「共通ロジック」という言葉を使いがちです。ソースコードの共有とは、両クライアントが同じ実装を読み込むことです。ビジネス上の動作の共有とは、両クライアントが1つの決定元から同じ結果を受け取ることです。ReactとFlutterは言語もUIモデルも違うため、実装の共有を強制すると、どちらのクライアントより理解しにくい第3の抽象層が生まれます。動作はAPIを通じて共有します。

注文がdraftからsubmittedへ移れるのは、明細が1つ以上あり、アカウントが有効な場合だけだとします。各クライアントがこのルールを持つと、すぐに4つの実装ができます。Reactのフォーム検査、Flutterのボタン状態、Webの送信ハンドラー、モバイルの送信ハンドラーです。ポリシーを変えるたびに、どのクライアントをリリースするより先に、すべてを更新する必要があります。古いモバイルビルドは何か月も端末に残る場合があります。

バックエンドは許可された操作を返し、その操作を受け取ったときにもう一度検証します。

{
  "order_id": "ord_4821",
  "status": "draft",
  "allowed_actions": ["submit"],
  "version": 7
}

操作をどう表示するかはクライアントが決めます。バージョン7でsubmitが有効かどうかはサーバーが決めます。別のリクエストが先に注文を変更した場合、最後の書き込みを黙って優先せず、サーバーは競合を返します。

Reactのドキュメントは、状態ごとに信頼できる情報源を1つにするよう勧めています。この指針はブラウザのコンポーネントツリー内に関するもので、複数クライアントを持つ製品全体の話ではありません。Webアプリとモバイルアプリに共通する親は、バックエンド契約です。永続するビジネス状態をそこへ移すことで、同じ考え方をシステム境界に適用できます。

Flutterのアーキテクチャガイドは、ViewとViewModelをRepositoryとServiceから分離します。また、Serviceは外部APIエンドポイントを包み、Repositoryはその結果をドメインモデルへ変換すると説明しています。これはクライアントの良い境界です。Repositoryがあるからといって、サーバーのポリシーをDartで再実装してよいわけではありません。モバイルのRepositoryはキャッシュ、再試行、データ変換を担当できますが、注文を送信できるかどうかを決める第2の権限元にはしません。

入力形式、オフライン表示、ナビゲーション、アニメーション、端末権限の処理など、一部のロジックはクライアント固有でかまいません。モバイルアプリはオフライン中に下書きをキューへ入れ、Webアプリはすぐ保存することもあります。接続した後は、両方が同じコマンドを同じサーバールールに送る必要があります。

PostgreSQLはAPIの背後に置く

ReactのバンドルもFlutterアプリも、PostgreSQLへ直接接続させてはいけません。どちらも配布されるクライアントであり、コードと接続情報を利用者が調べ、コピーし、変更できます。

PostgreSQLのマニュアルは、クライアント認証を、要求されたデータベースユーザーとしてクライアントを接続させてよいかをデータベースサーバーが判断する処理と説明しています。この仕組みはデータベース接続を守ります。しかし、Aliceが注文42は編集できても43は編集できないことや、古いモバイルビルドが新しいワークフロー遷移を使ってはいけないことは理解しません。アプリケーションの認可はAPIが行います。

Reactからの直接接続は特に成立しません。ブラウザにはデータベースへのネットワークアクセスが必要になり、ダウンロードされるコードに認証情報を含めることになるからです。Flutterにパスワードを埋め込んでも、誰かがアプリを解析するまで隠れるだけです。行レベルセキュリティはPostgreSQL内の防御を増やせますが、信頼できないクライアントを安全なデータベース接続元には変えません。安定したエンドポイント、回数と入力の制限、監査コンテキスト、インストール済みビルドを壊さずスキーマを変える場所は、引き続き必要です。

公開されるアプリケーション境界を1つにした構成を使います。

React client  \n               -> HTTPS API -> domain rules -> PostgreSQL
Flutter client /

APIには制限されたデータベースロールを与えます。移行用の認証情報は実行中のアプリケーションに入れません。移行は独立したデプロイ作業として実行し、専用のレビューと復旧計画を持たせます。この分離により、侵害されたAPIプロセスができることを抑え、クライアントへデータベース認証情報が渡るのを防げます。

2つのAIツールは、それぞれが完全なプロジェクトを作ろうとして、2つのバックエンドを生成することがあります。2つのサービスが意図したドメイン分割でない限り、その出力は採用しません。同じテーブルへ書き込むWeb用とモバイル用のバックエンドは、認可を重複させ、トランザクションを不統一にし、スキーマ変更ごとに2か所の修正点を作ります。クライアントごとに異なる応答形式が必要なら、薄いBackend for Frontendは妥当です。ただし、そのアダプターは同じドメインサービスを呼び、迂回して書き込まないようにします。

単純ですが有効な検査で境界を確認できます。生成されたReactとFlutterのリポジトリから、PostgreSQLの接続文字列、データベースホスト変数、SQLドライバー、高い権限を持つサービス認証情報を探します。クライアントコードで1つでも見つかれば、アーキテクチャレビューは不合格です。クライアント設定にあるべきものは、APIのベースURL、公開してよいID設定、秘密ではない機能設定だけです。

データベース移行には後方互換性も必要です。まずnullを許す列または新しいテーブルを追加し、両方の形式を扱えるコードをデプロイし、必要なら既存データを埋め、読み取りを切り替えます。サポート中のクライアントが依存しなくなってから、古いフィールドを削除します。モバイル配布では、この最後の期間がWebだけのチームの予想より長くなります。

認証の決定元は1つ、クライアントのアダプターは2つ

1つのID発行元、1つのユーザーレコード、1つのサーバー側認可ポリシーを使い、ブラウザとモバイルには別々のセッションアダプターを実装します。認証は呼び出し元が誰かを証明します。認可はその人が何をできるかを決めます。両者を混同すると、有効なトークンを受け入れた後、禁止された操作を隠す責任をクライアントに任せるエンドポイントができます。

Reactクライアントでは通常、ブラウザのリダイレクト、Cookieまたはトークン、サイトをまたぐリクエストへの対策、更新時に競合する複数タブを扱います。Flutterではディープリンク、アプリの一時停止、端末ストレージ、OSのコールバックを扱います。この違いは別のクライアントコードを必要としますが、別のユーザーディレクトリや異なるロールの意味は必要としません。

OWASPのMobile Application Security Cheat Sheetは、認証情報をアプリに埋め込まず、取り消し可能な安全なアクセストークンをプラットフォーム固有の安全な仕組みで保存するよう勧めています。この原則に従う一方で、限界も理解します。安全なストレージはファイルからの安易なトークン盗難を減らします。侵害された端末を信頼できる状態にはしないため、APIは保護対象の操作ごとに有効期限、対象、発行元、アカウント状態、権限を確認します。

どちらかのクライアントで画面を実装する前に、認証契約を書きます。

Access token: short lived, sent to the API
Refresh mechanism: rotated or invalidated by the identity system
Logout: ends the local session and revokes server-side refresh authority
Account disabled: API rejects new operations even if a client still shows cached data
Role changed: next authorized request uses current server policy

最も多くの問題を明らかにするテストは、ログイン成功ではありません。両クライアントを開いたままアカウントを無効にします。次の保護されたリクエストは両方で同じように失敗し、ローカルの非公開データはポリシーに従って消去され、更新処理を無限に繰り返さない必要があります。次にロールを変更し、古い画面から以前の操作を実行できないことを確認します。

古い認可を許容できる時間より長く、ロールの正しさをトークンのクレームに置かないでください。クレームはUIを素早く表示する助けになりますが、重要な操作ではサーバーが現在のポリシーを参照します。ロール変更を直ちに反映する必要があるなら、古いロールを持つ長寿命の自己完結型トークンは、その要件に反します。

ここで1つのビルダーが5点ではなく4点なのは、共通の文脈がプラットフォーム固有のセキュリティ作業をなくさないからです。ビルダーは両方のアダプターを生成できますが、ブラウザのリダイレクト、モバイルのディープリンク、更新処理の競合、時計のずれ、取り消し、端末復元時の動作は、人がテストする必要があります。

1つの契約でReactとFlutterの認識をそろえる

APIの記述を両クライアントのビルド入力とし、リリース済みバージョンへの互換性の約束とします。文章のプロンプトは契約ではありません。同じ文でも2回の生成で異なる解釈ができるからです。

HTTP APIにはOpenAPIが実用的です。リクエストフィールド、レスポンスフィールド、エラー本文、認証要件、安定した操作IDを定義します。その文書から薄いTypeScriptとDartのクライアントを生成または保守し、アプリケーションの動作は通常のReact HookとFlutter Repositoryに置きます。生成されたクライアントコードは交換可能にします。製品の決定をそこへ埋め込んではいけません。

次の断片は、バージョン競合を明示します。

/orders/{orderId}/submit:
  post:
    operationId: submitOrder
    requestBody:
      required: true
      content:
        application/json:
          schema:
            type: object
            required: [expected_version]
            properties:
              expected_version:
                type: integer
    responses:
      "200":
        description: Order submitted
      "409":
        description: Order changed since the client loaded it

信頼できる情報源は、サーバーの動作と確認済みの契約です。生成されたTypeScriptとDartの型はその投影にすぎません。ツールが契約を変えずにクライアントの型を編集した場合、ビルドでその編集を上書きまたは拒否します。

契約テストでは、静的なスキーマで表現できない動作を確認します。空の注文を送信し、両クライアントが作るリクエストで同じエラーコードになることを確かめます。古いexpected_versionでリクエストを再送し、409になることを確かめます。古いクライアントのテストデータへ未知の列挙値を送り、クラッシュせず安全な代替動作を取ることを確認します。

APIは追加型の変更を優先します。未知のフィールドを無視するクライアントなら、新しい任意レスポンスフィールドは通常安全です。フィールドの削除、任意フィールドの必須化、列挙値を別の意味で再利用する変更は、インストール済みのモバイルビルドを壊す可能性があります。意味を保てないときだけエンドポイントをバージョン化します。機械的なバージョン追加は、互換性の負担をさらに多くのディレクトリへ移すだけです。

ドメインモデルをクロスプラットフォームのパッケージで共有するという、よく聞く提案があります。注文、アカウント、請求書が両クライアントに現れるため、効率的に見えます。実際には、TypeScriptとDartのパッケージは、シリアライズ、null、日付、リリースツールを別々に扱う必要があります。1つの契約から転送形式を生成し、各クライアントでローカルのUIモデルへ変換します。定義の共有には意味があります。実行時モデルの共有を強制する必要はありません。

契約があると、2つのツールも使いやすくなります。各ツールが安易に解釈し直せない境界を持てるからです。ただし、両方の生成セッションの外で、契約変更、互換性確認、リリースノートを所有する担当者が必要です。その仕事を誰も持たなければ、契約は実装より遅れます。

リリース工程は独立させる

1つのビルダーが3つを作る場合でも、Webクライアント、モバイルクライアント、APIは別の予定でリリースします。生成を調整することと、デプロイを同時にすることは別です。

Reactはデプロイから数分でユーザーに届くことがあります。モバイルリリースにはストア審査があり、ユーザーが更新を先延ばしにする場合もあります。そのためAPIは、現在のWebビルドと、サポート期間内にあるすべてのモバイルバージョンに対応する必要があります。全クライアントが同時に更新される前提の計画は、最初の審査遅延や段階的公開で破綻します。

変更ごとに互換性マトリクスを使います。

セルに書く言葉は、バージョン番号より重要です。古いクライアントが実際に何をするかをチームに明言させるからです。マトリクスは変更計画に残し、可能な主張はテストへ変換します。

安全な機能公開は、多くの場合、次の順序で進めます。

1. 後方互換性のあるデータベース構造とAPI動作を追加します。
2. 新しいレスポンスを理解するクライアントをリリースし、機能は隠しておきます。
3. 書き込みを有効にする前に、エラーと互換性の兆候を観察します。
4. サーバーが制御する機能またはアカウント設定で有効にします。
5. サポート期間が終わってから古い経路を削除します。

機能フラグは公開範囲を制御するためのもので、非互換なスキーマを修復するものではありません。古いクライアントが新しい必須フィールドや列挙値の解析でクラッシュするなら、起動後にボタンを無効にしても救えません。互換性はペイロード設計に含めます。

2つのツールは、プラットフォーム固有のパッケージングで強みを持つ場合があります。モバイル向けビルダーはストアのメタデータや端末の権限に詳しく、Web向けビルダーはブラウザへのデプロイをうまく扱うかもしれません。その強みが、APIの準備、機能公開、サポート期間を調整する追加作業を上回る場合に限り、2ツール方式のリリース評価を上げます。

ログとエラーレポートにリリース識別子を残します。各APIリクエストに秘密ではないクライアント名とビルド識別子を付ければ、運用担当はブラウザの不具合と古いモバイルの動作を区別できます。この識別子はクライアントが偽装できるため、認可には使いません。

ロールバックには3つの異なる意味がある

クライアント、サーバー、データのロールバックは、それぞれ別の障害を解決し、別の手順を必要とします。全部を1つの「元に戻す」ボタンとして扱うと、復旧できるリリースがデータ損失に変わります。

Reactのデプロイは通常、以前の成果物へトラフィックを戻せます。モバイルのロールバックは、段階的公開を止め、修正版を申請することを意味する場合が多く、更新済みの端末には問題のあるバージョンが残ります。その期間はAPIが両バージョンを許容しなければなりません。

サーバーコードを戻せるのは、データベースが以前のバイナリと互換性を保っている場合だけです。追加型の移行なら通常は可能です。列名をその場で変える、意味を書き換える、データを削除するといった移行では不可能な場合があります。拡張してから縮小する移行を使います。新しい表現を追加し、両方のコードバージョンを動かし、データを移し、読み取りを切り替え、古い表現は後で削除します。

データのロールバックは危険です。データベースのスナップショットを復元すると、その時点以降に行われた正しい書き込みも消えます。多くの本番障害では、前向きな修復のほうが安全です。修正版をデプロイし、監査クエリで影響を受けた行を特定し、限定した補正を行います。スナップショットは大事故への備えですが、可逆な移行の気軽な代用品ではありません。

典型的な失敗を追ってみます。APIのデプロイでdelivery_windowを必須フィールドとして追加します。新しいWebクライアントは送信しますが、審査中のモバイルビルドは送信しません。チームがデータベース列をNOT NULLにすると、古いモバイルからの送信でサーバーエラーが発生します。Webだけ戻しても何も変わりません。古いバイナリが新しいスキーマを読めなければ、APIだけ戻すのも失敗します。データベース全体を復元すると、無関係な注文まで失われます。

適切な復旧では、APIがフィールドの欠落を受け入れ、文書化した既定値を設定するか、移行を延期します。モバイル対応が十分に広がるまでは、そのフィールドを任意として返します。これなら無関係な書き込みを戻さず、影響を受けたレコードだけ修復できます。元の問題はロールバックボタンがないことではありません。互換性のない順序でした。

デプロイ前に、次の4行を書きます。

Web rollback: artifact and routing action
Mobile containment: rollout stop, affected builds, fixed build path
API rollback: compatible binary and schema range
Data repair: query, owner, backup point, and forward correction

1つのビルダーのスナップショットと計画履歴が関連する変更を含むなら役立ちますが、範囲を確認してください。ソースのスナップショット、デプロイ済み成果物、PostgreSQLのバックアップは別の資産です。説得力のあるロールバックテストでは、各資産を使い捨て環境で復元し、古いクライアントが主要な書き込みフローを完了できることを示します。

2つのビルダーは統合の責任を増やす

2つのツールを使っても保守は半分になりません。2つの生成履歴、2組の前提、どちらの外にもある統合面が生まれます。

最初の1か月は、各ツールが得意なプラットフォームのコードを作るため、速く見えることがあります。コストが現れるのは、フィールド名の変更、権限の変更、アカウント状態の追加、ログアウト動作の変更、エンドポイントの廃止など、変更が境界をまたぐときです。各プロンプトに現在の契約と、もう一方のクライアントのリリース状態による影響を含める必要があります。1つ詳細が欠けるだけで、コンパイルは通るが製品の動作に反する、もっともらしいコードができます。

失敗の形は予測できます。Webツールが列挙値にarchivedを追加し、正しく表示します。モバイルツールは未知の値を解析エラーとして扱い続けます。APIが先にデプロイされ、アーカイブ済みレコードがユーザーの一覧に現れると、モバイル画面は全レコードを読み込めなくなります。個々の変更は妥当に見えました。異なるバージョンの組み合わせを誰もテストしていません。

保守には責任者と、繰り返し使える変更資料が必要です。

• 動作の変更と、それを所有するサーバールール
• APIと移行の差分
• Reactの受け入れ条件
• Flutterの受け入れ条件
• リリース順序とロールバックの限界

この資料は1つのビルダーでも有用ですが、1つの計画文脈なら変更全体に結び付けておけます。2つのツールでは、チームが資料をコピーし、両方の出力を記録し、競合する編集を照合する必要があります。自動化はスキーマのずれを検出できます。どちらの解釈が製品に合うかは決められません。

ソースをエクスポートすればツールへの依存が終わるとは考えないでください。エクスポートしたコードは管理権を与えますが、保守性は読みやすい構造、テスト、依存関係の選び方、ビルド手順、変更部分だけを再生成する明確な方法に左右されます。明日ビルダーが消えると想定して、生成プロジェクトを調べます。有能なReact開発者がWebをリリースし、Flutter開発者がモバイルアプリをビルドし、バックエンド開発者が元のチャット履歴なしでPostgreSQLを移行できるでしょうか。

保守は普通の証拠で測ります。契約テストの失敗、生成された変更を照合する時間、再生成で失われる手作業の編集、サポート外のクライアントバージョン、復旧演習の結果です。共有コードの行数のような見栄えだけの指標は避けます。表示用の変換が少し重複しても、巧妙な共有層より安く済むことがあります。

2つのビルダーが妥当になるのは、2つのチームがすでにその方法で働いている場合です。各チームが自分のクライアントを持ち、プラットフォームグループがAPIとIDを持ち、リリース前に自動互換性テストを実行します。この状況ならツールが組織に合います。1人の創業者が、存在しない組織図をまねる必要はありません。

どう判断すべきか

最初の画面を各ツールが描く速さではなく、クライアントをまたぐ変更を1つ実証して選びます。試行にはスキーマ変更、認可ルール、古いモバイルビルド、独立したリリース、ロールバック演習を含めます。

1つのビルダーの候補には、小さな縦方向の機能を作らせます。ReactとFlutterのクライアントから、PostgreSQLを使うGo APIへ同じ注文コマンドを送ります。両方が動いた後でルールを変えます。任意フィールドを追加し、1つのロールを拒否し、Webの変更だけリリースし、新しい行を失わず以前のサーバー成果物を復元します。ソースをエクスポートし、ビルダーの画面外でテストを実行します。

2つのツールの候補には、確認済みのOpenAPI文書を両方へ渡し、同じ手順を実行させます。セッション間でコピーする事実の数と、ツールが境界外を編集する回数を測ります。生成時間だけでなく、ずれの診断時間も含めます。

次の条件を満たすなら1つのビルダーを使います。

• 1つの契約を中心に、React、Flutter、バックエンドを別々のプロジェクトとして作る。
• PostgreSQLをバックエンドの背後に置き、秘密情報をクライアントに入れない。
• クライアントとサーバーの独立したリリースに対応する。
• ソース、デプロイ状態、別々の復旧地点を提供する。
• 生成コードをチャット履歴に頼らずビルドし、テストできる。

専門機能がモバイルまたはWebの結果を実質的に変え、契約管理の責任者が明確な場合は2つを選びます。「モバイルの出力がきれいだった」だけでは不十分です。端末連携、アクセシビリティ、ストア向けパッケージング、オフライン動作、既存のチームスキルは、保守コストを加味しても利点が残るなら理由になります。

Koder.aiは1つのチャット文脈からReact、GoとPostgreSQL、Flutterのアプリケーションを生成でき、計画モード、ソースのエクスポート、デプロイとホスティング、スナップショット、ロールバックに対応しています。この組み合わせは、ここで説明した1ビルダーの構成に合います。それでも縦方向の機能テストは実行してください。機能一覧だけではリリースと復旧の手順を証明できません。

判断は後から変えられます。境界が明確なシステムなら、ビジネスルールをAPIから出さずに、Reactの生成ツール、Flutterの生成ツール、または両方を交換できます。最初のアーキテクチャで、その選択肢を残します。

最後の厳しい確認は単純です。リリース日にモバイルツールが消えても、現在のAPI契約を説明し、エクスポートしたクライアントをビルドし、リリースを続けられるでしょうか。答えが記憶しているプロンプトに依存するなら、別のツールを加える前に責任の所在を直してください。