バイブコーディングで最初の壁になりやすいのが「デプロイ」です。
CursorやClaude Codeでコードを生成して、ローカル（自分のパソコン）では問題なく動いているのに、Vercelに公開したとたんに真っ白な画面や500エラーが出てしまう。
その原因の8割は、環境変数の設定漏れです。
今回はこの「環境変数」という概念を、非エンジニアの方にもわかるように丁寧に解説します。デプロイの仕組み、ドメイン設定まで一気に押さえましょう。
環境変数とは「パスワードを安全に管理する仕組み」
アプリを作ると、必ずAPIキーやデータベースのパスワードが必要になります。
たとえばSupabaseに接続するためのURL、Stripeで決済するための秘密鍵、SendGridでメールを送るためのAPIキー。これらは「知っている人だけが使える合言葉」です。
ここで絶対にやってはいけないのが、これらをコードの中に直接書くことです。
// 絶対ダメな例
const apiKey = "sk-1234567890abcdef";
コードはGitHubに上げることが多いですが、GitHubのリポジトリが公開設定になっていたら、APIキーが世界中に丸見えになります。実際にこれで課金被害に遭う事故は毎日どこかで起きています。
環境変数とは、こうした秘密情報をコードの外に切り出して管理する仕組みのことです。コードには「環境変数のここを見てね」という印だけ書いておき、実際の値は別のファイルや設定画面で管理します。
.envファイルの書き方
Next.jsプロジェクトのルートフォルダ（一番上の階層）に、.env.localというファイルを作ります。
SUPABASE_URL=https://xxxx.supabase.co
SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
STRIPE_SECRET_KEY=sk_test_51...
ルールはシンプルです。キー名=値 という形式で1行に1つ書くだけです。
ファイル名の末尾に .local がついているのは「このファイルはローカル専用で、GitHubには絶対にアップしない」という意味です。Next.jsは .env.local を自動的にGitの管理対象から外してくれます。
.gitignore（Gitの管理対象外ファイルのリスト）を確認すると、.env*.local が含まれているはずです。もし含まれていなければ、すぐに追加してください。
コードの中では次のように呼び出します。
const supabaseUrl = process.env.SUPABASE_URL;
process.env.キー名 と書くと、そのキーに設定した値が取り出せます。
NEXT_PUBLIC_プレフィックスの意味
Next.jsには特殊なルールがあります。環境変数の名前が NEXT_PUBLIC_ で始まるものだけが、ブラウザ側のコードで使えます。
Webアプリには「サーバーで動くコード」と「ブラウザで動くコード」の2種類があります。
サーバーで動くコードは、ユーザーのブラウザには見えません。だから秘密のAPIキーを置いても安全です。
ブラウザで動くコードは、ユーザーが「ページのソースを見る」をすれば中身が見えてしまいます。だから本当に秘密にしたい情報（決済の秘密鍵など）は絶対に置いてはいけません。
NEXT_PUBLIC_ をつけると「これはブラウザに渡してもいい情報です」という宣言になります。
# ブラウザに渡してもいい情報（公開前提）
NEXT_PUBLIC_SUPABASE_URL=https://xxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...
# サーバーだけで使う秘密情報（ブラウザに渡さない）
SUPABASE_SERVICE_ROLE_KEY=eyJ...
STRIPE_SECRET_KEY=sk_live_...
SupabaseのURLと公開用キー（anon key）はブラウザから直接アクセスするために必要なので NEXT_PUBLIC_ をつけます。一方、管理者権限のキー（service role key）や決済の秘密鍵はサーバー専用なので NEXT_PUBLIC_ をつけません。
ローカル・ステージング・本番の3環境
プロが使うアプリには通常、3つの環境があります。
ローカル環境とは、自分のパソコン上で動かす開発用の環境です。データが壊れても自分だけが困るので、気軽に実験できます。.env.local ファイルが使われます。
ステージング環境とは、本番と同じ構成で作られたテスト用の環境です。「本番に上げる前に最終確認する場所」です。実際のユーザーはここにはアクセスしません。.env.staging や Vercel の Preview 環境が使われます。
本番環境とは、実際のユーザーが使う環境です。ここでミスをすると本物の被害が出ます。.env.production や Vercel の Production 環境が使われます。
バイブコーディングの初期フェーズでは、ローカルと本番の2環境で始めることが多いです。ユーザーが増えてきたらステージングを追加するという順番で問題ありません。
重要なのは「それぞれの環境で別々の環境変数を使う」という点です。ローカルではSupabaseのテスト用データベースを使い、本番では本番用データベースを使う、という分け方をします。
Vercelデプロイの仕組み
Vercelは、Next.jsを作った会社が提供するホスティングサービスです。GitHubと連携させると、コードを push するだけで自動的にビルドしてWebサイトを公開してくれます。
流れを整理すると次のようになります。
- ローカルでコードを書く
git pushでGitHubにコードを送る- Vercelがそれを検知して自動でビルドを開始する
- ビルドが成功したらURLが発行される
- 世界中からアクセスできる状態になる
ここで多くの人がはまるのが、ステップ3のビルドです。
ローカルでは .env.local に書いた環境変数が使えます。しかしVercelのサーバーにはそのファイルがありません。あなたのパソコンにしか存在しないからです。
Vercelに環境変数を設定するには、Vercelの管理画面から手動で入力する必要があります。
手順はシンプルです。Vercelのプロジェクトページを開き、「Settings」から「Environment Variables」を選びます。ここに .env.local に書いたキーと値を一つずつ入力します。
設定できたら、次のデプロイから反映されます。すでにデプロイされているものに反映させるには「Redeploy」ボタンを押します。
よくある失敗パターンを挙げます。
パターン1: そもそも設定していない。ローカルでは動くのに本番で動かないときの原因の大半がこれです。
パターン2: 本番用のキーを使い忘れている。Supabaseには開発用プロジェクトと本番プロジェクトがあるのに、Vercelに開発用のURLを設定してしまうケースです。
パターン3: NEXT_PUBLIC_ の付け忘れ。ブラウザから呼び出す必要がある変数に NEXT_PUBLIC_ がついていないと、undefined（値なし）になってしまいます。
デバッグの基本は、Vercelのデプロイログを確認することです。「Functions」タブや「Deployments」からログを見ると、どの変数が undefined になっているかが確認できます。
カスタムドメインとDNS設定
Vercelでデプロイすると、最初は yourapp.vercel.app というURLが発行されます。これでも公開はできますが、ビジネス用途なら独自ドメインを使いたいはずです。
独自ドメインを使うには、次の2ステップが必要です。
ステップ1はドメインを取得することです。お名前.comやムームードメイン、Cloudflareなどで年間1,000〜2,000円程度で購入できます。
ステップ2はDNS設定です。DNSとは「このドメイン名はこのIPアドレス（サーバー）に繋いでください」という対応表のことです。電話帳のようなものです。
Vercelの「Settings」から「Domains」を開き、取得したドメイン名を追加すると、設定すべきDNSレコードが表示されます。表示された値をドメイン管理会社の設定画面に入力するだけです。
具体的には次のようなレコードを設定します。
Aレコードとは、ドメイン名とIPアドレスを紐づける設定です。76.76.21.21（VercelのIPアドレス）を設定します。
CNAMEレコードとは、www サブドメインを cname.vercel-dns.com に向ける設定です。
設定後、DNSが世界中に伝播するまで数分から最大48時間かかります。ほとんどの場合は数分で完了します。
HTTPS（通信の暗号化）はVercelが自動で設定してくれます。昔は証明書の取得と更新が手間でしたが、今はVercelが全部やってくれます。
ローカルでは動くのにVercelで500エラーになるときのチェックリスト
「ローカルでは動いていたのに本番で壊れた」というのはバイブコーダーあるあるです。遭遇したときのチェックリストを整理しておきます。
まず確認するのは、Vercelに環境変数が設定されているかどうかです。Vercel管理画面の「Settings → Environment Variables」を開き、.env.local の内容がすべて入力されているか確認してください。
次に確認するのは、NEXT_PUBLIC_ プレフィックスの付け忘れです。ブラウザ側で使っている変数に NEXT_PUBLIC_ がついているか確認してください。
それでも解決しない場合は、Vercelのデプロイログを確認します。「Deployments」から最新のデプロイを開き、「Functions」タブでエラーの内容を確認します。undefined や ECONNREFUSED といったキーワードが手がかりになります。
APIルートでエラーが起きているなら、Vercelの「Logs」タブからリアルタイムのログを確認できます。実際に問題のURLにアクセスしながらログを見ると、原因を特定しやすくなります。
よくあるエラーとその原因をまとめると次のとおりです。
500 Internal Server Error は、サーバー側のコードでエラーが発生しています。ほとんどの場合は環境変数が undefined になっています。
TypeError: Cannot read properties of undefined は、環境変数が設定されていないので null になっているオブジェクトのプロパティを読もうとしています。
Connection refused や ENOTFOUND は、データベースやAPIのURLが間違っているか設定されていません。
まとめ
今回のポイントを整理します。
環境変数とは、APIキーなどの秘密情報をコードの外で管理する仕組みです。.env.local ファイルに書いて、コードからは process.env.キー名 で呼び出します。
ブラウザ側で使う変数は NEXT_PUBLIC_ プレフィックスをつけます。秘密にしたい情報にはつけません。
Vercelにデプロイするときは、必ず管理画面の「Environment Variables」に同じ内容を設定してください。これを忘れると本番環境でアプリが動きません。
独自ドメインはVercelの「Domains」設定から追加でき、表示されたDNSレコードをドメイン管理会社の画面に入力するだけで設定できます。
「ローカルで動くのに本番で動かない」というトラブルに遭遇したら、まず環境変数の設定漏れを疑ってください。
次回は「データベース設計の基本とSupabaseのテーブル操作」を解説します。
Claude Codeを使った非エンジニア向けのバイブコーディング実践について、無料の個別相談を受け付けています。「自分のプロダクトに応用できるか聞いてみたい」という方はお気軽にどうぞ。
