Claude Codeで変更を元に戻す方法：/rewindとgit

Ailootの使い方に関する実用的な情報はドキュメントでご覧いただけます。

Claude Codeの「元に戻す」とは何か、なぜ3段階では足りないのか？#

Claude Codeを使い始めて最初の週に、私は/rewindを有効にしました。2回のプロンプトでプロジェクトの認証ロジックを壊されたからです。巻き戻して、ほっと息をつき、作業を続けました。1か月後、別のことが起きました。スキーマのマイグレーションを書き、Claudeに手伝ってもらってコミットし、ブランチを切り替えたところ、必要な手順を忘れていたことに気づいたのです。セッションはすでに別のものになっていたため、/rewindでは解決できませんでした。前のコミットにgit checkoutして解決しました。その1か月後、私は誤ってエージェントに「最後のpushまで全部戻して」と指示し、エージェントはgit reset --hardを実行して3時間分の作業を壊しました。git reflogに救われました。破棄されたコミットのハッシュがまだ残っていたのです。

この3つの話は、動作の異なる3段階の保護を示しています。それぞれ異なるミスを捕まえるため、すべて必要です。このガイドでは各段階のコマンド、制限、使用例を説明し、最初の失敗でClaudeにプロジェクトを壊されないよう、あらかじめプロジェクトを設定する方法も紹介します。

元に戻す3段階：何を、いつ使うか：

次に各段階を見ていきます。具体的な操作、落とし穴、そして壊れて元に戻す必要が生じないようにする設定方法を説明します。

/rewindを呼び出すには？コマンドとEscの2回押し#

応答のたびに、Claudeはそのセッション中に編集したすべてのファイルのスナップショットを自動的に取得します。スナップショットは~/.claude/file-history/{sessionId}/に保存され、最大30日間保持されます。スナップショットは差分形式で、ファイル全体ではなく状態間の違いだけが保存されます。既定では、1セッションにつき最大100個のスナップショットが保存されます。そのため、ほとんどの実際のプロジェクトでは、いつでもその日の作業を通じてClaudeが加えた変更の完全な履歴を確認できます。

巻き戻しメニューを開くには、入力欄が空のときにEscを2回押します。

[user-input is empty]
> _

[press Esc, Esc]

Rewind to which message?
  1. Create a migration for the User table          (3 files changed)
  2. Add the lastLoginAt field                      (1 file changed)
  3. Rewrite the authorization logic                (5 files changed)
  ...

入力欄に文字がある場合、最初にEscを2回押すとその文字が消え、Up履歴に保存されます。すでに入力を始めてから巻き戻す必要に気づいた場合に便利です。Anthropic公式ドキュメントから引用します。

/rewindコマンドでも同じようにメニューが開きます。同じメニューを開く別名として/checkpointもあります。どちらが使いやすいかは慣れの問題です。私はEsc Escを使います。より速く、キーボードから手を離さずに済むからです。

巻き戻しメニューの6つのモード：どれをいつ選ぶ？#

一覧から時点を選ぶと、操作メニューが表示されます。6項目あり、それぞれ動作が異なります。

モードの一覧：

Summarize up to here機能は、2026年5月11日～15日（第20週）にリリースされたClaude Code v2.1.139-v2.1.142で登場しました。

RestoreとSummarizeの違いは根本的です。Restoreは以前の状態に戻り、選択した時点以降に起きたことをすべて取り消します。Summarizeは何も取り消さず、圧縮するだけです。元のメッセージは参照用にセッションのトランスクリプトに残りますが、アクティブなコンテキストには要約だけが残ります。「何も起きなかったことにしたい」ならrestoreを使います。「残しておきたいが、コンテキストを使い続けたくない」ならsummarizeを使います。

Restore conversationまたはSummarize from hereの後は、選択したプロンプトの元のテキストが入力欄に戻ります。編集して再送信できます。Summarize up to hereの後は入力欄が空になり、会話の最後に残ります。

/rewindで元に戻せない変更は？#

多くの人が直面する主な制限がこれです。/rewindは緑のチェックマークを表示して「巻き戻しに成功しました」と言うのに、Claudeがファイル以外にも手を加えたため、プロジェクトは壊れたままです。3つのケースを見ていきましょう。

