Claude Codeのresume使い方｜セッション管理と分岐設計

Claude Codeのセッションは、放っておくと「個人の頭の中」にしか残りません。セッション管理とは、AIとの作業文脈をチームの資産として残す仕組み化の話です。

「昨日の作業の続きをしようとしたが、どのセッションか分からず結局ゼロから説明し直した」「別アプローチを試したいが、今のセッションの流れを壊したくない」「担当者が休むと、そのタスクの経緯が誰にも分からない」——複数のタスクを並行して進めるチームなら、誰もが抱える悩みです。

Claude Codeのセッションとは、一連の会話とその間に行われたファイル変更・コマンド実行を含む作業単位のことです。/resumeで過去セッションを呼び戻し、/branchで現在の文脈を保ったまま分岐させ、/forkで会話をバックグラウンドの新セッションに複製し、/renameで識別しやすい名前を付け、/exportで会話履歴を人が読めるテキストとして書き出す——この5つを運用ルールとして組み込むことで、作業の中断・再開・分岐・共有がシームレスにつながります。

本記事は、Claude Code実践シリーズの一部です。AI活用の全体像はAI活用完全ガイド、コマンドの全体像はClaude Codeチートシートで解説しています。

この記事でわかること

この記事では、Claude Codeのセッションを中断・再開・分岐・共有できる仕組みとして設計する方法を解説します。複数タスクを並行して進める方に向けて、コマンドの使い分けから運用ルールづくりまでを順に整理します。

• /resume・/branch・/fork・/rename・/exportの使い分け — それぞれ「何を残し、何を切り替えるか」が違います。役割を整理すると、使うコマンドが迷わず決まります。
• 起動フラグ（-c・-r・-n・--from-pr）によるセッション制御 — ターミナルから直接セッションを指定できます。--from-prを使うと、特定のPull Requestに紐づいた既存セッションだけに絞ったセッション一覧から再開できます。
• セッション名の命名規則と、チームで引き継げる運用設計 — 命名を個人の裁量に任せず規約にすることで、他のメンバーが一覧を見ただけで中身を推測できる状態をつくります。
• バックグラウンドセッションと/goalを使った並行・自律運用 — 1つのターミナルで切り替える運用から、複数を同時に走らせる運用へ広げる考え方を整理します。
• セッション管理が向かないケースと、その判断基準 — すべてを残せばよいわけではありません。捨てる判断も含めて設計します。

複数タスクを並行して進める方、AI活用をチームの仕組みとして広げたい開発リーダーの方に向けた内容です。最後まで読むと、自社の開発フローに合わせたセッション運用ルールを自分で設計し、明日から回せるようになります。

なぜセッション管理が「個人の効率化」で終わってはいけないのか

セッション管理の話は、多くの場合「再開が楽になる」という個人の時短の文脈で語られます。ただ、AI活用の現場で課題として上がりやすいのは、もう一段手前の問題です。AIとのやり取りの中に、設計判断の理由や試行錯誤の経緯が大量に蓄積されているのに、それがどこにも残らない、という点です。

スプレッドシートでの作業メモ管理が破綻する理由

AI活用を始めたチームでよく見るのが、作業の経緯をスプレッドシートや個人のメモアプリに手で転記する運用です。「どのタスクをどこまで進めたか」「なぜこの実装にしたか」を別の場所に書き写していく形ですが、これは手動更新が前提なので、忙しくなるほど更新が止まります。

結果として、実際の作業履歴（Claude Codeのセッション）とメモの内容に差分が生まれ、どちらが正なのか分からなくなります。転記の手間をなくし、作業した記録そのものを正とする形に寄せるのが出発点になると考えています。

「あの人に聞かないと分からない」を減らす

セッションに名前が付いておらず、/resumeの一覧が日時とディレクトリだけで並んでいる状態は、担当者本人にしか読み解けません。担当者が不在のとき、あるいは異動したとき、そのタスクの経緯はほぼ失われます。

ここは人の記憶力や几帳面さの問題ではなく、仕組みの問題として扱うのが実際的です。命名規約を決め、区切りで/exportを回す運用にしておけば、誰が担当しても同じ粒度の記録が残ります。属人的な「メモを取るのが上手い人」に依存しない状態をつくることが、セッション管理を設計する本来の目的です。

