AIが速く作るほど、「戻せる」が効いてくる — AI時代にGitが不要にならない理由

AIがコードを書いてくれるなら、GitやGitHubみたいな開発者の道具はもう覚えなくていいのでは——AIでアプリを作り始めた人から、よくこう聞かれる。

半分は正しい。コマンドを暗記する必要は、もうほとんどない。実際、うちでもGitの操作そのものはほぼ全部AIがやっている。

でも半分は逆だ。AIが速く大量に作るほど、Gitが提供している「構造」の方は効いてくる。 操作は不要になったのに、仕組みとしての重要度はむしろ上がった。理由は3つある。

1. 速く作るは、速く間違えるでもある

AIに開発を任せると、人間の何倍もの速度で変更が積み上がる。そして変更の速度が上がるということは、間違いが混ざる速度も上がるということだ。

人間の新人なら、1日かけて書いた変更を翌日レビューすれば追いつける。AIは1時間で10件の変更を出してくる。全部をその場で完璧に検品するのは無理で、どこかで「あとから間違いに気づく」ことを前提にするしかない。

このとき効くのが、Gitの一番基本の機能——変更がセーブポイントごとに記録されていて、いつでもその時点に戻せることだ。

うちの現場でも、AIが良かれと思って余計な変更を混ぜてきたことは何度もある。それでも被害が事故にならないのは、AIの精度が高いからではない。戻せるからだ。 AIに任せる勇気の正体は、性能への信頼ではなく、この「戻せる」という構造だった。

2. 壊れる範囲を、先に限っておける

Gitにはブランチという仕組みがある。本体（main）から枝分かれした作業用のコピーの上で変更を進め、良ければ本体に合流させる。

これをAIとの分業に当てはめると、意味が変わって見える。ブランチは「AIが壊していい範囲」の宣言だ。

AIには本体を直接触らせない。枝の上でだけ作らせる。枝の上で何が起きても、本体＝いま動いている業務には影響しない。うちではAIのセッションを複数並行で走らせることがあるが、それぞれ別の枝で作業させることで、互いに踏み合わない。

実際、この規律を徹底する前には、2つのAIセッションが同じ改修を同時に作り始めて、成果物が衝突したことがある。直したのはAIの性能ではなく運用で、「着手前に枝を分け、着手したことを台帳に書く」という構造を足したら再発しなくなった。

3. 「人が承認する場所」が、構造として手に入る

3つ目が、AI時代にいちばん大事になった変化だ。

Gitの世界には、枝の変更を本体に合流させる前に「この変更を入れていいか」を確認する関所がある（プルリクエストと呼ぶ）。人間同士の開発では、これは同僚によるレビューの場だった。

AIとの開発では、ここが「AIの提案を人が承認する場所」になる。

うちでは、本体への合流＝本番反映になるように仕組みを組んでいる。つまり合流ボタンを押すことが「公開してよし」の判断そのものだ。AIは枝の上でいくらでも作っていい。でも本番に届く手前に、必ず人の判断が1回挟まる——この関所は、注意書きやお願いではなく、仕組みとして存在する。

以前この Journal に「AIへの指示書に書いても、AIは確率でしか守ってくれない」という記事を書いた。「本番に出す前に確認して」と指示書に書いても、確率でしか守られない。合流の関所は、それを確定に変える装置でもある。

Gitは「開発者の道具」から「AIと働くための台帳」へ

まとめると、AI時代のGitは意味が変わった。

• 昔: プログラマがコードを管理するための専門道具
• いま: AIに仕事を任せるための、戻せる・壊れる範囲を限る・承認の場所を作る、の3点セット

これは実は、契約書の版管理や稟議のワークフローと同じ発想だ。誰が・いつ・何を変えたかが残り、確定の前に承認が挟まる。開発の専門知識というより、業務統制の話に近い。

だから、AIでアプリを作りたい人がGitについて知るべきことは、コマンドではなくこの3行で足りる。

• AIには枝（ブランチ）の上で作らせる。本体は直接触らせない
• 本体への合流は人が押す。そこが承認の場所
• 何かおかしければ、戻せる。だから任せられる

操作はAIに任せていい。でもこの構造を知らないままだと、AIの提案を「いいらしいから」で全部通すことになる。判断する場所がどこにあるかを知っていること——それがAI時代にGitを「使える」ということだと思う。