1. Bashコマンドは追跡されません。 Claudeがあるターンでrm file.txtやmv old.txt new.txtを実行しても、その変更はチェックポイントに含まれません。Anthropicのドキュメントには明記されています。

つまり、ClaudeがBashツールで独自にファイルを削除、移動、コピーした場合、/rewindではすべてを復元できません。git checkoutやバックアップからの復元が役立つことはありますが、キーを2回押すだけでは済みません。

2. 外部からの編集は捕捉されません。 VS Codeで手動でファイルを開いて何かを編集した場合や、2つ目のClaudeセッションが同じファイルを並行して変更した場合、最初のセッションからはその変更が見えません。現在のセッションでClaudeがターンを終えたときに、チェックポイントのスナップショットが取得されます。ターン間に起きたことは対象外です。

3. ファイル外の操作はまったく対象になりません。 npx prisma migrate devでPrismaのマイグレーションを適用するとデータベーススキーマが変更されますが、データベースはプロジェクトのファイルシステム外にあるため、/rewindでは元に戻せません。origin/mainへのforce-pushも同様です。コミットはリモートサーバーに送られており、チェックポイントでは取り戻せません。課金やレコード削除を行うリモートAPI呼び出しは、そのAPI独自の仕組みでしか取り消せません。

ルール： タスクがプロジェクトファイル外のもの（データベースのマイグレーション、git push、リモートAPI）に影響する場合は、それぞれの外部操作に対する別個のロールバック方法を用意してください。/rewindで扱えるのは、現在のセッション内のローカルファイル履歴だけです。

/rewindとgitの違いは？両方必要なのはなぜ？#

Anthropicのドキュメントでは、この併用方法が明示されています。

違いを表にまとめます。

併用方法は簡単です。「これで動いている。失いたくない」という状態になったらgit commitします。コミット間は/rewindに頼ります。すぐに実行でき、コミットメッセージも不要で、中間状態によってgitの履歴が散らかることもありません。作業が終わったら、意味のあるアトミックなコミットを作りましょう。

1つの/rewindでタスク全体をカバーできないのはなぜ？#

元に戻すことはコンテキストエンジニアリングの一部です。セッションのコンテキストを管理すれば（いつコミットするか、いつ/rewindを押すか、CLAUDE.mdにどんなルールを記載するか）、予測可能なClaudeになり、プロジェクトを壊したり作業を失ったりすることがなくなります。

Claudeに「戻して」と頼むと、なぜgit reset --hardが危険なのか？#

「現在の状態を保存して、最後のpushまで戻して」という依頼は、次のコマンドにつながることがあります。

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # 未コミットの変更を保存
git reset --hard 35eb731                                                # コミットd63695e..882e618を破棄

最初のコマンドは正しく、未コミットの変更をstashに保存しました。2つ目は破壊的でした。ブランチをコミット35eb731まで書き換え、そのコミットと882e618の間にあるすべてのコミットが孤立しました。孤立したコミットは通常、git gcが実行されるまで.git/objects/に残ります。これは通常2週間以内に自動的に実行されます。しかし、そのとき何をすべきかわからなければ、すでに時間との勝負が始まっています。

考え方は簡単です。自然言語の「戻す」「前に戻る」「復元する」「取り消す」「元に戻す」は、「以前の状態を見る」または「安全な場所に戻る」という意味です。「履歴を破壊する」という意味ではありません。git reset --hardコマンドは履歴を破壊します。ブランチを書き換え、HEADから到達可能なコミットを取り除きます。安全な代替方法はgit checkout <commit>です。これを使えばdetached HEADになり、ブランチに触れずに古い状態を確認できます。

実務上の主な教訓は、大きな作業、特に複数ファイルのリファクタリングを始める前に、現在の状態をgit commitすることです。1つコミットしておけば、Claudeの失敗も、作業を失うことなくgit checkout .コマンド1つで元に戻せます。

破壊的なresetの後、git reflogはどうやって救ってくれる？#

破壊的なリセットの後は、すぐにgit reflogを実行しましょう。

git reflog

出力は次のようになります。

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

