重要なポイント
Claude Codeで元に戻す方法には3段階あります。組み込みの`/rewind`コマンド（セッション内ですぐに復旧）、`git checkout`（最後のコミットの状態に戻す）、そして`git reflog`（誰かが`git reset --hard`を実行した場合の最後の安全網）です。それぞれの段階が対応するのは固有の種類のミスであり、その範囲を超えることはできません。`/rewind`しか知らないと、重大な失敗をしたときに手も足も出なくなります。
Claude Codeを使い始めて最初の週に、私は`/rewind`を有効にしました。2回のプロンプトでプロジェクトの認証ロジックを壊されたからです。巻き戻して、ほっと息をつき、作業を続けました。1か月後、別のことが起きました。スキーマのマイグレーションを書き、Claudeに手伝ってもらってコミットし、ブランチを切り替えたところ、必要な手順を忘れていたことに気づいたのです。セッションはすでに別のものになっていたため、`/rewind`では解決できませんでした。前のコミットに`git checkout`して解決しました。その1か月後、私は誤ってエージェントに「最後のpushまで全部戻して」と指示し、エージェントは`git reset --hard`を実行して3時間分の作業を壊しました。`git reflog`に救われました。破棄されたコミットのハッシュがまだ残っていたのです。
この3つの話は、動作の異なる3段階の保護を示しています。それぞれ異なるミスを捕まえるため、すべて必要です。このガイドでは各段階のコマンド、制限、使用例を説明し、最初の失敗でClaudeにプロジェクトを壊されないよう、あらかじめプロジェクトを設定する方法も紹介します。
**元に戻す3段階：何を、いつ使うか：**
| 段階 | コマンド | 対象 | 対象外 |
|----|----|----|----|
| 1\. セッション内 | `/rewind`または`Esc Esc` | Claudeが独自のツールで変更したファイル、会話履歴 | Bashコマンド、外部エディター、データベースのマイグレーション |
| 2\. コミット前 | `git checkout .`または`git stash` | ファイルに対するコミット前のすべての変更 | コミット済みの変更 |
| 3\. 重大な事故 | `git reflog` + `git reset --hard ` | `reset --hard`またはforce-pushで破棄されたコミット | 破壊的なBashコマンド（rm、データベースのマイグレーション） |
次に各段階を見ていきます。具体的な操作、落とし穴、そして壊れて元に戻す必要が生じないようにする設定方法を説明します。
## /rewindを呼び出すには？コマンドとEscの2回押し
重要なポイント
Claude Codeの巻き戻しメニューを開く方法は2つあります。1つ目は入力欄に`/rewind`と入力する方法です。2つ目は入力欄が空のときに`Esc`を2回押す方法です。入力欄に文字がある場合、まずEscを2回押すと内容が消去され、入力履歴に保存されます。もう一度2回押すとメニューが開きます。`/rewind`コマンドには`/checkpoint`という別名があります。
応答のたびに、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公式ドキュメントから引用します。
プロンプト欄にテキストがある場合、Escを2回押すと、メニューを開く前にまずテキストが消去されます。消去されたテキストは入力履歴に保存されるため、巻き戻しメニューを開いた後に上矢印キーで復元できます。
— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
`/rewind`コマンドでも同じようにメニューが開きます。同じメニューを開く別名として`/checkpoint`もあります。どちらが使いやすいかは慣れの問題です。私は`Esc Esc`を使います。より速く、キーボードから手を離さずに済むからです。
## 巻き戻しメニューの6つのモード：どれをいつ選ぶ？
重要なポイント
巻き戻しメニューで時点を選ぶと、6つのモードがある2つ目のメニューが表示されます。状態を復元するものが3つ（`Restore code and conversation`、`Restore conversation`、`Restore code`）、履歴を圧縮するものが2つ（`Summarize from here`、`Summarize up to here`）、操作を取り消すものが1つ（`Never mind`）です。最もよくある「コードと会話の両方を巻き戻したい」という場合は、最初の選択肢です。
一覧から時点を選ぶと、操作メニューが表示されます。6項目あり、それぞれ動作が異なります。
**モードの一覧：**
| モード | 動作 | 選択する場面 |
|----|----|----|
| `Restore code and conversation` | ファイルと会話履歴を選択した時点に戻す | 最もよくある場面。Claudeが間違った方向に進んだため、適切な指示でやり直したいとき |
| `Restore conversation` | 会話履歴だけを巻き戻す。ファイルは現在の状態のまま | コードは問題ないが会話が脱線したとき。現在の変更を保ったまま、この時点から言い直す |
| `Restore code` | ファイルを巻き戻す。会話はそのまま | Claudeの変更の一部が不要だったが、会話の文脈（たとえば次の手順について合意した内容）は残したいとき |
| `Summarize from here` | 選択した時点より後の内容をすべて要約する。ファイルには触れない | 長いデバッグセッションでコンテキストを使い切ったため、最初の指示をすべて保持しつつ空きを作りたいとき |
| `Summarize up to here` | 選択した時点より前の内容をすべて要約する。ファイルには触れない | 最初に長い説明があり、その後に具体的なタスクが続いたとき。説明を1つのメッセージにまとめ、最近の作業はそのまま残す |
| `Never mind` | 変更せずにメニューを閉じる | 気が変わったとき |
`Summarize up to here`機能は、2026年5月11日～15日（第20週）にリリースされたClaude Code v2.1.139-v2.1.142で登場しました。
Rewindメニューから「Summarize up to here」を使って、初期のコンテキストを圧縮できます。
— Anthropic What's new, https://code.claude.com/docs/en/whats-new
`Restore`と`Summarize`の違いは根本的です。Restoreは以前の状態に戻り、選択した時点以降に起きたことをすべて取り消します。Summarizeは何も取り消さず、圧縮するだけです。元のメッセージは参照用にセッションのトランスクリプトに残りますが、アクティブなコンテキストには要約だけが残ります。「何も起きなかったことにしたい」ならrestoreを使います。「残しておきたいが、コンテキストを使い続けたくない」ならsummarizeを使います。
`Restore conversation`または`Summarize from here`の後は、選択したプロンプトの元のテキストが入力欄に戻ります。編集して再送信できます。`Summarize up to here`の後は入力欄が空になり、会話の最後に残ります。
## /rewindで元に戻せない変更は？
重要なポイント
`/rewind`が追跡するのは、Claudeが独自のファイル編集ツールで加えた変更だけです。それ以外は確認も復元もできません。認識されない変更には3種類あります。Bashコマンド（rm、mv、cp）、外部からの編集（IDEでの手動編集、別セッションからの変更）、ファイル外の操作（データベースのマイグレーション、git push、リモートAPI呼び出し）です。
多くの人が直面する主な制限がこれです。`/rewind`は緑のチェックマークを表示して「巻き戻しに成功しました」と言うのに、Claudeがファイル以外にも手を加えたため、プロジェクトは壊れたままです。3つのケースを見ていきましょう。
**1. Bashコマンドは追跡されません。** Claudeがあるターンで`rm file.txt`や`mv old.txt new.txt`を実行しても、その変更はチェックポイントに含まれません。Anthropicのドキュメントには明記されています。
チェックポイント機能はBashコマンドで変更されたファイルを追跡しません。たとえばClaude Codeがrm file.txt、mv old.txt new.txt、cp source.txt dest.txtを実行した場合、これらのファイル変更は巻き戻しでは元に戻せません。
— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
つまり、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の違いは？両方必要なのはなぜ？
重要なポイント
`/rewind`は1つのClaude Codeセッション内で行うローカルのロールバックです。最大30日間、1セッションにつき最大100個の差分スナップショットを保存します。gitはブランチ、マージ競合、リモートリポジトリを備えた、チームで共有する長期的なプロジェクト履歴です。どちらか一方で他方を置き換えることはできません。各論理的な節目で`git commit`し、コミット間は`/rewind`に頼るのがベストプラクティスです。
Anthropicのドキュメントでは、この併用方法が明示されています。
チェックポイントは、セッション単位ですばやく復旧するために設計されています。コミット、ブランチ、長期的な履歴には、引き続きGitなどのバージョン管理システムを使用してください。チェックポイントは通常のバージョン管理を補完するものであり、置き換えるものではありません。チェックポイントを「ローカルな元に戻す操作」、Gitを「永続的な履歴」と考えてください。
— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
違いを表にまとめます。
| 項目 | /rewind | git |
|----|----|----|
| 粒度 | 会話のターンごと | コミットごと |
| 保存期間 | 最大30日間、1セッションにつき最大100個、ローカルの`~/.claude/file-history/` | 永続的。リポジトリの`.git/`とリモートサーバーに保存 |
| 追跡対象 | Claudeが独自のツールで行った編集 | コミット済みのすべての変更 |
| 追跡対象外 | Bash、外部編集、マイグレーション、push | コミット前の変更 |
| コマンド | Claude内のコマンド | 外部のバージョン管理システム |
| 会話を巻き戻す | はい | いいえ |
| セッションをまたいで使えるか | 同じセッション内のみ | どこでも使える |
併用方法は簡単です。「これで動いている。失いたくない」という状態になったら`git commit`します。コミット間は`/rewind`に頼ります。すぐに実行でき、コミットメッセージも不要で、中間状態によってgitの履歴が散らかることもありません。作業が終わったら、意味のあるアトミックなコミットを作りましょう。
## 1つの/rewindでタスク全体をカバーできないのはなぜ？
元に戻すことは**コンテキストエンジニアリング**の一部です。セッションのコンテキストを管理すれば（いつコミットするか、いつ`/rewind`を押すか、`CLAUDE.md`にどんなルールを記載するか）、予測可能なClaudeになり、プロジェクトを壊したり作業を失ったりすることがなくなります。
## Claudeに「戻して」と頼むと、なぜ`git reset --hard`が危険なのか？
重要なポイント
自然言語で「戻す」とは「履歴を見る」という意味であり、「履歴を破壊する」という意味ではありません。Claudeは既定で`reset --hard`ではなく`git checkout`を提案すべきで、保護ルールはCLAUDE.mdで設定できます。
「現在の状態を保存して、最後のpushまで戻して」という依頼は、次のコマンドにつながることがあります。
```bash
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 `です。これを使えばdetached HEADになり、ブランチに触れずに古い状態を確認できます。
実務上の主な教訓は、大きな作業、特に複数ファイルのリファクタリングを始める前に、現在の状態を`git commit`することです。1つコミットしておけば、Claudeの失敗も、作業を失うことなく`git checkout .`コマンド1つで元に戻せます。
## 破壊的なresetの後、git reflogはどうやって救ってくれる？
重要なポイント
`git reflog`を使うと、`git reset --hard`やforce-pushで削除されたコミットも含め、リポジトリ内のHEADの移動履歴をローカルで確認できます。各移動は既定で90日間保存されます。Claude（あるいはあなた、または誰か別の人）が破壊的なコマンドでコミットを破棄した場合、`git reflog`にハッシュが表示され、`git reset --hard `でブランチを復元できます。
破壊的なリセットの後は、すぐに`git reflog`を実行しましょう。
```bash
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のローカルオブジェクトストアから消えたわけではありません。ブランチ経由でアクセスできなくなっただけです。復元するには、次のようにします。
```bash
# 最後の「破棄された」コミットからブランチを作成
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.md`に、Claudeが独自に実行できるgitコマンド、明示的な確認が必要なコマンド、ユーザーが特定の文言を正確に指定しない限り禁止するコマンドを定めた指示を追加します。ClaudeはCLAUDE.mdをプロジェクトのシステムプロンプトとして扱い、既定でそのルールに従います。これにより、1つの「危険な」指示を、安全な2つのコマンドに変えられます。
脆弱性は、Claudeには既定で保護のための文脈がないことです。技術的には有効な方法なので、「戻して」を`git reset --hard`と解釈します。プロジェクトのシステムプロンプトファイルである`CLAUDE.md`に保護ルールを記載しましょう。
**最小限のルール**（`CLAUDE.md`に挿入）：
```markdown
## Git Safety Protocol
- 破壊的なgitコマンド（push --force、reset --hard、checkout .、restore .、clean -f、branch -D）は、私が明示的に要求しない限り絶対に実行しないこと。許可されていない破壊的な操作は役に立たず、作業を失うおそれがあります。
- 私が「戻す」「前に戻る」「復元する」「取り消す」「元に戻す」と言った場合は、確認用コマンドとして解釈すること。`git log`、`git diff`、`git checkout `（detached HEADを作成）、`git stash`（変更を保持）を使用する。
- 次のいずれかに該当するコマンドを実行する前に、必ず確認を求めること。
- ブランチ上のHEADを別のコミットに移動する
- コミット履歴を変更する
- コミット前の作業を失う可能性がある
- `--hard`、`--force`、`--aggressive`フラグを含む
- 破壊的なコマンドを実行する前に、番号付きで比較を提示すること。
- 安全：`git checkout `で一時的に確認する
- 破壊的：`git reset --hard`で永久に破棄する
- 私が明示的に選択するまで実行しないこと。
```
**チーム向けの拡張ルール**（リポジトリのルートにある`CLAUDE.md`に追加）：
```markdown
## 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 `で`view-last-push`ブランチを作成します。すべての作業を保持したまま、一時的にpushした状態を表示します。
> 2. 破壊的：`git reset --hard `を実行すると、4つのコミットとコミット前の変更を永久に破棄します。90日以内なら`git reflog`で復元できます。どちらにしますか？
作業を4時間失う代わりに、30秒の会話で済みます。
## Claude Codeで元に戻す5つの方法と、適切な選び方は？
重要なポイント
問題が起きた場合、深刻度の異なる5つの段階があります。`/rewind`（セッション内）、`git checkout .`（コミット前の変更）、`git checkout `（履歴を失わず以前のコミットに戻る）、`git reset --hard `（前方にあるコミットを失いながらブランチを戻す）、`git reflog` + 復旧（すべてが失われた重大な事故）。それぞれ前の段階より強力で危険です。
「Claudeが壊したので、急いで復元する必要がある」という場合は、はしごの一番下から順に進めます。必ず段階1から始めてください。
**段階1. `/rewind`—セッション内ですぐ元に戻す。**
`Esc Esc`を押すか、`/rewind`と入力します。問題が起きる前の時点を選びます。モード（通常は`Restore code and conversation`）を選びます。1秒後には過去の状態に戻り、やり直すことができます。「Claudeが間違ったことをした」ケースの80%に対応します。
**段階2. `git checkout .`—コミット前の変更をすべて取り消す。**
```bash
git diff # 実際に何が変わったか、まず確認する
git checkout . # すべてのファイルにあるコミット前の変更を取り消す
# または対象を指定する場合：
git checkout -- path/to/file.ts # 1つのファイルだけ
```
`/rewind`で元に戻せなかった場合（たとえばClaudeがBash経由でファイルに手を加えた場合）や、セッション履歴外の変更を取り消す必要がある場合に便利です。コミットされていない変更はすべて永久に消えます。後悔する可能性があるなら、先に`git stash`を実行してください（段階2.5を参照）。
**段階2.5. `git stash`—変更を棚上げする。**
```bash
git stash save "might still need this"
# 変更のないクリーンな状態に戻る
# ...
# 気が変わった場合はstashから復元する：
git stash pop
```
「永久に失う」と「そのままにしておく」のちょうど中間の選択肢です。明示的に削除するまでstashはローカルに残ります。
**段階3. `git checkout `—履歴を失わずに以前のコミットに戻る。**
```bash
git log --oneline # 適切なコミットのハッシュを確認。例：abc1234
git checkout abc1234 # detached HEAD。何も変更せずに状態を確認
# その状態でよければ、そこからブランチを作成する：
git checkout -b recovery abc1234
# 戻る：
git checkout main
```
安全な「一時的に戻る」方法です。detached HEADにしてもブランチは変更されません。`main`（または使用中のブランチ）の現在の作業もそのまま残ります。この状態で作業する場合は、ブランチを作成してください。
**段階4. `git reset --hard `—ブランチを以前の時点に戻す。**
⚠️ 破壊的な操作です。指定したハッシュより先のコミットは孤立します。
```bash
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を実行し、作業を消してしまった場合は、どうすればよいでしょうか？
```bash
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が表示されます。ほぼ考古学のような作業ですが、うまくいくこともあります。
**段階の選び方：**
| 起きたこと | 段階 |
|-----------------------------------------------|-----------------------------|
| Claudeが3つのファイルを書き換え、間違った状態にした | 1\. `/rewind` |
| 試したが気に入らず、セッションでは解決できない | 2\. `git checkout .` |
| 手動で壊した。失いたくないので、復元するかもしれない | 2.5. `git stash` |
| コミット済みの状態から1つ前に戻りたい | 3\. `git checkout ` |
| 先のコミットが不要だと確信している | 4\. `git reset --hard` |
| 破壊的なコマンドですでに消してしまった | 5\. `git reflog` |
## 元に戻す必要がないようにプロジェクトを守るには？
重要なポイント
最高の元に戻す方法は、元に戻す必要がない状態にすることです。3つの保護ルールがあります。30分ごとに進捗を確認し、レビューしたパスだけを明示的にステージして、動作する節目をコミットする。必須の`.claude/personal/`と`.env*`の行を`.gitignore`に追加する。大きな実験は`git checkout -b experiment-`で別ブランチ上で行う。コミットしたファイルの復旧間隔を狭められますが、外部システムと未コミット作業には別の復旧計画が必要です。
**ルール1. 30分ごとにコミットする。**
「タスクが終わるまで」待たないでください。動作する中間状態もすべてコミットします。コミットメッセージは何でもかまいません。大切なのは、Claude（またはあなた）が`git checkout`コマンド1つで動作していた状態に戻れることです。
```bash
# タスクの開始時
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`。**
次の行がプロジェクトのルートに必要です。
```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ブランチで作業しないでください。
```bash
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`を使う。**
データベースのマイグレーション、大規模なリファクタリング、依存関係の更新の前にタグを作成してください。
```bash
git tag pre-prisma-migration-v2
# 作業する
# 問題が起きた場合：
git reset --hard pre-prisma-migration-v2
# または状態を見るだけなら：
git checkout pre-prisma-migration-v2
```
タグは、reflogが整理された後でも失わないコミットへの名前付きポインターです。
## 次のステップ：元に戻すことはコンテキストエンジニアリングにどう組み込まれる？
重要なポイント
元に戻すことは独立したスキルではなく、Claude Codeのセッションコンテキストを管理する一部です。いつ`/rewind`を押すか、いつ`git commit`するか、いつ`git stash`するかを理解しているなら、単一のコマンドではなく、ワークフロー全体を管理しています。これは**Context Engineering**の一部です。これがなければClaudeは普通のアシスタントのように振る舞い、あれば予測可能なツールのように振る舞います。
この3段階の元に戻す方法は、壊れたときに状態を復元するという1つのスキルの基盤です。それだけでは範囲の狭いスキルです。しかし、ほかのコンテキストエンジニアリングツールと組み合わせると、さらに大きな効果を発揮します。
Plan Modeでは、すぐにコードを書くことはできません。まず計画を立て、確認を得てから実行します。これは予防的な「元に戻す」方法です。計画を事前にレビューするため、後で取り消すことになるコードを書かずに済みます。[Claude CodeのPlan Mode](https://ailoot.ai/blog/ja/claude-code-plan-mode/)のガイドもご覧ください。
[CLAUDE.md](https://ailoot.ai/blog/ja/claude-md-template/)では、上記のGit Safety Protocolを含め、Claudeが既定で従うルールを設定します。これは破壊的なコマンドからの予防的な保護です。
[Second Brain](https://ailoot.ai/blog/ja/claude-code-second-brain/)はセッション間でClaudeにプロジェクトの記憶を与えます。どのコードがあるか、ビジネスロジックは何か、以前どんな合意があったかを把握できます。記憶が多いほど、誤った動作をする可能性が低くなります。
[Skillsとサブエージェント](https://ailoot.ai/blog/ja/claude-code-skills-library/)は、あなたの方法論をコード化したものです。正しいgitワークフローをSkillに組み込めば、確認なしに`git reset --hard`を実行するサブエージェントはいなくなります。
そして、これらすべてが**Context Engineering**です。プロンプトの最中ではなく、プロンプトの前にコンテキストを管理しましょう。[コンテキストエンジニアリングとは何か](https://ailoot.ai/blog/ja/context-engineering/)もお読みください。
元に戻すことは最後の防衛線です。Plan Mode + CLAUDE.md + Second Brain + Skillsが最初の4つです。これらが整っていれば、元に戻すことはまれで簡単になります。整っていなければ、毎日の習慣になります。
### 出典
- [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing)
- [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new)
- [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes)
- [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
計画が終わるところから、元に戻すことが始まります。
[Ailootを開く](https://ailoot.ai/)。
## Claude Codeで変更を元に戻す方法：/rewindとgit：よくある質問
### 作業中のチェックポイントにgit add .を使いますか？
いいえ。git statusとgit diffで確認し、レビューしたファイル名だけをステージして、git diff --cachedを見てからコミットします。定期保存は無関係・既存ステージ変更を含める許可ではありません。
### /rewindはDB移行や外部API操作を戻せますか？
いいえ。対象はセッションの対応ファイル編集です。DB、リモートGit、APIへの影響は別の復旧手順を使い、範囲外のファイルにはGitやバックアップが必要です。
## Ailoot · 企業とそのプロジェクト群
Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。
企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。
Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。