個人の時短から、チームの再現性へ

とはいえ、いきなり全社ルールを作る必要はありません。まずは自分ひとりのセッションで/renameを使う習慣を付け、それが回るようになってからチームの規約に上げる、という順番が現実的です。段階の踏み方は本記事の後半で整理します。

セッション管理コマンドの全体像

Claude Codeのセッション管理は、大きく「再開する」「分ける」「識別する」「持ち出す」「捨てる」の5つの動作に分解できます。まずはコマンドがどの動作に属するかを押さえると、場面ごとの選択が早くなります。

5つの動作とコマンドの対応

「分ける」の2つは目的が違う

/branchと/forkはどちらも会話を分けますが、分けた後に自分がどちらにいるかが違います。/branchは自分が分岐先へ移り、/forkは自分が手元に残ります。この違いを取り違えると、意図せず元の文脈を離れてしまうので、最初に整理しておくのがポイントになります。

下の画面は、本記事で扱う主なコマンドとフラグを一覧にしたものです。/resume・/branch・/fork・/renameといったスラッシュコマンドと、claude -r・claude --resume SESSION_ID・claude -n "auth-refactor"・claude --from-pr 123といった起動時のコマンドが並んでいます。

以下の画面は、Claude Codeのセッション管理コマンドとフラグの一覧です。

コマンド単体ではなく流れで捉える

セッション管理コマンドは、単体で使うより「開始→作業→分岐→区切り→中断→再開→完了」という一連の流れの中に置くと意味がはっきりします。本記事の後半では、この流れをライフサイクルの表として整理します。個別のコマンドを覚えるより、自分の作業フローのどこにどのコマンドを置くかを決めるほうが、運用に乗りやすくなると考えています。

/resume — セッションの再開と、翌日への引き継ぎ

/resumeはセッション管理の入口になるコマンドです。過去のセッションを一覧から選んで、会話の文脈ごと作業を再開できます。ここでは基本操作と、起動時フラグでの再開、そして「何が復元されて何が復元されないか」を押さえます。

基本的な使い方

/resume

/resumeを実行すると、過去のセッション一覧が表示されます。各セッションには作業ディレクトリ、最後の操作日時、セッション名（設定されている場合）が表示され、選択するとそのセッションの続きから作業を再開できます。

起動時フラグでの再開

Claude Codeの起動時にフラグを渡して、再開するセッションを指定することもできます。

# セッション一覧から選んで再開（引数なしの--resume）
claude --resume

# セッション一覧から選んで再開（-rはresumeの短縮形）
claude -r

# 特定のセッションIDを指定して再開
claude --resume SESSION_ID

# 直前のセッションを続行（対話なしで即再開）
claude -c "前回の続きをお願い"

下の画面は、claude --helpの出力から--resume・--from-pr・agentsの説明行を抜き出したものです。フラグの正式な説明は、記事の情報ではなく手元のヘルプで確認するのが確実です。

以下の画面は、claude --help から resume・from-pr・agentsの説明行を抜き出した出力です。

復元される情報とされない情報

/resumeは万能ではありません。会話の文脈は戻りますが、実行環境まで丸ごと戻るわけではない点は理解しておく必要があります。

ただし、ファイルの実際の内容は「現時点の状態」である点に注意が必要です。中断中に他のメンバーがそのファイルを変更していれば、会話履歴が語る前提と実ファイルがずれます。再開直後に差分を確認する一手間を運用に入れておくと、この食い違いによる手戻りを避けられます。（出典: Manage sessions、2026年10月24日確認）

翌日への引き継ぎ手順

1日の作業を翌日に引き継ぐ流れは、コマンドを個別に覚えるより、手順として持っておくと運用しやすいです。

1. 作業終了時に/renameで名前をつける（例：0315-feature-auth）
2. ターミナルを閉じる（セッションは自動保存）
3. 翌日claude -rでセッション一覧を表示
4. 0315-feature-authを選択して作業再開
5. 「昨日の続きで、テストコードを書いて」と指示

差が出るのは作業そのものより「作業を始めるまで」の時間です。