HEAD@{1}からHEAD@{3}が、まさにその「破棄された」コミットです。gitのローカルオブジェクトストアから消えたわけではありません。ブランチ経由でアクセスできなくなっただけです。復元するには、次のようにします。

# 最後の「破棄された」コミットからブランチを作成
git branch recovered-work 882e618

# または直接切り替え
git reset --hard 882e618

これで、ブランチには重大な事故が起きるまでの履歴が再びすべて含まれます。

reflogの制限：

1. ローカルのみ。 reflogは.git/logs/HEADに保存され、リモートリポジトリにはありません。force-pushした後にローカルリポジトリのコピーを削除すると、reflogもフォルダーごと失われます。
2. 既定では90日間。 古い項目はgit gcによって削除される場合があります。git config gc.reflogExpire 200.days.agoで設定できます。
3. HEADに一度も含まれていない内容は対象外。 stash内にしかなかったコミットがあり、そのstashが破棄された場合、reflogに表示されるのはstashの最新状態だけで、その内部履歴は表示されません。

チームのルール： 重大な事故の直後にgit gc --aggressiveを実行してはいけません。まずreflogを調査して復旧し、その後で他の作業を行います。また、必要なものがすべてpushされたと確信できるまでは、ローカルリポジトリのクローンを削除しないでください。

CLAUDE.mdを使って破壊的なgitコマンドからプロジェクトを守るには？#

脆弱性は、Claudeには既定で保護のための文脈がないことです。技術的には有効な方法なので、「戻して」をgit reset --hardと解釈します。プロジェクトのシステムプロンプトファイルであるCLAUDE.mdに保護ルールを記載しましょう。

最小限のルール（CLAUDE.mdに挿入）：

## Git Safety Protocol

- 破壊的なgitコマンド（push --force、reset --hard、checkout .、restore .、clean -f、branch -D）は、私が明示的に要求しない限り絶対に実行しないこと。許可されていない破壊的な操作は役に立たず、作業を失うおそれがあります。
- 私が「戻す」「前に戻る」「復元する」「取り消す」「元に戻す」と言った場合は、確認用コマンドとして解釈すること。`git log`、`git diff`、`git checkout <commit>`（detached HEADを作成）、`git stash`（変更を保持）を使用する。
- 次のいずれかに該当するコマンドを実行する前に、必ず確認を求めること。
  - ブランチ上のHEADを別のコミットに移動する
  - コミット履歴を変更する
  - コミット前の作業を失う可能性がある
  - `--hard`、`--force`、`--aggressive`フラグを含む
- 破壊的なコマンドを実行する前に、番号付きで比較を提示すること。
  - 安全：`git checkout <commit>`で一時的に確認する
  - 破壊的：`git reset --hard`で永久に破棄する
- 私が明示的に選択するまで実行しないこと。

チーム向けの拡張ルール（リポジトリのルートにあるCLAUDE.mdに追加）：

## Git Workflow Rules

- 動作する節目ごとにコミットすること。WIPの前に`git status`と`git diff`を確認し、レビューしたファイル名だけを`git add -- path/to/file`でステージし、差分を見てからコミットする。時間は見直しのきっかけで、全作業ツリーを含める許可ではない。
- Claudeのコミットでは、`git add .`または`git add -A`を絶対に使わないこと。`git status` + `git diff`の後に、ファイル名を指定する。
- mainへの`git push --force`の前に停止し、私に確認すること。フィーチャーブランチでは、以前のバージョンを失ってもよいと確信できる場合に限り、慎重にforce-pushする。
- マージ競合を解決するときは、すぐに「ours」または「theirs」を選ばないこと。まず両方のバージョンを私に提示し、私が判断する。
- `.gitignore`には`.env*`、`.claude/personal/`、`node_modules/`、`dist/`を含めること。足りない場合は追加する。

これらのルールを追加すれば、次に「最後のpushまで戻して」と言われたとき、次のような応答になります。

コミット前のファイルが3つあり、最後のpush以降に4つのコミットがあります。方法は2つあります。

