😌Gitの重要性をバイブコーディングで再認識した話

この記事は、Gitの解説記事ではありません。commitという概念自体は知っていたのに実際には使いこなせていなかった人間が、AIにコードを書かせるようになって初めてGitの意味を体で理解した、という個人的な記録です。

「一応使ってた」だけのGitとの付き合い方

正直に書くと、これまでのGitとの距離感はかなり中途半端でした。commitという概念自体は知っていて、プロジェクトごとに「今回はGitを使おうかな」という気分で使ったり使わなかったりしていました。使っているときも、commitメッセージは「修正」「調整」のような雑なもので済ませていました。

一番の問題は、commitしてから実際に前のバージョンへ「戻った」経験が一度もなかったことです。つまり、戻れる保証としてのGitではなく、なんとなく履歴を積んでいるだけのGitでした。戻す機会がない限り、雑なcommitメッセージも、Gitを使わないプロジェクトがあることも、実害として表面化しませんでした。

	これまでの認識	今の認識
commit	変更の記録（儀式）	戻れる地点を作る操作
commitメッセージ	「修正」で十分	差分レビューの手がかり
branch	知識として知っているだけ	実験を隔離する退路

AIの提案が壊れた瞬間に気づいた、commitのない恐怖

この感覚が変わったのは、AIにコードを書かせるようになってからです。バイブコーディングでは、複数のファイルにまたがる変更を一度に提案されることが珍しくありません。人間同士のペアプログラミングなら「ここまでで一旦区切りましょう」と自然に立ち止まる場面でも、AIは止まらずに書き進めます。

典型的にはこういう場面です。ある機能の表示を直してほしいと頼んだつもりが、AIはその表示に関係する内部のロジックまで一緒に書き換えて返してきます。動けば気づきませんが、動かなくなったときに初めて、「どこからどこまでが自分の依頼の範囲で、どこからがAIの独自判断だったのか」が分からないことに気づきます。

ここで初めて、「commitしていない状態で壊れると、元の状態にもAIの変更にも輪郭がなく、自分では追えない」という恐怖に直面しました。戻る先のcommitがなければ、git checkoutは何もしてくれません。Gitの「戻れる」という機能は、戻る先をあらかじめ作っておかない限り機能しない、という当たり前のことに、実際に使ったことがなかったせいで気づいていませんでした。

正直、この当たり前さに気づくまでにここまで時間がかかるとは思っていませんでした。頭では分かっていたつもりのことと、実際に痛い目を見て理解することの間には、かなりの距離があります。

これは決して珍しい失敗ではないようで、Gitでの復旧手段をまとめた記事¹が公開から10年以上経った今でも読まれ続けているのも、同じ状況に陥る人が多いことの表れだと思います。

ブランチを切れば、AIに大胆な実験をさせられる

もう一つの気づきは、ブランチの使い方です。今までは「ブランチ」も知識としては知っていましたが、一人で開発している以上、本流を汚す相手もいないので必要性を感じていませんでした。

AIに実装を任せる場面では話が変わります。「この設計で一旦全部書き直してみて」のような、当たるかどうかわからない大胆な指示を出したいことがあります。このとき、mainブランチのまま進めると、うまくいかなかった場合に何がどう変わったのかを手作業で切り分ける羽目になります。先にブランチを切っておけば、うまくいかなければブランチごと消せばよく、mainは無傷のまま残ります。

AIに「大胆に試していい」と言えるのは、ブランチという退路を先に用意してあるときだけだと気づきました。逆に言うと、ブランチを切る習慣がないと、AIへの指示そのものが無意識に保守的になっていた気がします。壊れたら困るから、大きな変更を頼むのを避ける。それは安全策のようで、実際にはAIの提案力を自分で制限していただけでした。

一人開発だとブランチは「チームで衝突しないための道具」だと思われがちですが、相手がAIの場合はむしろ逆で、「自分一人でも大胆な指示を出すための道具」として機能します。衝突相手は他人ではなく、未来の自分が困る可能性そのものです。

なぜ相手がAIだと、Gitの意味が変わるのか

一段抽象化すると、Gitの役割そのものは変わっていないと思います。変更の記録と、戻れる保証と、実験を隔離する仕組み。これは人間同士の開発でも同じです。

変わったのは、その保証が必要になる頻度と、必要になったときの被害の大きさです。人間が書くコードは、書く速度も変更の範囲も自分の手加減の中に収まります。AIが書くコードは、指示さえ出せば躊躇なく広い範囲を一度に変えてきます。commitやブランチという退路を用意しておく習慣がないまま任せると、被害が大きくなってから初めて必要性に気づく、という順番になりやすいのだと思います。

言い換えると、Gitはこれまで「丁寧な人が使う道具」だと捉えていましたが、今は「自分の判断力を過信しない人が使う道具」だと捉え直しています。AIは自分の代わりに手を動かしてくれますが、その手を止める権利まで渡す必要はありません。commitとブランチは、その権利を実際に行使可能な状態にしておくための仕組みです。

人間相手なら、相手も「まずいかもしれない」と思えば手を止めてくれます。AIは指示された範囲で最後まで実行しようとするので、止める判断そのものを人間側が事前に仕込んでおく必要があります。Gitはその「事前に仕込んでおく」を実現する、ほぼ唯一の実用的な手段でした。

この経験から変えた3つの習慣

同じ遠回りをしたくない人向けに、実際に変えたことを残しておきます。

• AIに変更を頼む前に必ずcommitする: 「動いている」状態を先に確定させてから頼む。頼んだ後で気づいても遅い
• commitメッセージに「何をお願いしたか」を書く: 「ログイン画面のバリデーション追加をAIに依頼」のように書くと、後から見返したときに人間の指示とAIの実装のどちらに問題があったかを切り分けやすい
• 大きめの変更や設計変更は必ずブランチを切ってから頼む: うまくいかなければブランチごと破棄する前提にすると、AIへの指示自体を大胆に出せるようになった

どれも特別な技術ではなく、Gitの教科書に最初の方で書いてあるような基本操作です。使ったことがなかっただけで、必要性はずっと前から目の前にあったのだと思います。

総括

バイブコーディングでGitが重要になるのは、コードを書くスピードが上がるからではなく、判断の主導権をAI任せにしないための最後の砦になるからだ、というのが今のところの結論です。commitとブランチは、AIに何をどこまで任せていいかを、後からでも人間が判断し直せるようにするための仕組みだと考えると、腑に落ちました。

参考リンク

• Gitでやらかした時に使える19個の奥義
• 僕が考える最強のコミットメッセージの書き方
• Git公式サイト

AIの利用について

この記事は、Claudeに一次稿を作成してもらい、内容を確認・修正したものです。記事の題材となった気づきや実体験は自分自身のもので、AIには構成と文章化を手伝ってもらいました。

1. Gitでやらかした時に使える19個の奥義。2015年の記事ながら、現在も多くのLGTMを集め続けています。 ↩