Replitアプリがプレビューでは動くのに公開後に壊れる？創業者のためのチェックリスト

Replitでアプリをテストし、誰かにリンクを送ったところ、すぐに「ログインできない」「保存できない」「決済が通らない」と言われた。Agentにそれらの機能を作り直させる前に、このReplit本番デプロイ・チェックリストを使ってください。2つの環境の違いが原因であれば、新たな実装をしなくても障害を説明できる可能性があります。

なぜReplitのプレビューでは動くのに本番で失敗するのか？

Replitのプレビューと公開アプリは別々の環境です。本番アプリは、編集中のプロジェクトとはURL、設定、データ、実行時の挙動が異なる場合があります。

Replitの公開ガイドによると、公開すると本番デプロイが作成され、その後の編集は再度公開するまで本番に反映されません。まず、意図したリリースをテストしているかを確認してください。公開URL、最後に公開した日時、失敗する操作、そして新しいブラウザセッションでも同じ障害が起きるかどうかを記録しましょう。

無関係なスクリーンショットを5枚集めて、Agentにアプリ全体を直すよう頼むのはやめましょう。障害を1つに絞ります。たとえば「新規顧客が保存を押すとエラーになる」といった具合です。期待した結果、実際の結果、発生時刻を記録してください。そうすれば、公開アプリのログと照合できる具体的な手がかりが得られます。

アプリは適切なデプロイタイプを使っているか？

デプロイは、アプリが実行するプログラムの種類に対応している必要があります。静的ファイルの集合とフルスタックアプリケーションでは、ホスティングの要件が異なります。

2026年10月時点で、Replitのデプロイタイプに関するドキュメントでは、Autoscale、Static、Reserved VM、Scheduledの各デプロイが区別されています。Publishing設定でデプロイタイプを確認し、アプリが実際に必要とするものと比較してください。

同じドキュメントには、Replit Agentで作成したアプリはバックエンドを必要とするため、Staticとは互換性がないと記載されています。アプリをカスタマイズしている場合は、ビルドコマンドと実行コマンドを開発者に確認してもらいましょう。より大きなマシンを購入しても、存在しないサーバールートや誤った起動コマンドは直りません。

必要な本番シークレットは本当に利用可能か？

公開アプリが使用する認証情報と設定を、その名前と想定する環境も含めて確認してください。開発中にキーが使えていたからといって、本番の連携が正しく設定されている証拠にはなりません。

ReplitのSecretsガイドでは、Publishing → Adjust settings → Production app secrets から設定するよう案内されています。また、機密性の高いシークレットと機密性のない設定値も区別されています。値をトラブルシューティング用のプロンプトにコピーすることなく、そこで必要な項目を確認してください。

1. 必要な変数名の一覧、それぞれがどこで読み込まれるか、ビルド時と実行時のどちらで使われるかを確認してもらう。
2. 本番の項目がそれらの名前と完全に一致し、意図したプロバイダーのアカウントに属していることを確認する。
3. サーバーの認証情報はサーバー側に置く。フロントエンドの変数やブラウザ向けバンドルはシークレットの保管場所ではない。
4. プラットフォームやビルドプロセスで必要な場合は再公開し、公開URL上で元の操作を繰り返す。

公開アプリは意図したデータベースを読んでいるか？

本番でレコードが表示されないことをUIの不具合と判断する前に、本番のデータベースを特定してください。開発環境で見えているサンプルデータは、顧客向けアプリが読み込むデータとは限りません。

Replitの開発用・本番用データベースのガイドでは、環境が分かれていること、そして現行インフラとレガシーインフラで設定手順が異なることが説明されています。Databaseツールでの本番の選択状況と、自分のアプリに該当する公開設定を確認してください。別世代のプロジェクト向けのチュートリアルが自分のプロジェクトに当てはまると思い込まないようにしましょう。

架空のディレクトリアプリで考えてみます。プレビューでは10件の店舗が表示されるのに、本番サイトでは1件も表示されません。一覧コンポーネントを作り直す前に、本番に承認済みの店舗レコードが存在するかを確認してください。足りないのは、意図的なデータインポートや初期化の手順かもしれません。コピーするのは本番で使って問題のないデータだけにし、インポートやスキーマ変更の前には既存の顧客レコードを保護しましょう。

書き込みに失敗する場合は、その操作と機密情報を除いたエラーを収集してください。そのうえで、接続障害なのか、テーブルの欠如なのか、制約違反なのか、認可の問題なのかを開発者に切り分けてもらいましょう。接続文字列を何度も変更すると、元の問題が見えにくくなり、開発作業を誤ったデータに向けてしまうおそれがあります。

ファイルや外部コールバックは公開ドメインで機能するか？

アップロードされたファイルの保存先と、外部サービスが呼び出すドメインを確認してください。どちらもプレビューでは正しく見えても、公開アプリには適していないことがあります。

アップロードについては、Replit App Storageが永続的なオブジェクトストレージを提供しています。実行環境のフォルダに書き込んだファイルが、プロダクトに必要な永続性やアクセス制御を備えていると決めつけず、現在の実装を確認してください。管理された形でリリースした後、ファイルのアップロード、取得、アクセス制限をテストしましょう。

ログインプロバイダー、決済のWebhook、メール内のリンクについては、許可されたオリジン、登録済みエンドポイント、リダイレクト先URLを各プロバイダーの設定で確認してください。必要な箇所では、意図した公開ドメインを指している必要があります。アプリを離れ、プロバイダー側の操作を完了し、意味のある画面に戻ってくるまでの往復全体をテストしましょう。

サービス、環境、公開コールバックのパス、シークレット名、担当者をまとめた小さな連携一覧を用意しておきましょう。この一覧に含めるのは設定に関する事実であり、シークレットの値ではありません。後でドメインを変更したり引き継ぎをしたりする際のレビューがずっと楽になります。

本番での修正はどう検証すべきか？

公開URL上で元の操作を再現し、対応する本番の証跡を確認してください。公開が成功したということはリリースが完了したという意味であり、顧客のすべてのワークフローが成功したことの証明にはなりません。

Replitのモニタリングガイドでは、リクエストのステータス、応答時間、リソース使用量、アプリケーションログについて説明されています。失敗した操作のタイムスタンプを使って調査範囲を絞り込みましょう。リソース使用量の高さとアプリケーションエラーは別の所見なので、キャパシティを変更する前に原因を診断してください。

1. 公開ドメイン上で新しいアカウントを使い、失敗していた操作をまったく同じ手順で繰り返す。
2. ページを再読み込みした後、意図したレコードや連携の結果が存在することを確認する。
3. 対応するサーバーリクエストやログを確認し、その周辺の失敗ケースも安全にテストする。
4. 主要な操作をスマートフォンでも繰り返し、以前から動いていた挙動が引き続き機能することを確認する。

それでもデプロイに開発作業が必要な場合は？

設定の確認で障害が解消しない場合は、壊れている特定の境界に絞って開発の範囲を決めましょう。再現手順、デプロイ設定、機密情報を除いたエラー、関係するサービスの全体図を用意してください。

利用者を広げる前には、より包括的なAI MVP本番チェックリストを、プロンプトを繰り返すたびに新たな不具合が生まれている場合は修正ループのガイドを活用してください。次のバージョンのレビューやリリースのサポートが必要なら、Replitアプリについての相談を予約してください。必要なのが設定の修正なのか、的を絞ったコード変更なのか、より大きなリリース計画なのかを一緒に見極めます。