生成アプリはいつ移行すべきか？

生成されたアプリは、公開前に移せば安く、きれいに済みます。利用が伸びてから移せば、判断材料は増えますが、失敗を許容しにくくなります。適切な時期は、プロジェクトがLovable、Bolt、v0、Replitのどれで始まったかより、現行プラットフォームが管理する状態を持つ境界をすべて把握し、リハーサルできるかで決まります。

私は公開を、ID、データ、公開ドメインがユーザーへの約束になる時点だと考えています。その前なら、移行の失敗は開発時間の損失で済みます。公開後は同じ失敗で顧客が締め出され、書き込みが失われ、セッションが無効になったり、プロダクトの二つのバージョンへトラフィックが流れたりします。利用が伸びれば、残すべきものを判断する根拠は得られます。しかし単なるコード移動が、運用上の変更になります。

ソースツリーの大きさで決めないでください。管理型認証と稼働中のデータベースを持つ小さなアプリのほうが、大きな静的サイトより移しにくいことがあります。所有権で判断しましょう。リポジトリ、ユーザーID、データベース、シークレット、ファイル、定期処理、ドメイン、デプロイ、ロールバック経路を誰が管理していますか？

公開前の移行は自由を買う

現行プラットフォームが所有権、デプロイ、データ所在地、保守性に関する既知の要件を満たせないなら、公開前に移行するのがたいてい良い選択です。ユーザーと交渉せずに、スキーマを変え、認証を置き換え、環境変数の名前を変え、テストデータをリセットできます。

この段階は、シードしたアカウントと使い捨てのレコードしかないアプリにとくに向いています。コードをエクスポートし、クリーンな環境でビルドし、マイグレーションからデータベースを作り直せます。元のワークスペースで暗黙に提供されていた要素も分かります。失敗はどれも有益です。顧客データを抱える前に依存関係を明らかにしてくれます。

時期が早いからといって、作業を省けるわけではありません。生成プロジェクトは、元のプラットフォームが設定を注入し、データベースURLを渡し、関数をホストし、ビルド慣例を理解しているから動くことがあります。ソースをエクスポートできても、ファイルを持っていることしか証明しません。別のホストで同じシステムをビルド、実行できる証明にはなりません。

公開前には、私はクリーンルームテストを必須にします。プロジェクトを作成していないチームメイトに、リポジトリ、安全な開発用の値を含むシークレット一覧、セットアップ手順だけを渡します。その人がログインし、レコードを作成し、主要なユーザーフローを完了できなければ、まだ移植可能ではありません。

待つべき理由もあります。初期プロトタイプはデータモデルが毎日変わることがあり、次のプロダクト判断で移行作業が無駄になるかもしれません。現行プラットフォームが、予定する公開、ソースのエクスポート、デプロイ、カスタムドメイン、信頼できるロールバック経路を支えているなら、小さく公開して学ぶ価値は、誰も欲しがらないプロダクトのインフラを磨く価値を上回ることがあります。

公開前に問うべきなのは「移せるか」ではありません。「移行は既知の公開リスクを取り除くのか。それとも推測を守るために費用を払っているのか」です。具体的な制約があるから移行します。一般的なインフラのほうが立派に感じるから、という理由だけで移行しないでください。

利用の伸びは責任も連れてくる

実際の利用で元の環境が満たせない要件が見えてきたなら、利用が伸びた後の移行には意味があります。ただし、すでに使われている公開上の約束をすべて守る計画が必要です。重要な経路、実際のデータ量、ユーザーが起動するバックグラウンドジョブ、重要な連携が分かっています。その根拠が、想像上のアーキテクチャへの高価な移行を防ぎます。

責任も同じように具体的です。既存のパスワードは引き続き使えるか、ユーザーに管理されたリセット経路を用意しなければなりません。URL、請求書、Webhook、外部キーで公開されるなら、データベースIDは安定している必要があります。アップロード済みファイルには転送計画が必要です。メールリンクとOAuthコールバックは正しいドメインを指す必要があります。コピー中に発生する書き込みは新しいデータベースへ届くか、意図的に停止しなければなりません。

