AI コーディングで Git の使い方が変わった

AI コーディングエージェントを毎日使っていると、ある日ふと気づくことがある。Git の使い方が、いつの間にか変わっている。コミットメッセージは自分で書くものではなく、AI が自分の動作ログとして残すものになった。Worktree は「知ってはいるが使わない上級機能」から、3 つのエージェントを並列に走らせるための日常インフラに変わった。git revert も怖くない。AI が書いたコードは捨てても安い。

意識して変えたわけではない。使っているうちに、Git の役割が静かにずれていった。この記事では、その変化が業界全体でどう起きているのかを、製品・論文・実践者のブログから整理する。

コミットメッセージが AI のためのジャーナルになった

コミットメッセージを自分で書くことが減った。AI エージェントが動作ログとして残し、次のセッションの AI が git log で読む。書き手も読み手も AI になった。

Simon Willison はエージェントと Git を使うガイドで、エージェントに「最近の変更を見て」と伝えるとまず git log を実行し、そこからプロジェクトの文脈を組み立てる様子を報告している。コミットメッセージの質が、AI の理解の質を直接決めるという構造だ。

この流れを学術的に推し進めたのが Lore プロトコル（arXiv 2603.15566、2026 年 3 月）だ。論文では「Decision Shadow」という概念を提唱している。通常のコミットは最終的な差分だけを記録するが、そこに至るまでの推論、制約、棄却した代替案——つまり意思決定の「影」——は捨てられてしまう。Lore はコミットメッセージ末尾に構造化データを付与する git trailer という既存の仕組みを使い、この影を各コミットに埋め込む。新しいインフラは不要で、git だけで完結する。

面白いことに、33,580 件の PR を分析したフィンガープリント研究では、コミットメッセージのパターンだけで 5 種類の AI エージェントを 97.2% の精度で見分けられたという。Codex は multiline commit、Claude Code は dense comments、Cursor は箇条書き——意図せず、各エージェントが git 上に固有の「筆跡」を残している。

Worktree がエージェントの並列実行基盤になった

git worktree は 2015 年から存在する機能だが、人間が日常的に使うことは少なかった。AI エージェントがこれを変えた。

私自身、複数のエージェントをそれぞれ別の worktree で走らせている。片方がバグ修正をしている間に、もう片方がテストを書く。stash も checkout も不要で、コンテキストスイッチが発生しない。

incident.io は自社ブログで、w core some-feature claude と打つだけで worktree と Claude Code セッションが即座に立ち上がるカスタムツールを紹介している。Claude Code をほとんど使っていなかった状態から、4 ヶ月で複数エージェントの並列運用に至った。Steve Yegge の Gas Town は worktree 経由で複数の Claude Code エージェントを協調させるツールで、当初のカオスぶりから Mad Max にちなんで名付けられた。

Agentmaxxing と呼ばれるパターンでは、5〜7 体のエージェントを同時に走らせ、開発者の役割はコードを書くことからアウトプットをレビューすることに変わる。ただし実用上の上限は 5〜7 体で、それを超えるとマージコンフリクトが効率を食い潰す。

製品レベルでの対応も進んでいる。Claude Code は --worktree フラグ（v2.1.49 以降）を備え、Copilot Agent は copilot/ プレフィックス付きブランチを自動作成し、GitButler は Cursor セッションごとにブランチをフックで自動生成する。

ただし課題もある。Upsun の検証では、約 2GB のコードベースに対する 20 分の Cursor セッションが 9.82GB のディスクを消費した。Worktree 間のマージコンフリクトはサイレントに発生し、気づくのはビルド時だ。

失敗したら revert：Git がセーフティネットとして日常化した

AI がコードを書く時代、書いたコードを捨てるコストは劇的に下がった。git revert や git reset は「怖い最終手段」から「日常的なクリーンアップ」に変わった。

私のワークフローでは、AI セッションがうまくいかなければ、そのセッションのコミットをまとめて revert して最初からやり直す。チェックポイントは普通の git コミットだ。

Aider（最も初期の AI コーディング CLI の一つ）は git をセーフティネットの中核に据えた。AI の編集はすべて自動コミットされ、いつでも git diff や git revert で任意の変更を取り消せる。Claude Code はこれとは別に、編集ごとのスナップショット（チェックポイント）を持ちつつ、意味のあるまとまりでの git コミットも併用する。Copilot Coding Agent は copilot/ ブランチプレフィックスに制限し、main を直接触れないようにした上で、各ステップをコミットとしてリアルタイムに可視化する。

