依頼の意図を一度取り違えたまま、Claude Code に5ステップほど作業を進めさせてしまったことはないでしょうか。三つのファイルが書き換わり、テストの形も変わり、戻したいのに「どこまで戻せばいいのか」が分からなくなる。手で戻そうとすると、今度は会話の文脈と実際のコードがずれてしまう。私自身、個人開発で複数サイトの自動投稿まわりをいじっているときに、この「半端に進んだ状態」に何度も足を取られてきました。
2026年6月の Claude Code アップデートで、この /rewind まわりの挙動と安定性が一段底上げされました。機能自体は以前からありますが、長時間セッションでの省メモリ化やエージェント挙動の改善と合わせて、実運用で頼れる安全網になってきています。ここでは「いつ使うと効くのか」「git と何が違うのか」「自動運用で誤解しやすい点」を、実際の使いどころに沿って整理します。
/rewind が戻してくれるもの、戻さないもの
Claude Code はセッション中、編集の節目ごとにチェックポイントを自動で記録しています。/rewind を実行する（あるいはエスケープキーを素早く2回押す）と、これまでのチェックポイント一覧が出て、そこへ戻せます。
ここで一番大事なのは、戻せる対象が二系統あることです。
ひとつは「会話（コンテキスト）」。Claude とのやり取りの履歴を、選んだ時点まで巻き戻します。もうひとつは「コード（ファイルの中身）」。Claude Code がそのセッションで編集したファイルを、選んだ時点の状態へ戻します。/rewind のメニューでは、この二つを「両方戻す」「コードだけ戻す」「会話だけ戻す」と選び分けられます。
逆に、戻らないものをはっきり押さえておくと事故が減ります。Claude Code の編集を経由せずにあなたが手で書き換えたファイル、git や rm などのコマンドが起こした副作用、ネットワーク越しに送ってしまった外部への書き込み（API 呼び出し・push・デプロイ）。これらは /rewind の管轄外です。チェックポイントはあくまで「Claude Code が把握している編集」のスナップショットだと考えてください。
git のリセットと何が違うのか
「それ git でいいのでは」と思うかもしれません。実際、用途は重なります。ただ二つは見ている対象が違います。
git reset や git stash が戻すのは、コミットやワーキングツリーというコードの状態だけです。あなたと Claude がどういう経緯でその実装にたどり着いたか、という会話の文脈は git には残りません。一方 /rewind は、コードと会話をセットで巻き戻せます。「この方針で行こうと合意した直前」まで、対話ごと戻れるわけです。
私の使い分けはこうしています。コミット済みの安定点に戻したい、あるいはブランチをまたぐような大きなやり直しは git。まだコミットしていない試行錯誤の途中で「ついさっき方針がずれた」ところだけ戻したいときは /rewind。後者は git で表現しづらい、会話とコードが一緒にずれた状態をきれいに戻せるのが強みです。両者は競合しません。/rewind で会話とコードを近い状態に戻してから、必要なら git で仕上げる、という重ね方が安全だと考えています。
実際の巻き戻し手順
込み入った場面ほど、操作はシンプルに保つのが安全です。次の流れを基本形にしています。
まず、巻き戻す前に未コミットの手編集を退避します。/rewind はチェックポイント外の手編集を消す可能性があるため、念のため逃がしておきます。
# 巻き戻し前に、手で触った分を退避しておく
git stash push -u -m "before-rewind"
# 退避できているか確認
git stash list次に Claude Code 側で /rewind を開き、「どこで方針がずれたか」を会話履歴から探して、その直前のチェックポイントを選びます。ずれた発言そのものではなく、ひとつ手前を選ぶのがコツです。ずれた地点を含めて戻すと、また同じ誤解の続きから再開してしまいます。
戻したあとは、コードと会話が食い違っていないかを一度だけ確認します。具体的には、戻した時点で「まだ存在しないはずのファイル」が残っていないか、テストが当時の形に戻っているかを見ます。問題なければ、退避した手編集のうち本当に必要なものだけを選んで戻します。
# 戻した状態を確認してから、必要な手編集だけ拾う
git diff
git stash pop # 衝突したら片方ずつ取り込むこの「退避 → 巻き戻し → 確認 → 選んで戻す」を一つの型にしておくと、慌てている場面でも手順を思い出せます。
自動運用で誤解しやすい点
ここが、公式の説明だけでは見えにくいところです。/rewind は対話セッションのための安全網であって、無人で回すスケジュール実行の取り消し機構ではありません。
私は個人開発で複数サイトの記事生成を自動で回していますが、自動実行のジョブが途中でおかしくなったとき、/rewind で後から救う、という設計にはしていません。理由は単純で、無人ジョブはたいてい push やデプロイといった外部への確定操作まで一気に進むため、/rewind が戻せる範囲（ローカルのファイルと会話）を超えてしまうからです。巻き戻せるのは手元だけで、すでに公開された結果は戻りません。
ですので、自動運用側では /rewind を当てにせず、確定操作の前に止まれるゲートを別に置く設計にしています。コードを書き換える段階と、それを外へ送る段階を分け、送る前に検証を挟む。/rewind が活きるのは、あくまで自分が画面の前にいて、対話で試行錯誤しているときです。役割を取り違えなければ、両者はきれいに住み分けられます。
長時間のセッションそのものが不安定だと感じる場合は、巻き戻し以前にコンテキストの劣化が起きている可能性もあります。その兆候と対処はClaude Code の長時間セッションで精度を保つ方法 — コンテキスト劣化の兆候と対処で扱っています。セッションそのものが復元できないケースはClaude Code の resume が前回のセッションを復元できない時の対処法も併せてご覧ください。
巻き戻しを「使わずに済む」設計へ
/rewind は心強い安全網ですが、頻繁に使うようなら、その手前で防げたはずの取り違えが多い、という信号でもあります。私が意識しているのは、大きく任せる前に「何をどう変えるか」を一度言葉にして合意しておくことです。方針を先に短く確認しておくと、5ステップ進んでから巻き戻す場面そのものが減っていきます。
それでもずれるときはずれます。そのときに /rewind があると知っているだけで、思い切って任せられる範囲が広がります。安全網は、使う回数を減らすために整えておくもの——そう考えると、この機能の価値は「巻き戻せること」以上に「安心して前に進めること」にあるのだと感じています。
私はこの機能を、思い切って任せるための足場として捉えています。まずは次に Claude Code を使うとき、エスケープキーを2回押してチェックポイント一覧を一度開いてみてください。どこに戻れるのかを目で確かめておくだけで、いざという時の判断が速くなります。お読みいただきありがとうございました。