利用の伸びに単一のしきい値はありません。給与計算にアプリを使うアクティブな顧客10社の移行リスクは、静的カタログを読む1万人より大きいことがあります。アカウント数ではなく、状態と結果を数えてください。1分あたりに変わるデータ量、重複操作のコスト、影響を受ける全ユーザーへサポートが届く速さ、事業がメンテナンス時間を許容できるかを考えます。

この段階でチームは、観測した需要とアーキテクチャを変える許可を混同しがちです。ユーザーが増えても、書き直しが自動的に正当化されるわけではありません。エクスポートしたアプリが理解でき、現行サービスを境界ごとに分けられるなら、スタック全体を置き換えるより段階的な移行のほうが安全です。

利用が伸びた後の移行を承認する前に、私は所有権マップを書面で求めます。

• ソースリポジトリとビルドプロセス
• ユーザーディレクトリと有効なセッション
• 主データベース、ファイル、バックアップ
• シークレット、定期ジョブ、外部向けWebhook
• ドメイン、メール送信者レコード、監視、ロールバック権限

空欄は切り替え当日に詰める細部ではなく、進行を止める要因です。プラットフォーム名が重要なのは、これらの資産のエクスポートや再設定の方法を変えるときだけです。

認証はIDの移行

認証は、後から作り直せるログイン画面ではなく、IDと信頼ルールの移転として扱ってください。見えるフォームは簡単な部分です。パスワードハッシュ、プロバイダーのsubject ID、確認済みメールの状態、多要素認証の登録、復旧手段、セッション、認可ロールが、実際の継続性を担います。

まず、アプリがユーザーテーブルを所有しているか、管理型サービスにIDを委ねているかを確認します。ユーザーをエクスポートできるなら、利用可能なフィールドと、移行先へパスワードハッシュをインポートできるかを調べましょう。どちらもハッシュと呼ばれていても、互換性があるとは限りません。移行先が完全に同じアルゴリズムとパラメータを支えなければ、全パスワードをリセットする必要があります。

ソーシャルログインには別のID境界があります。OAuthプロバイダーは通常、安定したプロバイダー固有のsubject識別子を返します。新実装がメールアドレスだけでアカウントを対応付けると、アドレス変更時やプロバイダーごとに別名が返る場合に、誤って人を統合しかねません。発行者、プロバイダーsubject、ローカルユーザーIDの組を保持してください。切り替え前にコールバックURLを再登録し、新規ログインと既存アカウントの両方をテストします。

OWASPのSession Management Cheat Sheetは、権限変更後にセッション識別子を更新するよう勧めています。移行そのものは権限変更ではありませんが、この助言は大切な境界を示します。セッション状態はセキュリティ状態です。ある認証スタックの不透明なCookieを、別のスタックでシリアライズしようとするのは、たいてい割に合いません。完全に理解しているなら旧検証機構を一時的に維持し、そうでなければセッションを失効させて、再ログインが必要だと伝えてください。新サービスが検証できないCookieを黙って受け入れてはいけません。

Cookieのスコープは、他が正しい移行でも壊すことがあります。新ホストが出すCookieの名前、ドメイン、パス、Secure、HttpOnly、SameSite属性を確認してください。MDNのSet-Cookieリファレンスによると、Domain属性を持つCookieはそのドメインとサブドメインで利用でき、省略した場合は設定したホストに限定されます。旧アプリでWeb画面とAPIに別ホストを使っていたなら、この違いが重要です。古いCookieによって新しいフローが正常に見えないよう、新しいブラウザープロファイルでテストしましょう。

認可は別に比較する価値があります。ユーザーは認証に成功しても、組織のメンバーシップ、管理者ロール、サブスクリプションの権利、行レベルポリシーを失うことがあります。異なるロールのアカウントをサンプルとしてエクスポートし、データ移行前に期待するアクセスのテストを書いてください。ログイン成功画面だけでは、ほとんど何も証明しません。

公開前の移行では、今のうちにIDシステムを置き換え、テストユーザーを削除することを私は勧めます。利用が伸びた後なら、継続性の方針を一つ明示的に選びます。

• 互換性のあるパスワードハッシュをインポートし、プロバイダーIDを保持する。
• アプリを移す間、旧IDサービスを維持する。
• 有効期限付きで一度だけ使えるトークンによるリセットを求める。
• 書き込みの権限を一方に定め、短期間の二重読み取りブリッジを動かす。

