Claude Codeのresumeとforkの違い — フォークの意味と使い分け

Claude Codeのresumeとforkは何が違うか

claude --continueやclaude --resumeで行う再開(resume)は、同じセッションIDのまま会話に新しいメッセージを積み重ねます。一方--fork-sessionや/branchで行うフォーク(fork)は、そこまでの会話を新しいセッションIDへコピーします。元のセッションは、コピーが作られた時点のまま手つかずで残ります。

違いは、後から元の会話に手が入るかどうかです。forkなら元の会話を凍結したまま別の枝で作業でき、resumeでは元の会話そのものが書き換わり続けます。

本記事はresumeとforkの正面比較に絞ります。/branch単体の操作手順やチェックポイントとの違いはセッションブランチの記事に、/branchコマンド自体の詳細仕様はClaude Code branchコマンドの記事にあります。

フォークとは何か、「ここからフォーク」は何をするのか

フォーク(fork)とは、今の会話を新しいセッションIDにコピーして、枝分かれさせることです。「フォークされたセッション」は、このコピー側を指します。

VS Code拡張では、メッセージにカーソルを重ねると出る巻き戻しボタンから、フォークを選べます。選択肢は3つです。

ターミナルでは、/branchかclaude --continue --fork-sessionが同じ役割です。違うのは起点で、/branchは今の時点、VS Codeの「ここからフォーク」は選んだメッセージです。

claude resumeではなくclaude --resumeで再開する

CLIリファレンスのコマンド表に、サブコマンドとしてのclaude resumeは載っていません。再開は、フラグのclaude --resume(短縮形-r)か、セッション内の/resumeで行います。引数なしならセッションのピッカーが開き、IDか名前を渡せばその会話に戻ります。

claude --resume
claude --resume auth-refactor

実機のヘルプでは2つのフラグはどう書かれているか

v2.1.287のclaude --helpでは、再開系のフラグが次の文言で並んでいます(抜粋、日本語は筆者の訳)。

注目したいのは、--fork-sessionに単独で使える場面が書かれていない点です。「再開時に」という前置きどおり、--continueか--resumeに付けて初めて意味を持つ修飾子です。CLIの上では、resumeとforkは別々の機能ではありません。「元のIDを使い回すか、新しいIDを払い出すか」というスイッチ1つの差として現れます。

--no-session-persistenceも見落としやすい行です。保存されないセッションは、resumeでもforkでも起点にできません。

何も指定しない新規セッションは何も引き継がない

Claude Codeは各セッションを個別に保存し、新しいセッションは前のセッションの会話履歴を持たずに始まります。学習内容を持ち越したいときは、auto memoryかCLAUDE.mdに明示的に書く必要があります。

resumeとforkは、この独立性に対する2通りの例外です。resumeは同じセッションIDへ戻ることで会話の独立性を解除し、forkは新しいIDを作りながら、起点の会話だけをコピーで持ち込みます。

resumeが復元するもの・しないもの

claude --resumeで再開したセッションは、会話履歴に加えて終了時点の状態の一部を復元します。

• 会話履歴: ツール呼び出しと結果を含む全履歴。クラッシュなどで実行中だった呼び出しは再実行されず、Claudeには「結果が記録される前に切れた呼び出し」として見えます
• モデル: 使っていたモデルで続きます。モデルが廃止済み・availableModelsで許可されていない・起動時に--modelなどで指定した場合は復元されません
• エージェント: --agentで始めたセッションは同じエージェントで続きます
• 権限モード: 条件付きで復元されます(次節)
• アクティブなgoal: 終了時にアクティブだったgoalは引き継がれ、ターン数・タイマー・トークン消費の基準値はリセットされます

起動時の構成フラグは復元されません。--mcp-config・--settings・--plugin-dir・--fallback-model・--add-dirで足したディレクトリは、再開時に渡し直します。/add-dirで途中から足したディレクトリも戻りません。settings.jsonやsettings.local.jsonは起動のたびに読み直されるので、そこに書いた設定は渡し直し不要です。復元項目の全体は/resumeコマンドの記事にまとめています。

権限モードは再開の入口で変わる

「resumeは権限モードまで戻す」は半分しか正しくありません。復元されるかどうかは、再開の入口で決まります。

