AIコーディングとエージェント

【バイブコーダー #3】AIがコードを全部書いてくれるのに、なぜGitが必要なのか(壊れたアプリを1分でロールバック)

バイブコーディングをしていると、必ずこんな日が来ます。昨日まで正常に動いていたアプリに機能を1つ追加してほしいと頼んだら、AIがあちこちを修正し、アプリ全体が動かなくなる日です。「さっきの状態に戻して」と頼んでも、AIは正確には戻せません。修正箇所は20か所もあり、そのうちどこが…

読了 6 分
【バイブコーダー #3】AIがコードを全部書いてくれるのに、なぜGitが必要なのか(壊れたアプリを1分でロールバック)のカバー画像

バイブコーディングをしていると、必ずこんな日が来ます。昨日まで正常に動いていたアプリに機能を1つ追加してほしいと頼んだら、AIがあちこちを修正し、アプリ全体が動かなくなる日です。「さっきの状態に戻して」と頼んでも、AIは正確には戻せません。修正箇所は20か所もあり、どこが問題なのかAI自身にも分からないからです。

Gitは、そんな日のために存在します。「AIがコードを全部覚えているのに、なぜGitが必要なのか」とよく聞かれますが、結論から言えば、AIはコードを覚えていません。 会話が長くなると忘れ、新しい会話を開けば白紙に戻ります。コードの過去を覚えているのはAIではなくGitです。

Gitはゲームのセーブポイント

Gitの考え方はゲームのセーブとまったく同じです。ボス戦に入る前にセーブしますよね。死んでもセーブポイントからやり直せるからです。Gitのコミットが、そのセーブに当たります。1回のコミットには、その瞬間のプロジェクト全ファイルのスナップショットが恒久的に保存されます。

セーブファイルが増えるように、コミットも増えていきます。「ログイン機能完成」時点のコミット、「決済を追加する前」時点のコミット。いつでも好きな時点に戻れます。AIがアプリを壊したときに必要なのは、まさにこれです。20か所の修正から問題箇所を探す必要はなく、プロジェクト全体を最後のセーブポイントに戻せば終わりです。

COMMITセーブポイントのタイムラインで、AIがアプリを壊したときに最後のコミットへロールバックし、GitHubへプッシュしてバックアップする流れを示す図
セーブポイントがあれば、20か所のうちどこが問題か探す必要はありません

覚えるべき言葉は4つだけ

Gitには数十個のコマンドがありますが、バイブコーダーに必要な概念は4つだけです。コマンドを暗記する必要もありません。AIに言葉で指示すればよいからです。

  • リポジトリ:プロジェクトフォルダに付く「セーブデータ保管庫」です。AIコーディングツールが通常、最初に作成します。
  • コミット:セーブです。現在のスナップショットを保管庫に記録します。
  • プッシュ:セーブファイルをクラウドにバックアップすることです。バックアップサーバーがGitHubです。パソコンが壊れてもコードが残る理由です。
  • ロールバック(巻き戻し):プロジェクト全体を過去のセーブポイントに戻すことです。

GitHubにバックアップするときの注意点は、第2回ですでに扱いました。リポジトリを公開(Public)にすると、ボットが数分以内にスキャンします。特別な理由がなければ、**非公開(Private)**にするのが基本です。

実践のリズム:「機能1つ、コミット1つ」

Gitの使い方は、1つの習慣に要約できます。何か1つが正常に動くようになったら、そのたびにセーブすることです。

  • ログインがついにできた → 「今の状態をコミットして」
  • デザインを手直しする前 → 「修正する前にコミットして」
  • 今日の作業終了 → 「コミットしてGitHubにプッシュして」

CursorでもClaude Codeでも、AIコーディングツールはこの言葉を理解して代わりに処理してくれます。自分でコマンドを入力する必要はありません。重要なのはタイミングです。ボス戦(大きな修正)の前にセーブしなければ、死んだときに戻る場所がありません。AIに大きな修正をさせる前のコミットが、最も価値のあるコミットです。

逆に、最もよくある失敗はこれです。数日間コミットせずに作業を積み上げ、その後AIがアプリを壊してしまうこと。戻るセーブポイントがないため、正常に動いていた頃のコードは永遠に失われます。コミットしていない変更はGitでも守れません。

壊したとき:1分でロールバック

AIがアプリを壊したら、次の順番で対応します。

  1. 落ち着いてAIにこう伝えます。「さっきの修正でアプリが壊れた。最後のコミットの状態に戻して」
  2. AIがロールバックを実行すると、コミット後の変更がすべて消え、プロジェクトがセーブポイントに戻ります。
  3. アプリが再び動くことを確認したら、さきほど失敗した修正をより小さな単位に分けて再度試します。一度に20か所を直させず、1回に1つずつ変更します。

ここで第1回の区別が再び登場します。**ロールバックで戻るのはコードだけです。**DBに蓄積されたデータはGitとは無関係にそのまま残ります。コードを昨日の状態に戻しても、今日登録したユーザーは消えません。逆に、誤って削除したデータをGitで復元することもできません。コードの過去はGitが、データの過去はDBバックアップが担います。

.envファイルも同じです。第2回で.gitignoreに登録してGitが追跡しないようにしたため、Gitはこのファイルを守りません。キーを再発行したら、パスワードマネージャーなどに別途記録しておくと安全です。

「ROLLBACK REWINDS CODE ONLY」の文字とともに、コードのフィルムが過去へ巻き戻る一方でDATABASEの金庫はそのまま残る対比イラスト
ロールバックで巻き戻るのはコードだけ。データの過去はDBバックアップが担います

今日できるセルフチェック

AIにこう聞いてみましょう。

  1. 「このプロジェクトにはGitリポジトリが作られている?最後のコミットはいつ?」—リポジトリがない、または最後のコミットが1週間前なら、今がコミットのタイミングです。
  2. 「GitHubにバックアップ(プッシュ)されている?リポジトリは公開?非公開?」—バックアップがなければ作成を頼み、公開状態なら非公開への切り替えを検討します。
  3. 「コミットしていない変更はどれくらい溜まっている?」—正常に動いているなら、すぐにコミットしてもらいます。

まとめ

  • AIはコードの過去を覚えられません。記憶するのはGitの仕事です。
  • コミットはセーブ、プッシュはクラウドバックアップ(GitHub)、ロールバックはセーブポイントへの復帰です。
  • リズムは1つです。正常に動くたびに、そして大きな修正の直前に「コミットして」と伝えます。
  • ロールバックで戻るのはコードだけです。DBデータと.envはGitの外側の世界です。
  • 特別な理由がなければ、リポジトリは非公開が基本です。

次回はデプロイです。自分のパソコンでは完璧に動くアプリが、なぜインターネットに公開すると動かなくなるのか、localhost、サーバー、ドメイン、環境変数がそれぞれ何を意味するのかを解説します。