AIでブラウザゲーム制作を進めていたら、フリーズ修復で挫折した話

今日は、ブラウザゲーム制作を進めていた。

途中までは、わりと順調だったと思う。
敵AIを少しずつ強くして、ただ突っ込んでくるだけではなく、こちらの動きに対応できるように調整していた。

「お、これは少しゲームっぽくなってきたかも」

そう思える瞬間もあった。

でも、途中でブラウザがフリーズした。

そこから修復が必要になり、PowerShellを使って直そうとしたものの、うまく扱えずに挫折した。

結果だけ見ると、今日はゲーム制作が大きく進んだ日ではない。
むしろ、途中まで積み上げたものがぐちゃっと崩れて、疲れて終わった日に近い。

でも、こういう日もブログのネタにしておこうと思う。

AIを使っても、個人開発は普通に詰まる

最近は、AIやCodexを使えば、個人でもかなりのことができるようになってきた。

コードを書いてもらったり、バグの原因を探してもらったり、改善案を出してもらったりできる。
自分ひとりでは絶対に進まなかったようなゲーム制作も、AIの力を借りることで少しずつ形になってきている。

これは本当にすごい。

ただ、だからといって、何でも簡単に進むわけではない。

今回もそうだった。

敵AIを強くするところまでは進んでいた。
ゲームの方向性も少しずつ見えてきていた。
でも、ブラウザがフリーズして、修復が必要になった瞬間、一気に流れが止まった。

さらに、PowerShellでの操作もうまくいかなかった。

AIに「こう直して」と言われても、自分がその操作を正しく実行できなければ、そこで詰まる。

結局、AIを使った個人開発でも、最後は自分の理解や操作力が必要になる。

ここが難しいところだと思った。

敵AIを強くする作業は、少し面白くなってきていた

今日やっていたのは、ブラウザゲームの敵AIを強くする作業だった。

ただ強くするだけではなく、プレイヤー側が勝っている理由を見て、敵AIにもその考え方を取り入れていくような方向で調整していた。

たとえば、自分の中では、ゲームの勝ち筋として「拠点を安全に増やしていくこと」がかなり大事だと感じている。

いきなり敵の本拠地を攻めるよりも、まずは安全な場所に前線拠点を作る。
その拠点を守る。
そこからさらに次の拠点を作る。
資源や位置の有利を広げてから、最後に本格的に攻める。

こういう流れの方が、ゲームとして面白いし、勝ち筋としても安定しそうだった。

だから敵AIにも、ただ攻めるだけではなく、

• 安全なレーンを選ぶ
• 有利な場所に拠点を作る
• 拠点を守る
• 無駄な戦闘を減らす
• 資源差を作ってから攻める

といった考え方を持たせたいと思っていた。

この方向性自体は、今でも悪くないと思っている。

むしろ、ここはかなり面白くなりそうな部分だと思う。

でも、技術的なトラブルで一気に止まる

ただ、個人開発の怖いところは、ゲーム内容以前のところで止まることがある点だ。

今回で言えば、ブラウザのフリーズだった。

ゲームバランスを調整しているつもりが、突然ブラウザが固まる。
それを直そうとすると、今度はPowerShellの操作が必要になる。
そこでうまくいかない。

こうなると、ゲームを面白くする以前に、開発環境との戦いになる。

正直、かなりしんどい。

「敵AIをもっと賢くしたい」
「ゲームとして面白くしたい」
「もう少しだけ進めたい」

そう思っていたのに、実際にはコマンド操作やエラー対応で時間が消えていく。

これが続くと、気持ちも折れやすい。

今日も最終的には、かなり挫折感があった。

「AIがあれば簡単にゲームが作れる」は半分本当で、半分違う

AIを使ったゲーム制作は、たしかに強力だ。

自分ひとりでは書けないコードも出してくれる。
設計の相談にも乗ってくれる。
バグ修正の方向性も出してくれる。

でも、「AIがあれば簡単にゲームが完成する」と考えると、たぶんかなり危ない。

実際には、

• どんなゲームにしたいのか考える力
• AIに何を頼むか整理する力
• 出てきたコードを適用する力
• エラーを読んで状況を伝える力
• PowerShellなどの基本操作
• 壊れたときに戻す判断力

