この記事は「 本番環境などでやらかしちゃった人 Advent Calendar 2025 」の6日目です。
私の前職で起こった出来事です。
stg環境がいかに大切かを思い知らされたやらかしを共有したいと思います。
本来あるべき姿
普通の開発においてはこのような形になっていることが当たり前かと思います。
しかし、前職の環境では以下のようになっていました...
はい。この構造を見て、「これはアカン...」と思われた方。御名答です。
また、当時開発環境にはパラメーターでコードを指定すると任意コードを実行できるというエンドポイントがありました。
stg環境にコードを上げた後に本番環境のデータベースを使ってテストするという大変危険な構造になっています。
更に数ヶ月後には、以下のような環境になりまして全エンジニア冷や汗状態と化しました。
🚨事件発生🚨
動的実行にて本番環境のusersデータベースが削除されました。
正規表現で以下のコマンドは実行できないように制限していました。
DELETE, DROP
みなさまお気づきでしょうか。SQLコマンドで削除が行えるコマンドが一つ抜けていることを。
そうです。「「「「「「「TRUNCATE」」」」」」」 が抜けています。
実際に実行されたコードは以下です。
sql:TRUNCATE TABLE users;
※この環境ではsql:をつけることでMySQLのrootユーザーで動的実行できるようになっていました。
DELETEと異なり、TRUNCATEは削除を戻すことができません。
幸い削除の2時間前のバックアップが自分の手元にあり、1時間程でサービスを復旧させることができましたが、サービスの導入会を翌日行う予定が控えていたので、延期にするかなどの判断がよぎりましたが、特に欠損もなく復元ができました。
なぜこうなったか❓
当初は環境を分けて開発していました。
自分含め当初はインターンだったわけですが、エンジニアがインターンで構成されるというカオスでサービス提供をしていたので、自分が2日程休んでいる間に環境が破壊されることが多々ありました。
余談ですが、コードの命令規則どころかサービスの構成図すら存在していませんでした。
現在は解消されているのかは不明ですが、多くのコードがAIのノーチェックで書かれていることが多々あり、不安定な動作をしております。
どうすればよかったか😔
動的実行できる仕組みを即廃止すべきでした。
また、サービスのシステム構造を全員が理解して、環境が破壊されないような仕組み作りをすべきだったと反省しています。
GitHubのリポジトリにPRを出して通せばいつでも本番環境にデプロイされる形だったため、GitHub Actionにてビルドチェックなどはされる仕組みはありましたが、無効化することができる仕組みが構築されており、多々無効化されてpushされることもありました。
結論は、
インターンを管理できない状態 かつ 動的実行ができる状態でサービスを作らない
これに尽きます。
当時のメンバーはこのような形でした。
・フロントバックエンド(各2年実務経験あり) ← me
・フロントエンド(完璧に理解できる笑)、バックエンド(少しだけ) (実務経験なし)
・データベース理解できる(実務経験なし、コンテストで県1位)
まとめ
・動的実行ができる仕組みを作らない
・本番環境と開発環境は分離する。
・インターンへの教育はしっかりする。
・環境破壊ができない環境を作る。
・会社の環境を整える
おわりに
現在、ラーメン店向けの業務システム開発
（券売機UI、QR決済連携、在庫管理、CSV自動処理、LINE連携、Cloudflare Workers など）を行っておりますが、
次のステップとして 新たな開発案件・企業様とのご縁を探しております。
主に以下の領域を得意としています。
・Webアプリケーション開発（React / Next.js）
・バックエンド開発（FastAPI / Node.js）
・サーバーレス（Cloudflare Workers / Firebase）
・LINE API / 決済API / 業務システム連携
・小規模〜中規模プロダクトの0→1構築、既存システム改善
・ちょっとDXしてみたいけど何かしたい
業務委託・インターン いずれも歓迎です。
もし「話だけでもしてみたい」「ちょっと相談したい」という方がいらっしゃいましたら、
X（旧Twitter）のDM等からお気軽にご連絡いただけますと幸いです。
今後も現場で得た知見をQiitaにアウトプットしていきますので、
引き続きよろしくお願いいたします。