Claude Code rewindで戻らない変更5つ｜巻き戻せる範囲

Claude Code rewindは、会話とClaude Codeが編集したファイルを、選んだプロンプトの時点までまとめて戻すしくみです。ただしbashで書き換えたファイル、サブエージェントの編集、シンボリックリンクは戻りません。この記事では、巻き戻せる範囲と戻らない5つの変更、復元メニューの6項目、そして復旧の手順を公式仕様に沿って整理します。

01Claude Code rewindとは｜何を戻すコマンドか

Claude Code rewindは、会話履歴とClaude Codeのファイル編集ツールが加えた変更を、過去のある時点まで一緒に戻す機能です。公式ドキュメントでは、あなたがプロンプトを送るたびに直前のコードの状態がチェックポイントとして自動的に記録される、と説明されています。つまり巻き戻しの単位はコミットではなく、プロンプト1通です。

この「会話も一緒に戻る」点が、gitやエディタのundoとの決定的な差になります。ファイルだけを手で元に戻しても、Claude側は自分が書き換えたつもりのまま話を続けるため、次の指示から前提がずれていきます。rewindはそのズレごと巻き戻すので、戻したあとの一手目が噛み合います。

FIG. 01rewindが担当する3つの層

01

記録

ユーザーのプロンプトごとにチェックポイントが1つ作られ、その時点のファイルの状態が保存される。

02

選択

/rewind またはEsc2回でメニューを開くと、セッション中に送ったプロンプトが一覧で並ぶ。

03

実行

コードと会話の復元3種、コンテキストを圧縮する要約2種、キャンセルの計6つから選ぶ。

使いどころは、実装方針が途中でずれた、頼んでいない範囲まで編集された、一括置換で表示が壊れた、といった場面です。実行前に方針を固めるClaude CodeのPlan Modeが「起こる前の防止」だとすれば、rewindは「起きてしまったあとのやり直し」にあたります。両方を持っておくと、任せられる範囲が広がります。

02rewindの起動方法｜/rewindとEsc2回で開かないとき

起動方法は2つで、プロンプト入力欄に /rewind と打つか、入力欄が空の状態でEscキーを2回押します。Esc2回が反応しないという相談のほとんどは、この「空の状態で」という条件を満たしていないことが原因です。

# 方法1: スラッシュコマンド（入力欄の状態を問わない）
/rewind

# 方法2: キーボード（入力欄が空のときだけメニューが開く）
Esc Esc

Esc2回でメニューが開かない原因

入力欄に文字が残っていると、Esc2回はメニューではなく入力の消去として働くためです。公式ドキュメントは、消したテキストは入力履歴に保存されるので、rewindの操作を終えたあとに上矢印キーで呼び戻せる、と補足しています。確実に開きたいときは、入力欄の状態に左右されない /rewind を打つほうが早いです。

メニューに「Restore code」が出てこない理由

選んだチェックポイント以降に、記録されたファイル変更が1件も無いからです。コードを戻す2つの選択肢は、そのチェックポイントに戻すべき変更があるときだけ表示されます。編集が無い場合のメニューは「Restore conversation」「Summarize」系「Never mind」だけになります。

ここで見落としがちなのが、Claudeがbash経由でファイルを触っていたケースです。作業した実感があるのにコードの復元が出ないときは、その区間の変更がそもそも追跡対象外だったと考えて、gitでの確認に切り替えるのが早い判断です。

03rewindメニューの6項目｜復元3種・要約2種・キャンセル

rewindは「戻す」だけの機能ではありません。メニューには復元3種のほかに、会話を圧縮してコンテキストの空きを増やす要約が2種類あり、合わせて6つの行動を選べます。この要約2種を知っていると、長いセッションを途中で捨てずに済みます。

FIG. 02rewindメニューの選択肢と役割

選択肢	何が起きるか	選ぶ場面
Restore code and conversation	コードと会話の両方をその時点へ戻す	方針がずれた・大きくやり直す（基本形）
Restore conversation	会話だけ戻し、コードは現在のまま保つ	成果物は活かし、文脈だけ整理し直す
Restore code	ファイル変更だけ戻し、会話は残す	やり取りの経緯を残して実装をやり直す
Summarize from here	その地点から後ろの会話を要約に圧縮する	デバッグの往復で膨らんだ後半を畳む
Summarize up to here	その地点より前の会話を要約に圧縮する	前半の探索を畳み、直近のやり取りは残す
Never mind	何もせずメッセージ一覧へ戻る	選び直す・様子を見る

迷ったときは「Restore code and conversation」を選びます。ファイルの中身とClaudeが覚えている前提が同じ時点にそろうので、戻したあとの指示が一度で通ります。会話だけ・コードだけの復元は、片方を意図的に残したいときの使い分けです。

