AIアプリビルダーで構築されたアプリのデプロイ方法

動作するアプリを生成しました。次に、実際のユーザーがそれに触れるかどうかを決定する部分、つまりデプロイが来ます。このガイドでは、プラットフォームでのワンクリックホスティングとコードをエクスポートしてセルフホストするという両方の実用的なパス、およびライブデモと信頼性の高い本番システムを区別する環境、データベース、ドメイン、ロールバックの決定について説明します。

デプロイは単一のボタンではありません。一連の決断です。AIアプリビルダーは足場の多くを取り除きますが、運用上の懸念事項（シークレット、データ、ドメイン、リカバリ）は、すべてのソフトウェアチームが直面する同じものです。何かを出荷する前に、次のことを行ってください。 デプロイ前チェックリスト そして実行する 生成されたコードのセキュリティ監査。レビューされていないアプリをデプロイすることは、最も一般的な回避可能な間違いです。

ステップ1：ホスティングモデルを選択する

大きく分けて2つの道があり、利便性と制御性をトレードオフします。

プラットフォームでのワンクリックホスティング

ほとんどのAIビルダーは、生成したものをホストできます。デプロイをクリックすると、プラットフォームがURLをプロビジョニングし、フロントエンドをビルドし、バックエンドサービスを実行します。これは最速のルートであり、プロトタイプ、内部ツール、初期ローンチに適したデフォルトです。インフラストラクチャの制御の一部を放棄しますが、メンテナンスされたランタイム、自動ビルド、通常は管理されたデータベースを獲得します。

コードのエクスポートとセルフホスティング

2つ目の方法は、ソースをダウンロードして、自分が管理するインフラストラクチャ（クラウドVM、コンテナプラットフォーム、またはバックエンドランタイムと組み合わせた静的サイトプロバイダなどの管理ホスト）にデプロイすることです。カスタムインフラストラクチャ、コンプライアンスの境界、またはジェネレーターが再度触れないコードを変更する機能が必要な場合は、これを選択してください。コミットする前に、実際にすべてをエクスポートできることを確認してください。参照： コードを本当に所有しているかどうか。まだ広くアプローチを検討している場合は、 AIビルダー、ノーコード、手書きコードの比較 を最初に読む価値があります。

ステップ2：実際に何をデプロイしているのかを理解する

AI生成アプリは通常、異なるライフサイクルを持つ2つの部分で構成されます。

• 静的フロントエンド — HTML、CSS、およびコンパイルされたJavaScript。これは ビルド 一度ビルドされ、ファイルとして提供されます。CDNまたは静的ホスト上に置くことができ、ほぼ無料でスケールします。
• バックエンドサービス — API、認証、およびビジネスロジックで、 実行 継続的に実行され、永続的なプロセス、データベース接続、およびシークレットが必要です。

この区別が重要なのは、 ビルド時 および ランタイム 懸念事項は異なります。ビルド時はコードがコンパイルされバンドルされるタイミングで、ビルド変数は組み込まれ、再ビルドなしには変更できません。ランタイムはサーバーが実行されるタイミングで、ランタイム変数（データベースURL、APIキー）はライブで読み取られ、再ビルドなしにローテーションできます。シークレットをビルド時のフロントエンド変数に入れると、出荷されたバンドルを見る誰にでも公開されます — これは頻繁に発生する重大なエラーです。

ステップ3: 環境変数とシークレットを設定する

Never hardcode credentials in source, and never commit a real .env file. Instead:

• コミットされたものを保持する 例 必要なキーをプレースホルダ値と共に列挙したファイルを作成し、実際の値はホストのシークレットマネージャーや環境設定で提供します。
• 分離する 公開 設定（フロントエンドに公開しても安全で、慣例的に接頭辞が付けられることが多い）を 非公開 シークレット（データベースパスワード、APIキー、署名シークレット）はサーバーサイドのみに留める必要があります。
• 使用する 環境ごとに異なるシークレット — 開発、ステージング、本番は決してキーを共有すべきではありません。
• チャット、スクリーンショット、生成されたサンプルに一度でも登場した認証情報はすべてローテーションしてください。

ステップ4: 実際のデータベースに接続しマイグレーションを実行する

生成されたアプリは多くの場合、再起動のたびにリセットされるローカルまたはインメモリデータベースから始まります。本番では永続的で管理されたデータベースが必要です。