/branch と /fork — 会話の分岐と複製

分岐は、AI活用で最も価値が出る操作の一つです。人間が「Aで進めるかBで進めるか」を迷ったとき、両方を実際に作って比べられるからです。ここでは2つのコマンドの違いと、分岐が有効な場面を整理します。

仕様変更の注意（重要）: /forkはv2.1.212で意味が変わりました。会話を分岐して自分がその分岐先で作業したい場合は/branchを使います。 現在の/forkは「現在の会話をバックグラウンドの新セッションに複製し、自分は手元のセッションで作業を続ける」コマンドで、複製側はエージェントビューに独立した行として並びます。v2.1.211以前の/forkはforkされたサブエージェントを起動する挙動でした。（出典: Commands reference、2026年8月1日確認）

基本的な使い方

# 会話をこの時点で分岐し、自分が分岐先に移る
/branch [名前]

# 会話をバックグラウンドの新セッションに複製し、手元はそのまま作業を続ける
/fork [プロンプト]

/branchを実行すると、現在の会話がこの時点で分岐し、自分は分岐側に切り替わります。元の会話は保持され、/resumeで戻れます。/forkを実行すると、現在の会話を丸ごとコピーしたセッションがバックグラウンドで動き出します。プロンプトを添えるとその作業をすぐ始め、添えなければエージェントビューで最初の指示を待ちます。

分岐が有効な場面

設計の代替案を検討するとき

Aパターンの実装をある程度進めた段階で「Bパターンも試したい」と思った場合、/branchで分岐すれば、Aパターンの会話の流れを失わずにBパターンを試せます。なお、分岐するのは会話であって、ファイルは分岐も隔離もされません。両案のファイル変更を分けて試したいときは、Gitのブランチやworktree、コミットを併用します。

# 元のセッションでAパターンを実装中
> REST APIで認証機能を実装して
...（実装完了）

# ここで/branchして分岐
/branch graphql-jwt

# 新セッションで別案を試す
> やっぱりGraphQL + JWTで認証を実装して

破壊的な変更を試すとき

大規模なリファクタリングや依存関係の更新など、元に戻すのが大変な変更を試す場合、/branchで会話の流れを残したまま別の進め方を試せます。元の会話は残るため、うまくいかなければ/resumeで会話に戻れます。ただし/branchと/resumeが戻すのは会話であり、ファイルの変更は元に戻りません。ファイルへの変更を安全に試すなら、Gitのworktreeやコミットを先に用意するか、/rewindのチェックポイントを使います。

/branchと/rewindの使い分け

分岐と巻き戻しは似て見えますが、「元の作業を残すかどうか」で判断が分かれます。

/rewindのチェックポイントが追うのはClaudeによるファイル編集です。公式ドキュメントによると、Claudeが編集ツールで一度編集したファイルであれば、その後にBashコマンドが加えた変更も/rewindで戻せます。一方、Bashコマンドだけで変更したファイルは追跡されず、そのまま残ります。そうしたファイルはGitなどのバージョン管理で戻します。ここは/branchとの使い分けで押さえておく点です。/rewindについては/rewindコマンドガイドで詳しく解説しています。

ただし、分岐を増やしすぎると一覧が読めなくなります。比較のために分岐したなら、比較が終わった時点でどちらを採ったかを決め、採らなかった側は/exportで判断の記録だけ残して一覧から意識的に外す、という運用にしておくのが実際的です。

/rename と /export — 識別と持ち出しを仕組みにする

/renameと/exportは、地味ですがチーム運用では最も効く2つです。前者は「後から探せる状態」を、後者は「本人がいなくても読める状態」をつくります。どちらも個人の心がけではなく、規約として決めてしまうのがポイントになります。

/rename — セッションの命名

/rename セッション名

現在のセッションに任意の名前をつけます。/resumeでセッション一覧を表示した際に名前が表示されるため、目的のセッションを素早く見つけられます。

セッション名を体系的につけておくと、後から探しやすくなります。

どのパターンが適切かは、チームの管理方法によって変わります。チケット管理ツールを中心に運用しているならチケット番号型が自然ですし、受託開発で顧客ごとにリポジトリが分かれているなら顧客名+タスク型のほうが探しやすくなります。企業様によって最適な形は異なりますので、既存の管理単位に合わせて1つ選ぶのが失敗しない決め方だと考えています。