書き込み可能なユーザーディレクトリを二つ運用してはいけません。メールアドレス変更やアカウント削除依頼の競合は、この一時的な便利さを障害に変えます。

データベース転送では意味を保つ

データベース移行が成功するのは、移行先が制約、識別子、タイムスタンプ、関係、移行中に受け付けたすべての書き込みを保つときだけです。行数は弱い確認です。二つのデータベースが同じ行数でも、金額の精度、タイムゾーン、一意性、NULLの扱い、外部キーで食い違うことがあります。

公開前は、開発用データベースをコピーするのでなく、バージョン管理したマイグレーションからデータベースを作り直してください。アプリに必要なレコードだけをシードします。このテストは、スキーマ履歴が完全であり、ホスト型コンソールで誰かが手作業で作ったテーブルにアプリが依存していないことを示します。

利用が伸びた後は、スキーマ移行と実データ移行を分けます。移行元のエンジンとバージョン、拡張機能、照合順序、生成列、トリガー、行レベルポリシー、シーケンス、大きなオブジェクトを記録してください。移行先のデータベースエンジンが異なるなら、アプリ移行としても扱います。SQL構文は変更のごく一部です。トランザクションの振る舞いと型の意味で厄介な問題が起こります。

PostgreSQLのドキュメントは、pg_dumpを読み取りや書き込みを止めない一貫性のあるエクスポートとして説明しています。これは便利ですが、チームはこの約束を読み込みすぎることがあります。一貫性のあるスナップショットには、スナップショット開始後にコミットされた書き込みは含まれません。この差を埋めるには、変更キャプチャ、最終的な書き込み停止、またはメンテナンス時間が必要です。

切り替え記録とともに保存できる照合クエリを使いましょう。この断片は、重要な三つのテーブルについて、件数、識別子の範囲、更新時刻の範囲を確認します。

SELECT 'users' AS table_name, count(*) AS rows,
       min(id)::text AS min_id, max(id)::text AS max_id,
       max(updated_at) AS newest_update
FROM users
UNION ALL
SELECT 'projects', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM projects
UNION ALL
SELECT 'orders', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM orders;

両側で実行し、差があればすべて調べてください。次に、件数だけでは見えない業務上の不変条件をテストします。欠けたユーザーを指す注文がないこと、残高と台帳が一致すること、各ファイルレコードにオブジェクトがあること、一意性ルールが同じ重複を拒否することです。

バックアップには復元テストが必要です。エクスポートファイルができたことは、コマンドが終了した証拠にすぎません。空の移行先に復元し、その上でアプリを動かし、所要時間を測ってください。測定した復元時間が、復元によるロールバックが現実的か、気休めにすぎないかを教えてくれます。

ファイルストレージは、データベース行の背後に隠れがちです。エクスポートしたuploadsテーブルにはオブジェクト名が残っていても、実際のオブジェクトはプラットフォーム管理のバケットに残ります。バイト列、チェックサム、コンテンツタイプ、アクセスルール、所有権メタデータをコピーし、ストレージコンソールではなくアプリ経由でダウンロードをサンプリングしてください。URLに署名トークンや旧ホスト名が含まれるなら、古いURLをコピーせず再生成します。データベースコピー中にユーザーがファイルを差し替えられるなら、ユーザーアップロードも同じ切り替え時間帯の状態として扱います。

環境変数は隠れたアーキテクチャを明かす

環境変数を、受け継いだ文字列の寄せ集めから、環境ごとに名前を持つ契約へ変えてください。欠けた変数は分かりやすく失敗します。より危険なのは、テスト用決済キー、古いWebhookシークレット、ユーザーを旧ホストへ戻すコールバック元のように、もっともらしいが誤った本番値を持つ変数です。

コード、プラットフォーム設定、ビルド設定、サーバーレス関数、定期ジョブ、デプロイシステムから変数を棚卸しします。古い環境全体を新ホストへコピーしてはいけません。各値を、所有者、機密性、適用範囲、ローテーション方法、ビルド時に読むか実行時に読むかで分類します。

