バイブコーディングで作ったアプリが本番で動かない。よくある原因と対策

結論：バイブコーディングのアプリが本番で動かない原因は5パターン

Bolt.new・Lovable・Cursor・Claude Codeなどで「ローカルでは完璧に動く」アプリを作ったのに、本番デプロイした途端に動かなくなる——このパターンには共通の原因があります。

AIは「ローカルで動くコード」を得意としていますが、本番環境との差分を埋める作業が苦手です。具体的には以下の5つが9割の原因を占めます。

1. 環境変数が本番に反映されていない——ローカルの.envが本番サーバーに設定されていない
2. CORSエラー——フロントエンドとバックエンドが別ドメインになっていてリクエストがブロックされる
3. APIキーのハードコーディング——AIがコードに直接キーを埋め込んでいてセキュリティリスクになる
4. ローカルパス・ファイル依存——ローカルの絶対パスや相対パスが本番環境では存在しない
5. エラーハンドリングの欠如——AIはhappy path（正常系）しか書かない。本番の異常系で落ちる

るみな

Bolt.newで作ったアプリ、ローカルは完璧なのにVercelにデプロイしたら真っ白になった。何が起きてるの？

きだけん

8割以上は環境変数の設定漏れかCORSです。まずVercelのダッシュボードでEnvironment Variablesが設定されているか確認してください。

原因1：環境変数が本番に反映されていない

バイブコーディングで作ったアプリが本番で真っ白になる場合、ほぼ確実にまずここを疑ってください。

ローカルでは .env ファイルにAPIキーやデータベースURLを書いておけば動きます。しかし .gitignore に .env が含まれているため（セキュリティ上当然）、GitHubにpushしても本番環境には届きません。

症状のパターン：

• ページが真っ白になる / ローディングが終わらない
• APIの呼び出しが全部失敗する
• 「undefined」「null」が返ってくる
• コンソールに「NEXT_PUBLIC_〇〇 is not defined」などのエラーが出る

対処法（Vercelの場合）：

1. Vercelダッシュボードにログイン → 該当プロジェクトを選択
2. 「Settings」→「Environment Variables」
3. ローカルの .env の内容をすべて登録する
4. 「Redeploy」を実行する（設定変更は再デプロイしないと反映されない）

Railwayや他のホスティングサービスでも同様に、管理画面のEnvironment Variables（環境変数）セクションで設定が必要です。

実際にVercelに環境変数なしでデプロイしてみたときのエラーと、設定後の変化を確認しました。

「設定したのに直らない」場合は再デプロイを忘れている場合がほとんどです。

原因2：CORSエラー

CORSエラーは「フロントエンド（例：myapp.vercel.app）からバックエンドAPI（例：api.myapp.railway.app）にリクエストを送ろうとしたが、ブラウザのセキュリティポリシーでブロックされた」状態です。

ローカルでは localhost:3000 → localhost:8000 と同じマシン内で完結していたものが、本番では別ドメインになって初めてCORSが問題になります。

症状：

• ブラウザのコンソールに「Access to fetch at 〇〇 from origin 〇〇 has been blocked by CORS policy」と出る
• APIリクエストが400〜500番台のエラーではなく、ネットワークレベルでブロックされている

バックエンドでの対処法（Node.js/Express の場合）：

const cors = require('cors');
app.use(cors({
  origin: 'https://myapp.vercel.app',  // 本番フロントエンドのURLを指定
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  credentials: true,
}));

Next.js（API Routes）の場合：

// pages/api/example.js または app/api/example/route.js
export async function GET(req) {
  return new Response(JSON.stringify({ data: 'ok' }), {
    headers: {
      'Access-Control-Allow-Origin': 'https://myapp.vercel.app',
      'Content-Type': 'application/json',
    },
  });
}

注意：origin: '*'（全許可）で動作確認後、本番では必ず特定ドメインに絞ってください。*のままにするとセキュリティリスクになります。

るみな

CORSって何度見てもよくわからない。とりあえず*にすれば動くから毎回そうしてた

きだけん

ローカルでの動作確認は*でもOKですが、本番に出す前に必ず特定のドメインに絞めてください。*のままだと全ドメインからのリクエストを受け入れることになり、APIが悪用される可能性があります。

原因3：APIキーのハードコーディング

AIにAPI連携のコードを生成させると、こういうコードが出てくることがあります。

// AIが生成したコード（危険な例）
const client = new OpenAI({
  apiKey: 'sk-proj-xxxxxxxxxxxxxxxxxxxxxxxxxxxx',  // ← 直接書いてある！
});

これをそのままGitHubにpushすると、キーが公開リポジトリに載ります。実際に数分以内にボットに拾われてAPIキーが悪用された事例は多数報告されています。