起動時のセッション命名

# 名前を指定してセッション開始
claude -n "auth-refactor"

-nフラグで起動時にセッション名を設定できます。作業開始前にセッション名を決めておくことで、後から/renameする手間を省けます。命名を「作業後の整理タスク」ではなく「作業開始の儀式」にしてしまうほうが、運用として定着しやすくなります。

/export — 会話のエクスポート

/export

現在の会話を、メッセージとツールの出力を人が読めるテキストにして書き出します。引数なしで実行すると、クリップボードへのコピーかファイルへの保存を選ぶ画面が開きます。/export ファイル名のようにファイル名を渡すと、選択画面を省いてそのファイルへ直接書き込みます。作業記録の保存、チームメンバーへの共有、ドキュメント化に活用できます。活用場面は、技術的な意思決定の記録、コードレビューの補足資料、複雑な問題解決の過程をチームに共有するナレッジ共有の3つが中心です。

ただし、エクスポートしたテキストは会話がそのまま出るため分量が多くなります。すべてのセッションを書き出すと読まれない資料が積み上がるだけなので、「設計判断が発生したセッションだけ出す」といった基準を先に決めておくほうが実用的です。

複数タスクの並行管理

セッション名をつけておくと、複数タスクの切り替えが迅速になります。例えばフロントエンドのバグ修正とバックエンドのAPI追加を並行して進めたい場合、次の手順が組めます。

1. バグ修正用セッションを開始: claude -n "bugfix-login-form"
2. 修正作業を進めた後、一旦中断
3. API追加用セッションを開始: claude -n "feature-user-api"
4. API実装を進めた後、バグ修正に戻る: claude -r → bugfix-login-formを選択

--from-prでPRに紐づいたセッションを探して再開する

--from-prは、PRの内容を読み込むためのフラグではありません。特定のPull Requestに紐づいた既存セッションだけに絞ってセッション一覧を開き、その続きから作業を再開するためのフラグです。コードレビューの指摘対応のように、PRごとに文脈が積み上がる作業に効きます。

基本的な使い方

claude --from-pr 123

PR番号、またはGitHub・GitHub Enterprise・GitLab・BitbucketのPR（マージリクエスト）のURLを指定します。セッションとPRの紐づけは、ClaudeがPRを作成したときに自動で行われます。つまり、そのPRをClaudeで作ったセッションがあれば、そのセッションを一覧から選んで再開できます。

PR作成からレビュー対応までを同じ文脈でつなぐ

1. ClaudeでPRを作成する（このとき、セッションがPRに自動で紐づく）
2. レビューの指摘を受けたら、claude --from-pr 456でそのPRに紐づくセッションの一覧を開く
3. 該当セッションを選んで再開し、「レビューで指摘された問題を修正して」と指示
4. 修正が完了したらgit pushでPRを更新
5. /rename pr-456-review-fixで記録

PRを作ったときの会話がそのまま残るため、なぜその実装にしたのかを説明し直す必要がありません。レビューの指摘と修正内容が同じ会話に並ぶので、後から「なぜこう直したか」を追いやすくなる点も実務上は大きいところです。

AIに任せる範囲と人が判断する範囲

ここで整理しておきたいのが役割分担です。PRレビューをAIに通すと指摘は大量に出ますが、すべてをそのまま採用するのは適切ではありません。

AIは優秀なレビュー補助ですが、最終的に何をマージするかの判断は人が持つ前提で組むのが安全です。特に影響範囲の大きい変更は、AIの指摘を参考情報として扱い、人のレビューを省略しない運用にしておくべきだと考えています。

Agent viewとバックグラウンドセッションで並行管理する

ここまでは「1つのターミナルでセッションを切り替える」前提の運用でした。2026年10月時点では、セッションをバックグラウンドへ逃がして一覧で管理する経路が加わっています。/forkで複製したセッションが並ぶのも、この一覧です。Agent viewは公式ドキュメント上、research previewの機能です。

claude agentsでセッションを一覧する

