ホストを選んでデプロイする
たいていのバイブコーディングされたアプリには、自分で世話をするサーバーは必要ありません。現代のプラットフォームは、あなたのコードを受け取って数分でライブのを返してくれます。よくある選択肢です。
- 静的サイトとフロントエンド: Cloudflare Pages、Vercel、Netlify、GitHub Pages。
- フルスタックアプリと（アプリケーション・プログラミング・インターフェース。あるプログラムが別のプログラムと話すために使う出入り口です): Cloudflare Workers、Vercel、Render、Fly.io、Railway。
- より重いバックエンド: コンテナプラットフォーム、または小さなVPS（バーチャル・プライベート・サーバー。データセンターにある、常時稼働するコンピューターのうち、あなたが借りた自分専用の一区画です)。
正しいやり方は、何を作ったかをAIに伝えて推薦させることです。試してみましょう。「これはPostgresデータベースを使ったNext.jsアプリです。寛大な無料枠を持つ、最も安くて信頼できるホストが欲しい。デプロイ手順と設定ファイルを教えて」。選択を実際に左右するものについて具体的に伝えましょう。フレームワーク、データベースの有無、バックグラウンドジョブやファイルアップロードが必要かどうか、そして予算です。静的なマーケティングページと、キューを持つフルスタックアプリでは、住む場所がまったく違います。
1つ選んだら、デプロイはたいてい数個のコマンドで済みます。
# 例: Wrangler 経由の Cloudflare Workers
npm install -g wrangler
wrangler login
wrangler deploy
# 例: Vercel
npm install -g vercel
vercel --prod
プラットフォームの設定(wrangler.toml、vercel.json など)はAIに生成させ、最初のデプロイで出るエラーを説明させましょう。最初のデプロイはほぼ必ず何かしらのエラーを出します。ビルドコマンドの不足、出力ディレクトリの間違い、Nodeバージョンの不一致、ビルドが必要としているのに見つからない環境変数(コードの外側からアプリに渡される、名前付きの設定値のことです)などです。どれもあなたが馬鹿なことをしたという意味ではなく、プラットフォームにもう一つ伝える必要があるという意味です。エラーをそのまま貼り戻して修正を頼み、さらになぜ起きたかも尋ねて、次は驚かされないようにしましょう。2、3回のやり取りで、一時的なURLでライブになります。祝う前にそのURLを開いて、コアのフローをクリックしてみましょう。「デプロイが成功した」と「アプリが動く」は同じ主張ではありません。
すべてのデプロイは同じパイプラインを歩きます。プレビューのステップがあなたのセーフティネットです。すべての変更が、本物のユーザーに触れる前に、クリックして確認できる自分専用のURLを持つのです。
自分のマシン プラットフォーム
┌──────────────┐
│ コード記述 │
│ git commit │
│ git push │
└──────┬───────┘
│ push
▼
┌──────────────┐ 失敗 ┌──────────────────┐
│ BUILD ├─────────▶│ エラーを読み, │
│ 依存を導入 │ │ 直して再push │
│ コンパイル │◀─────────┤ (2~3回) │
└──────┬───────┘ 再試行 └──────────────────┘
│ 成功
▼
┌──────────────┐
│ PREVIEW │ 一時URL — ここで主要フローをクリック
│ *.pages.dev │ ── 共有 · テスト · 検証 ───┐
└──────┬───────┘ │
│ OK? ──── いいえ ──────────────────┘
│ はい
▼
┌──────────────┐
│ PRODUCTION │ 本番ドメイン · 実ユーザー
└──────────────┘