npm run dev と npm run build の違い｜ブラウザゲーム制作で初心者が混乱したポイント

ブラウザゲーム制作をしていると、PowerShellでよく出てくるコマンドがある。

npm run dev

と、

npm run build

この2つ。

自分も最初は、なんとなく言われるままに打っていた。

「動かすときは npm run dev」
「確認するときは npm run build」

くらいの理解だった。

でも、ブラウザゲーム制作でフリーズしたり、エラーが出たり、AIやCodexに修復してもらったりしているうちに、この2つの違いをちゃんと理解しておいた方がいいと思うようになった。

今回は、初心者の自分用メモとして、npm run dev と npm run build の違いを整理しておく。

ざっくり言うと、dev は開発用、build は本番前チェック

まず、かなりざっくり言うとこう。

npm run dev
→ 開発中のゲームやアプリをブラウザで動かすためのコマンド

npm run build
→ 公開・本番用に問題なく作れるか確認するコマンド

自分の感覚で言うと、

npm run dev
→ 作りながら見るための起動ボタン

npm run build
→ 壊れていないか確認する検査ボタン

という感じ。

どちらも大事だけど、役割が違う。

npm run dev は「開発中に動かして確認する」コマンド

npm run dev は、開発中のゲームやWebアプリをブラウザで動かすために使う。

たとえば、自分のブラウザゲームを起動したいときは、PowerShellでプロジェクトフォルダに移動してから、こう打つ。

npm run dev

うまくいくと、PowerShellにこんな感じのURLが表示される。

http://localhost:5173/

このURLをブラウザで開くと、開発中のゲームを確認できる。

つまり、npm run dev は、

• ゲーム画面を表示する
• 操作して動きを見る
• 敵AIの挙動を確認する
• UIの表示を確認する
• 修正後にブラウザで試す

ためのコマンド。

ゲーム制作で言えば、実際にプレイしながら確認するために使う。

dev は開発中に便利だけど、本番用チェックとは違う

npm run dev はとても便利。

コードを修正すると、ブラウザ側に反映されることも多い。
動きを見ながら調整できる。
ゲームの操作感やバランスを確認しやすい。

ただし、ここで注意したいのは、

dev で動いているからといって、完全に問題ないとは限らない

ということ。

開発用サーバーでは動いているように見えても、npm run build をするとエラーが出ることがある。

自分もここで混乱しやすかった。

「ブラウザでは動いていたのに、build したらエラーが出る」
「dev では画面が出るのに、公開用には作れない」
「動いてるならOKじゃないの？」

と思ってしまう。

でも、dev と build は見ているポイントが少し違う。

dev は開発中に動かすためのもの。
build は公開できる形にまとめられるか確認するもの。

だから、両方見る必要がある。

npm run build は「公開できる形にできるか確認する」コマンド

npm run build は、ゲームやWebアプリを本番用にまとめられるか確認するためのコマンド。

PowerShellではこう打つ。

npm run build

このコマンドを実行すると、TypeScriptやViteなどの設定に従って、プロジェクト全体をチェックしながら、本番用のファイルを作ろうとする。

このとき、コードに問題があるとエラーが出る。

たとえば、自分が実際につまずいたようなエラーだと、

Cannot redeclare block-scoped variable

みたいなものが出ることがある。

これは、ざっくり言えば、

「同じ名前の変数を同じ範囲で重複して宣言している」

というようなエラー。

こういう問題は、ブラウザでなんとなく動いているように見えても、build の段階で止まることがある。

build は「完成品を作る前の検査」に近い

自分の中では、npm run build は完成品を作る前の検査に近い。

ゲーム制作で言えば、

npm run dev
→ 実際に遊びながら確認する

npm run build
→ コード全体が壊れていないか検査する

という感覚。

build が通らない状態だと、どこかに問題が残っている可能性が高い。

もちろん、build が通ったからといってゲームが面白いとは限らない。
敵AIが賢いとも限らない。
バランスが良いとも限らない。

でも、少なくとも、

公開用の形にまとめる段階で止まるようなエラーはない

という確認にはなる。

なので、AIやCodexにコードを修正してもらった後は、まず npm run build を試すのが大事だと思った。

