カテゴリOの入口——変更を安全に運ぶ章
カテゴリNまでで、コードを書き、動かし、整えるための基礎を積んできました。ここからのカテゴリOは、その変更を安全に運ぶための章です。バイブコーディングでは、AIが一度に多くのコードを書き換えます。もし壊れたときに戻れる仕組みが無ければ、それは崖の上で綱渡りをするようなものです。この講義は、その足元に張る安全網の話から始まります。
このスライドのポイント
- カテゴリNまで: コードを書き、動かし、整える基礎
- カテゴリO: その変更を安全に運ぶための章
- バイブコーディングでは、AIが一度に多くのコードを書き換える
- 戻れる仕組みが無ければ、それは崖の上の綱渡り
バージョン管理の定義と3つの力
バージョン管理とは、ファイルの変更履歴を時系列で保存し、3つのことができる仕組みです。1つ目は比較で、いつ何が変わったかを見られます。2つ目は復元で、過去の状態へ戻せます。3つ目は分岐で、本体を傷つけずに安全に試せます。この3つを実現する事実上の標準ツールがGitで、以降の講義でも中心に据えます。カテゴリBで触れた「動いていたときの記録」や、A-09で見た「元に戻せる変更」を、実際に支えている基盤の正体が、このバージョン管理です。
このスライドのポイント
- バージョン管理＝ファイルの変更履歴を時系列で保存する仕組み
- ①比較（いつ何が変わったか）②復元（過去の状態へ戻す）③分岐（安全に試す）
- Git＝その事実上の標準ツール（本章で中心に据える）
- B章の「動いていたときの記録」・A-09の「元に戻せる変更」を支える基盤の正体
なぜ必要か——戻れないことが最大のリスク
この仕組みを持たないと、何が起きるでしょうか。AIが大きくコードを書き換えて、どこかが壊れたとき、戻る手段がありません。これはバイブコーディングで最も大きな事故のリスクです。「昨日は動いていたのに」と思っても、いつの変更が原因だったのかを調べる手立てもありません。コードを速く書けることよりも、壊れたときに確実に戻れることのほうが、AIと組む開発では効いてきます。だからこの章を、道具の一番手前に置きます。
このスライドのポイント
- 無いと: AIが大きく書き換えて壊れたとき、戻る手段がない
- これがバイブコーディングで最も大きな事故のリスク
- 「昨日は動いていたのに」を調べる手段もない
- 書く速さより、壊れたときに戻れることが効いてくる
構造——履歴の鎖
全体像を、履歴の鎖として捉えます。変更を保存するたびに保存点が生まれ、それが時系列に、一本の鎖のようにつながっていきます。この鎖があることで、先ほどの3つの力が使えます。任意の2点を選んで比較でき、任意の点へ復元でき、任意の点から新しい枝へ分岐できます。細かい操作を覚える前に、まずは、保存点が左から右へ並んでいる、というこの一枚の絵を頭に入れてください。以降の講義は、すべてこの絵の上で進みます。
このスライドのポイント
- 変更を保存するたびに「保存点」が生まれる
- 保存点が時系列に一本の鎖としてつながる
- 鎖があるから、任意の2点を比較・任意の点へ復元・任意の点から分岐できる
- まず「保存点が並んでいる」一枚の絵を頭に入れる
具体例——壊した変更を特定して戻す
具体的な場面で見てみます。AIに機能の追加を頼んだところ、頼んでいない別の場所が壊れてしまったとします。バージョン管理があれば、現在と過去の保存点を比較して、どの変更が壊したのかを特定できます。そして、その変更の前の状態へ復元すれば、数分で元に戻せます。もしこの仕組みが無ければ、どこが原因か分からないまま、最悪の場合は作り直しです。同じ事故でも、バージョン管理の有無で結果が大きく変わる、ということです。
このスライドのポイント
- 場面: AIに機能追加を頼んだら、頼んでいない別の場所が壊れた
- 比較で、どの変更が壊したのかを特定する
- その変更の前の保存点へ復元すれば、数分で元に戻せる
- 無ければ、原因不明のまま最悪は作り直し。同じ事故でも結果が変わる
サンプル: 履歴の鎖と3つの力の図
ここで、履歴の鎖と3つの力を、一枚の図として確認します。保存点が左から右へ並び、そこから比較・復元・分岐の3本の矢印が伸びる形です。読むときの要点は2つあります。1つは、矢印はすべて既存の保存点を起点にしている点です。もう1つは、分岐しても元の鎖はそのまま残る点です。自分のプロジェクトを始めるときは、AIへ「このプロジェクトはバージョン管理されていますか。されていなければ、作業を始める前に初期化してください」と確認するところから入るとよいでしょう。
混同しやすい概念——コピーの保管との違い
よく似て見えるものと区別しておきます。ファイルのコピーを手で取っておく方法は、一見バージョン管理に似ています。しかし、コピーはすぐに散らかり、どれが最新なのかも、どこが変わったのかも分かりません。これに対してバージョン管理は、履歴を体系的に、そして比較できる形で残します。ファイル名の末尾に日付やv2を足して、フォルダを増やしていくやり方からの卒業だと考えてください。
このスライドのポイント
- ファイルのコピーを手で取っておく方法は、一見バージョン管理に似ている
- しかしコピーは、散らかる・どれが最新か分からない・どこが変わったか比較できない
- バージョン管理は、履歴を体系的に、比較できる形で残す
- 「◯◯_final_v2.zip」を増やしていくやり方からの卒業
バイブコーディングでの確認点
AIと開発するうえでの鉄則を、1つ持ち帰ってください。AIに変更させる前に、いま動いている状態を保存しておく、ということです。これがあれば、AIがどれだけ大胆にコードを書き換えても、いつでも直前の安全な地点へ戻れます。この「動く状態の保存」こそが、次回以降で学んでいく保存点の作成にあたります。細かいやり方はこの先で扱いますので、まずは、変更の前に足場を固める、という習慣そのものから始めましょう。
このスライドのポイント
- AI開発の鉄則: AIに変更させる前に、いま動いている状態を保存しておく
- そうすれば、AIがどれだけ大胆に書き換えても直前の安全地点へ戻れる
- この「動く状態の保存」が、次回以降で学ぶ保存点の作成にあたる
- まずは「変更の前に足場を固める」習慣から
まとめと次回
最後に一問一答です。バージョン管理の3つの力は何でしょうか。（少し間をとります）答えは、比較・復元・分岐の3つです。30秒でまとめます。バージョン管理とは、ファイルの変更履歴を時系列で残し、比較・復元・分岐を可能にする仕組みで、AIと組む開発の安全網でした。次回は、この履歴を管理するひとつの単位である、リポジトリへ進みます。関連資料は「Git・GitHub 完全入門」と「Git・GitHubワード50」です。ここまでお疲れさまでした。
このスライドのポイント
- 一問一答:「バージョン管理の3つの力は？」→ 比較・復元・分岐
- 30秒まとめ: バージョン管理は変更履歴を時系列で残し、比較・復元・分岐を可能にする、AIと組む開発の安全網
- 次回: 履歴を管理する単位「リポジトリ」へ
- 関連資料: 「Git・GitHub 完全入門」「Git・GitHubワード50」
