【第28回】自分のURLで世界に公開する｜Vercel へデプロイ（嫁子が教えるTS講座）
今回のゴール
- 手元で動いているものを、自分のURLで公開できる
- 環境変数をどこに置くかが分かる
- 手元のデータベースが本番では使えない理由が分かる
第5部の最後です。前回（認証の入口）まででアプリの中身はそろいました。全体の流れは講座の目次へ。
嫁子: 公開って大げさに聞こえるけど、やることはGitHubに置いて、つなぐだけだよ。
ただし今日は1つだけ落とし穴があるの。手元で動いていたデータベースが、そのままでは本番で動かない。そこが今日の本題だと思ってね。
1. 公開までの流れ
全体はこうなります。
- 第3回で覚えたGitで、コードをGitHubに置く
- Vercelでそのリポジトリを選ぶ
- 環境変数を入れる
- 自動でビルドされ、URLが発行される
ビルドの設定はほぼ不要です。Next.jsのプロジェクトだと分かると、必要な設定を自動で判断してくれます。
CLIから公開する方法もあります。プロジェクトのフォルダで次を打つと、対話形式で進みます。
npx vercel
ただしGitHubとつないでおくほうが後が楽です。理由は次の項目です。
2. pushすると自動で反映される
GitHubとつないでおくと、pushするたびに自動でデプロイされます。ここで2種類のURLができるのが便利なところです。
| どこにpushしたか | 何ができるか |
|---|---|
main（本番ブランチ） |
本番URLが更新される |
| それ以外のブランチ | そのブランチ専用のプレビューURLが作られる |
プレビューURLは、本番に影響を与えずに確認できる場所です。試したい変更を別のブランチでpushすれば、公開中のものを壊さずに実物を見られます。
第3回で「ブランチは今は覚えなくていい」と書きましたが、使いどころはここです。公開してから初めて、ブランチが必要になります。
嫁子: この仕組みはけっこう効くよ。
AIに大きめの変更を頼んだとき、いきなり本番に入れずにプレビューで見られるでしょ。第3回で言った「安全網があるから大胆に任せられる」の、公開版だね。
3. 環境変数は管理画面に入れる
第23回で .env.local に秘密の値を入れました。このファイルはGitに含まれないので、当然Vercelにも届きません。
そのため、同じ内容を管理画面側にも登録します。
環境変数には適用範囲を選べる区分があります（2026年9月時点）。
| 区分 | いつ使われるか |
|---|---|
| Production | 本番。main にpushしたとき |
| Preview | 本番以外のブランチのデプロイ |
| Development | 手元での開発（vercel env pull で取得できる） |
本番と手元で違う値を使えるので、練習用のデータベースと本番用のデータベースを分けられます。
大事な注意が1つあります。環境変数を変えても、すでに公開されているものには反映されません。新しくデプロイしたときから有効になります。変えたのに動きが変わらないときは、ここを疑ってください。
嫁子: 「設定したのに反映されない」の原因は、だいたい再デプロイ忘れなの。
あと、
.env.localの中身を全部そのままコピーしないでね。手元用の値（SQLiteのファイルパスとか）は、本番では別のものになるから。
4. 手元のSQLiteは、本番では使えない
ここが今日いちばん大事なところです。
第25回で「手元はSQLite、本番はPostgreSQL」と書きました。その理由がここで出てきます。
Vercelのようなサービスでは、実行するたびに入れ物が用意され、終わると消えます。ファイルに書き込んでも、次のアクセスでは残っていません。SQLiteは「ファイル1つ」なので、書き込んだデータが保持されないことになります。
エラーにはなりません。書けたように見えて、次に開くと消えているという形で出ます。
| 手元 | 本番 | |
|---|---|---|
| SQLite | 動く。ファイルが残る | 書けるが、次のアクセスで消える |
| PostgreSQLなど | 動く（用意は必要） | 動く。データは残る |
対応は、外部のデータベースサービスを使い、接続情報を環境変数に入れることです。第26回のPrismaを使っていれば、スキーマの provider と接続先を変えるだけで済みます。コードはほぼそのままです。
嫁子: 「本番だけデータが消える」は、原因に気づくまでが長いやつだよ。
動いてるように見えるからね。公開する前に「このデータはどこに残るのか」を一度確認する、を習慣にしておいて。
ちなみに、このブログ（夫のひきだし）はそもそもデータを保存しない作りなの。記事のファイルから毎回HTMLを組み立てて置いてるだけ。保存が要らないなら、そのほうが事故は起きないよ。
5. 公開したあとに見るところ
デプロイが終わったら、次の3つを確認してください。
- ビルドが成功したか — 失敗していればログにエラーが出ます。そのままAIに貼れば原因が分かります
- 環境変数の入れ忘れが無いか — 手元で動いて本番で動かない場合、まずここ
- 保存したデータが残るか — 登録して、少し時間をおいてから開き直す
手元では出ないエラーが、本番で初めて出ることがあります。第15回でやった strict の型エラーは、ビルド時にまとめてチェックされるためです。開発中は動いていても、ビルドで止まることがあります。
嫁子: 「手元では動くのに本番で落ちる」は、恥ずかしいことじゃなくて普通のことだよ。
環境が違うんだから当たり前なの。大事なのは、ログを読んで切り分けられるか。エラー文をそのままAIに渡せる時点で、もう困らないと思う。
つまずきポイント
公開されたURLは誰でも開けます。リンクを知らなければ見られない、と考えないでください。個人的な情報を扱うなら、前回の認証が必要になります。
無料の範囲には上限があります。趣味の範囲なら足りることがほとんどですが、想定外のアクセスが来たときの挙動は、事前に確認しておくと安心です。
GitHubに鍵が入っていないか確認してください。第23回で書いた通り、公開リポジトリに入れた秘密の値は取り返せません。
今回のまとめ
- GitHubにpush → Vercelでリポジトリを選ぶ、で公開できる。設定はほぼ不要
mainへのpushで本番が更新され、他のブランチはプレビューURLになる.env.localは届かないので、環境変数は管理画面にも登録する（本番・プレビュー・開発で分けられる）- 変更しても再デプロイするまで反映されない
- 手元のSQLiteは本番でデータが残らない。外部のデータベースに切り替える
- 公開後は「ビルド成功／環境変数／データが残るか」の3点を確認する
次にやること
第5部（バックエンドとデータ）はこれで終わりです。次回から第6部・応用に入り、このブログと同じ土俵であるCloudflare Workersの話をします。
Vercelで一通り動かせるようになったうえで、「同じことを別の場所でやるとどう違うのか」を見ていきます。第6部は3回だけで、講座の締めくくりになります。
今回の宿題：何でもいいので1つ、実際に公開してみてください。自分のURLが発行される瞬間を一度体験しておくと、ここまでの内容が実感に変わります。中身は「こんにちは」だけでも構いません。
嫁子: 公開すると、急に自分のものになった感じがすると思うよ。
手元で動いてるだけのものは、まだ半分なの。誰かに見せられる形になって、やっと完成だからね。