dev と build の違いを表にすると

自分用に整理すると、こんな感じ。

コマンド	役割	使う場面
npm run dev	開発中のゲームを動かす	ブラウザで動作確認したいとき
npm run build	本番用に作れるか確認する	エラーがないか検査したいとき

もう少し具体的にすると、こう。

確認したいこと	使うコマンド
ブラウザでゲームを起動したい	npm run dev
敵AIの動きを見たい	npm run dev
UIが表示されるか確認したい	npm run dev
TypeScriptエラーを確認したい	npm run build
公開用ファイルを作れるか確認したい	npm run build
Codex修正後に壊れていないか確認したい	まず npm run build、その後 npm run dev

この最後が大事だと思う。

コードを修正した後は、

1. npm run build でエラー確認
2. npm run dev で実際にブラウザ確認

という流れにすると、安全に進めやすい。

自分のブラウザゲーム制作での使い分け

自分のブラウザゲーム制作では、だいたいこんな流れで使うことになりそう。

まず、プロジェクトフォルダに移動する。

cd "$HOME\Webアプリ開発（2026年3月8日～）\RTS_app\rts-prototype"

次に、エラーがないか確認する。

npm run build

ここでエラーが出たら、まずそのエラーを直す。
無理に npm run dev で動かそうとしない。

build が通ったら、開発用サーバーを起動する。

npm run dev

表示されたURLをブラウザで開いて、実際にゲームを確認する。

この流れが基本になりそう。

CodexやAIに修正してもらった後は build が大事

AIやCodexにコードを修正してもらうと、一見すごく進んだ気になる。

実際、かなり助かる。

ただ、自分の場合、ここで油断しやすい。

「修正してもらったから、たぶん大丈夫だろう」
「とりあえず dev で動かしてみよう」
「ブラウザで開けば確認できるだろう」

と思ってしまう。

でも、修正後にまずやるべきなのは、たぶん npm run build。

なぜなら、build でエラーが出る場合、コードとして壊れている可能性があるから。

特に、以下のような修正後は build した方がいい。

• 新しい関数を追加した
• 既存ファイルを大きく書き換えた
• 複数ファイルを変更した
• 変数名や型を変更した
• AIに自動修復してもらった
• エラー対応のパッチを当てた

こういうときは、まず npm run build。

そしてエラーが出たら、そのエラー全文をAIに貼る。

npm run build を実行したら、以下のエラーが出ました。
原因と修正方針を教えてください。

という形にすると、相談しやすい。

dev は「ゲームとしての確認」に使う

一方で、npm run dev はゲームとしての確認に使う。

build が通ったとしても、それだけではゲーム内容まではわからない。

たとえば、

• 敵AIが強くなりすぎていないか
• 味方が変な動きをしていないか
• ブラウザがフリーズしないか
• UIが崩れていないか
• ボタンが反応するか
• ゲームとして面白いか

こういうことは、実際に起動して触らないとわからない。

だから、build が通った後に npm run dev を使う。

自分のゲーム制作で言えば、敵AIを強くした後は、dev で実際にプレイして確認する必要がある。

ただし、ここでブラウザがフリーズした場合は、単に「ゲームバランスが悪い」だけでなく、

• 無限ループしていないか
• AIの計算が重すぎないか
• 毎フレーム処理が増えすぎていないか
• ログ出力が多すぎないか
• 同じ処理を大量に繰り返していないか

みたいな技術的な問題も疑う必要がある。

このあたりは、今後の課題。

dev 実行中は PowerShell が止まって見える

初心者として混乱しやすいポイントがこれ。

npm run dev を実行すると、PowerShellがそのまま止まったように見えることがある。

でも、これはエラーで止まっているとは限らない。

開発サーバーが起動し続けている状態。

つまり、そのPowerShellは今、

開発サーバーを動かす係

になっている。

なので、そのまま別のコマンドを打とうとしても、入力できないことがある。

別のコマンドを打ちたい場合は、

Ctrl + C

で止める。

または、PowerShellをもう1つ開いて、そちらで別のコマンドを実行する。

これを知らないと、

