2026年最新

Claude CodeのGitやらかしを元に戻す方法｜誤コミット・force push・resetの復旧術【2026年】

「AIが勝手に変なコミットをした」「force pushでリモートが壊れた」「reset –hardで変更が消えた」——Claude CodeにGit操作を任せると、たまにこんな“やらかし”が起きます。本記事では、AIのGitミスを症状別に安全に元へ戻す手順を、コマンド付きでまとめます。

Claude CodeのGitやらかしは、ほとんどのケースで元に戻せます。AIが意図しないコミットやリセット、force pushをしてしまっても、Gitは操作の履歴を記録しているため、正しい手順を踏めば復旧できることが多いのです。この記事では「まず落ち着くべき理由」から、症状別の具体的な戻し方までを順番に解説します。

作業を止めて、まずこれをしない

「やらかした」と気づいたら、慌てて追加のreset・commit・pushをしないでください。操作を重ねるほど復旧が難しくなります。まずは手を止めて、以下を順に確認しましょう。

まず落ち着く：AIのGit操作はほぼ元に戻せる

Gitには git reflog という「HEADの移動履歴」がすべて記録されています。コミット・リセット・ブランチ切り替えなど、ほぼあらゆる操作の前後の状態が残っているため、「消えたように見えるコミット」もたいてい復旧できます。

まずは現状を把握します。Claude Codeのセッション内なら、こう頼むだけでもOKです。

今のgitの状態と、直近の操作履歴（reflog）を見せて

裏側では次のコマンドが動きます。自分で打って確認しても構いません。

git status          # 今の変更状況
git log --oneline -10   # 最近のコミット
git reflog -20      # HEADがどう動いたかの履歴

復旧の基本：reset / revert / restore / reflog の違い

復旧コマンドは4つ覚えれば十分です。どれを使うかは「pushしたかどうか」で大きく変わります。

コマンド	役割	使う場面
`git reset`	コミットを巻き戻す（履歴を書き換える）	push前の取り消し
`git revert`	打ち消すコミットを新たに作る（履歴は残す）	push後の安全な取り消し
`git restore`	作業中ファイルを最後のコミットに戻す	コミット前の変更を捨てたい
`git reflog`	HEADの移動履歴を見る	消えたコミットを探す

いちばん大事な原則

push前なら reset、push後なら revert。チームで共有しているブランチを reset＋force pushで書き換えると、他の人の作業を壊します。共有済みは必ず revert を選びましょう。

【症状別】AIのGitやらかし対処法

① 間違ったコミットをした（まだpushしていない）

直前のコミットを取り消します。変更内容は残したいのが普通なので、ファイルはそのままで「コミットだけ」を取り消します。

# Claudeへの頼み方
直前のコミットだけ取り消して。変更内容は残して

# 裏で動くコマンド（soft = 変更を残す）
git reset --soft HEAD~1

コミットメッセージだけ直したいなら、取り消さず修正もできます（git commit --amend）。

② 作業中の変更を消された／おかしくされた（コミット前）

AIが編集してしまった作業中のファイルを、最後のコミットの状態に戻します。ただしこれは現在の変更を捨てる操作なので、必要な変更が混じっていないか確認してから行います。

# 特定ファイルだけ元に戻す
git restore path/to/file.js

# まるごと最後のコミット状態に戻す（変更は破棄）
git restore .

「捨てるか残すか迷う」ときは、いったん退避（stash）しておくと安全です。

git stash      # 変更を一時退避
git stash pop  # あとで戻す

③ 違うブランチにコミットしてしまった

AIが main など別ブランチに直接コミットしてしまったケース。正しいブランチへコミットを移します。

# Claudeへの頼み方
直前のコミットを feature/xxx ブランチに移して、mainからは取り消して

# 裏で動く流れ（コミットのハッシュを控えてから）
git switch feature/xxx     # 正しいブランチへ
git cherry-pick <ハッシュ>  # コミットを移植
git switch main
git reset --hard HEAD~1     # mainから誤コミットを除去（push前のみ）

④ pushしてしまったコミットを取り消したい

すでにリモートへpush済みなら、履歴を書き換える reset ではなく、打ち消しコミットを作る revert が安全です。

# Claudeへの頼み方
あのコミットを revert で打ち消して、pushして

# 裏で動くコマンド
git revert <ハッシュ>
git push

これなら他のメンバーのリポジトリを壊さずに、変更を安全に取り消せます。

⑤ git reset –hard で変更やコミットが消えた

もっとも焦るパターンですが、reflogでほぼ救出できます。消える前のHEAD位置を探して、そこへ戻します。

git reflog              # 消える前の状態を探す（例: a1b2c3d）
git reset --hard a1b2c3d   # その地点へ復元

Claudeにも「reflogを見て、reset –hardする前のコミットに戻して」と頼めます。

⑥ force pushでリモートを上書きしてしまった

AIが --force でリモートを上書きし、他の人のコミットが消えた場合。まだ復旧の余地はあります。

上書き前のコミットを持っている人（自分や同僚のローカル）が git reflog で正しい状態を探し、そこから復元してpushし直す
GitHubなどでは、消えたコミットのハッシュが分かれば一定期間アクセスできることがある

今後はこれで防ぐ

force pushが必要なときは、必ず git push --force-with-lease を使います。これは「自分が知らないリモートの更新があれば失敗する」安全版で、他人の作業を上書きする事故を防げます。

AIにGitを任せる時の予防策

復旧手順を知るのと同じくらい、やらかしを防ぐ設計が大事です。次の4つで事故率が大きく下がります。

こまめにコミットする：戻れる地点が増え、被害が最小化される
push・force push・mainへの操作は内容を確認してから承認：取り消しにくい操作ほど目視を
force pushは --force-with-lease を徹底
作業ブランチを切ってPR経由にする：mainを直接触らせない

そもそものGit操作の任せ方はClaude CodeでGit操作を自動化する方法で解説しています。承認の自動化（Auto Mode）を使う場合は、リスクの理解もあわせてAuto Modeの解説を確認しておくと安心です。

よくある質問（FAQ）

Q. reset と revert はどう使い分ける？

push前なら reset（履歴ごと巻き戻す）、push後なら revert（打ち消しコミットを足す）です。共有ブランチでは必ず revert を選びます。

Q. git reset –hard で消したファイルはもう戻らない？

コミット済みだった変更なら git reflog でほぼ復旧できます。一度もコミットしていない作業中の変更は戻せないことがあるため、こまめなコミットが予防になります。

Q. Claudeに「戻して」と頼むだけで直る？

多くのケースは可能です。ただしreflogやforce push絡みの復旧は状況判断が要るので、本記事の症状別手順で「何が起きたか」を把握してから指示すると確実です。

Q. やらかしを根本的に減らすには？

こまめなコミット、mainを直接触らせない（作業ブランチ＋PR）、force pushは --force-with-lease、の3点が効果的です。

まとめ

Gitやらかし復旧のまとめ

・気づいたら手を止める。追加のreset/commit/pushをしない

・push前は reset、push後は revert（共有ブランチは必ずrevert）

・消えたコミットは git reflog で探して reset --hard <ハッシュ> で復元

・force pushは --force-with-lease で事故防止

・予防はこまめなコミット＋作業ブランチ＋PR経由

Gitは「やり直しに強い」ツールです。AIに任せて多少のやらかしがあっても、reflogという履歴がある限り、たいていは元に戻せます。復旧の型をひとつ覚えておけば、安心してClaude CodeにGitを任せられます。