簡潔なマニフェストがあれば、境界をレビューできます。

DATABASE_URL          runtime   secret   owner=backend   rotate=yes
PUBLIC_APP_ORIGIN     build     public   owner=web       rotate=no
SESSION_SIGNING_KEY   runtime   secret   owner=security  rotate=yes
MAIL_SENDER           runtime   public   owner=ops       rotate=no
WEBHOOK_SECRET        runtime   secret   owner=backend   rotate=yes

React系フロントエンドでは、ビルド時と実行時の違いが重要です。ビルド中に埋め込まれた値は、誰かが実行時設定を変えても変化しません。クライアントを再ビルドし、配信されたバンドルに公開設定が含まれることを確認してください。フレームワークの公開用プレフィックスで始まる名前だからといって、シークレットを変数に入れてはいけません。

利用が伸びた後の移行では、移行先で重複期間を支えられるならシークレットをローテーションします。Webhook検証やセッション署名では、旧シークレットと新シークレットを短期間受け入れ、新しいものだけを発行します。最大配信時間またはセッション時間を過ぎたら旧値を削除します。プロバイダーがシークレットを一つしか支えないなら、最終切り替えと調整し、依存関係を手順書に明記してください。

公開前は未使用変数を削除し、必須値が欠けていれば起動に失敗させます。利用が伸びた後は、整理の前に可観測性を加え、廃止したように見える連携がまだ呼び出されていないか確認します。変数名から推測すると、経理が実際に必要としている静かな月次ジョブを止めることになります。

環境ごとに値を比較しますが、移行文書にシークレットを貼り付けてはいけません。シークレット名とバージョンラベルを記録し、値は移行先のシークレットストアに保管します。アプリのIDには、そのデプロイに必要なものだけを読める権限を与えてください。変数が変わったら、変更者と消費したリリースを記録します。この小さな規律が、切り替え当夜のよくある質問「実際にどのデータベースURLをデプロイしたのか」に答えます。

ドメイン切り替えはトラフィック制御の変更

DNS伝播中、旧デプロイと新デプロイの両方が安全にトラフィックを受けられるよう、ドメイン切り替えを設計してください。DNSは一斉には切り替わりません。変更の直前にTTLを下げても、すでに古い値をキャッシュしたリゾルバには影響しません。

予定した移行の数日前に該当レコードのTTLを下げ、権威DNSの応答を確認します。少なくとも以前のTTLに慎重なリゾルバの余裕を加えた期間は、旧デプロイを健全に保ってください。トラフィックを向ける前に新ホストで証明書を準備し、apexドメイン、wwwホスト、APIサブドメイン、リダイレクト、IPv6レコードを別々に検証します。

ドメインは玄関にすぎません。認証コールバック、許可するオリジン、Cookieドメイン、正規URL、Webhookエンドポイント、メールリンク、モバイルのディープリンク設定を更新してください。リポジトリとプラットフォーム設定から旧ホスト名を検索します。リダイレクトはブラウザーには役立ちますが、厳格なOAuthコールバックの不一致や、誤ったエンドポイント向けに署名されたWebhookは直せません。

停止時間ゼロが可能なのは、両バージョンが互換性のある状態で動ける場合だけです。新リリースが旧コードで読めないデータベース変更を含むと、DNSの重複期間に障害が起きます。expand-and-contract方式のスキーマ変更を使いましょう。まず新しい列やテーブルを追加し、両方の形式を理解するコードをデプロイし、データを移してから、すべてのトラフィックが旧リリースを離れた後に旧形式を削除します。

低トラフィックのプロダクトでは、複雑なライブレプリケーションより短いメンテナンス時間のほうが安全なことがあります。いつ書き込みを止めるかを伝え、適切なメンテナンス応答を返し、バックグラウンド処理を排出し、最終コピーを取り、照合し、トラフィックを切り替え、書き込みを再開します。隠れた処理をキューに入れないなら、読み取り専用アクセスは残せます。

ロールバックにはデータのルールが必要です。移行先に書き込みが届いていなければ、DNSを戻すのは簡単です。ユーザーが両側に書き込んだ後では、DNSを戻すとデータを捨てたり分岐させたりしかねません。安全にロールバックできる最後の時点を定め、その後はトラフィックの逆転で整合性が戻るふりをせず、前進するか変更を照合します。