Agent viewは、動いているセッションを1画面にまとめるダッシュボードです。実行中・入力待ち・完了が並び、行を選べばそのセッションの会話にそのまま入れます。

claude --bgで起動したバックグラウンドセッションは、v2.1.144以降/resumeの一覧からも再開できます。前述のバグ修正とAPI追加を行き来する運用は、2本を別々のバックグラウンドセッションとして起動し、Agent viewで状態を見ながら必要な方にアタッチする形にも置き換えられます。

バックグラウンドセッションの隔離とworktree

claude --bgやエージェントビューから新しく起動したバックグラウンドセッションは、ファイルを編集する前に.claude/worktrees/配下のgit worktreeへ移るため、同じリポジトリで2本走らせても手元の作業ツリーが混ざりません。並行実行を仕組みとして安全に回すための設計です。

ただし、開いていたセッションを/backgroundや←で後からバックグラウンドへ移した場合は隔離されず、それまでと同じ作業ツリーを編集し続けます。ほかにも、すでにリンクされたworktreeの中で動いている場合、作業ディレクトリがgitリポジトリでなくWorktreeCreateフックも設定していない場合、作業ディレクトリの外への書き込みは隔離されません。2本を並行で走らせたいときは、2本目をclaude --bgで新しく起動するのが確実です。（出典: Agent view、2026年10月24日確認）

スーパーバイザによる永続化

これらのセッションはユーザーごとの別プロセス（スーパーバイザ）が管理し、ターミナルを閉じても、スーパーバイザの再起動やマシンのスリープを跨いでも生き残ります。ただしマシンのシャットダウン（再起動を含む）では実行中のセッションは止まります。その場合は、保存された会話から再開します。機能ごと止めたい場合はsettings.jsonに"disableAgentView": trueを書きます。（出典: Agent view、2026年8月1日確認）

/goalとauto modeで離席中も完了条件まで進める

セッションを長く走らせるときに効くのが/goalです。完了条件を設定すると、条件が成立するまでターンを跨いで作業を続け、成立した時点で自動的に停止します。ただしこれは権限設定を変えるものではないため、無人運用では、auto modeか事前の許可ルール（permissionsのallow）といった、確認なしで実行できる権限の備えが別途必要になります。

/goalで完了条件を決めてから離席する

# 完了条件を設定する
/goal npm test が全て通り、型エラーが0件になるまで続ける

# 現在の状態（条件・経過時間・評価済みターン数・トークン消費）を確認する
/goal

# 解除する
/goal clear

各ターンの終了後に、小型の高速モデルが条件成立を判定する仕組みです。判定役は会話にすでに出ている内容だけで成否を判断し、自分ではツールを呼びません。条件は「Claudeの出力で証明できる形」で書く必要があります。

未達成のゴールの復元と判定の仕組み

未達成のゴールは--resume/--continueでセッションを再開したときに復元されます（条件は引き継がれますが、ターン数・時間・トークンの基準はリセットされます）。/resumeを軸にした本記事の運用と、そのまま噛み合う挙動です。利用にはClaude Code v2.1.139以降が必要で、ワークスペースの信頼ダイアログを承認済みであることが前提です（判定の仕組みがhooks機構の一部のため、disableAllHooksを設定していると利用できません）。条件の書き方や実行回数の制限のかけ方は/goalコマンドで条件達成まで自律実行させる方法で解説しています。（出典: Goals、2026年8月1日確認）

Auto modeを併用して確認待ちで止まらないようにする

Manualモード（設定値はdefault）は、読み取りだけが確認なしで実行できるモードです。なお現行の対話型CLI（v2.1.283以降）は、claude -pでの実行やdisableAutoModeの設定などに当たらなければ、auto modeで開始します（auto modeが使えない環境ではManualで開始）。ファイル編集やシェルコマンドなどには確認が入るため、事前の許可ルール（permissionsのallow）で許可していない操作があると、離席している間に止まってしまいます。許可ルールを網羅的に用意する代わりに、auto modeと併用する方法もあります。auto modeは許可の判断を分類器モデルに任せ、安全な操作は中断なく実行し、危険な操作はブロックする権限モードです。

押さえておきたい仕様と注意点

