結論から言うと、Claude Codeで中断した作業に戻る基本操作は2つだけです。直前のセッションに戻るならclaude --continue、過去の一覧から選んで戻るならclaude --resume。ただし再開で戻ってくるのは会話のコンテキストであって、実行状態ではありません。この区別を持たずに「再開すれば全部元通り」と考えると、長時間セッションや無人運用でつまずきます。
この記事では、再開の基本操作から、再開で戻るもの・戻らないものの区別、直近のアップデートで再開まわりの修正が集中している背景、そして「そもそも再開に頼らない」設計判断までを整理します。想定読者は、Claude Codeでの作業が1セッションで終わらなくなってきた方、定時実行や長時間タスクでClaude Codeを回している方です。
再開の基本操作は2つ＋1つ
セッションへの復帰は、ターミナルからなら次の2つです。
# 現在のディレクトリで直近のセッションを再開する
claude --continue
# 過去のセッション一覧から選んで再開する
claude --resume
--continue（短縮形-c）は「さっきの続き」専用です。ターミナルを閉じてしまった、PCを再起動した、といった場面で最短で戻れます。--resume（-r）はセッションの選択画面が開き、同じプロジェクトで並行して進めていた別の作業スレッドへ戻るときに使います。セッションIDが分かっているならclaude --resume <セッションID>で選択画面を飛ばして直接その会話へ戻れます。対話中なら/resumeコマンドで同じ選択画面を開けます。いずれも公式CLIリファレンスに記載のフラグです（2026-09-09確認）。
セッションの履歴はローカルに保存され、作業ディレクトリごとに管理されます。同じリポジトリで--continueすれば、そのリポジトリで最後に動かしていた会話に戻る、という対応関係です。この「過去の会話の続きから再開する」ワークフロー自体も公式ドキュメントのcommon workflowsに一節が割かれています（同日確認）。
もう一つ覚えておきたいのが、非対話モードとの組み合わせです。claude -pによるヘッドレス実行でもセッションは残り、CLIリファレンスにある通りclaude --continue -p "続きの指示"のように非対話のまま前回の続きへ指示を足せます。スクリプトから「前回の続きとして」追加の指示を投げる形が作れるわけです。ヘッドレス運用の全体像は別記事にまとめています。
再開で戻るのは「会話」であって「実行状態」ではない
ここが本題です。再開で戻ってくるものと戻らないものを分けて書きます。
戻るものは会話のコンテキストです。それまでのやり取り、Claudeが読んだファイルの内容についての理解、指示の経緯。つまり「モデルに何を話したか」は保存されています。
戻らないものは、セッションの外側にあった実行状態です。
- 起動していた開発サーバーや、実行中だったプロセス
- シェルの環境変数など、その場限りのシェル状態
- 完了前に中断されたバックグラウンドタスクの実行そのもの
- 中断中に他の誰か（または他のエージェント）が変えたファイルの差分
ファイルはディスクの現状がそのまま使われます。会話が「編集は完了しました」で終わっていても、その後に自分が手で直した分、別ブランチへ切り替えた分は、再開したClaudeの認識と食い違います。再開直後に長い作業を続けるなら、まずgit statusや現状確認をさせてから進めるのが安全です。
なお「会話を戻す」と聞くと/rewindを連想しますが、役割が違います。/rewindは同一セッション内で編集前のチェックポイントへ巻き戻す機能、--resumeは中断したセッション自体へ戻る機能です。巻き戻しで何が戻って何が戻らないかは、こちらで整理しています。
修正が9件重なった2.1.265が示すもの
「再開なんて履歴を読み直すだけでは」と思うかもしれません。実際はかなり難しい問題です。それが分かるのが、2026-09-08のバージョン2.1.265です。公式チェンジログ（2026-09-09確認）を読むと、このリリースだけで中断・再開に関わる項目が9件並んでいます。
Claude Code公式チェンジログRelease notes for Claude Code, including new features, improvements, and bug fixes by version.code.claude.com
主なものを拾うと、こうなります。
- 前のプロセスがツール実行中に落ちた後の再開で、最後のプロンプトを書き換えず、中断されたツール呼び出しを「interrupted」として保持するようになった
- フォアグラウンドで起動したサブエージェントを再開すると、ツール一覧と前置部が変わってプロンプトキャッシュの再利用が壊れていた問題の修正
- コンテナ再起動後のワークフロー再開で、実行記録（run journal）が無い場合に全エージェントを再実行せず、明確なエラーで止まる変更
- 多くのファイルを読んだ長時間セッションの、再開にかかる時間の改善
- バックグラウンド実行のセッションが、アイドルタイムアウト直前に届いたメッセージでターンの途中に終了させられてしまう問題の修正
- VS Code側では、一定期間非アクティブなセッションの自動アーカイブ（既定14日）も入った
個々は細かい修正ですが、並べると論点が浮かびます。中断した瞬間の状態をどう記録するか（interruptedの保持）、再開時に何を同じに保つべきか（前置部とキャッシュ）、記録が無いときに黙って全部やり直してよいか（run journalが無ければエラー）、放置されたセッションをいつ終わらせるか（自動アーカイブ）。「途中で止まった実行を拾い直す」は、それ自体が設計課題だということです。ツール実行の途中でプロセスが落ちる、コンテナごと再起動される——長く回すほど、この種の中断は例外ではなく前提になります。
特に3つ目の変更は姿勢がはっきりしています。記録が無いなら再実行して埋め合わせるのではなく、エラーで止まる。二重実行は「何もしない」より危険な失敗だからです。
無人運用では、再開より「再入できる設計」に寄せる
ここからは私の運用での判断です。私はSNS運用の自動化でClaude Codeの定時実行を毎日回していますが、この構成ではセッション再開を信頼性の仕組みとして使っていません。
理由は前節までの通りで、再開が保証するのは会話の復元までだからです。無人運用で本当に困るのは「会話の続きが分からない」ことではなく、「投稿は済んだのか、済んでいないのか」が分からないことです。これはセッションの外、つまり共有された状態の側で解決する問題で、具体的には処理ステータスを外部のキューに持たせ、claimしてから実行し、結果を書き戻す形にしています。途中で落ちたら、次の実行が同じキューを見て「済んだものはやらない、済んでいないものだけ拾う」。再開ではなく再入です。
AIエージェントの二重投稿を止める排他claim設計｜Notionキューのstatus遷移 実装記録AIエージェントにSNS投稿を任せると、怖いのは投稿しないことではなく二重に投稿することです。行ロックが使えないNotionの投稿キューで、status遷移と「claim→直後再読」の楽観的排他、15分staleルール、あえて自動リトライしない設計をどう組んだか、実運用中の構成をそのまま解説します。www.tentspace.net
整理すると、使い分けはこうなります。
- 対話的な開発作業 →
--continue・--resumeで素直に戻る。会話の文脈こそが資産なので、再開の価値が最大の場面 - 長時間の1セッション → 再開を前提にしつつ、再開直後に現状確認を挟む。会話とディスクの食い違いを最初に潰す
- 無人の定時実行 → 再開に頼らず、処理状態を外部に持たせて再入可能にする。セッションは使い捨てにできる形が理想
逆に言うと、1の用途でわざわざ再入可能な設計を組むのは過剰です。中断・復帰のコストをどこで払うかは、セッションが「人の作業の続き」なのか「システムの実行単位」なのかで決まります。
まとめ
- 中断からの復帰は
claude --continue（直近）とclaude --resume（一覧から選択）、対話中は/resume。セッションはローカルに、作業ディレクトリ単位で保存される - 再開で戻るのは会話のコンテキスト。実行中プロセス、シェル状態、バックグラウンドタスク、中断中のファイル変更は戻らないので、再開直後は現状確認から入る
- 2.1.265では中断・再開まわりの修正が9件重なった。中断時の状態記録、再開時のキャッシュ整合、二重実行の回避は、それ自体が設計課題として扱われている
- 無人運用では再開を信頼性の仕組みにせず、処理状態を外部キューへ持たせて「再入できる」設計に寄せる。再開が活きるのは、会話の文脈が資産になる対話的な作業のほう