第1章から読む →

トップ / 第7章

CHAPTER 07 DEPLOY

公開と運用

手元で作ったサイトをインターネットに公開し、安全に運用し続けるまでの流れを押さえます。

読む目安 15分確認問題 3問

この章でわかること

  • 開発から公開までの流れ(ローカル→GitHub→Vercel)
  • ビルド・デプロイ・プレビューの意味
  • 公開後に必要な運用とトラブル時の確認ポイント

1. 開発から公開までの全体の流れ

Next.jsのサイトは、一般的に次のような流れで作られ、公開されます。

① 手元のパソコン 作って動作確認 ② GitHub 変更履歴つきで保管 ③ Vercel 自動でビルド・公開 GitHubに変更を送ると、Vercelが自動で検知して公開まで進めてくれる
現在、最も一般的なNext.jsの公開の流れ

① 手元のパソコンで作る(ローカル開発)

開発者のパソコンの中でサイトを動かしながら作ることをローカル開発と呼びます。npm run dev という命令を実行すると、ブラウザで http://localhost:3000 を開いてサイトを確認できます。localhost は「自分のパソコン自身」を指す特別な住所で、ほかの人からは見えません。

② GitHubに保管する

GitHub(ギットハブ)は、プログラムを変更履歴つきで保管・共有するサービスです。「いつ、誰が、どこを変えたか」がすべて記録されるので、問題が起きたら前の状態に戻せます。共有フォルダに「変更履歴」と「元に戻す」機能が付いたものと考えてください。

③ Vercelで公開する

Vercelは、Next.jsの開発元であるVercel社が提供する公開用サービス(ホスティングサービス)です。GitHubと連携しておくと、変更が送られるたびに自動で準備・公開してくれます。

2. よく出てくる用語:npm・ビルド・デプロイ

npm(エヌピーエム)と package.json
Next.jsやReactなど、世界中で公開されているプログラムの部品を取り込むための道具が npm です。どの部品のどのバージョンを使っているかは、package.json というファイルに一覧で記録されます。「材料の仕入れ先リスト」のようなものです。
ビルド(npm run build)
開発用に書いたプログラムを、本番で速く動く形に変換・圧縮し、作り置き(SSG)するページを事前に作る作業です。ここでエラーが出ると公開できません。料理でいえば、試作品をお店に出せる形に仕上げる工程です。
デプロイ
ビルドしたものをサーバーに配置して、インターネットから見られるようにすることです。「公開」とほぼ同じ意味で使われます。

なお、Next.js 16系では、ビルドなどを行う内部の道具としてTurbopack(ターボパック)が標準になり、開発中の画面の更新やビルドが以前より大幅に速くなっています。

3. Vercelの便利な機能と費用

プレビューデプロイ:本番前に確認できる

Vercelの最も便利な機能の1つがプレビューデプロイです。本番とは別の作業用の枝(ブランチ)で変更を送ると、その変更だけを反映した確認用のURLが自動で発行されます。

非エンジニアの方にとっては、このURLを開いて「文言は合っているか」「スマホで崩れていないか」を確認し、問題なければ本番に反映する、という安全な確認の流れが作れるのが大きな利点です。

費用の考え方

  • Hobby(無料):個人の非商用利用向け。学習や個人ブログならこれで十分です。
  • Pro(有料):仕事や商用サイトで使う場合はこちらが必要です。利用量(アクセス数や処理量)に応じて追加料金がかかることもあります。

料金体系は変わることがあるので、導入時は必ず公式サイトで最新の情報を確認してください。

Vercel以外の選択肢

Next.jsはVercel専用ではありません。Netlify、Cloudflare、AWS(Amplify など)、Google Cloud、自社のサーバーなどでも動かせます。ただし、一部の機能はVercel以外では追加の設定が必要になることがあります。会社の方針でAWSを使う、といった場合は、開発者に対応範囲を確認しましょう。

4. 公開後の運用で大切なこと

サイトは公開して終わりではありません。安全に使い続けるために、次のことが必要です。

アップデート(特にセキュリティ更新)

Next.jsには、定期的にセキュリティ上の問題(脆弱性=ぜいじゃくせい、プログラムの弱点)の修正版が出ます。2026年からは、決まった流れでセキュリティ更新を公表する体制も整えられました。修正版が出たら速やかに更新することが大切です。「誰が、どのくらいの頻度で更新するか」は、最初に決めておきましょう。

環境変数の設定

第5章で学んだ環境変数(APIキーなど)は、手元の .env.local に書いても、本番環境には自動で送られません。Vercelの管理画面の「Environment Variables」で、本番用の値を設定する必要があります。

ログと監視

本番でエラーが起きたとき、何が起きたかを記録したものをログと呼びます。Vercelの管理画面では、ビルドのログや、動作中のエラーのログを確認できます。

5. トラブル時に最初に確認すること

症状まず疑うこと
公開(デプロイ)が失敗するビルドのログに出ているエラー文。手元で npm run build が通るか
手元では動くのに、本番だけエラーになる本番環境に環境変数が設定されているか
データを更新したのに画面が変わらないキャッシュ(作り置き)が残っていないか(第4章)
変更後に表示がおかしくなったVercelの機能で1つ前の公開状態に戻す(ロールバック)

エラーが起きたときは、エラー文をそのままコピーしてAIや開発者に伝えるのが近道です。「動きません」だけでは原因が分かりません。

この章のまとめ

  • 流れは「手元で作る(localhost)→ GitHubに保管 → Vercelが自動でビルド・公開」。
  • ビルドは本番用への変換、デプロイは公開。プレビューデプロイで本番前に確認URLを使える。
  • 運用ではセキュリティ更新と環境変数の設定が重要。本番だけ動かないときは、まず環境変数を確認する。

確認問題

選択肢を1つ選んで「答え合わせをする」を押すと、正誤と解説が表示されます。何度でも選び直せます。