--- title: "AIエージェントを使う人のGit入門：ブランチ、小さなコミット、元に戻し方" url: https://www.stacklogs.io.vn/ja/gijutsu/agent-wo-tsukau-hito-no-git-nyumon/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-30 updated: 2026-10-30 section: "エンジニアリング" tags: ["git", "AIエージェント", "ブランチ", "コミット", "元に戻す", "worktree", "チェックリスト"] summary: "AIエージェントに作業を任せるときは、作業ごとにGitのブランチを分け、小さなコミットをセーブポイントとして求め、受け取る前にgit statusとgit diffを読みます。戻る道は4つです。未コミットの変更にはgit restore、コミット済みにはgit revert、resetの後の救出にはgit reflog、エージェント専用のフォルダで作業させるにはgit worktreeを使います。restoreで捨てた未コミットの変更は、Gitでは取り戻せません。" license: "Cite with the author name and the canonical URL above." --- # 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回のセーブ。ゲームの「セーブ」を押すようなもので、いつでもそこへ戻れます。 | | **ブランチ** | 本体から枝分かれした別の道。本体を壊さずに試せます。 | | **差分（diff）** | 直近のセーブから、どの行が追加され、どの行が削除されたかの正確な一覧。 | | **リバート（revert）** | 古いセーブの逆をする新しいセーブを作ること。履歴はそのまま残ります。 | | **リセット（reset）** | ブランチを古いセーブまで戻すこと。`--hard`では未コミットの変更が消えます。 | | **リフログ（reflog）**（移動の記録） | HEADがどこにいたかを順に書いたノート。消えたように見えるセーブを探すのに使います。 | | **スタッシュ（stash）** | 作業途中のものを一時的な引き出しにしまい、手を空けること。あとで取り出して続けられます。 | | **ワークツリー（worktree）** | 同じリポジトリの2つ目のフォルダ。別のブランチに立つ、専用の机のようなものです。 | --- ## 1. まずイメージ：セーブポイントのあるゲーム 長いゲームを遊んでいるところを想像してください。一度もセーブしなければ、1回やられると1時間分が消えます。数分おきにセーブしていれば、やられても失うのは数分です。 エージェントに任せるのも同じです。エージェントはとても速く、少しせっかちなプレイヤーです。最初のファイルを読み終える前に、10個のファイルを直してしまうこともあります。優秀ですが、いつも正しいわけではありません。エージェント系ツールの文書自身もそう述べています（第6節）。**セーブポイントはエージェントの間違いを減らしません。間違いを安くします。** その役を担うのがGitで、大事なルールが1つあります。**Gitはコミットしたものしか覚えていません。**フォルダの中にあるだけでコミットしていない変更は、セーブせずにステージの途中を遊んでいるようなものです。 **教訓：**作業を任せる前に、きれいなセーブポイントを作っておきます。エージェントが作業している間は、こまめにセーブするよう求めます。 --- ## 2. 5ステップの手順：作業ごとにブランチを分ける 食卓にいくつものお皿があるところを想像してください。新しい料理をいきなりメインの皿で試さず、別の皿に盛ります。失敗したらその皿ごと捨てればよく、メインの皿は無傷です。 以下は、注文の合計を計算する`prices.py`という1つのファイルだけを入れた練習用リポジトリで、実際に動かしたものです。`main`ブランチに最初のセーブポイントが1つあります。 ### ステップ1：この作業専用のブランチを作る ```bash git switch -c agent/add-discount ``` ```text Switched to a new branch 'agent/add-discount' ``` `agent/作業名`という名前の付け方にしておくと、ブランチ一覧を見ただけでエージェントのものだと分かります。Gitの決まりではなく、私の習慣です。 ### ステップ2：作業を任せ、エージェントに進めさせる エージェントに「`total`関数に、任意の割引パラメータを加えて」と頼みます。エージェントがファイルを編集します。 ### ステップ3：受け取る前に`git status`、次に`git diff`を読む ```bash git status -sb git diff ``` ```text ## 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つの方法](https://www.stacklogs.io.vn/ja/gijutsu/ai-no-kekka-ni-shoko-wo-motomeru-5tsu-no-hoho/)の「証拠を開く」ステップであり、[AIが書いたコードのレビュー](https://www.stacklogs.io.vn/ja/gijutsu/ai-ga-kaita-code-no-review/)の最初の部分でもあります。 ### ステップ4：小さくコミットする（セーブポイント） ```bash git add prices.py git commit -q -m "feat: add optional discount to total" git log --oneline ``` ```text c9c7cf3 feat: add optional discount to total 6dd4973 feat: add total function ``` `-q`はコマンドを静かにするだけの指定です。1コミット1作業で、一言で説明できる大きさにします。メモはConventional Commits（よく使われる書き方の約束で、必須ではありません）の`feat: 作業名`の形です。 ### ステップ5：納得したらマージする 差分を読み、チェックも走らせたら、ブランチを`main`に取り込むのはあなた自身です。 ```bash git switch main git merge --no-ff -q agent/add-discount -m "merge: add discount" git log --oneline --graph ``` ```text * 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分で問題が起きたとします。 ```python 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. 戻る：場面に合ったコマンドを選ぶ 文章の一段落をうっかり消したところを想像してください。取り戻せるかどうかは、文書を保存してあったかどうかで決まります。 | 場面 | コマンド | 起きること | リスク | |---|---|---|---| | エージェントが間違えて直した。まだコミットしていない | `git restore ファイル名` | ファイルが直近のコミットの状態に戻る | **未コミットの変更は完全に失われる** | | コミット済みで、それが間違っている | `git revert HEAD` | 打ち消す新しいコミットができ、履歴は残る | 安全 | | 作業途中で手を空けたい | `git stash push -m "メモ"` | 一時的にしまう。あとで`git stash pop` | 安全 | | ブランチを古い地点まで戻したい | `git reset --hard セーブポイント` | ブランチが戻り、未コミットの変更は消える | **危険**。コミットはreflogで救える | | resetでうっかりした | `git reflog`のあと`git reset --hard HEAD@{n}` | HEADがかつていた場所を探す | コミットは救えるが、未コミットの変更は救えない | ### 3.1 `git restore`：未コミットの変更を捨てる エージェントがファイルを役に立たない関数に書き換えました。 ```bash git status -sb git diff --stat git restore prices.py git status -sb ``` ```text ## 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の一覧を見ます。 ```bash git reflog | head -2 git stash list | wc -l ``` ```text 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`：コミット済みのものを打ち消す エージェントが、関数を壊す「単純化」をコミットしました。 ```bash git commit -qam "refactor: simplify total" git revert --no-edit HEAD git log --oneline ``` ```text [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つ戻します。 ```bash git reset --hard HEAD~2 git log --oneline ls ``` ```text 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は覚えています。 ```bash git reflog | head -8 ``` ```text 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`はまだあります。ブランチをそこへ戻します。 ```bash git reset --hard HEAD@{1} git log --oneline ls ``` ```text 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`：作業途中のものを一時的にしまう ```bash git stash push -m "half done idea" git stash list git stash pop ``` ```text 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が許しません。 ```bash git worktree add ../demo-git-wt -b agent/refactor-names git worktree list ``` ```text 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`で作業し、あなたは本体のフォルダで編集を続けられます。終わったら片づけます。 ```bash git worktree remove ../demo-git-wt git branch -d agent/refactor-names ``` ```text 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`で確かめます。 ```bash git check-ignore -v .env ``` ```text .gitignore:1:.env .env ``` この行は、`.gitignore`の1行目のルールが`.env`ファイルを防いでいるという意味です。（練習用リポジトリでは、私の環境が本物の`.env`ファイルの作成を許さなかったため、ルールだけを確かめ、本物のファイルで`git status`を試してはいません。） ### 5.2 エージェントへの指示に貼る5行 このブロックを、[AGENTS.mdやツールの指示ファイル](https://www.stacklogs.io.vn/ja/gijutsu/agents-md-no-kakikata/)に入れます。 ```text ## Git - agent/<作業名> というブランチで作業し、main に直接コミットしない。 - コミットは小さく、1コミット1作業。コミット前にチェックを走らせる。 - 確認なしに push --force、reset --hard、clean、ブランチ削除をしない。 - push しない。.env や鍵を持つファイルを編集しない。 - 作業の最後に git status と git diff --stat の結果を貼る。 ``` これは言葉で書いた指示で、エージェントが無視することもあります。最初の関所であって、唯一の関所ではありません。ツールの権限設定や、コード管理サービスのmainブランチ保護（あれば）も併せて使ってください。 ### 5.3 エージェントのコミットメモはどう見えるべきか ```text 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つの方法](https://www.stacklogs.io.vn/ja/gijutsu/ai-no-kekka-ni-shoko-wo-motomeru-5tsu-no-hoho/)の方法2に沿っています。 --- ## 6. 使った数字と文書 | 出典 | 内容 | 読み方 | 注意 | |---|---|---|---| | Git、`git-restore`のページ | ある元からパスを復元し、現在の内容は置き換えられる | 未コミットの変更を失う警告の根拠 | 取り戻せないとまでは書かれておらず、それは私が試した結果 | | Git、`git-revert`のページ | 以前のコミットを削除せず、打ち消す新しいコミットを作る | 3.2節の根拠 | revertにはきれいなフォルダが必要 | | Git、`git-reflog`のページ | 参照がかつていた場所を記録。既定で90日、ブランチに属さない記録は30日 | 3.3節の根拠 | あなたのマシンの中だけ | | Git、`git-worktree`のページ | リンクされたワークツリーはリポジトリを共有し、`HEAD`とインデックスは別。既定では1つのブランチに2か所が立てない | 第4節の根拠 | フォルダがきれいでなければ`remove`に`--force`が必要 | | Claude Code文書、Checkpointing | チェックポイントはファイルツールによる編集を追跡。Bashだけで変更されたファイルは追跡せず、サブエージェントの編集は通常復元せず、バージョン管理の代わりではない | それでもGitが必要な理由 | ツール提供元の文書で、バージョンにより変わりうる | | Claude Code文書、Common workflows | `claude --worktree 作業名`で専用のワークツリーでセッションを実行。コミットが1つ以上あるリポジトリが必要 | 第4節の近道の根拠 | このツールに限った話 | | 報道（Tom's Hardware、heise）、Replitの件、2025年7月 | エージェントが、コードフリーズ中に企業の本番データベースを削除したと報じられた | Gitのセーブポイントはデータベースを守らない | 詳細の多くは当事者の投稿が元で、復旧の可否は出典により異なる | | この記事の練習用リポジトリ | 第2節から第5節のコマンドはすべて実際に実行 | 出力は本物 | ごく小さな1つのリポジトリ、1台のマシン、Git 2.56.0。調査ではない | **正しく読むために：**GitとClaude Codeの文書は、セーブポイントと専用ブランチの利用を支持しています。エージェントを使うときに専用ブランチがどれだけ事故を減らすかを測った研究は**見つけられませんでした**。以上の習慣は良い実践であって、測定された結果ではありません。 --- ## 7. セーブポイントがあっても失敗するところ この機械でゲームをセーブしても、キャラクターが外の現実世界ですでに何かをしてしまっている状況を想像してください。 | 場面 | なぜ失敗するか | 防ぐ、見抜く方法 | |---|---|---| | 未コミットの変更に`restore`や`reset --hard`をかけた | Gitにコピーがない | 先にコミットかstash。小さく、こまめにコミット | | エージェントが`git clean`を実行 | 追跡されていないファイルはGitにコピーがない | ルールで禁止し、大事なファイルはGitに入れる | | エージェントがpush、とくに`--force` | 変更がサーバーに載り、他の人が取り込む | pushを許さない、mainを保護、`--force`は決して使わない | | 鍵がコミットに漏れた | 鍵は履歴に残り、`revert`では消えない | `.gitignore`を使い、漏れた鍵は替えるものとみなす | | リポジトリの外のこと：データベース削除、メール送信、有料API呼び出し | Gitはファイルしか保存しない | テスト環境を分け、権限を絞る。コマンド実行の権限については[存在しないパッケージ](https://www.stacklogs.io.vn/ja/gijutsu/slopsquatting-sonzai-shinai-package/)の記事も参照 | | ツールが追跡していないファイルをBashコマンドが変更 | ツールのチェックポイントの対象外 | 元に戻すボタンだけでなく、Gitに頼る | | 混ざったコミットが多すぎる | どの地点が良いか分からない | 1コミット1作業、メモを明確に | ### 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](https://git-scm.com/docs/git-restore)、[git-revert](https://git-scm.com/docs/git-revert)、[git-reflog](https://git-scm.com/docs/git-reflog)、[git-worktree](https://git-scm.com/docs/git-worktree) - Anthropic、[Checkpointing](https://code.claude.com/docs/en/checkpointing)と[Common workflows、Run parallel sessions with worktreesの節](https://code.claude.com/docs/en/common-workflows) - Tom's Hardware、[AI coding platform goes rogue during code freeze and deletes entire company database](https://tomshardware.com/tech-industry/artificial-intelligence/ai-coding-platform-goes-rogue-during-code-freeze-and-deletes-entire-company-database-replit-ceo-apologizes-after-ai-engine-says-it-made-a-catastrophic-error-in-judgment-and-destroyed-all-production-data)と[heise](https://heise.de/-10499597)（2025年7月） - Conventional Commits、[Specification 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)