AIエージェントを使う人のGit入門：ブランチ、小さなコミット、元に戻し方

AIエージェントにコードの作業を任せる人なら誰でも、Gitを使ったことがない初心者の方でも読めます。前提知識は要りません。用語にはどれも身近なたとえを添え、コマンドの部分には印をつけてあるので、写して試しても、読み飛ばしてもかまいません。

実例のコマンドと出力は、すべて練習用リポジトリで実際に動かしたものです（Gitのバージョンは2.56.0、2026年10月30日）。「例」と書いた場面は作った例で、実在の人物や会社には触れていません。エージェントが内部でどう間違えるのかは、まだ誰にも完全には分かっていません。以下のたとえは覚えやすくするための補助にすぎません。

---

まず要点#

• エージェントは数分で多くのファイルを直せます。戻る手段がないと、1回の失敗が作業時間をまるごと飲み込みかねません。Gitはセーブポイントです。コミットしたものだけを覚えています。
• 基本の習慣は、任せる作業ごとにブランチを分ける、エージェントに小さなコミットを求める、結果を受け取る前にgit status、次にgit diffを読むの3つです。
• 戻る道は4つあり、場面ごとに使い分けます。git restore（まだコミットしていない）、git revert（コミット済みで最も安全）、git reflog（うっかりの後の救出）、git worktree（最初からエージェント専用のフォルダで作業させる）。
• いちばんの死角：git restoreで捨てた未コミットの変更は取り戻せません。この記事の練習用リポジトリでは、reflogにその記録はありませんでした。
• セーブポイントが守るのはリポジトリ内のファイルだけです。消えたデータベースや送信済みのメールはGitの外にあります。
• 破壊的なコマンド（push --force、reset --hard、clean）は、エージェントへの指示に確認なしで実行しないと書いておきましょう。

---

むずかしい言葉をやさしく#

---

1. まずイメージ：セーブポイントのあるゲーム#

長いゲームを遊んでいるところを想像してください。一度もセーブしなければ、1回やられると1時間分が消えます。数分おきにセーブしていれば、やられても失うのは数分です。

エージェントに任せるのも同じです。エージェントはとても速く、少しせっかちなプレイヤーです。最初のファイルを読み終える前に、10個のファイルを直してしまうこともあります。優秀ですが、いつも正しいわけではありません。エージェント系ツールの文書自身もそう述べています（第6節）。セーブポイントはエージェントの間違いを減らしません。間違いを安くします。

その役を担うのがGitで、大事なルールが1つあります。**Gitはコミットしたものしか覚えていません。**フォルダの中にあるだけでコミットしていない変更は、セーブせずにステージの途中を遊んでいるようなものです。

**教訓：**作業を任せる前に、きれいなセーブポイントを作っておきます。エージェントが作業している間は、こまめにセーブするよう求めます。

---

2. 5ステップの手順：作業ごとにブランチを分ける#

食卓にいくつものお皿があるところを想像してください。新しい料理をいきなりメインの皿で試さず、別の皿に盛ります。失敗したらその皿ごと捨てればよく、メインの皿は無傷です。

以下は、注文の合計を計算するprices.pyという1つのファイルだけを入れた練習用リポジトリで、実際に動かしたものです。mainブランチに最初のセーブポイントが1つあります。

ステップ1：この作業専用のブランチを作る#

git switch -c agent/add-discount

Switched to a new branch 'agent/add-discount'

agent/作業名という名前の付け方にしておくと、ブランチ一覧を見ただけでエージェントのものだと分かります。Gitの決まりではなく、私の習慣です。

ステップ2：作業を任せ、エージェントに進めさせる#

エージェントに「total関数に、任意の割引パラメータを加えて」と頼みます。エージェントがファイルを編集します。

ステップ3：受け取る前にgit status、次にgit diffを読む#

git status -sb
git diff

## agent/add-discount
 M prices.py
diff --git a/prices.py b/prices.py
index de87eb8..d7bc76f 100644
--- a/prices.py
+++ b/prices.py
@@ -1,2 +1,3 @@
-def total(items):
-    return sum(item["price"] * item["qty"] for item in items)
+def total(items, discount=0):
+    subtotal = sum(item["price"] * item["qty"] for item in items)
+    return subtotal * (1 - discount)

Mは1つのファイルが変更されたという意味です。-で始まる行は削除された行、+で始まる行は新しい行です。この読み取りは、記事AIの結果に証拠を添えさせる5つの方法の「証拠を開く」ステップであり、AIが書いたコードのレビューの最初の部分でもあります。

ステップ4：小さくコミットする（セーブポイント）#

git add prices.py
git commit -q -m "feat: add optional discount to total"
git log --oneline

c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function

-qはコマンドを静かにするだけの指定です。1コミット1作業で、一言で説明できる大きさにします。メモはConventional Commits（よく使われる書き方の約束で、必須ではありません）のfeat: 作業名の形です。