• 以前はBedrock・Vertex AI・FoundryでCLAUDE_CODE_ENABLE_AUTO_MODE=1の指定が必要でしたが、v2.1.207以降は指定なしで使えます。止めたい場合は設定のdisableAutoModeを使います。2026年10月時点の公式ドキュメントでも、auto modeはすべてのプロバイダーで利用できると案内されています
• 対象は全プランで、Proでも利用できます
• 分類器が3回連続、または通算20回ブロックするとauto modeは一時停止し、通常の許可プロンプトに戻ります。この閾値は設定で変更できません

権限モード「default」の表示名はv2.1.200で「Manual」に変わりました。設定値はdefaultのままですが、CLIはmanualもエイリアスとして受理します。（出典: Permission modes / CHANGELOG 2.1.200、2026年10月24日確認）

バックグラウンド実行と自律実行は、影響範囲が読めるタスクに限るのが安全です。本番環境に触れる操作や、仕様の解釈が割れる実装は、手元のセッションで確認しながら進める前提にしておくべきだと考えています。

チームで回るセッション運用と、向かないケースの見極め

ここからは、個人の使い方をチームの仕組みに上げる段階の話です。決める項目は、命名規約・記録を残す基準・広げる順番の3つです。これらを決めてしまえば、あとは各自の作業に委ねる形で回り始めます。あわせて、セッション管理を持ち込まないほうがよい場面も正直に整理しておきます。

命名規約をチームで統一する

チームでClaude Codeを使う場合、セッション名の命名規則を揃えておくと運用がスムーズです。フォーマットを1つ決め、CLAUDE.mdに書いてリポジトリで共有するのが手堅い方法です。

[日付]-[タスク種別]-[対象]
例: 0315-fix-auth, 0316-feat-api, 0317-review-pr42

規約を「推奨」ではなく「デフォルト」にするために、カスタムコマンドのプロンプト内に命名ルールを埋め込んでおく手もあります。カスタムコマンドに「作業完了時にセッション名を規約に沿って更新する」指示を入れておけば、人が覚えていなくても命名が揃います。命名規約を仕組みとして定めておけば、新しく担当になったメンバーでも同じ手順でセッションを引き継げます。人の努力ではなく仕組みで揃える、という発想です。

こうしたClaude Codeの活用に関心のある方は、経営データの可視化やコンテンツマーケティングの効率化もぜひご覧ください。

セッションのライフサイクルを意識する

個別コマンドではなく、開始から完了までの流れとして押さえると運用に落としやすくなります。長くなったセッションは、作業の区切りごとに/compactで要約し、コンテキストを軽量化する習慣をつけてください。区切りの定義もチームで揃えておくと、「1機能の実装が終わったら/compact」のように判断が迷いません。

この表をそのまま使う必要はありません。自社の開発フローに合わせて、使わないフェーズは削って構いません。大事なのは「開始時に名前を付ける」「完了時に記録を残す」の2点を外さないことです。

残さないほうがよいケースと、段階的な広げ方

すべてのタスクをセッション管理の対象にすると、かえって一覧が読めなくなります。正直なところ、向かない場面もあります。

特に4つ目は実務で起きやすい落とし穴です。会話履歴は戻っても、その間に他のメンバーが同じファイルを変更していれば前提が崩れます。「1週間以上空いたセッションは再開せず新規に立てる」といった目安をチームで決めておくと、無駄な手戻りを避けられます。

いきなり全部をやろうとすると続きません。次の順番で段階を踏むのが現実的です。

まずは第1段階の「名前を付ける」だけから始めて、続いたら次に進むという形で段階的に広げていただければと思います。第4段階の並行実行は、その前段が安定していないと管理しきれなくなるため、順番を飛ばさないのがポイントになります。/resumeで前日のセッションを再開した後、今日のタスクに合わせてモデルを切り替える運用はモデル選択とeffort設定ガイドで解説しています。

よくある質問

Q1. セッションの保存期間に上限はありますか？

