npm run buildを毎回実行する理由｜本番ビルド落ちを防ぐ

"Next.jsで開発していると、ローカルの動作確認だけでpushして、Vercelの本番ビルドで初めて型エラーに気づくことがあります。本記事ではnpm run buildを毎回実行すべき理由と、失敗時の確認手順を実務ログをもとに解説します。"

「ローカルではnpm run devで問題なく動いていたのに、pushしたらVercelのビルドが失敗した」——こうした経験がある方は少なくないはずです。筆者自身もtoolarc.jpの運用で、開発サーバーでは気づかなかった型エラーが、本番ビルドの段階で初めて表面化したことが何度もありました。

原因の多くは、npm run dev（開発サーバー）とnpm run build（本番ビルド）でチェックの厳しさが異なることにあります。この記事では、pushする前にnpm run buildを毎回実行すべき理由と、エラーが出たときの確認手順を1分で分かる形にまとめます。

今日の結論

npm run devで問題なく動いていても、npm run buildでエラーが出ることがあります

原因の多くは型エラーやESLintエラーで、開発サーバーでは警告どまりになりやすいためです

pushする前にローカルでnpm run buildを実行しておくと、Vercelでの失敗や公開後の修正戻りを減らせます

エラーが出たら、最初の数行と該当ファイルパスを確認すると原因を切り分けやすくなります

なぜローカルでは問題なくても本番ビルドで落ちるのか

npm run devは開発中の使い勝手を優先しており、型エラーがあってもブラウザ上にエラーオーバーレイを出しつつ動作を続けることがあります。一方npm run buildは本番向けの厳格なチェックを行うため、TypeScriptの型エラーがあるとビルド自体が失敗します。

ESLintの扱いはNext.jsのバージョンによって変わる可能性があります。執筆時点では、Next.js 16以降はnext buildが自動でLintを実行しなくなる方向性が示されており、next lintコマンド自体も廃止が進んでいます。利用しているNext.jsのバージョンでLintがビルドに含まれるかどうかは、公式ドキュメントで確認することをおすすめします。

また、CursorなどのAIツールでコードを生成した場合、エディタ上の型チェックとビルド時の型チェックが完全に一致しないケースもあります。AIが生成したコードだからこそ、pushする前のnpm run buildが最後の確認役になります。

npm run buildを実行する手順

変更が一区切りついたらターミナルを開きます
npm run build を実行します
エラーが出たら、最初の数行と該当ファイルパスを確認します
修正したら、もう一度npm run buildを実行します
成功したことを確認してから、commit / pushに進みます

ビルドが失敗したときの確認ポイント

エラーメッセージが長く表示されて戸惑うこともありますが、まずは先頭の数行に注目すれば十分です。多くの場合、エラー種別（Type errorかLint errorか）とファイルパスさえ分かれば、修正の見当がつきます。

環境変数の設定漏れが原因になることもあります。ローカルの.env.localでは動いていても、Vercel側に同じ環境変数が設定されていないと、ビルドやデプロイ後の挙動がずれることがあるため、あわせて確認しておくと安心です。

チェックリスト：pushする前に確認したいこと

確認項目	見るポイント
エラー種別	Type errorかESLint errorかを見分ける
ファイルパス	エラーメッセージ内のファイル名と行番号を特定する
環境変数	ローカルの`.env.local`とVercel側の設定に差がないか
import / exportの記述	パスの誤りやdefault exportの有無
再実行	修正後にもう一度`npm run build`を実行して成功を確認する

まとめ・次に読む

npm run buildをpush前に実行する習慣は、地味に見えても公開後の手戻りを減らす効果があります。関連して、pushのタイミングや本番ビルドの確認範囲についてさらに知りたい方は、以下の記事もあわせてご覧ください。

Next.jsやVercelのビルド挙動は、バージョンやプロジェクト構成によって変わることがあります。本記事は執筆時点（2026-07-01）の情報に基づいています。重要な判断をする際は、Next.js公式ドキュメントやVercelの公式ヘルプもあわせてご確認ください。