ステップ5：納得したらマージする#

差分を読み、チェックも走らせたら、ブランチをmainに取り込むのはあなた自身です。

git switch main
git merge --no-ff -q agent/add-discount -m "merge: add discount"
git log --oneline --graph

*   04cbf8d merge: add discount
|\  
| * 5aee66b feat: add extra script
| * c5b6fbf Revert "refactor: simplify total"
| * 6f88dd0 refactor: simplify total
| * c9c7cf3 feat: add optional discount to total
|/  
* 6dd4973 feat: add total function

mainブランチには、あなたが目を通したものだけが入ります。途中のセーブポイント（refactor、Revert、extra script）は、第3節の実験で作ったものです。

2.1 自分で確かめられる計算（例、読み飛ばし可）#

数字を作った例です。エージェントが3時間（180分）休まず作業し、最後の1分で問題が起きたとします。

session = 180
no_commit_loss = session            # 一度も保存しない: 最大180分を失う
every = 20
saves = session // every            # セーブポイント9個
worst_loss = every                  # 失うのは最大20分
print(saves, worst_loss, session - worst_loss)
# 9 20 160

結果の読み方：20分ごとにコミットすれば、セーブポイントは9個になり、最悪の事故でも失うのは180分ではなく最大20分、つまり160分は守られます。20分はこの例のための私の仮定です。現実に決まった公式はありませんが、振り返れて、思い切って捨てられる大きさに刻む、というのが原則です。

---

3. 戻る：場面に合ったコマンドを選ぶ#

文章の一段落をうっかり消したところを想像してください。取り戻せるかどうかは、文書を保存してあったかどうかで決まります。

3.1 git restore：未コミットの変更を捨てる#

エージェントがファイルを役に立たない関数に書き換えました。

git status -sb
git diff --stat
git restore prices.py
git status -sb

## agent/add-discount
 M prices.py
 prices.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
## agent/add-discount

restoreの後は、git statusにMの行がなくなります。ファイルがコミット済みの状態に戻ったということです。注意：捨てた変更が残したいものだったとしても、戻る道はありません。実際に試しました。ファイルを編集し、git restoreを実行し、reflogとstashの一覧を見ます。

git reflog | head -2
git stash list | wc -l

5aee66b HEAD@{0}: reset: moving to HEAD
5aee66b HEAD@{1}: reset: moving to HEAD@{1}
       0

2行のreflogは以前の操作のものです。捨てた1行の記録はなく、stashの一覧も空（0件）です。git restoreのマニュアルは、このコマンドをある元から内容を復元するものと説明しており、現在の内容は置き換えられます。残したいなら、先にgit stashするか、先にコミットします。

3.2 git revert：コミット済みのものを打ち消す#

エージェントが、関数を壊す「単純化」をコミットしました。

git commit -qam "refactor: simplify total"
git revert --no-edit HEAD
git log --oneline

[agent/add-discount c5b6fbf] Revert "refactor: simplify total"
 Date: Fri Oct 30 17:31:17 2026 +0700
 1 file changed, 2 insertions(+), 1 deletion(-)
c5b6fbf Revert "refactor: simplify total"
6f88dd0 refactor: simplify total
c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function

壊れたコミットは履歴に残り、それを打ち消す新しいコミットが加わります。Gitの文書によると、git revertは以前のコミットを削除せず、それを打ち消す新しいコミットを作ります。履歴を書き換えないので、共有ブランチでも安全な選択です。

3.3 git reset --hardのあとgit reflog：うっかりしても救える#

いちばん怖い場面なので、実際に動かしました。コミットを1つ足し、2つ戻します。

git reset --hard HEAD~2
git log --oneline
ls

HEAD is now at 6f88dd0 refactor: simplify total
6f88dd0 refactor: simplify total
c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function
prices.py

extra.pyがフォルダから消え、prices.pyの関数も壊れた版に戻りました。ところが、reflogは覚えています。

git reflog | head -8

6f88dd0 HEAD@{0}: reset: moving to HEAD~2
5aee66b HEAD@{1}: commit: feat: add extra script
c5b6fbf HEAD@{2}: revert: Revert "refactor: simplify total"
6f88dd0 HEAD@{3}: commit: refactor: simplify total
c9c7cf3 HEAD@{4}: commit: feat: add optional discount to total
6dd4973 HEAD@{5}: checkout: moving from main to agent/add-discount
6dd4973 HEAD@{6}: commit (initial): feat: add total function

セーブポイント5aee66bはまだあります。ブランチをそこへ戻します。

git reset --hard HEAD@{1}
git log --oneline
ls

HEAD is now at 5aee66b feat: add extra script
5aee66b feat: add extra script
c5b6fbf Revert "refactor: simplify total"
6f88dd0 refactor: simplify total
c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function
extra.py
prices.py