自動承認寄りのモードで作業していたセッションをピッカーから開いたら、いつもの確認が戻って面食らう、という挙動の理由がここにあります。復元させたいときは、IDか一意な名前を直接渡して再開します。ただしbypassPermissionsはこの経路でも戻らないので、起動フラグかpermissions.defaultModeで指定し直します。逆に、復元されたモードを上書きしたいときは--permission-modeか--dangerously-skip-permissionsを付けます。

--continueと--resumeの選び方

--continueは現在のディレクトリの直近の会話を開き、--resumeはピッカーかIDで選びます。--resume <name>は、名前が完全一致すればその場で再開し、あいまいならピッカーに名前を検索語として入れた状態で開きます。

--continueが拾わない会話があります。claude -pやAgent SDKで作ったセッションと、最初のプロンプトが/loopだったセッションは、ピッカーにも--continueにも出てきません。IDを渡せば再開でき、claude -p --continueならこれらも対象に含まれます。「直前まで使っていたはずの会話が出てこない」ときは、まずこの除外条件を疑ってください。v2.1.211より前は、会話の早い段階で/loopを1回使っただけで、そのセッションがピッカーから恒久的に消える不具合がありました。

名前を付けていないセッションの既定の表示名(my-app-3fのような作業ディレクトリ名+2文字)は再開の手がかりになりません。claude --resume my-app-3fでは見つからず、AI生成のタイトルか自分で付けた名前が必要です。

他の端末や場所から再開したいとき

claude --resume <session-id>は、どのディレクトリからでも実行できます。まず現在のプロジェクトとそのワークツリーを探し、見つからなければマシン上の他のプロジェクトを探します(v2.1.223以降。それより前はセッションが最後に作業していたディレクトリまで戻る必要がありました)。

ただし横断検索には条件があります。他のプロジェクトのうち、そのIDのメッセージ入りトランスクリプトを持つのがちょうど1つのときだけIDが解決されます。トランスクリプトを手でコピーして複製が増えていると、Claude Codeは適当な1本を選ばず、見つからないと報告します。IDに一致するセッションがどこにも無いときは、次の文言が出ます。

No conversation found with session ID: <session-id>

コピーで退避した.jsonlが原因で再開できなくなるのは、この仕様のためです。対処としては、claude --resume <transcript-path>のように.jsonlトランスクリプトファイルの絶対パスを渡すと、そのファイルに保存された会話を再開できます。

元のプロジェクトが消えている場合の挙動は、選び方で変わります。ピッカーから他のワークツリーのセッションを選ぶとその場で再開し、セッションのワークツリーがなくなっていれば今のディレクトリで再開します。無関係なプロジェクトのセッションを選んだときはcd付きの再開コマンドがクリップボードにコピーされ、そのディレクトリ自体がなければ今のディレクトリで再開します。

forkが引き継ぐもの・独立するもの

/branchを実行すると、その時点までの会話履歴が新しいセッションIDにコピーされ、実行中のプロセスがコピー側へ切り替わります。CLIの--fork-sessionでは、新しいプロセスがコピーから始まります。元のセッションはディスク上に残り、/resume <元の名前>でいつでも戻れます。

何が引き継がれるかは、プロセスが同じかどうかで分かれます。

フォークは、今の会話を枝分かれさせて枝の側に自分が乗り移る操作です。乗り移った後は、元の幹で何が起きても気づけません。分岐後の状態はセッションブランチの記事の「ブランチ後に何が引き継がれ、何が引き継がれないか」でも別角度から扱っています。

同じ「引き継ぎ」でも、resumeと--fork-sessionの組み合わせでは権限の持ち越しが逆転します。/branchは同じプロセスなので承認済みの許可が残り、claude --resume <id> --fork-sessionは新しいプロセスで始まるので許可が空になります。--fork-sessionを使うスクリプトでは、この差を前提に承認の取り直しを見込む必要があります。

状況別に選ぶ

中断した作業の続きを書きたい

claude --continue(直近の1本)かclaude --resume(選んで再開)を使います。同じセッションIDのまま履歴に追記されるので、続きが1本の会話に収まります。

別のアプローチを試し、ダメなら元に戻りたい

/branch <名前>でコピー側に移り、試して、ダメなら/resume <元の名前>で戻ります。コマンドラインから同じことをするなら次の形です。

claude --continue --fork-session

名前を省略すると、最初のプロンプトから自動で名前が付きます。コンパクション後はコンパクション前の最初のプロンプトが使われます(v2.1.198以降。それより前は固定名のBranched conversationになりました)。/branchの確認メッセージには、新しいセッションIDと元のセッションIDの両方が表示されます。