Summarizeは「戻す」ではなくコンテキストの空きを増やす操作

要約2種はディスク上のファイルを一切変更しません。元のメッセージもセッションのトランスクリプトには残るため、Claudeは細部を参照できます。圧縮された箇所には「Summarized conversation」というマーカーが表示されるので、どこを畳んだかが後から追えます。

用途としては、/compact を会話全体にかける代わりに、膨らんだ区間だけを狙って畳むイメージです。冒頭の要件定義は原文のまま残し、途中のログ貼り付けだけを要約する、といった精密な削り方ができます。消費量そのものを下げる打ち手はClaude Codeのトークン節約術で別途まとめています。

要約の焦点を指示する方法

Summarizeの行を矢印キーでハイライトすると、行に「add context (optional)」という入力欄が現れます。ここに残したい観点を書いてEnterを押すと、その指示に沿って要約されます。数字キーで選ぶと指示なしで即座に実行されるため、焦点を指定したいときは矢印キーで合わせるのがポイントです。

復元後にプロンプトが入力欄へ戻る挙動

会話を復元した場合と「Summarize from here」を選んだ場合、選んだメッセージの元のプロンプトが入力欄に復元されます。同じ指示をそのまま再送してもよいですし、条件を1行足してから送り直すこともできます。一方「Summarize up to here」を選んだときは会話の末尾に留まり、入力欄は空のままです。

04Claude Code rewindで戻らない変更5つ

ここが最も誤解の多い部分です。rewindが戻すのは、あくまでClaudeのファイル編集ツールが記録した変更と会話までで、それ以外は現在の状態が残ります。「巻き戻したのに直っていない」という事故は、ほぼこの5つのどれかに当たります。

① bashコマンドで加えたファイル変更

チェックポイントはbash経由の変更を追跡しません。公式ドキュメントは rm file.txt、mv old.txt new.txt、cp source.txt dest.txt を例に挙げ、これらはrewindで取り消せないと明記しています。追跡されるのは編集ツール経由の変更だけで、bash経由は操作の種類を問わず対象外です。

② サブエージェントが行った編集

サブエージェントはファイル編集ツールを使いますが、その編集は通常あなたのセッションのチェックポイントに記録されません。例外は、フォアグラウンドで動くフォーク実行のスキル（context: fork かつ background: false）です。この場合は自分のターンの中で作業ツリーを編集するため、rewindで戻ります。

逆に、バックグラウンドで走らせたフォークのスキルや、バックグラウンドの /code-review --fix による修正は戻りません。ここはgitで戻す前提になります。役割分担の考え方はClaude Codeのスキルとサブエージェントの使い分けで整理しています。

③ シンボリックリンク・ハードリンクのファイル

rewindはシンボリックリンクとハードリンクを復元しません。リンク先を書き戻すと、システム上の無関係なファイルを上書きしかねないためです。復元時にはこれらのパスが飛ばされ、「Restored the code, but skipped N files」という警告が出ます。

該当しやすいのは、dotfile管理ツールがプロジェクトへ張り込んだ設定ファイルと、pnpmがハードリンクで配置したファイルです。心当たりのあるリポジトリでは、rewind後に必ず差分を確認します。

④ セッション外の手動編集と、別セッションの編集

チェックポイントが追跡するのは、現在のセッションで編集されたファイルだけです。あなたがエディタで直接直した内容や、並行して走っている別セッションの編集は、同じファイルにたまたま触れていない限り記録されません。複数セッションを並列で走らせる運用をしている場合は、この落とし穴に当たる確率が上がります。

⑤ 実行済みコマンドの副作用

インストール、マイグレーション、外部APIの呼び出し、データベースの更新、push、デプロイは、rewindの対象外です。これらはファイル編集ではなく外界への作用なので、そもそもチェックポイントの守備範囲に入っていません。無人で走らせるほど致命傷になりやすい領域で、対処はrewindではなく権限モードの設計と承認フローの側で行います。

FIG. 03戻るもの／戻らないものの線引き

rewindで戻るもの	rewindでは戻らないもの	戻し方
編集ツールによるファイル変更	bashのrm・mv・cpによる変更	git checkout / revert
Claudeが新規作成したファイル	バックグラウンドのサブエージェントの編集	git checkout / revert
会話履歴とコンテキスト	シンボリックリンク・ハードリンク	手動で再作成
フォアグラウンドのフォーク実行スキルの編集	セッション外・別セッションの編集	エディタのundo / git
コミット前の作業ツリーの状態	実行済みコマンド・push・デプロイ・DB更新	各サービスの手順で個別に

