Claude Codeが意図と違う方向に進んだとき、慌ててセッションを捨てる必要はない。会話とコードの状態を以前のチェックポイントへ戻せる「rewind（巻き戻し）」機能を使えば、壊れる前の地点までやり直せる。本記事では、/rewindとEscダブルタップによる操作、戻るもの・戻らないもの、gitとの併用、そして「早めに止めて巻き戻して指示し直す」ワークフローを、2026年6月時点の公式仕様にもとづいて開発者向けに整理する。
結論：rewindは「会話・コードの局所的なundo」、gitは「永続的な履歴」
先に要点をまとめておく。
- rewindとは：Claude Codeがファイル編集ツールで加えた変更を自動でチェックポイント化し、任意の地点へ会話・コード・その両方を戻せる機能。プロンプトを送るたびに新しいチェックポイントが作られる。
- 使い方：入力欄が空の状態で
Escを2回押すか、/rewindを実行してメニューを開く。戻したい地点を選び、復元アクションを選択する。 - 戻らないもの：bashコマンドが変更したファイル、Claude以外（手動・別セッション）の変更、外部APIやデータベースへの副作用は対象外。gitの代替ではない。
対象読者：Claude Codeで実装を回している開発者・エンジニア・PM。「AIが暴走して困った」経験がある人ほど効く。今日できること：Escで止める→巻き戻す→指示し直す、という軌道修正の型を1つ手に入れる。
rewind・チェックポイントとは何か（会話とコードの状態を遡る）
Claude Codeは作業中、Claudeのファイル編集を自動的に追跡している。公式ドキュメントの表現を借りれば、「チェックポイント機能は各編集の前にコードの状態を自動でキャプチャする（checkpointing automatically captures the state of your code before each edit）」。これにより、大胆で広範囲な変更を指示しても「いつでも以前の状態に戻れる」というセーフティネットが効く。
追跡の仕組みは次の3点に整理できる。
- ユーザーがプロンプトを送るたびに、新しいチェックポイントが1つ作られる
- チェックポイントはセッションをまたいで保持される。ターミナルを閉じても、再開した会話から遡れる
- チェックポイントはセッションとともに30日後に自動でクリーンアップされる（設定で変更可能）
重要なのは、これが「コードのスナップショット」と「会話履歴」の両方を巻き戻せる、という点だ。単なるファイルのundoではなく、「Claudeとのやり取りそのもの」を特定地点まで戻せる。だから「変なプロンプトを送って迷走し始めた」地点まで丸ごとリセットできる。
使い方：/rewindとEscダブルタップで巻き戻す
rewindメニューを開く方法は2つある。手順は以下のとおり。
- メニューを開く：入力欄が空の状態で
Escを2回押す。または/rewindコマンドを実行する。 - 地点を選ぶ：メニューにはそのセッションで送った各プロンプトが一覧表示される。戻したい（あるいは要約したい）地点のメッセージを選ぶ。
- アクションを選ぶ：後述の復元・要約アクションから1つ選んで確定する。
ここで1つ、初心者が必ずハマる落とし穴がある。入力欄にテキストが残っていると、Escの2回押しは「入力のクリア」になってメニューが開かない。公式ノートにも「If the prompt input contains text, double Esc clears it instead of opening the menu.」と明記されている。クリアされたテキストは入力履歴に保存されるので、rewindを終えたあとにUpキーで呼び戻せる。メニューが開かないときは、まず入力欄を空にすることを思い出してほしい。
選べる復元・要約アクション
地点を選んだあとに提示されるアクションは、公式の表記でおおよそ次のとおり。
Restore code and conversation … コードと会話の両方をその地点へ戻す
Restore conversation … 会話だけ戻す（コードは現状のまま）
Restore code … コードだけ戻す（会話は残す）
Summarize from here … その地点以降を要約に圧縮（文脈節約）
Summarize up to here … その地点より前を要約に圧縮
Never mind … 何もせずメッセージ一覧に戻るとくに使い勝手がいいのが「Restore code（コードだけ戻す）」だ。ファイル変更だけを取り消し、会話履歴は残す。つまり「Claudeは何を試して、なぜ失敗したかを覚えたまま、ファイルだけクリーンに戻る」状態になる。「さっきのアプローチはダメだったよね、次はこうして」と、文脈を引き継いで指示し直せる。
逆に「Restore conversation（会話だけ戻す）」は、コードは現状のまま会話だけ特定地点へ戻す。会話やSummarizeから復元すると、選んだメッセージの元プロンプトが入力欄に戻るので、そのまま再送・編集できる。
どこまで戻る／戻らないか（bash・外部副作用・gitとの関係）
ここが本記事でいちばん大事なところだ。rewindは万能ではない。公式ドキュメントが明示している「Limitations（制限事項）」を、誤解なく押さえておく必要がある。
戻らないもの①：bashコマンドが変更したファイル
チェックポイントは、Claudeのファイル編集ツール経由の直接編集だけを追跡する。bashコマンドが変更したファイルは追跡されない。たとえばClaude Codeが次のようなコマンドを実行した場合、
rm file.txt
mv old.txt new.txt
cp source.txt dest.txtこれらのファイル変更はrewindでは元に戻せない。公式の表現でも「These file modifications cannot be undone through rewind. Only direct file edits made through Claude’s file editing tools are tracked.」とされている。「削除系・移動系の操作はチェックポイントの守備範囲外」と覚えておくと安全だ。
戻らないもの②：外部・別セッションの変更、外部副作用
チェックポイントは「現在のセッション内で編集されたファイル」だけを追跡する。Claude Code外で自分が手で加えた変更や、同時並行する別セッションの編集は、原則として捕捉されない（たまたま同じファイルを触った場合を除く）。さらに、外部APIへのリクエスト、データベースへの書き込み、メール送信といったセッション外で起きた副作用は、そもそもファイルの話ではないので巻き戻しの対象にならない。「ローカルのファイル状態は戻せても、外の世界に出てしまった作用は戻せない」と切り分けておく。
戻らないもの③：gitの代替にはならない
チェックポイントは「クイックなセッション単位の復旧」のための仕組みだ。永続的なバージョン履歴やチーム共有のためには、引き続きgit（コミット・ブランチ・長期履歴）を使う必要がある。公式は端的に「Think of checkpoints as “local undo” and Git as “permanent history”.」と言い切っている。ベストプラクティス側の警告も明快で、「Checkpoints only track changes made by Claude, not external processes. This isn’t a replacement for git.」。チェックポイント＝ローカルなundo、git＝永続的な履歴。この役割分担を崩さないことが、事故らない運用の前提になる。
早めに方向修正するワークフロー（Escで止める→巻き戻す→指示し直す）
rewindは「壊れてから慌てて使う」よりも、「早めの軌道修正の道具」として日常的に組み込むほうが効く。公式ベストプラクティスの「Course-correct early and often（早く・頻繁に軌道修正する）」がそのまま指針になる。最良の結果はタイトなフィードバックループから生まれる、という考え方だ。
具体的な操作レイヤーは次の4段階で覚えておくと迷わない。
Escで止める：Claudeが明らかに違う方向へ進み始めたら、まずEscでアクションを中断する。公式によれば「Context is preserved, so you can redirect.」＝文脈は保たれるので、そのまま指示を出し直せる。これは巻き戻しではなく「進行中の手を止める」操作。- 巻き戻すか判断する：中断した時点でファイルがすでに望まない状態なら、
Esc + Escまたは/rewindでメニューを開く。会話・コードの状態を以前へ戻すか、選んだメッセージから要約するかを選ぶ。 - 戻し方を選ぶ：会話は活かして失敗の文脈を残したいなら「Restore code」。プロンプト送信前の地点まで丸ごと戻すなら「Restore code and conversation」。「Undo that（さっきのを取り消して）」とClaudeに直接頼んで戻させる手もある。
- 指示し直す：戻したあと、より具体的なプロンプトで再開する。なお公式は「同じ問題で2回以上修正したら文脈が失敗アプローチで汚れている。
/clearで仕切り直し、学んだことを織り込んだ具体的なプロンプトで始め直すほうが、長い会話に修正を積み重ねるより、ほぼ確実に良い結果を出す」としている。巻き戻して粘るか、いっそ/clearするかの線引きは「同じ失敗2回」が目安だ。
このループを身につけると、「リスクのあることをまず試させて、ダメなら巻き戻す」という実験的な進め方ができるようになる。チェックポイントがあるから、思い切った一手のコストが下がる、という発想の転換だ。
git・checkpointの併用と限界、そして使い分け
ここまでを踏まえて、実務での使い分けを表に落としておく。
| シーン | 使う手段 | 理由 |
|---|---|---|
| Claudeの直近編集を取り消したい | rewind（Restore code） | セッション内の編集を即座にundoできる。コミット不要 |
| 迷走した会話ごと戻したい | rewind（Restore both） | 会話とコードを同じ地点へ揃えられる |
| 動く状態を恒久的に保存したい | git commit | チェックポイントは30日で消える。永続履歴はgitの役割 |
| bashで消した／移動したファイルを戻したい | git（事前コミット） | bash変更はrewind対象外。コミット済みならgitで復元 |
| 別アプローチを並行して試したい | fork / worktree | 元セッションを保ったまま分岐できる（要約とは別物） |
実装の現場では、「Escで止める→rewindで局所修正」を1日に何度も回しつつ、節目では必ずgit commitで安全地帯を作る、という二段構えが安定する。rewindはあくまで作業中の小回り、gitは戻れる土台。大きな変更に入る前にコミットしておけば、rewindの守備範囲外（bash変更・外部編集）で何かあってもgitで救える。この前提を置けるからこそ、rewindで思い切った実験ができる。
なお、文脈を圧縮したいだけならrewindの「Summarize from here / up to here」を、まるごと別アプローチへ分岐したいならclaude --continue --fork-sessionを使う、という使い分けも公式に示されている。「戻す（restore）」と「圧縮する（summarize）」と「分岐する（fork）」は似て非なる操作なので、目的に合わせて選びたい。
まとめと次のアクション
rewindは、Claude Codeを「失敗してもいい場所」に変える機能だ。最後に、今日から試せる3つのアクションを挙げておく。
- 空入力で
Esc×2、または/rewindを一度開いてみる。どの地点に戻れるか、どんな復元アクションがあるかを実際に確認する。入力欄が空でないと開かない点に注意。 - 「Restore code」で会話を残したまま巻き戻す練習をする。失敗の文脈を活かして指示し直す感覚を掴むと、軌道修正が一気に速くなる。
- 大きな変更の前に必ずgit commitする習慣をつける。bash変更・外部副作用はrewindで戻らないため、gitの安全地帯がrewindの実験性を支える。
関連して、変更前の「探索→計画」を分離したいならPlan Mode、危険な自動実行を隔離したいならサンドボックスが効く。あわせて押さえると、rewindと組み合わせて「止める・戻す・隔離する」の安全運用が一通りそろう。Claude Codeの基本テクニックを体系的に押さえたい場合は、実践テクニック完全ガイドから入るのがおすすめだ。
関連記事
- Claude Code Plan Mode実践ガイド｜安全に大変更【2026】
- Claude Codeサンドボックスで安全に自動実行【2026】
- CLAUDE.md設計・運用ガイド｜効くプロジェクトメモリ【2026】
- Claude Code 実践テクニック完全ガイド｜12スキル学習順【2026】
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