考えてみると、revert が怖かったのは「自分が時間をかけて書いたコード」だったからだ。AI が書いたコードなら、また生成すればいい。怖いのは git 操作ではなく、AI が生成したコードをそのまま信用することのほうだ。

bisect や blame を気軽に使えるようになった

git bisect、blame、reflog——知ってはいるけれど、コマンドを毎回調べ直すのが面倒でつい使わない。そんな機能を、AI エージェントは躊躇なく使う。

Simon Willison は同ガイドで「エージェントはほとんどの開発者より git bisect の使い方がうまい」と指摘している。bisect は「たまに思い出す便利機能」から「気になったらすぐ頼めるツール」に変わった。AI はコマンド体系を忘れないし、複雑な reflog 検索にも混乱しない。

Code Archeologist は AI が git 履歴を分析し、コードの「遺伝子系統樹」やヒートマップ、ナレッジ砂漠（誰も理解していないコード領域）を可視化するツールだ。手作業では追いきれない規模のパターンを、履歴のメタデータから浮かび上がらせる。Git AI は git notes を使った帰属情報の追跡に取り組んでおり、Quesma のブログは「vibe coding の時代こそ git blame が必要だ」と論じている。

いずれも新機能ではない。ただ、自分でコマンドを覚えなくても AI に頼める、というだけで使用頻度が変わった。

Git がエージェントのメモリバックエンドになった

ジャーナルとしての利用を超えて、git をエージェントの記憶の永続化レイヤーとして使う動きがある。

Letta Context Repositories は、エージェントの記憶を git バックドの Markdown ファイル（MemFS）として管理する。記憶の変更は毎回コミットされ、複数のサブエージェントが独立した worktree で並行処理し、git のコンフリクト解決を通じてマージする。DiffMem はワーキングツリーを現在の知識、コミットグラフを時間的な記憶としてマッピングし、数千の会話にわたって AI が記憶を維持する仕組みだ。

さらに踏み込んだ研究もある。Fork, Explore, Commit は git のセマンティクスを OS レベルに持ち込んだ。BranchFS はコピーオンライトによる隔離を提供し、ブランチ作成を 350μs 未満で実行する。AI エージェントの並列探索のために設計された OS 機能だ。

これらはまだ主流ではない。しかし方向性は明確で、git のデータモデル——スナップショット、DAG、マージ——が AI の記憶管理に自然にフィットするという認識が広がっている。

「人間同士のツール」という前提を降りる時期なのかもしれない

ここまで読むと、Git の使われ方はかなり変わっているのに、いくつかの「問題」が繰り返し指摘されていることに気づく。

たとえば粒度のミスマッチ。AI はコミットより速く変更するから git では追跡しきれないという声。あるいは AI スロップ。AI が大量の PR を生成してメンテナーの注意力を食い潰すから GitHub がキルスイッチを検討しているという話。

これらは本当に Git の問題だろうか、と考えることがある。粒度の問題は、AI の変更を人間がレビューする前提で考えるから生じているのかもしれない。AI スロップも、人間が読む PR として AI の出力を流すから問題になっているように見える。もしかすると、「Git は人間同士のコラボレーションツールだ」という前提のほうが古くなりつつあるのではないか。

この記事で見てきた変化——ジャーナル、worktree、セーフティネット、メモリバックエンド——は、どれも Git を「人間同士のツール」としてではなく「人間と AI のインフラ」として使い始めたことと関係しているように見える。問題が残っているのは、その切り替えが中途半端なところなのかもしれない。

おわりに

Git は人間同士のコラボレーションのために設計された。今起きているのは、その前提が少しずつ緩むことで、Git が本来持っていたポテンシャル——ログ、分岐、マージ、スナップショット——が AI との協業インフラとして活きはじめているという変化だと思う。この記事で紹介したパターンは、どこか一社が計画したものではなく、製品と実践者の間でそれぞれ自然に生まれた。

自分としては、コミットメッセージは AI が自分の動作ログとして残すものになったし、worktree で複数のエージェントを並列に走らせるし、リスクのある操作の前にはチェックポイントを打つ——気づいたらそういう使い方になっていて、日々の開発がだいぶ楽になった。