1. 管理されたデータベースをプロビジョニングする （PostgresやMySQLが一般的です）そしてその接続文字列をコピーします。
2. 接続文字列を設定する ランタイムシークレットとして — ビルド変数ではありません。
3. マイグレーションを実行する テーブルとインデックスを作成します。手作業でテーブルを編集するのではなく、アプリに付属のマイグレーションツールを使用し、スキーマ変更がバージョン管理され繰り返し可能になるようにします。
4. マイグレーションが追加的で元に戻せることを確認します。 列の名前変更や削除よりも追加を優先します。破壊的な変更は、実データが存在するとロールバックが困難です。
5. 必要なものだけシードする 実際のユーザーが来る前にバックアップが有効になっていることを確認します。

まずステージングコピーで完全なマイグレーションをテストします。空のデータベースで動作するマイグレーションでも、本番データに対しては失敗する可能性があります。

ステップ5: デプロイ — 基本の手順

選択したホストに関わらず、信頼性のある順序は同じです。

1. まずステージングにデプロイする。 本番環境をビルドが最初に実行される場所にしてはいけません。
2. すべてのランタイムシークレットと本番データベースURLを設定する 最初のデプロイ前にホストに設定します。
3. ビルドをトリガーする ログを監視します。ここでのビルド失敗は通常、依存関係の欠落かビルド変数の欠落が原因です。
4. データベースマイグレーションを実行する 対象のデータベースに対して。
5. バックエンドサービスを起動する エラーなく起動することを確認します — クリーンビルドでも、設定値が悪ければランタイムでクラッシュすることがあります。
6. フロントエンドを公開する 正しいバックエンドURLを指していることを確認します。
7. 本番環境に昇格する ステージングでのスモークテストに合格した後にのみ。

ステップ6: カスタムドメイン、DNS、HTTPSを追加する

アプリはプラットフォーム提供のURLで起動します。独自ドメインを使用するには：

• DNSをホストに向ける。 Add the records your provider specifies — typically a CNAME for a subdomain like app.yourdomain.com, or A/ALIAS records for a root domain. DNS changes can take minutes to hours to propagate.
• HTTPSを有効にする。 ほとんどのホストはDNSが解決されると自動的にTLS証明書を発行・更新します。すべての通信をHTTPSで提供します。セキュアクッキーや多くのブラウザ機能にはHTTPSが必要です。
• アプリの許可されたオリジンとコールバックURLを更新する （CORSおよび認証リダイレクト）を新しいドメインに合わせます。そうしないと、ログインやAPI呼び出しが暗黙的に失敗します。

ステップ7: CI/CDとロールバック計画を設定する

手動デプロイは最初のリリースでは問題ありませんが、その後は面倒になります。

継続的デリバリーの基本

メインブランチへのプッシュでテスト、ビルド、デプロイが自動的に実行されるようにリポジトリを接続します。デプロイ前にテストステップが成功することを必須にします。本番デプロイはレビューまたは保護ブランチの後ろにゲートし、未検証のものがリリースされないようにします。

ロールバック戦略

決定する 前に リリース時に悪いリリースを元に戻す方法を：

• 以前のビルドをデプロイ可能な状態に保ちます。 ほとんどのプラットフォームでは、以前のバージョンを即座に再プロモートできます。そのボタンの場所を把握しておきましょう。
• リリースにタグを付ける これにより、本番環境で何が動いているかを正確に特定できます。
• データベースマイグレーションは難しいケースとして扱います。 コードは数秒でロールバックできますが、スキーマやデータの変更はそうではない場合があります。古いビルドが新しいスキーマでも動作するように、後方互換性のあるマイグレーションを出荷してください。

ステップ8: デプロイ後のスモークテストを実行する

公開直後に、重要なパスを手動で確認します:

• カスタムドメインでHTTPS経由でホームページが読み込まれること。
• サインアップとログインが機能し、ドメインへのリダイレクトも含めて動作すること。
• 作成/読み取り/更新/削除のフローが実際のデータベースにデータを永続化し、リフレッシュ後も保持されること。
• 外部統合（支払い、メール、サードパーティAPI）が本番キーで応答すること。
• エラーモニタリングとログがイベントをキャプチャしているため、ユーザーが報告する前に問題を発見できます。

これらのいずれかが失敗した場合は、本番環境でデバッグするのではなくロールバックします。

デプロイは、巧妙なショートカットよりも忍耐と反復可能なシーケンスに報います。環境、データ、ロールバックの基本を一度正しく設定すれば、それ以降のリリースはルーチンになります。生成されたコードをさらに進める方法については、以下を参照してください。 プロトタイプから本番への移行、または探索する LogicMintのプラン あなたのステージに合ったホスティングオプションを確認できます。