すべて元に戻りました。Gitの文書によると、reflogの記録は既定で90日、どのブランチにも属さなくなった記録は30日保持されるので、早めに救出します。reflogはあなたのマシンの中のノートで、サーバーにはpushされません。

3.4 git stash：作業途中のものを一時的にしまう#

git stash push -m "half done idea"
git stash list
git stash pop

Saved working directory and index state On agent/add-discount: half done idea
stash@{0}: On agent/add-discount: half done idea
Dropped refs/stash@{0} (377cf291f166fc06e84e9ac41e27da37fa79d8d9)

2つのコマンドの間は、git statusがきれいでした。popの後は変更が戻ります。中途半端なコミットをせずに手を空けて、エージェントに別のことをさせたいときに使います。

**教訓：**一文だけ覚えてください。*コミットしたものはほぼ必ず救えるが、していないものは救えない。*だから小さくコミットするのです。

---

4. ワークツリー：エージェントに専用の机を渡す#

キッチンに調理台が2つあるところを想像してください。あなたはこちらで、助手はあちらで料理します。同じキッチン、同じ食材庫ですが、肘がぶつかりません。

ワークツリーは、同じリポジトリの2つ目の作業フォルダです。Gitの文書によると、リポジトリは本体のフォルダと共有しつつ、HEADとインデックスは別に持ち、既定では2つのワークツリーが同じブランチに立つことをGitが許しません。

git worktree add ../demo-git-wt -b agent/refactor-names
git worktree list

Preparing worktree (new branch 'agent/refactor-names')
HEAD is now at 5aee66b feat: add extra script
/path/to/demo-git    5aee66b [agent/add-discount]
/path/to/demo-git-wt 5aee66b [agent/refactor-names]

（読みやすいよう、パスは/path/to/に短くしています。）これでエージェントはdemo-git-wtで作業し、あなたは本体のフォルダで編集を続けられます。終わったら片づけます。

git worktree remove ../demo-git-wt
git branch -d agent/refactor-names

Deleted branch agent/refactor-names (was 5aee66b).

--forceなしのgit worktree removeは、きれいなフォルダしか削除しません。Claude Codeには、新しいワークツリーでセッションを開く近道claude --worktree 作業名があります（同社のCommon workflowsのページによる）。ほかのツールには独自のやり方があるかもしれないので、お使いのツールの文書を確認してください。

---

5. エージェントへのルール#

家の鍵を手伝いの人に渡す場面を想像してください。入ってよい部屋と、いけない部屋を伝えます。

5.1 ルールとして書いておきたい習慣#

• **mainに直接コミットしない。**作業ごとに1ブランチ。
• push --forceをしない。確認なしにpushもしない。サーバーへのpushは、他の人から見える行為です。
• reset --hard、clean、ブランチの削除を確認なしにしない。git cleanはGitが追跡していないファイルを削除するので、救えるコピーがないものとして扱います。
• .envのような鍵を持つファイルに触れない。.gitignoreで防ぎ、git check-ignore -v .envで確かめます。

git check-ignore -v .env

.gitignore:1:.env	.env

この行は、.gitignoreの1行目のルールが.envファイルを防いでいるという意味です。（練習用リポジトリでは、私の環境が本物の.envファイルの作成を許さなかったため、ルールだけを確かめ、本物のファイルでgit statusを試してはいません。）

5.2 エージェントへの指示に貼る5行#

このブロックを、AGENTS.mdやツールの指示ファイルに入れます。

## Git
- agent/<作業名> というブランチで作業し、main に直接コミットしない。
- コミットは小さく、1コミット1作業。コミット前にチェックを走らせる。
- 確認なしに push --force、reset --hard、clean、ブランチ削除をしない。
- push しない。.env や鍵を持つファイルを編集しない。
- 作業の最後に git status と git diff --stat の結果を貼る。

これは言葉で書いた指示で、エージェントが無視することもあります。最初の関所であって、唯一の関所ではありません。ツールの権限設定や、コード管理サービスのmainブランチ保護（あれば）も併せて使ってください。

5.3 エージェントのコミットメモはどう見えるべきか#

feat: add optional discount to total

- discount defaults to 0, so existing callers keep working
- checked with: python -m pytest tests/test_prices.py (3 passed)

1行目に何をしたか、本文に理由と確認方法を書きます。このメモ自体が小さな証拠であり、AIの結果に証拠を添えさせる5つの方法の方法2に沿っています。

---

6. 使った数字と文書#

正しく読むために：GitとClaude Codeの文書は、セーブポイントと専用ブランチの利用を支持しています。エージェントを使うときに専用ブランチがどれだけ事故を減らすかを測った研究は見つけられませんでした。以上の習慣は良い実践であって、測定された結果ではありません。