起動時フラグを変えて同じ会話を続けたい

--continueか--resumeにフラグを渡し直します。構成フラグは復元されないので、--mcp-configなどは毎回指定が必要です。

今の会話を止めずに副次タスクだけ任せたい

これは/forkの守備範囲です。--fork-sessionや/branchは自分がコピー側へ移るため、元の会話に残ったまま裏で動かしたい用途には向きません。

バックグラウンドで動いているセッションをresumeしたとき

再開しようとしたセッションが、バックグラウンドセッションとしてまだ動いている場合、挙動が変わります。v2.1.285より前は拒否されましたが、現在はclaude --resumeや/resumeで、動いているセッション自体を開きます。

--continueは、終わったバックグラウンドセッションは開きますが、動いているものは開きません(終わったものを開くにはv2.1.257以降)。直近の会話が動作中のバックグラウンドセッションだと、次の文言とセッションIDを出して終了します。

Your most recent conversation is running in the background

--bgと--resume <session-id>の組み合わせは、ヘルプ上、同じIDで続きをバックグラウンドへ送るか、すでに動いている場合はコピーを始めて、その旨を表示すると説明されています。

長時間放置した会話を再開するときだけ出るダイアログ

Pro・Maxプランで、約1時間以上操作がなく10万トークンを超えるセッションを再開すると、復元のあと最初のメッセージを送る前にダイアログが開きます。プロンプトキャッシュが失効しているため、どの選択肢でも次のリクエストは全履歴を一度処理し直します。

選択肢は3つあります。

• Resume from summary: /compactをすぐ実行します。全履歴の要約を1回送り、履歴を要約・直近のやり取り・最近読んだ最大5ファイルに置き換えます
• Resume full session as-is: 会話をそのまま読み込みます。最初のメッセージで全履歴を処理し直してキャッシュし直し、キャッシュが温かい間はそこから読みます
• Don't ask me again: 全履歴のまま再開し、以後のresumeでダイアログを出さなくします

このダイアログはresume固有の挙動で、/branchのように会話の途中で実行するコマンドには当てはまりません。

resumeとforkに関わる仕様変更

セッションの命名・検索まわりは、複数バージョンにまたがって整備されてきました。

フォークしたセッションはピッカーにどう並ぶか

/branchや--fork-sessionで作ったセッションはコピー元と別のIDを持つので、/resumeのピッカーに別の行として出ます。同じセッションについて複数のエントリが見つかると1行にグループ化され、→キーで展開できます。ピッカーではCtrl+Bで現在のgitブランチのセッションに絞れ、Ctrl+Aで全プロジェクトに広げると各セッションのプロジェクトパスも見えます。

同じセッションを2つのターミナルで開いたときの落とし穴

フォークせずに同じセッションを2つのターミナルから再開すると、両方からのメッセージが1本のトランスクリプトに交互に書き込まれます。片方が編集中のファイルをもう片方が知らずに触る、といった競合も起こりえます。ピッカー上での見え方は、セッションブランチの記事の「分岐せずに同じセッションを2つの端末で開くとどうなるか」にあります。

並行して2本走らせたいなら、2つ目は--fork-session付きで開きます。

forkとworktreeは分離する対象が違う

並行作業の分離方法としてforkとよく並べて語られるのがgit worktreeですが、分離するものは別のレイヤーです。forkが分離するのは会話(セッションID)で、作業ディレクトリは元のセッションと同じままです。worktreeが分離するのはディレクトリそのもので、ブランチごとに別々のチェックアウトを用意し、それぞれで独立したセッションを走らせます。

Claude Codeのセッションは作業ディレクトリに紐づきます。同じディレクトリのままgitブランチを切り替えると、Claudeが見るファイルは新しいブランチのものに変わりますが、会話履歴は変わりません。ディレクトリを分けない限り、forkしたコピー側も元のセッションと同じ作業ツリーを見ます。ファイル変更を伴う並行作業を分離したいなら、forkによる会話の分岐とworktreeによるディレクトリの分離を組み合わせる形になります。

まとめ

IDの扱いの違いより実務で効くのは、再開の入口で権限モードの復元が変わる点と、--fork-sessionが別プロセスなので許可の持ち越しが切れる点です。再開できない・出てこないときは、-pや/loopで作った会話の除外、--add-dirなど渡し直しが必要なフラグ、手でコピーした複製の3つを順に疑うと、原因に当たりやすくなります。