「PowerShellが固まった？」
「何も打てない？」
「また壊れた？」

と勘違いしやすい。

自分もここは覚えておきたい。

build は終わると PowerShell が戻ってくる

npm run build は、基本的には実行して結果が出たら終わる。

成功したら成功。
エラーが出たらエラー。

その後、またPowerShellでコマンドを打てる状態に戻る。

つまり、

npm run dev
→ サーバーを起動し続ける

npm run build
→ チェックして終わる

という違いもある。

ここはかなり大事。

初心者のうちは、

dev は起動しっぱなし
build は確認して終了

と覚えておくとよさそう。

エラーが出たときの相談テンプレ

今後、AIやChatGPTに相談するときは、こんな形で貼るとよさそう。

ブラウザゲーム制作中です。

実行したコマンド：
npm run build

出たエラー：
ここにエラー全文を貼る

直前にやったこと：
敵AIの処理を修正しました。
analysis.ts を変更しました。

確認したいこと：
原因と、初心者でも安全にできる修正手順を教えてください。
できれば、まず調査方針からお願いします。

npm run dev で問題が出た場合は、こう。

ブラウザゲーム制作中です。

実行したコマンド：
npm run dev

起きた問題：
ブラウザがフリーズしました。

直前にやったこと：
敵AIを強くする修正を入れました。

確認したいこと：
無限ループや重い処理の可能性を含めて、確認すべき場所を整理してください。
いきなりコード修正せず、まず原因候補を出してください。

このテンプレは、かなり使えそう。

AIに丸投げするのではなく、状況を整理して渡す。
これだけで、修復の成功率が上がる気がする。

初心者が覚えるなら、この順番でいい

npm run dev と npm run build の違いは、最初から完璧に理解しなくてもいい。

まずはこの順番で覚えればよさそう。

1. プロジェクトフォルダに移動する

cd "$HOME\Webアプリ開発（2026年3月8日～）\RTS_app\rts-prototype"

2. build でエラー確認する

npm run build

3. エラーがなければ dev で起動する

npm run dev

4. ブラウザで確認する

表示されたURLをブラウザで開く。

5. 止めたいときは Ctrl + C

Ctrl + C

この流れだけでも、かなり事故が減りそう。

自分用の結論

自分用にまとめると、こう。

npm run dev は、開発中のゲームをブラウザで動かすためのコマンド。
npm run build は、コードが公開用にまとめられるか確認するためのコマンド。

さらに短くすると、

dev = 動かして見る
build = 壊れていないか検査する

という感じ。

今後、CodexやAIでゲーム制作を進めるときは、

修正後はまず build
問題なければ dev
ブラウザで実際に確認

この順番を意識したい。

まとめ：dev と build を理解すると、挫折しにくくなる

ブラウザゲーム制作では、PowerShellやnpmコマンドでつまずくことがある。

自分も、AIを使って敵AIを強くしようとしていた途中で、ブラウザがフリーズしたり、修復対応でPowerShellに詰まったりした。

その中で、npm run dev と npm run build の違いを理解しておくことは大事だと思った。

npm run dev は、開発中のゲームをブラウザで動かすためのもの。
npm run build は、コードが本番用にまとめられるか確認するためのもの。

どちらか片方だけでは足りない。

build が通っても、ゲームとして面白いかはわからない。
dev で動いても、公開用に問題なく作れるとは限らない。

だから両方使う。

まず build で壊れていないか確認する。
次に dev で実際に動かして確認する。

この流れを覚えるだけでも、AIを使った個人開発でかなり挫折しにくくなると思う。

50歳FIREに向けて、副収入の種としてゲーム制作を育てていく。
そのためには、派手な機能追加だけではなく、こういう地味な基礎も大事になる。

今日の学びはシンプル。

dev は動作確認。
build はエラー確認。
修正後は、まず build。

次にゲーム制作を再開するときは、この順番を意識して進めたい。

“関連記事

・AIでブラウザゲーム制作を進めていたら、フリーズ修復で挫折した話
・PowerShell初心者が最低限覚えたいコマンドまとめ
・未完成でも前に進む。僕がゲーム開発を続ける理由 “