Claude Codeのセッション履歴はローカルに保存されます。ただし永久には残りません。履歴（トランスクリプト）には保持期間があり、既定は30日で、それを過ぎて使っていないセッションはバックグラウンドの整理で自動的に削除され、/resumeの一覧にも出なくなります。保持期間はsettings.jsonのcleanupPeriodDaysで変更できます。長く残したい記録は、/exportでテキストとして保存しておくのが確実です。また、セッション数が増えると一覧の視認性が下がるため、完了したタスクのセッションは定期的に整理するのが実用的です。整理の頻度は、週次の振り返りのタイミングに合わせると習慣化しやすくなります。

Q2. /branchで分岐した後、元の会話に戻れますか？

戻れます。/branchで分岐しても元の会話は保持されるため、/resumeで元の会話を選択すれば分岐前の会話から作業を継続できます。分岐先と元の会話の両方を行き来することも可能です。ただし戻るのは会話であり、ファイルの変更は元に戻りません。ファイルも戻したい場合は、Gitのコミットやworktree、/rewindのチェックポイントを併用してください。なお/forkの場合は、複製されたセッションがバックグラウンドで独立して動き、手元のセッションはそのまま残ります。

Q3. チームメンバーとセッションを共有できますか？

セッション自体をメンバー間で直接共有する機能はありません（Remote Controlで手元のセッションをclaude.ai/codeやモバイルアプリから続けられますが、動くのは手元のマシンで、同じ人が別の画面から操作する用途です。teleportはクラウドのセッションを手元に持ってくる機能です）。チームで引き継ぐ手段としては、/exportで会話履歴を人が読めるテキストとして書き出し、それを共有することは可能です。また、カスタムコマンドやCLAUDE.mdをGitリポジトリで共有すれば、チーム全員が同じ設定・コマンド体系で作業できます。共有の対象は全セッションではなく、設計判断が発生したものに絞るほうが読まれる記録になります。

Q4. セッションが重くなったときの対処法はありますか？

長いセッションはコンテキストウィンドウを圧迫し、応答品質の低下や速度低下を引き起こします。/compactで会話を要約するか、/clearで完全にリセットして新しいセッションを開始してください。作業の区切りごとに/compactを実行する習慣をつけるのが有効です。

Q5. 非エンジニアのメンバーにも同じ運用を求めるべきですか？

同じ粒度を求める必要はないと考えています。命名規約のように全員で揃えると効果が出るものと、/goalやバックグラウンド実行のように使う人が限られるものがあります。まずは開発チーム内で運用を固め、他部門に広げるかどうかはその後に判断するほうが現実的です。

まとめ

Claude Codeのセッション管理は、単なる再開機能ではなく、AIとの作業文脈をチームの資産として残すための仕組みです。本記事の要点を整理します。

• セッション管理コマンドは「再開する（/resume）」「分ける（/branch・/fork）」「識別する（/rename）」「持ち出す（/export）」「捨てる（/clear）」の5つの動作に分解して捉える
• 会話の分岐は/forkではなく/branch。/forkは複製側をバックグラウンドに置き、自分は手元に残る
• /resumeは会話履歴と参照情報を復元するが、ファイルの実内容は現時点の状態。再開直後の差分確認を運用に入れる
• 起動時の-c・-r・-nと--from-prを組み合わせれば、ターミナル操作だけでセッションを制御できる
• 命名を個人の心がけではなく規約とカスタムコマンドで仕組み化すると、担当者が変わっても同じ記録が残る

まずは次の作業開始時にclaude -n "タスク名"で名前をつけて始めるところから試すのがおすすめです。次の3ステップで進められます。

1. 今週中: 自分のセッションに-nで名前を付ける習慣を付け、claude -rで一覧が読める状態になるか確かめる
2. 今月中: チームで命名フォーマットを1つ決め、CLAUDE.mdに記載してリポジトリで共有する
3. 定着後: 設計判断が発生したセッションを/exportして共有し、必要に応じてバックグラウンド実行へ広げる

なお、最適な運用はチームの規模や開発フローによって異なります。既存のチケット管理やレビュー体制に合わせて、無理なく回る形に調整していただければと思います。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Code Agent Teamsの使い方｜複数AIエージェントをチームで協働させる方法
• Claude Code × VS Code / JetBrains連携｜IDEとターミナルの最適な使い分け
• Claude Code vs Cowork｜開発者と業務担当者で異なるAIツールの選び方