新しいホスティングアカウントの外からアプリを監視してください。複数の公開リゾルバでドメインを解決し、証明書チェーンを要求し、温かいキャッシュなしでページを開き、元に戻せるトランザクションを一つ送信し、結果のバックグラウンド処理が完了することを確かめます。ホストのダッシュボードがデプロイを正常と示しても、ユーザーは古いDNS応答を受けたり、地域のエッジが古いビルドを返したりします。重複期間が終わるまで、公開ドメインと移行先固有のテストホストの両方に対する合成チェックを動かします。

ソースの整理が移行の持続性を決める

ソースの整理では、便利な生成構造を消したり、無関係な書き直しを始めたりせず、プラットフォームとの結びつきを取り除くべきです。生成コードは重複が多かったり扱いにくかったりしますが、見た目が気に入らないことは移行要件ではありません。独立したビルド、テスト、セキュリティレビュー、将来の保守を妨げる部分を変えてください。

まず来歴を確認します。リポジトリ全体をエクスポートし、ライセンスファイル、アセットの帰属表示、生成されたマイグレーション、ロックファイル、設定を残します。シークレットやプラットフォームトークンがGit履歴に入っていないか確認してください。最新ファイルから消しても無効化にはならないため、露出した認証情報をローテーションし、履歴を書き換えるべきか判断します。

次に、プラットフォーム固有のimport、プロキシパス、データベースクライアント、認証ヘルパー、ストレージアダプター、デプロイファイル、生成されたAPIエンドポイントを探します。可能であれば、狭いアプリケーションインターフェースの背後で置き換えます。リポジトリ全体の検索は有用ですが、ユーザーフローを実行して初めて、どの参照がまだ重要か分かります。

依存関係の整理は、独立したビルドが動いてから行います。パッケージを一度に一つずつ削除し、既存のパッケージマネージャーでロックファイルを再生成し、各グループの後にテストを実行してください。同じ変更でフレームワークを更新し、状態管理を置き換え、全コンポーネントを改名し、ホスティングを移行してはいけません。一つの失敗に対する説明が多すぎます。

生成されたサーバーコードは、信頼境界で特に注意深く確認します。すべてのリクエストを、ルートから認可チェック、データベースクエリまで追跡し、サーバーがクライアント側の表示ルールに依存していないか検証してください。アップロード上限、外部リクエストの宛先、エラーメッセージ、管理ルートをレビューします。これは生成ハンドラーをすべて書き直す呼びかけではありません。プラットフォームのミドルウェアと管理型プロキシがなくなった後も、コードがアクセスルールを守るかを絞って確認する作業です。

生成プロジェクトには、通常の運用ファイルも必要です。偽の値を含む環境変数マニフェストの例、データベースマイグレーションのコマンド、ビルドと起動の手順、ヘルスチェック、バックグラウンドワーカーの説明です。これらの手順は実行できる状態に保ちます。「データベースを設定する」とだけ書かれたREADMEは、データベースがあることしか記録していません。

公開前の整理では、互換性の約束がないためスキーマのリセットや大規模リファクタリングもできます。利用が伸びた後の整理では、インフラ移行が落ち着くまで公開APIの形、識別子、ユーザーに見える動作を保ちます。新デプロイには、プロダクトの動作を変える前の静かな期間を与えてください。移行と再設計が同時に来ると、サポートは苦情が移行によるものか新機能によるものか判別できません。

リハーサルが停止時間を判断可能にする

移行リハーサルでは、最近の匿名化済みデータコピーを使って本番の順序を再現し、測定した所要時間、照合結果、検証済みの中止地点を出すべきです。他プロジェクトから写したチェックリストでは、自分のデータベースの復元時間や、メンテナンスモード開始後も書き込み続けるジョブは分かりません。

一人が実行し、もう一人が観察、時間記録、飛ばされた確認の指摘を担当します。小さなチームなら二人目は創業者でも構いませんが、結果の変化に気付けるだけの文脈が必要です。コマンドを打つ人が、そのコマンドの成功を判断する唯一の人でもあってはいけません。

実用的な手順書には厳格な順序があります。

