AIで作ったアプリをエクスポートしてセルフホストする方法
AIで作ったアプリをセルフホストするには、まずコードを取り出します(ダウンロードするか、自分が所有するGitHubリポジトリに同期します)。次に、シークレットを環境変数として作り直し、データベースを移行または再作成し、アプリの性質に合ったホストにデプロイします。静的なフロントエンドなら静的ホスト、バックエンドを持つものならサーバーやコンテナを動かせるプラットフォームです。コードは通常いちばん簡単な部分です。大変なのは、データ、シークレット、そしてビルダーがあなたの代わりに裏で動かしていたサービスです。
そもそもエクスポートする理由
コードを持ち出すことには、良い理由もあれば、あまり良くない理由もあります。
良い理由:
- 所有権と保険。 自分のリポジトリにコードのコピーがあれば、ビルダーが料金、機能、利用規約を変更しても身を守れます。
- 開発者への引き継ぎ。 エンジニアのチームは、コードをGitで、普段のツールやレビューの仕組みの中で扱いたがります。
- 特定の要件。 データの保存場所、特定のクラウドプロバイダー、社内のセキュリティポリシー、ビルダーが提供していないインフラなど。
- 規模やコスト。 自前のインフラを運用することが本当に割に合う規模になった場合。
あまり良くない理由: 利用者が数人しかいない小さなアプリを、毎月わずかな額を節約するために移すこと。セルフホストは、アップデート、バックアップ、監視、セキュリティパッチといった作業をあなたに移します。それが正しい判断になることもありますが、承知の上で決めましょう。
現実的な中間策は、今いる場所で作り続けて動かしつつ、早い段階から自分のGitHubリポジトリに同期しておくことです。運用の手間をかけずに保険を手に入れられます。Gitに不慣れなら、GitHubとはを読んでください。
エクスポートに含まれるものと含まれないもの
エクスポートを頼りにする前に、中身を開いて確認しましょう。一般的には次のとおりです。
| 含まれるもの | 通常は含まれないもの |
|---|---|
| ソースコード(フロントエンド、バックエンド) | シークレットの値(APIキー、パスワード) |
設定ファイル(package.json、Dockerfile、ビルド設定) | インストール済みの依存関係(node_modulesなど)。これらは再インストールされます |
| アプリが使っている場合のデータベーススキーマとマイグレーションファイル | データベースに入っている実際のデータ |
| プロジェクト内の静的アセット | 別のストレージに保存されたユーザーのアップロードファイル |
| ビルダーが管理するサービス:ホスティング、ドメイン、データベースサーバー、ファイルストレージ |
シークレットは意図的に除外されています。メールで送ったりコミットしたりするかもしれないアーカイブに、有効なキーが含まれていてはいけないからです。依存関係はロックファイルから再構築されるため、除外されています。
ステップ1:コードを取り出す
一般的な方法は2つあります。
- アーカイブをダウンロードする。 手早く、一度きりの移行やバックアップには十分です。
- GitHubに同期する。 継続的に使うものにはこちらが向いています。履歴がすべて残り、どこにでもクローンでき、ほとんどのホストは、GitHubリポジトリへのプッシュごとに直接デプロイできます。
どちらの方法でも、コンピューター(またはクラウドの開発環境)でクローンするか展開し、READMEを探しましょう。なければ、移行する前にビルダー内のAIに作成してもらいましょう。
このプロジェクトをこのプラットフォームの外で動かすためのREADMEを書いてください。スタック、必要なランタイムのバージョン、インストールとビルドのコマンド、起動コマンドとポート、コードが読み込むすべての環境変数(名前と用途のみ、値は含めない)、データベースのマイグレーションの実行方法を含めてください。
この1つのプロンプトで何時間も節約できます。暗黙のうちに行われていたセットアップの部分を、文章として書き出させるからです。
ステップ2:まずローカルで動かす
どこかにデプロイする前に、アプリが単独で動くことを確かめましょう。
- ランタイムをインストールする。 READMEに書かれたもの(Node.js、Python、Java、.NETなど)を、対応するバージョンで。
- 依存関係をインストールする。(
npm install、pnpm install、pip install -r requirements.txt、または同等のもの) - ローカルの
.envファイルを作る。 環境変数を入れ、可能ならテスト用のキーを使います。Gitには含めないでください。環境変数とシークレットとはで考え方を説明しています。 - データベースに接続する。 ローカルのPostgreSQL、またはマネージドプロバイダーの無料の開発用データベースを使います。
- マイグレーションを実行し、アプリを起動して主要な流れを一通り操作します。
ここで壊れるものは、ホスト上でも壊れます。そして自分のマシンでデバッグするほうがずっと簡単です。よくある予想外のトラブルは、ビルダーのプレビューURLがコードに直接書き込まれている、ビルダーが自動で注入していた環境変数が不足している、プラットフォームの上にしか存在しなかったサービス(ファイルストレージ、画像のリサイズなど)に依存している、といったものです。
ステップ3:データを移す
アプリに実際の利用者がいるなら、データはコードよりも重要です。
- データベースをエクスポートする。 PostgreSQLなら、
pg_dumpで作ったファイルをpg_restoreまたはpsqlで新しいデータベースに復元できます。直接アクセスできない場合は、ビルダーのAIに実行とその出力の説明を頼みましょう。 - アップロードされたファイルを移す。 利用者が画像や文書をアップロードしていれば、それらはデータベースとは別のオブジェクトストレージにあります。新しいストレージ(S3互換のバケットなど)にコピーし、保存されたURLに古いホストが含まれていれば更新しましょう。
- 切り替えを計画する。 稼働中のアプリでは、短いメンテナンス時間を取るのが単純な方法です。書き込みを止め、最後のエクスポートを取り、新しいホストに復元し、DNSを切り替え、再開します。各ステップは先に書き出しておきましょう。
- 本番の移行の前に、復元をテストする。 作業用のデータベースに復元してみましょう。
PostgreSQLに慣れていなければ、PostgreSQLとはで基本を説明しています。
ステップ4:ホストを選ぶ
ホストはアプリの性質に合わせて選びましょう。以下の名前は2026年9月時点で各カテゴリーの代表的なプロバイダーの例であり、ランキングではありません。最新の機能と料金は各社のサイトで確認してください。
| アプリの形 | 必要なもの | 例のホスト |
|---|---|---|
| 静的サイトまたはSPA(HTML、CSS、JSのみ) | CDNを使ったファイルホスティング | Netlify、Vercel、Cloudflare Pages、GitHub Pages |
| フルスタックフレームワーク(Next.jsなど) | サーバーまたはサーバーレス関数 | Vercel、Netlify、Render、Railway |
| APIまたはバックエンド(Node、Python、Java、C#) | 常時稼働、またはゼロへのスケールダウンが可能なサーバー | Render、Railway、Fly.io、クラウドのコンテナサービス |
| Dockerfileを持つもの | コンテナランタイム | Fly.io、Render、Railway、AWS、Google Cloud、Azure |
| 完全な制御 | 自分で管理する仮想サーバー | DigitalOcean、Hetzner、Linode、任意のクラウドVM |
さらに必要になるものもあります。
- マネージドデータベース。 多くのアプリホストがPostgreSQLを提供しており、NeonやSupabaseのような専用サービスも単体で提供しています。マネージドは手間をかける価値があります。バックアップや更新を他者に任せられるからです。
- オブジェクトストレージ。 アプリにアップロード機能があれば必要です。
- メール送信、決済、AIプロバイダー。 これらは通常、同じAPIキーを新しいホストに設定するだけで済みます。
トレードオフについて公平に言えば、プラットフォームホスト(最初の4行)は設定と運用が手早い反面、制御の自由度が低く、アクセス数に応じてコストが上がることがあります。仮想サーバーは一定の負荷では安上がりになることが多く、完全に自分の管理下に置けますが、パッチ適用、TLS、バックアップ、監視、復旧はすべてあなたの責任になります。その役割を誰も担いたくないなら、プラットフォームを選びましょう。ホスティングの基本については、Webホスティングとはをご覧ください。
ステップ5:デプロイして切り替える
- リポジトリをホストに接続する。 またはコンテナイメージをプッシュする。
- ホストのダッシュボードで環境変数を設定する。 READMEにあるものすべてを、本番の値で。
- ビルドと起動のコマンド、ポートを設定する。 多くのホストは
PORT環境変数でポートを渡します。アプリはそれを待ち受け、localhostだけでなくすべてのインターフェース(0.0.0.0)で待ち受ける必要があります。 - 新しいデータベースに対してマイグレーションを実行する。
- DNSに触る前に、ホストの一時的なURLでテストする。
- 古いURLを指している外部サービスを更新する。 決済のWebhook、ログイン用のOAuthリダイレクトURL、メールのリンク、許可されたオリジンなど。
- DNSレコードを新しいホストに向けて、ドメインを移す。 レコードの設定方法はカスタムドメインの接続方法で説明しています。
- 確信が持てるまで古いデプロイを少しの間稼働させておき、その後で停止する。
ステップ6は、最も忘れられやすいものです。移行後にログインや決済が静かに失敗するのは、たいてい古いホストを指したままのコールバックURLが原因です。
ステップ6:運用を引き継ぐ
セルフホストすると、ビルダーが担っていたことはすべてあなたの仕事になります。最低限、次のものが必要です。テスト済みの復元を伴う自動データベースバックアップ、エラー追跡、稼働監視のアラート、依存関係の更新、そして各アカウントへのアクセス権を持つ人の記録。AIのプロトタイプを本番環境に持っていく方法で、この一覧をさらに詳しく説明しています。
エクスポートのチェックリスト
- 自分が所有するリポジトリにあるコード。実行、ビルド、環境変数を説明するREADMEがある
- クリーンなクローンからアプリがローカルで動く
- データベースをエクスポートし、復元をテスト済み。アップロードされたファイルをコピー済み
- アプリの形に合ったホストを選定済み。マネージドデータベースとストレージも用意
- 新しいホストのすべての環境変数に本番の値を設定済み
- Webhook、OAuthリダイレクト、メールのリンクを更新済み
- DNSを切り替え済み。古いデプロイは少しの間残し、その後削除
- バックアップ、監視、アクセス権の一覧を用意済み
Mythexからのエクスポート
Mythexでは、作ったコードはあなたのものです。Proプランでは、プロジェクト設定 → エクスポートからプロジェクトをアーカイブとしてダウンロードできます。また、GitHubを接続して、自分のリポジトリとプッシュやプルができます。Freeプランではコードを読み取り専用で閲覧できますが、エクスポートや同期はできません。シークレットとnode_modulesはエクスポートに含まれないため、新しいホストではシークレットを作り直してください。手順はエクスポートして別の場所で動かすとGitHub、エクスポート、インポートのドキュメントに記載されています。Mythexでホスティングを続けながら、GitHubの同期を自分用のコピーや引き継ぎの経路として使うこともできます。移行する場合は、新しいホストが稼働したらMythexのアプリを公開停止にしてください。
よくある質問
AIアプリビルダーからコードをエクスポートできますか?
ツールとプランによります。プロジェクト全体をダウンロードしたり、自分が所有するGitHubリポジトリに同期できるビルダーもあれば、アプリをプラットフォームの中に留めるビルダーもあります。数か月かけて使い始める前に確認し、エクスポートに含まれるものと含まれないものを読んでおきましょう。
エクスポートにデータベースやAPIキーは含まれますか?
通常、コードはエクスポートされますが、データやシークレットは含まれません。シークレットキーは意図的に除外されるのが普通で、データベースの中身は別途エクスポートが必要です(PostgreSQLであればpg_dumpなど)。ホストを切り替える前に、両方の計画を立てておきましょう。
エクスポートしたアプリはどこにホストすればよいですか?
静的なフロントエンドは、Netlify、Vercel、Cloudflare Pagesなどの静的ホストに適しています。独自のサーバーを持つアプリには、Render、Railway、Fly.ioのようなコードやコンテナを実行できるプラットフォーム、または自分で管理する仮想サーバーが必要です。アプリにデータベースがある場合は、マネージドデータベースも必要になります。
セルフホストはビルダーに留まるより安くなりますか?
規模が大きくなれば、そうなることもあります。小規模なアプリでは、データベース、メール、監視、そして保守にかかるあなた自身の時間まで含めると、差はわずかなことが多いです。移行するのは、月々の数ドルを節約するためだけではなく、管理権限や特定の要件のためにしましょう。