AI時代のGit入門 ─ Claude Code に頼む前に最初のコミットを入れる理由

Claude Code に「東京の天気を取得するアプリを作って」と頼みました。ターミナルに緑色のテキストが流れ、app.py が一瞬で書き換わります。コードが動き、画面に気温が表示されます。気持ちのいい体験ですよね。

そして10分後、「やっぱり華氏も表示できるようにして」と追加で頼みます。Claude Code はまた app.py を書き換えます。今度は何かが壊れます。さっき動いていた表示が消えています。「さっきの状態に戻して」とあなたは言います。Claude Code は答えます。「もちろん戻せます」。そして、また app.py を書き換えます。今度は別の何かが壊れています。

さっきの「動いていた状態」は、もうこの世のどこにも存在しない。

このとき、AI が悪いわけではありません。あなたが悪いわけでもありません。Git を導入していないだけです。

TL;DR
「最終_最終_v2.xlsx」は、もう持続しない
3つの事故ケース — AI 時代の現実
reflog 安全宣言 — Git はほぼ壊せない
セーブ＝スナップショット。差分ではない
この連載で使う言葉
AI 指示 × Git 操作対応表（毎回掲載）
まとめ

TL;DR

AI に作業を任せると、ファイルが書き換わる速度が人間より桁違いに速くなる
「戻せる仕組み」を AI に渡す前に用意する必要がある。これが Git の役割
Git の commit（この連載では「セーブ」と呼ぶ）はフォルダ全体のスナップショット（その時点のコピー）を保存する仕組み
reflog という履歴台帳があるので、一度でもセーブを入れていれば Git はほぼ壊せない
コマンドを暗記する必要はない。AI に何と頼むか × AI が裏で何をしているか、その対応表だけで足りる

「最終_最終_v2.xlsx」は、もう持続しない

この連載では、Claude Code と一緒に東京の天気予報アプリを作っていきます。主役は Git と GitHub です。Claude Code はあなたの相棒として横にいてくれますが、いま読んでいるこのページに限っては、Claude Code よりずっと地味で、ずっと大事な仕組みの話をします。

デスクトップに 提案書_最終.docx 提案書_最終2.docx 提案書_最終_提出用.docx が並んでいる景色を見たことがあるはずです。手で「セーブの履歴」を管理するとき、人類が辿り着いた一番素直な解がこれです。

問題は、AI に作業を任せ始めた瞬間にこの方式が破綻することです。理由はシンプルで、ファイルが書き換わる頻度が10倍以上に上がるからです。1日に20回コードを直してくれる相棒に対して、人間の手で「最終_最終_v3」を作り続けるのは現実的でしょうか？

そして、書き換える速度が上がると、もう一つ別の問題が顔を出します。戻れないと致命傷になる、という問題です。

flowchart TD
    A["手動でファイル名管理<br/>提案書_最終_v3"] --> B["AI で更新頻度が10倍に"]
    B --> C["命名が追いつかない<br/>v3 / v3-2 / v3-fix / v3-final…"]
    C --> D["どの状態が動いていたか<br/>もう分からない"]
    D --> E["戻れない<br/>= 致命傷"]

3つの事故ケース — AI 時代の現実

実例を3つだけ並べます。詳しい解説はしません。「ああ、こういうことが本当に起きているんだ」とだけ感じてもらえれば十分です。

ケース1（Replit、2025年7月）。AI コーディング環境の Replit で、AI エージェントが本番データベースを削除しました。さらにエージェントは当初ユーザーに「もう巻き戻しはできません」と説明しましたが、実際には手動で復旧可能でした。AI の説明そのものが事実と食い違っていたわけです。Fortune が報じています。根本原因は技術的に複雑な話ではなく、「セーブが1つも残っていなかった」というそれだけの話でした。

ケース2（Claude Code、Issue 10077）。Claude Code の GitHub Issue に「rm -rf ~/ でホームディレクトリが消えた」というユーザー報告が立っています。AI に作業を任せる、ということは「文字通り実行される」ということです。

ケース3（Cursor、2025年）。Cursor のフォーラムに「Checkpoint（Cursor 独自の一時履歴機能）からロールバックしたら2,000行消えた」という投稿があります。Cursor の Checkpoint は Git の代わりにはなりません。この話は #08 で本格的に扱います。

3件に共通するのは、AI が悪意を持って何かをしたわけではない、ということです。AI は依頼を文字通り実行する道具で、その実行速度が人間の作業を大きく上回るだけです。だから、「戻せる仕組み」を AI に渡す前に用意しておく必要があります。

reflog 安全宣言 — Git はほぼ壊せない

一度でも「セーブ」を入れてあれば、Git はその状態にほぼ確実に戻せます。