こういうものが必要になる。

自分はまだ、このあたりが弱い。

だから、AIに助けてもらっているのに、途中で自分の操作力不足で止まってしまうことがある。

今日の挫折は、まさにそこだったと思う。

それでも、失敗した日は無駄ではない

今日の結果だけ見れば、あまり気分は良くない。

ブラウザはフリーズした。
PowerShellもうまく使えなかった。
修復もスムーズにできなかった。
途中まで順調だった流れも止まった。

でも、完全に無駄だったかというと、そうでもない。

敵AIをどう強くすれば面白くなるかは、少し見えてきた。
自分がPowerShellまわりで詰まりやすいこともわかった。
ブラウザゲーム制作では、フリーズ対策やログ確認が重要だということもわかった。

そして何より、こういう失敗も発信のネタになる。

成功した日だけを書くと、ブログは続かない。
でも、失敗した日も「何に詰まったのか」「何を学んだのか」「次にどうするのか」まで書けば、ちゃんと記事になる。

これは、個人開発ブログとして大事な考え方かもしれない。

次は「壊れたときの戻し方」を先に整えたい

今回の反省として、次はゲームの機能追加よりも、先に開発の安全対策を整えたい。

たとえば、

• 作業前にバックアップを取る
• 変更したファイルをメモする
• エラーが出たらすぐ貼れるようにする
• PowerShellで使う基本コマンドを整理する
• フリーズしたときの確認手順を決めておく
• 一気に大きく直さず、小さく変更する

このあたりを整えた方がいいと思った。

ゲーム制作は、面白い機能を追加するだけでは進まない。

壊れたときに戻せること。
原因を確認できること。
作業の流れを整理できること。

これも、個人開発の大事な一部なんだと思う。

FIREに向けた副収入の種は、こういう失敗込みで育てる

自分がゲーム制作をしている理由のひとつは、将来の副収入の種にしたいからだ。

もちろん、今すぐゲームで稼げるとは思っていない。
そんなに甘くない。

でも、ゲーム制作を続けることで、

• 自分のコンテンツを作る力
• AIを使って開発する力
• ブログで制作過程を発信する力
• 小さなツールやゲームを公開する経験
• 将来の収益化につながる可能性

こういうものを少しずつ育てていけると思っている。

その中には、今日みたいな失敗も含まれる。

むしろ、失敗せずに進めることの方が難しい。

ブラウザがフリーズする。
PowerShellで詰まる。
修復できなくて挫折する。
一旦やる気が落ちる。

それでも、そこで終わりにせず、記録に残す。
次に同じ失敗をしないようにする。
そして、ブログ記事として誰かの参考になる形に変える。

これも、将来の自由を作るための積み上げだと思う。

今日は失敗した。でも、記事にはできた

今日は、ゲーム制作としては挫折した日だった。

途中まで敵AIを強くできていた感覚はあった。
でも、ブラウザがフリーズして、修復対応でつまずいた。
PowerShellもうまく使えず、最終的には気持ちが折れた。

ただ、それでも完全なゼロではない。

敵AIの方向性は少し見えた。
自分の弱点も見えた。
開発環境を整える必要性もわかった。
そして、こうして記事にすることもできた。

個人開発は、きれいな成功だけでは進まない。
失敗して、詰まって、戻って、また少し進む。

その繰り返しなんだと思う。

50歳FIREを目指す自分にとって、ゲーム制作はまだ小さな種でしかない。

でも、種は最初から大きな木ではない。
うまく育たない日もある。
虫がつく日もある。
水をやりすぎる日もある。
途中で折れそうになる日もある。

それでも、記録しながら育てていく。

今日は失敗した。
でも、失敗したことも含めて、またひとつ経験値になった。

次は、いきなり大きな機能追加を狙うより、まずは壊れたときに戻せる開発環境を整えたい。

そして、また少しずつ敵AIを強くしていく。

派手な進捗ではない。
でも、これも自分の人生を立て直すための、小さな積み上げのひとつだと思っている。

ブラウザゲーム制作をしていると、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やnpmコマンドの基本でもつまずくことがあります。

・PowerShell初心者が最低限覚えたいコマンドまとめ
・npm run dev と npm run build の違い
・未完成でも前に進む。僕がゲーム開発を続ける理由