正しい書き方：

// 環境変数から読み込む（正解）
const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

AIに指示するときは「APIキーは環境変数から読み込むコードで生成してください。ハードコーディングしないでください」と明示的に指定することで防げます。

GitHubのコードにキーが含まれていないか確認する方法：

• コミット前に git diff で変更内容をチェック
• sk-（OpenAI）・ANTHROPIC_API_KEY・AIzaSy（Google）などのキーのプレフィックスをgrepして確認
• GitHubの「Secret scanning」機能で自動検出（パブリックリポジトリでは自動ON）

原因4：ローカルパス・ファイル依存

バイブコーディングで作ったアプリが本番でファイル読み込みエラーを出す場合、ローカルの絶対パスや ../uploads/ のような相対パスが本番サーバーには存在しないことが原因です。

よくある問題：

• /Users/yourname/project/uploads/ のようなローカル絶対パスが本番に存在しない
• ローカルでテスト用にアップロードした画像ファイルが本番にない
• SQLiteのDBファイルをローカルパスで参照していて本番で見つからない

対処法：

• ファイルの保存先はAWS S3・Cloudflare R2・Supabase Storageなどクラウドストレージに切り替える
• データベースはSQLiteファイルからPostgreSQL（Supabase・Neon・Railway）に移行する
• パスの参照は path.join(__dirname, ...) を使って相対パスに統一する

原因5：エラーハンドリングの欠如

これが最も根本的な問題です。AIが生成するコードは「正常に動く場合」を想定して書かれています。本番では以下のような異常系が必ず発生します。

• APIが5秒以内に応答しなかった（タイムアウト）
• ユーザーが想定外の入力をした（空文字・特殊文字・極端に長いテキスト）
• データベースへの接続が一時的に切れた
• 外部APIのレート制限に引っかかった（429エラー）
• ファイルサイズが想定以上だった

これらのエラーに対するハンドリングがないと、アプリ全体がクラッシュするか、ユーザーに何の情報もない白画面を見せることになります。

AIへの指示の改善例：

// NG：「APIを呼び出すコードを書いて」
// OK：「APIを呼び出すコードを書いて。タイムアウト（5秒）・
//       ネットワークエラー・レート制限（429）のエラーハンドリングも含めて。
//       ユーザーには適切なエラーメッセージを表示すること」

「エラーハンドリングも含めて実装して」の一言を追加するだけで、AIが生成するコードの品質が大きく上がります。

セキュリティ：バイブコーディングで特に見落とされがちな問題

2026年のBSIMM16レポートによると、AI生成コードの約45%に何らかのセキュリティ上の問題が含まれているとされています。バイブコーディング特有のリスクとして以下を確認してください。

1. デバッグ用エンドポイントが残っている：開発中に作った /api/debug や /api/test が本番に残っていないか確認する
2. SQLインジェクション対策がない：AIが生成するDBクエリが文字列結合になっていないかチェックする（プレースホルダーを使うよう指示する）
3. 認証なしのAPIエンドポイント：ユーザーデータを返すAPIに認証チェックがついているか確認する

本番デプロイ前チェックリスト

バイブコーディングで作ったアプリを本番に出す前に、以下を確認してください。

るみな

チェックリストがあると安心！デプロイのたびにこれを確認します

きだけん

特に環境変数とCORSの2つだけで8割の問題は防げます。この2つを必ず確認する習慣をつけるだけで、バイブコーディングでも安定した本番運用ができるようになります。

まとめ：ローカルで動くのに本番で動かない場合の確認順序

1. ブラウザのコンソールを開く（F12）——エラーメッセージを確認する
2. CORSエラーが出ていたら——バックエンドのCORS設定に本番ドメインを追加して再デプロイ
3. undefined / not defined が出ていたら——環境変数の設定漏れ。HostingサービスのENV設定を確認して再デプロイ
4. 404 / connection refused が出ていたら——APIのURLが本番環境用になっているか確認
5. それ以外のエラー——エラーメッセージをそのままCursor/Claude Codeに貼り付けて「本番環境でこのエラーが出ました。原因と修正方法を教えてください」と聞く

バイブコーディングの概要については「バイブコーディング完全ガイド」も参考にしてください。

きだけん

生成AI講師/副業コンサルタント

AI初心者が副業で月10万円を目指すための実践ノウハウを発信しています。生成AI講師として20名以上を指導し、自身もクラウドワークスで案件受注中。教育関連企業で10年勤務、娘の学費を稼ぐため日々研鑽中です。 全ての人が何かを「継続」し、「成果を出す」ことの手伝いをライフワークにしたいと考えています。