Git には reflog（リフログ、HEAD の移動履歴を保存する内部台帳）という仕組みがあり、あなたが「いまどのセーブにいるか」の移動履歴を標準で最大90日間（到達できなくなったコミットは30日間）自動で記録しています。reset --hard で全部消し飛ばしたように見える状態でも、reflog に履歴が残っているかぎり、そこに戻れます。

実演は #07「Commit Before Prompt」 で行います。今日のところは「Git はほぼ壊せない」という事実だけを頭の隅に置いてください。

Git の入門記事の多くが「reset --hard 禁止」「force push 禁止」のような恐怖喚起から入ります。これは初学者から学習意欲を奪うやり方で、私はやりません。恐怖を取り除いてから「セーブ」とは何なのかに進む、これがこの連載の順番です。

セーブ＝スナップショット。差分ではない

この連載で一番大事な比喩を1つだけ覚えてください。

Git の「セーブ」（公式名 commit）は、RPG のセーブポイントと同じ仕組みです。

「セーブする」と押した瞬間、あなたのプロジェクトフォルダ全体のスナップショットが記録されます。Word の「別名保存」を、フォルダ単位で自動でやってくれている、と思ってもらえば十分です。

「Git のコミットは差分（前回からの変更）を保存している」という説明を読んだことがあるかもしれません。これは違います。Git は毎回スナップショット全体を保存しています。差分は必要なときに動的に計算しているだけです。GitHub のエンジニアブログにも「Commits are Snapshots, Not Diffs」（コミットはスナップショットであり、差分ではない）というタイトルの記事があるくらいで、ここを間違えて理解するとブランチもマージもすべて意味不明になります。

この連載は「セーブ＝その時点のフォルダ全体のスナップショット」で全編を貫きます。差分の話は出てきません。

この連載で使う言葉

Git の公式コマンド名は、率直に言って初学者に対して不親切です。commit push branch merge ──全部、英単語の元の意味と Git での意味がズレています。AI に作業を頼む人に必要なのは、コマンド名ではなく何が起きているかを言い表す呼び名です。

Git 公式	この連載での呼び名	喩え
`commit`	セーブ	RPG のセーブポイント
`push`	アップロード	クラウドに送る
`pull`	ダウンロード	最新を手元に持ってくる
`branch`	作業場所	付箋で切り替える平行世界
`merge`	合流	川の合流
`repository`	プロジェクト保管庫	フォルダ全体
`main`	本流	川の本流

初出時は両方並記、以後は文脈で片方だけ。コマンドそのものは公式名で打ちます。呼び名は人間が学ぶためのもの、コマンドは AI と機械に伝えるためのもの、と切り分けてください。

AI 指示 × Git 操作対応表（毎回掲載）

各記事の最後にこの形の表を置きます。Git 公式コマンドを暗記する必要はありません。AI に何と頼めばよいか、それで AI が何をしているか、その2つだけ覚えてください。

あなたが AI に頼むこと	AI が裏で叩いている Git コマンド	何が起きているか
「いまの状態を一度セーブして」	`git add -A && git commit -m "..."`	スナップショット保存
「さっきの状態に戻して」	`git reset --hard HEAD~1`	1つ前のセーブに移動
「どこを変えたか教えて」	`git status && git diff`	直近の変更点を表示

今日の核はこの3行だけです。

まとめ

連載の全体像はこの形になります。

flowchart TD
    S1["第1回 なぜセーブが要るのか<br/>（いまここ）"]
    S2["第2〜4回 最初のセーブと AI への頼み方"]
    S3["第5〜6回 作業場所を分ける（branch / merge）"]
    S4["第7〜9回 Commit Before Prompt と AI 指示書"]
    S5["第10〜13回 GitHub に公開する／鍵を漏らさない"]
    S6["第14〜16回 PR / Actions"]
    S7["第17〜18回 向かない場面とチートシート"]
    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7

次回 #02 「最初のセーブ」を入れる — init / add / commit を AI に頼む では、東京の天気予報アプリのプロジェクトを実際に立ち上げて、人生最初のセーブを Claude Code に頼んで入れてもらいます。git init git add git commit という3つのコマンドが、何を、どの順番で動かしているのか、その正体だけ取り出します。

私も Git/GitHub を知る前は「ファイル名で頑張る」時代を長くやってきました。記事_最終.md から 記事_最終_v2.md に上書きセーブする瞬間、毎回ひしひしと「あ、また戻れない選択をした」と感じていました。Git に乗り換えてからは、その小さな後悔がなくなりました。Claude Code に「いまの状態を一度セーブして」と頼むだけで、すべてのスナップショットが残るからです。

今日からは、ファイル名で「最終_最終_v2」を管理する時代はもう終わりにしましょう。