05「Restored the code, but skipped N files」と出たときの復旧手順

この警告は、大半のファイルは戻せたものの一部が飛ばされたことを意味します。復元されたファイルはそのまま使って問題ありませんが、飛ばされたファイルは手当てが要ります。まず理由を特定し、それから対処を選びます。

FIG. 04スキップの理由と対処

理由	起きていること	対処
Symlink	シンボリックリンクのため復元しない	手動で張り直す
Permission denied	ファイルや親ディレクトリに書き込めない	chmodで書き込み可にして再実行
Not a regular file	ディレクトリ・デバイスなど通常ファイル以外	復元対象外なので手動で管理する
File disappeared	ターン開始後に削除・移動された	バージョン管理かバックアップから戻す
Directory in the way	書き込む場所にディレクトリがある	移動かリネームして再実行
File changed	記録時点と中身が違うため上書きしない	現在の変更をバックアップしてから /rewind を再実行する

手順としては、飛ばされたファイルと理由を控え、消えた・変わったファイルは現状を残すか戻すかを判断し、権限やリンクの問題は先に解消してから /rewind をもう一度実行します。

# 1. 飛ばされたパスの現状を確認する
ls -l <path>

# 2. Permission denied のとき、書き込みを許可する
chmod u+w <path>

# 3. Symlink のとき、リンクを張り直す
ln -s <target> <link>

# 4. File disappeared / File changed のとき、gitで戻す
git checkout -- <path>

# 5. 原因を解消してから、もう一度実行する
/rewind

どのパスが飛ばされたかを正確に知りたいときは、復元前にデバッグログを有効にしておきます。

# デバッグログを有効にして起動する
claude --debug

# セッション内で有効にする場合
/debug

# ログの場所（飛ばされたパスとシステムエラーが記録される）
~/.claude/debug/<session-id>.txt

このログには、飛ばされたファイルのフルパスと、スキップごとのシステムエラーが残ります。「なぜこのファイルだけ戻らなかったのか」を推測で詰めるより、ログを開いたほうが確実に早く終わります。

06チェックポイントの保持期間｜100件と30日の2つの上限

上限は2種類あり、直近100チェックポイント分のファイルスナップショットと、セッションごと30日で削除というルールが同時に適用されます。長いセッションでは、日数より先に件数のほうに当たることがあります。

古いチェックポイントが破棄されると、どのチェックポイントからも参照されなくなったスナップショットのファイルが削除されます。ただし各ファイルの最初のスナップショットだけは残り、VS Code拡張がセッション差分の基準として使います。100プロンプトを超える長丁場では、序盤の任意地点に戻れるとは限らないと考えておくのが安全です。

30日の期限は、セッションの保持期間の設定と連動しています。変更する場合は settings.json の cleanupPeriodDays を書き換えます。

// ~/.claude/settings.json
{
  "cleanupPeriodDays": 60
}

もう一つ実務で助かる仕様が、チェックポイントは会話と一緒に保存される点です。セッションを再開したあとでも /rewind が使えるため、「昨日の続きを開いたら巻き戻せない」という事態にはなりません。設定ファイルの書き方全般はCLAUDE.mdの書き方もあわせて参照してください。

07/clearで消えた会話にrewindで戻れる？

戻れます。同じClaude Codeのプロセス内で /clear を実行した場合、rewindメニューの先頭に /resume <session-id> (previous session) という項目が追加され、これを選ぶと /clear の直前まで動いていた会話を再開できます。

この項目が出るのは、Claude Codeを終了するか、別のセッションを再開するまでの間です。プロセスを閉じてしまった場合や、Claude Code v2.1.191より前のバージョンでは、/resume を実行して一覧から前のセッションを選び直します。

# /clear の直後にプロセス内で戻す
/rewind
#   → 一覧の先頭 "/resume  (previous session)" を選択

# プロセスを閉じたあと、または旧バージョンの場合
/resume
#   → 一覧から直前のセッションを選ぶ

「重くなったからとりあえずリセットした」あとで青くなる場面は珍しくありません。/clear は取り返しのつく操作だと知っておくと、セッションを畳む判断が軽くなります。

08rewindと/branch・gitの使い分け

やり直しの手段はrewindだけではありません。別案を並行で試したいときは、セッションを分岐させる /branch を使います。ここで注意したいのは、Claude Codeに /fork というコマンドは存在しない点です。セッション内では /branch、コマンドラインからは --fork-session を使います。

# セッション内で分岐する（元のセッションはそのまま残る）
/branch try-streaming-approach

# コマンドラインから分岐して再開する
claude --continue --fork-session