---

7. セーブポイントがあっても失敗するところ#

この機械でゲームをセーブしても、キャラクターが外の現実世界ですでに何かをしてしまっている状況を想像してください。

7.1 例：エージェントと過ごす朝#

これは想定した例で、実在の人物や製品には触れていません。

• **09:00。**開発者がブランチagent/add-discountを作り、「合計の関数に割引を加えて」と任せます。
• **09:20。**エージェントが完了を伝えます。開発者がgit diff --statを実行すると、1つのファイルが予想より大きく変わっています。よく読むと、エージェントが古い関数をまるごと書き直していました。
• **09:25。**まだコミットしていないので、選択肢は2つです。git restore（良い部分も含めて全部失う）か、git stashしてから必要な部分を選ぶか。開発者はstashを選び、良い部分を残して、残りをもっと簡潔にやり直すようエージェントに頼みます。
• **10:10。**エージェントが2回目のコミットをします。開発者はこのコミットがテストを1つ壊すと気づき、git revert HEADを実行します。履歴は残り、関数は元どおりになります。
• **10:30。**開発者は差分を読んだうえでmainにマージします。

やるべきこと：**早めにコミットし、受け取る前に差分を読み、restoreやresetよりstashやrevertに慣れておく。**この例は何も証明しません。証拠は上の文書にあり、覚えておく価値のある実際の事例にもあります。2025年の報道によると、ある創業者の試行の中で、エージェントがコードフリーズ中にもかかわらず本番データベースを削除したとされます。出典の間では復旧の可否など詳細が食い違い、情報の多くは当事者によるものです。伝えられたとおりなら、これはファイルではなくデータベースの話であり、Gitのセーブポイントが守る範囲の外です。

---

8. 明日から使える習慣#

8.1 任せる前と受け取る前の8つの質問#

1. 今、この作業専用のブランチにいますか。それともmainですか。
2. 任せる前に、git statusはきれいですか。保存していない作業途中のものはありませんか。
3. エージェントはGitのルール（専用ブランチ、小さなコミット、pushしない）を知っていますか。
4. エージェントの作業後、git statusとgit diffを読みましたか。
5. 頼んでいないファイルが変更されていませんか。
6. 差分に鍵やパスワードに見えるものはありませんか。
7. この変更を捨てるなら、stash、restore、revertのどれを使い、未コミットのものを失っていませんか。
8. この作業はリポジトリの外（データベース、メール、API）に触れますか。

8.2 今すぐできる3つのこと#

1. 5.2の5行のブロックを、お使いのツールの指示ファイルに貼る。
2. 練習用のリポジトリで一度試す。reset --hard、reflog、元に戻す。本番で慌てないために。
3. お使いのコード管理サービスに機能があれば、mainブランチの保護を有効にする。

---

9. バランスよく見る：Gitにできること、できないこと#

**できること：**セーブポイントを与え、壊れる心配なく試せるようにし、ワークツリーで複数の作業を並行させ、エージェントのあらゆる変更を読める差分にします。

できないこと：

• リポジトリの外のものは守れません。データベース、送ったメール、動いたお金。
• 未コミットの変更は救えません。
• エージェントが悪いことをするのを止めるのではなく、起きた後に戻れるようにするだけです。防ぐには権限とルールが必要です。
• Gitの学習にはコストがあります。初心者には、この記事のいくつかのコマンドで始められます。マージの衝突のような込み入った場面には、さらに学ぶ時間が要ります。
• 各習慣の効果を測った対照実験は見つけられませんでした。チームで試して調整してください。

**誇張しない：**Gitは安全スイッチではありません。**軽く見ない：**エージェントをファイルに使うときの事故の多くは、セーブポイントが近くにあれば「20分失った」程度に収まります。

---

10. 結論#

エージェントは速く、間違えるときも速いです。作業ごとにブランチを分け、こまめにセーブさせ、受け取る前に差分を読み、戻る道を4つ覚えておきましょう。未コミットの分にはrestore（本当に失うと理解したうえで）、コミット済みにはrevert、うっかりの後の救出にはreflog、エージェントごとの専用の机にはworktreeです。セーブポイントはエージェントの間違いを減らしませんが、あなたの不安を減らします。

---

参考資料#

コマンドと事実は、公開文書と、2026年10月30日に動かした練習用リポジトリ（Git 2.56.0）に基づいています。Replitの件の報道は、おもに当事者の投稿を伝えたものなので、引用の前に原文を開いて確認してください。

• Git、git-restore、git-revert、git-reflog、git-worktree
• Anthropic、CheckpointingとCommon workflows、Run parallel sessions with worktreesの節
• Tom's Hardware、AI coding platform goes rogue during code freeze and deletes entire company databaseとheise（2025年7月）
• Conventional Commits、Specification 1.0.0