1. 安全：git checkout <last-push-hash>でview-last-pushブランチを作成します。すべての作業を保持したまま、一時的にpushした状態を表示します。
2. 破壊的：git reset --hard <last-push-hash>を実行すると、4つのコミットとコミット前の変更を永久に破棄します。90日以内ならgit reflogで復元できます。どちらにしますか？

作業を4時間失う代わりに、30秒の会話で済みます。

Claude Codeで元に戻す5つの方法と、適切な選び方は？#

「Claudeが壊したので、急いで復元する必要がある」という場合は、はしごの一番下から順に進めます。必ず段階1から始めてください。

段階1. /rewind—セッション内ですぐ元に戻す。

Esc Escを押すか、/rewindと入力します。問題が起きる前の時点を選びます。モード（通常はRestore code and conversation）を選びます。1秒後には過去の状態に戻り、やり直すことができます。「Claudeが間違ったことをした」ケースの80%に対応します。

段階2. git checkout .—コミット前の変更をすべて取り消す。

git diff                    # 実際に何が変わったか、まず確認する
git checkout .              # すべてのファイルにあるコミット前の変更を取り消す
# または対象を指定する場合：
git checkout -- path/to/file.ts   # 1つのファイルだけ

/rewindで元に戻せなかった場合（たとえばClaudeがBash経由でファイルに手を加えた場合）や、セッション履歴外の変更を取り消す必要がある場合に便利です。コミットされていない変更はすべて永久に消えます。後悔する可能性があるなら、先にgit stashを実行してください（段階2.5を参照）。

段階2.5. git stash—変更を棚上げする。

git stash save "might still need this"
# 変更のないクリーンな状態に戻る
# ...
# 気が変わった場合はstashから復元する：
git stash pop

「永久に失う」と「そのままにしておく」のちょうど中間の選択肢です。明示的に削除するまでstashはローカルに残ります。

段階3. git checkout <commit>—履歴を失わずに以前のコミットに戻る。

git log --oneline               # 適切なコミットのハッシュを確認。例：abc1234
git checkout abc1234            # detached HEAD。何も変更せずに状態を確認
# その状態でよければ、そこからブランチを作成する：
git checkout -b recovery abc1234
# 戻る：
git checkout main

安全な「一時的に戻る」方法です。detached HEADにしてもブランチは変更されません。main（または使用中のブランチ）の現在の作業もそのまま残ります。この状態で作業する場合は、ブランチを作成してください。

段階4. git reset --hard <commit>—ブランチを以前の時点に戻す。

⚠️ 破壊的な操作です。指定したハッシュより先のコミットは孤立します。

git reflog                                  # 現在の状態のハッシュを控える
git reset --hard abc1234                    # ブランチを書き換える
# 間違いに気づいた場合はreflogで戻る：
git reset --hard HEAD@{1}                   # reset前の状態に戻る

先のコミットが不要だと確信している場合に限り使用してください。また、考えが変わったときの戻り先を把握できるよう、resetの前に必ずgit reflogを確認してください。

段階5. git reflog + 復旧—壊滅的な事態。

Claude、あなた、同僚などがすでにgit reset --hardまたはforce-pushを実行し、作業を消してしまった場合は、どうすればよいでしょうか？

git reflog                                          # 事故の前の最後のハッシュを探す
git branch recovered HEAD@{N}                       # そこからブランチを作成
git checkout recovered                              # そのブランチに切り替える
git diff main                                       # 現在の状態と比較する
git checkout main && git merge recovered            # 確信があればmainに復元する

すでにreflogが消えている場合（既定で90日経過後）、最後の手段はgit fsck --lost-foundです。.git/objects/にあるdangling commitが表示されます。ほぼ考古学のような作業ですが、うまくいくこともあります。

段階の選び方：

元に戻す必要がないようにプロジェクトを守るには？#

ルール1. 30分ごとにコミットする。

「タスクが終わるまで」待たないでください。動作する中間状態もすべてコミットします。コミットメッセージは何でもかまいません。大切なのは、Claude（またはあなた）がgit checkoutコマンド1つで動作していた状態に戻れることです。

# タスクの開始時
git status                        # ステージ済み・未ステージの全パスを確認
git diff                          # 変更をレビュー
# 例のパスを、実際にレビューしたファイルへ置き換える。
git add -- path/to/file.ts
git diff --cached                 # コミットする内容を確認
git commit -m "wip: starting User schema migration"