/branch を実行すると、新しい分岐と元のセッションの2つのIDが表示されます。元のセッションはディスク上で変更されずセッションピッカーにも残るため、/resume でいつでも戻れます。

FIG. 05rewind・/branch・gitの役割分担

手段	何をするか	元の状態	向いている場面
rewind	会話とコードを過去の時点へ置き換える	置き換わる	失敗した1手を素早く取り消す
/branch・–fork-session	会話を複製して別の道を試す	そのまま残る	2案を比較する・元を消したくない
git	変更を永続的に記録・復元する	履歴として残る	長期の履歴管理とチーム共有

公式ドキュメントも、チェックポイントはセッション単位の素早い復旧のための設計であり、バージョン管理の代わりではないと明言しています。節目ではコミットで区切りをつけ、コミットとコミットのあいだの試行錯誤をrewindで支える、という二段構えが基本形です。

09rewindで戻せない事故を防ぐ運用ルール3つ

rewindを保険として機能させるには、作業の置き方を少し変える必要があります。要点は、戻せる範囲に作業を寄せること、戻せない操作の手前で区切りを打つこと、そして無人運用では実行そのものを止める層を持つことの3点です。

FIG. 06rewindを活かす運用ルール

01

編集は編集ツールへ寄せる

ファイルの書き換えをbashのsedやmvで済ませない。編集ツール経由なら記録に載り、あとで戻せる。

02

動いたらコミットで区切る

1機能ぶん通ったらコミットする。100件・30日の上限の外へ、確定した状態を逃がしておく。

03

戻せない操作は実行前に止める

push・デプロイ・DB更新・外部送信は巻き戻らない。承認を要求する側の設定で入口を絞る。

1日の作業をこの順で回す

具体的な流れは次のとおりです。1セクションぶん作らせて表示を確認し、問題なければコミットします。次の作業で方針がずれたら、手で直さずに /rewind を開き、直前の良かった時点まで「Restore code and conversation」で戻して指示を出し直します。手で直すと会話の前提だけが古いまま残るため、二度手間になりがちです。

# 実務の基本ループ
# 1. 1機能ぶん作らせる → 動作を確認
# 2. 通ったらコミット（100件・30日の上限の外へ逃がす）
git add -A && git commit -m "feat: hero section"

# 3. 次の作業でずれたら巻き戻す
/rewind
#   → 直前の良かったプロンプトを選び Restore code and conversation

# 4. push・デプロイは戻らないので、コミット確定後に手動で

無人で走らせるときに追加でやること

無人でエージェントを走らせる場合は、3つ目のルールが要になります。承認を毎回省く設定の危険度と絞り方はClaude Codeの権限バイパスで、夜間の自動実行を組む際の考え方はClaude Codeの定期実行でそれぞれ扱っています。

10Codex CLIにrewindはある？

あります。ただし戻るのは会話だけです。OpenAIのCodex CLIにはEscキーによる巻き戻しがあり、会話と履歴を過去の地点へ戻せますが、その地点より後にCodexが加えたコード変更は元に戻りません。

コードと会話を同じ地点へ同時に戻す /rewind を実装してほしいという要望は、openai/codexリポジトリにIssue #11626としてオープンのまま残っています。要望の中身は、チェックポイントの一覧表示、コードと会話の同時復元、元に戻すファイルの事前プレビュー、復元したプロンプトの再編集の4点です。

したがって2026年9月時点では、「会話とコードを同じ地点へ同時に戻す」操作は、コーディングCLIの中でもClaude Code側の強みだと整理できます。他ツールを併用している場合、巻き戻しの前提を揃えられるのはClaude Codeのセッションだけになる、と想定して運用を組むほうが安全です。

11Claude Code rewindのよくある質問

12まとめ：rewindは短期の保険、境界の外はgitで戻す

Claude Code rewindを使いこなす分かれ目は、操作を覚えることではなく、境界を正確に把握することにあります。戻るのは編集ツールが記録した変更と会話まで、戻らないのはbash・サブエージェント・リンク・セッション外の編集・実行済みの副作用の5つです。この線引きが頭に入っていれば、巻き戻して直らなかったときに慌てず、次の一手をgitに切り替えられます。

今日から変えられることは3つです。ファイルの書き換えを編集ツール側に寄せる、1機能通ったらコミットして100件・30日の上限の外へ逃がす、そしてpushやデプロイのような戻らない操作は承認の側で止める。この3つを回しておけば、失敗しても失うのは1ターンぶんの作業だけで済みます。

あわせて、実装前に方針を固めるClaude CodeのPlan Mode、任せる範囲を決める権限モードの選び方、日々の操作を短くするスラッシュコマンド12選もご覧ください。

13出典