最近まで、私はClaude Codeのセッションを一切区切らずに使っていた。朝一のバグ調査からそのまま新機能の実装に入り、途中でレビュー指摘の対応まで同じ会話に混ぜ込む。気づけば1つの会話に3つも4つもタスクが積み重なっていて、Claudeの返答がだんだんずれていく。しびれを切らして/clearを打った瞬間、今度は別の不安がやってくる。「さっきまでの判断、全部消えたよな」。
セッション管理を何もしていない人ほど、この2つの不安を行ったり来たりしているのではないかと思う。詰め込みすぎて事故るか、消しすぎて過去の判断を失った気がするか。/new・/rename・/resumeという3つのコマンドは、実はこの往復に終止符を打つための一本のワークフローになっている。区切る・名付ける・再開する、という順番で見ていきたい。
区切る——/newは/clearの"エイリアス"に過ぎない
Claude Codeの公式ベストプラクティスガイドは、よくある失敗パターンの一つを"kitchen sink session"と呼んでいる。1つのタスクから始めて、途中で関係ない質問をして、また元のタスクに戻る。コンテキストが無関係な情報で埋め尽くされる状態だ。対処法として挙げられているのはシンプルで、「関係ないタスクの間は/clearする」というだけだ。
もう一つ、ガイドが挙げている失敗パターンが「訂正を繰り返す」ケースだ。2回訂正してもうまくいかないなら、/clearして、そこまでで学んだことを踏まえた良いプロンプトを書き直す方が、訂正を積み重ねた長いセッションよりも大抵うまくいく、とされている。
ここで一度整理しておきたいのが、/newというコマンドについての誤解だ。「/newの方が軽い」「/newは履歴を完全に消してくれる」という理解を私は最近まで持っていたが、これは正確ではない。公式ドキュメントの/clearの項目には"Aliases: /reset, /new"と明記されている。/newは独立した新規セッション専用コマンドではなく、/clearとまったく同じ実装を指す別名だ。引数の挙動（/new [name]で前の会話にラベルを付けられる点）も含めて、/clearと何一つ違わない。「/newと/clear、結局どっちを使えばいいのか」という疑問への答えは、「どちらでもいい、同じものだから」だ。
区切ること自体の操作方法はここまでにして、判断基準の話に移る。「迷ったら/clear」という単純なルールは拍子抜けするほど簡単だが、効果は大きい。無関係な話題に切り替わった瞬間に区切る癖をつけるだけで、kitchen sink sessionの大半は防げる。
名付ける——セッションをブランチのように扱う
公式ベストプラクティスガイドには、こんな一文もある。「/renameでセッションに名前をつけて、ブランチのように扱う。それぞれの作業の流れに、それぞれの永続的なコンテキストを持たせる」。Gitでfeatureブランチを切るのと同じ感覚で、1つの作業テーマに1つの名前付きセッションを対応させる、という発想だ。
/renameの具体的な操作方法や、命名できるタイミング（起動時・セッション中・ピッカーから、など）は、以前書いた『Claude Code の /resume を使い倒す — -c だけじゃないセッション管理の全貌』という記事で一通り扱っているので、詳細はそちらに譲る。ここでは、いつ・なぜ名付けるべきかという判断基準に絞って書きたい。
私が最近意識しているのは、「再訪する可能性が少しでもあるタスクは、開始時点で名付けておく」というルールだ。数分で終わる質問には不要だが、複数日にまたがりそうな実装や、後でレビュー対応として戻ってくることが分かっている作業は、最初に名前を付けておくと後の自分が楽になる。名付け忘れに気づいたら、ピッカーのCtrl+Rで後からでも救済できるので、「今すぐ完璧に運用する」必要はない。
意外と見落とされがちな仕様もある。名前を付けていないセッションは、ピッカー上には自動生成されたタイトルとして表示されるものの、--resume や/resume のような名前指定での直接再開には使えない。見た目の識別名と、検索に使える識別子は別物だ。/renameで明示的に名付けたセッションだけが、後から名前で呼び出せる。
複数のセッションを並行して進める場合、公式ガイドが薦める「Writer役のセッションとReviewer役のセッションを分ける」という運用にも/renameは相性が良い。私はfeature-x-writer・feature-x-reviewerのように役割ごとに名前を付けて、2つを行き来している。
なお、VS Code拡張やデスクトップアプリでは/renameが動作しないという報告がGitHub Issueに複数件上がっている。公式ドキュメントはCLIを対象に書かれており、この点についての明確な確認は取れていない。CLI以外の環境で使っている場合は、挙動が異なる可能性があることを頭の片隅に置いておくといい。
再開する——/resumeで戻らないものを知っておく
/resumeそのものの基本操作（4つのentry pointの違いや、ピッカーのキー操作、保存先のパス・保持期間）も先述の記事で詳しく扱っているので、ここでは繰り返さない。この記事で書いておきたいのは、resumeした際に「何が復元されないか」という、実務でつまずきやすい落とし穴の方だ。
権限モードは復元されない。bypassPermissionsやplanモードで作業していたセッションを/resumeで再開しても、モードは引き継がれず、通常の確認プロンプトに戻る。「さっきまで許可なしで動いていたのに、再開したらいちいち聞かれるようになった」という違和感の正体はこれだ。
起動時に指定したフラグ群も引き継がれない。--mcp-config・--settings・--plugin-dir・--fallback-model・--add-dirはすべて再開のたびに指定し直す必要がある。「resumeしたらMCPサーバーが消えている」と感じたときは、たいていこれが原因だ。
セッションIDでの再開にも制約がある。セッションIDの検索は、セッションを開始した作業ディレクトリとそのgit worktreeの範囲に限定されている。そのスコープの外から同じセッションIDを指定するとNo conversation found with session IDというエラーになる。作業ディレクトリを移動してからresumeする場合は注意したい。
Pro・Maxプランを使っている人限定の仕様も押さえておきたい。⚠️この仕様は公式ドキュメント上Pro/Maxプランについてのみ記載があり、APIやBedrock経由での利用に該当するかは明記されていない。1時間以上放置した上に10万トークンを超えるセッションを再開しようとすると、プロンプトキャッシュが失効しているため「Resume from summary」「Resume full session as-is」「Don't ask me again」という3択のダイアログが出る。要約を選べば読み込みは速いが詳細を失うリスクがあり、フルセッションを選べばコストと時間がかかる。長時間放置したセッションを再開する前に、この選択肢があることを知っておくと戸惑わずに済む。
/resumeと紛らわしいコマンドとして/rewindもある。/rewindは同一セッション内で会話やコードを過去の時点に戻す機能で、/resumeとは別物だ。ただし/clearした直後・同一プロセス内に限り、/rewindメニューの先頭に「/resume 」という特別な項目が現れ、/clearする前の会話に一時的に戻れる（v2.1.191以降）。「区切ったら最後、二度と戻れない」わけではなく、この抜け道が用意されている点は覚えておいて損はない。ちなみにチェックポイントはBashコマンドによるファイル変更までは追跡しないので、「セッションを戻せば何でも安全に取り消せる」という過信は禁物だ。
並行して進める——/branch・/fork・/backgroundの使い分け
複数のタスクを同時並行で進めたい場面では、/renameで名前を分けて行き来するだけでなく、セッションそのものを物理的に分ける方法もある。/branch・/fork・/backgroundはどれも「今のセッションから枝分かれする」機能だが、元のセッションがどうなるか・会話履歴がどう引き継がれるかがそれぞれ異なる。
| コマンド | 元セッションはどうなるか | 会話履歴 | 用途 |
|---|---|---|---|
/branch [name] | そのまま残る（ディスク上は不変、ピッカーにも残る） | それまでの会話をコピーして分岐先に切り替える | 別アプローチを試したいが、元の道も残しておきたいとき |
/fork [prompt] | フォアグラウンドのまま実行を継続する | コピー時点までの会話・作業ディレクトリ・モデル・権限モードなどを引き継いだ独立コピーがバックグラウンドで新規作成される | 元の作業を止めずに、別タスクを並行させたいとき |
/background [prompt] | バックグラウンドに移行し、ターミナルが解放される | 同一の会話がそのまま継続する（コピーではない） | 今の会話は続けたいが、ターミナルを他の作業に使いたいとき |
/branchは「試して失敗してもいい別ルート」を作る感覚に近い。/forkは「今の会話を止めずに、コピーを裏で走らせる」もので、元のセッションと分岐先のセッションが同時に動く。/backgroundはコピーを作らず、今の会話そのものを裏に回す点が他の2つと違う。バックグラウンドに回したセッションはclaude agentsコマンドで一覧・監視でき、必要ならCtrl+Rで名前を付けて見分けやすくできる。
私は当初、この3つを混同していた。「とりあえず/backgroundにすればいい」と思っていたが、元のセッションを無傷で残しておきたいときは/branch、元の作業を止めずに別視点を試したいときは/fork、という使い分けを覚えてからは、狙った用途通りにセッションを分けられている。
まとめ
/new・/rename・/resumeは、ばらばらの便利機能ではなく、「区切る→名付ける→再開する」という一連の意思決定として捉えると使い方が定まってくる。無関係な話題に切り替わったら/clear（/newでも同じ）で区切る。再訪しそうな作業は/renameで名前を付けておく。そして/resumeで戻るときは、権限モードや起動フラグが引き継がれないことを踏まえて、必要なら指定し直す。
1つの会話に全部を詰め込んで身動きが取れなくなる前に、次にタスクが切り替わる瞬間、まず/clearを打ってみてほしい。それだけで、セッションを"信じていいか分からない"という不安のかなりの部分は消えるはずだ。
コメント