「一部だけGit管理」の罠。AIで爆速開発中にファイル誤上書き…全域Git管理と自動リカバリ体制へ移行した話

August 6, 2026

個人開発でWebサービスを運用していると、「開発スピード」と「安全対策」のバランスに悩むことがよくあります。

今回、まさにその甘さが裏目に出て冷や汗をかくトラブルが発生しました。 AIツールを使った爆速フロントエンド改善の最中にコードを事故らせてしまい、復元に冷や汗をかいた体験と、そこから学んだ「全域Git管理」への改善策を記録しておきます。

私の開発している本サイトは、実は少し特殊な管理構成になっていました。

トップページ（LP部分）： GitHub Actions を用いた自動デプロイが便利だったため、しっかり Git でバージョン管理。
Webアプリ部分（Reactフロントエンド＋ Flaskバックエンド）：サーバー上に staging（検証環境）と production（本番環境）のディレクトリを分け、手動でコードを配置。

普段のアプリ修正では、「変更前に手動でファイルを別名保存（app_bak.py や index_old.jsx など）しておき、Stagingで確認してからProductionへ上書きする」という、古き良き（？）手動バックアップ運用を行っていました。

トップページで「Gitって便利だな〜」と実感していたにもかかわらず、アプリ本体は「Stagingがあるから大丈夫だろう」と油断していたのです。

事態が動いたのは、AIツール（Antigravity）を導入してフロントエンド（React）のUI/UX改善を行っていた時でした。

AIのコード生成スピードは圧倒的で、こちらの指示に合わせて複数のコンポーネントやAPI呼び出しのコードを怒涛の勢いでリファクタリングしてくれます。

「すごい、めちゃくちゃ開発が進む！」とテンションが上がり、作業に没頭していました。そして、Staging環境での確認を済ませ（たと思い込み）、そのままProduction環境へファイルを上書き配置。

…しかし、直後に画面を開いて絶句しました。

「表示が崩れてる…というか、Flaskバックエンドとの通信もエラーで動かない！？」

Staging環境の段階で見落としていた不具合が、そのまま本番環境に反映されてしまったのです。

急いで「直前のファイルに戻そう！」とサーバーを開いたのですが、そこで血の気が引きました。 AIが複数ファイルにまたがる大幅な書き換えを一瞬で行ってくれたため、いつもならやっていた「変更直前の手動バックアップ（別名保存）」をすっかり取り忘れていたのです。

Git管理していないディレクトリのため、git checkout で一瞬で巻き戻すこともできません。完全な手詰まりです。

絶望的な状況の中、救世主となってくれたのは「別のAI」でした。

動かなくなってしまった最新コードと、Flask側のAPI定義、そして記憶と残骸を別AIに読み込ませ、「どこで依存関係が崩れたのか」「元のロジックとどう乖離しているか」を地道に解析させました。

AIが崩したコードのパズルを、別のAIの手を借りて解き明かすという何とも現代的な（そして不毛な）作業を繰り返し、なんとか正常に動く状態まで復元することができました。

今回のヒヤリハットから得た一番の教訓は、 「AIを活用する時代だからこそ、手動バックアップ（ファイル別名保存）は完全に破綻する」 ということでした。

人間が1ファイルずつ手書きで直している時代なら、「ファイルをコピーして保存」も機能していました。しかし、AIは**人間とは比べものにならないスピードと量（複数ファイル同時修正）**でコードを変更します。その速度感の中で、人間が毎回漏れなく手動バックアップを取り続けるのは不可能です。

また、「StagingとProductionを分けているから安心」というのも勘違いでした。バージョン管理（世代管理）がなければ、一度プロダクションに不具合が混入した際、「どの時点のコードが正解だったのか」を追うことができなくなります。

AIが爆速でコードを生み出すからこそ、人間側には 「いつでもボタン一つで1秒前の正常な状態（コミット）に巻き戻せる安全網」 が絶対に必要なのだと痛感しました。

今回の件を猛省し、現在は以下の環境改善を進めています。

これで次回からは、どんなにAIと攻めたリファクタリングに挑戦して事故ったとしても、落ち着いて git reset や git revert を叩けば一瞬で平和な日常を取り戻せます。

「ちょっと一部だけGit管理から外れてるんだよね…」という箇所がある方、AI開発を本格化させる前に、ぜひサイト全域のGit管理化をおすすめします！