1. 関係のないデプロイを凍結し、現行のバージョン、DNS値、シークレットのバージョンを記録する。
2. 書き込みをメンテナンスモードにし、キューを排出し、定期ジョブを停止して、最終的な移行元ウォーターマークを記録する。
3. 残りのデータをコピーし、テーブルと業務上の不変条件を照合してから、認証と主要なユーザーフローをテストする。
4. トラフィックを切り替え、証明書とコールバックを確認し、エラーとキュー深度を監視してから、書き込みを再開する。
5. 宣言したチェックポイントで、新システムを継続するか、文書化されたロールバックのデータルールを実行する。

公開前は、移行先を破棄し、リポジトリから作り直すことでリハーサルします。目標は再現性です。本番に似せたコピーより、空のデータベースと新しい環境のほうが多くを明らかにします。

利用が伸びた後は、規模と同時実行性をリハーサルします。遅いインデックスや長時間のマイグレーションが表れるだけの代表的なデータをコピーしてください。あれば安全な読み取りトラフィックを再生し、既知の識別子を持つ合成書き込みを作り、リトライを許可する前にバックグラウンドジョブが冪等であることを確認します。データベースの整合性が保たれたからといって、メールジョブが二度送られても無害ではありません。

書き込み停止時間は、メンテナンス時間全体とは分けて測定します。多くの場合、移行元を稼働させたまま大量コピーを実行し、差分と検証のためだけに書き込みを止められます。リハーサルで、許容時間内に差分が終わらないと分かったなら、レプリケーションか変更キャプチャを加えてください。顧客を待たせてから、その要件を知ってはいけません。

移行後も証拠を保管します。移行元と移行先のバージョン、タイムスタンプ、行の確認結果、スモークテスト結果、DNS応答、担当者の判断、旧サービスを無効にした時刻です。この記録はデバッグを速め、次の移行計画が誰かの記憶に頼るのを防ぎます。

可逆性で段階を選ぶ

最適な移行段階は、現実的に起こしうる失敗をまだ元に戻せる段階です。公開前のプロダクトには判断材料が少ない一方、ほぼ無制限の自由があります。利用が伸びた後のプロダクトには根拠がありますが、移行中ずっと一貫性を保つべき状態を抱えています。

私は六つの判断基準を使います。

• 既知のコンプライアンス、所有権、エクスポート、ホスティング、アーキテクチャの制約が予定した公開を妨げるなら、公開前に移行する。
• プラットフォームが現在のニーズを満たし、チームが不安だけを理由に移行しようとしているなら、そのまま公開する。
• 計測した利用で制約が明らかになり、ID、データ、トラフィックの継続性をリハーサルできるなら、利用が伸びた後に移行する。
• 復元可能なデータベースをエクスポートできない、ドメインを管理できない、シークレットを列挙できない、書き込みの所有者を定められないなら、延期する。
• 認証やデータを一時的に残しつつコンピュートとホスティングを移せるなら、段階的な分離を選ぶ。

Lovable、Bolt、v0、Replitはいずれも、移植性が選択した正確なサービス、利用プラン、その時点で生成されたコードに左右されるプロジェクトを作れます。実際のリポジトリとアカウントの管理機能を調べてください。ベンダーの分類だけでは、特定のパスワードハッシュ、データベース拡張、ファイル、デプロイ設定を移せるかは分かりません。

新しいチャット型開発環境を選ぶなら、計画とロールバックの管理機能が、移行をレビュー可能な変更へ分けるコストを下げます。Koder.aiはソースのエクスポート、デプロイとホスティング、カスタムドメイン、スナップショットとロールバックに対応しているため、記事の助言を一つのプラットフォームに依存させず、こうした所有権の確認を移行計画に組み込めます。

移行しないと決めても、公開前に移行予算を決めてください。ソースを自分たちの管理下に置き、スキーマをバージョン管理し、環境の契約を文書化し、復元をリハーサルします。アプリが小さいうちなら、これらの行動にかかる費用ははるかに少なく、危機ではなく利用の伸びが理由になったときに移行する選択肢を保てます。

チームが今日その復元を実行できないなら、移植性はアプリの性質ではなく、まだ意図にとどまっています。