# 30分後（または最初に動作する状態になった後）
git status
git diff
git add -- path/to/file.ts         # 実際にレビューしたパスを指定
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# タスクの終了時—意味のあるコミットを作成
git reset --soft HEAD~2           # 3つのwipコミットを1つにまとめる
git commit -m "feat(auth): add lastLoginAt field to User table"

PostToolUseで通知する場合も、レビューと明示パスのルールを保ちます。無確認の定期自動コミットにすると、無関係な編集やステージ済みの変更が入るため、タイマーだけでコミットしないでください。

ルール2. 最低限の.gitignore。

次の行がプロジェクトのルートに必要です。

# シークレット
.env
.env.local
.env.*.local

# ローカルのClaude Code設定（チームのリポジトリにはpushしない）
.claude/personal/
.claude/sessions/
.claude/file-history/

# 依存関係とビルド
node_modules/
dist/
.next/
build/

私は.claude/personal/フォルダーを自分の実験やメモに使っています。共有リポジトリに含めてはいけません。.claude/sessions/と.claude/file-history/はClaude Codeのローカルストレージです。リポジトリに含めるべきではありません。容量を多く使い、特定のマシンにひも付いているためです。

ルール3. 実験は別のブランチで行う。

作業規模が大きい場合（10ファイル以上のリファクタリング、新しいデータベースへの移行、モジュールの書き換え）は、mainブランチで作業しないでください。

git checkout -b experiment/auth-rewrite
# 作業し、30分ごとにコミットする
# うまくいった場合：
git checkout main
git merge experiment/auth-rewrite
# うまくいかなかった場合：
git checkout main
git branch -D experiment/auth-rewrite     # ブランチを削除する
# これでmainブランチはそのまま

この簡単な習慣によって、「Claudeがプロジェクトを壊した」が「Claudeが1つのブランチを壊したので、それを削除してやり直す」になります。

ルール4. 危険な操作の前にgit tagを使う。

データベースのマイグレーション、大規模なリファクタリング、依存関係の更新の前にタグを作成してください。

git tag pre-prisma-migration-v2
# 作業する
# 問題が起きた場合：
git reset --hard pre-prisma-migration-v2
# または状態を見るだけなら：
git checkout pre-prisma-migration-v2

タグは、reflogが整理された後でも失わないコミットへの名前付きポインターです。

次のステップ：元に戻すことはコンテキストエンジニアリングにどう組み込まれる？#

この3段階の元に戻す方法は、壊れたときに状態を復元するという1つのスキルの基盤です。それだけでは範囲の狭いスキルです。しかし、ほかのコンテキストエンジニアリングツールと組み合わせると、さらに大きな効果を発揮します。

Plan Modeでは、すぐにコードを書くことはできません。まず計画を立て、確認を得てから実行します。これは予防的な「元に戻す」方法です。計画を事前にレビューするため、後で取り消すことになるコードを書かずに済みます。Claude CodeのPlan Modeのガイドもご覧ください。

CLAUDE.mdでは、上記のGit Safety Protocolを含め、Claudeが既定で従うルールを設定します。これは破壊的なコマンドからの予防的な保護です。

Second Brainはセッション間でClaudeにプロジェクトの記憶を与えます。どのコードがあるか、ビジネスロジックは何か、以前どんな合意があったかを把握できます。記憶が多いほど、誤った動作をする可能性が低くなります。

Skillsとサブエージェントは、あなたの方法論をコード化したものです。正しいgitワークフローをSkillに組み込めば、確認なしにgit reset --hardを実行するサブエージェントはいなくなります。

そして、これらすべてがContext Engineeringです。プロンプトの最中ではなく、プロンプトの前にコンテキストを管理しましょう。コンテキストエンジニアリングとは何かもお読みください。

元に戻すことは最後の防衛線です。Plan Mode + CLAUDE.md + Second Brain + Skillsが最初の4つです。これらが整っていれば、元に戻すことはまれで簡単になります。整っていなければ、毎日の習慣になります。

計画が終わるところから、元に戻すことが始まります。

Ailootを開く。