
こんにちは。よっしーです(^^)
背景
この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。
1. これは一言でいうと何か
セッションは、プロジェクトディレクトリに紐付けられた保存済みの会話です。ローカルに保存されるため、中断したところから再開したり、別のアプローチを試すために分岐したり、タスク間を切り替えたりできます。
このページが扱うのは CLI です。デスクトップアプリ、Claude Code on the web、VS Code 拡張機能は、それぞれ独自のセッション履歴を保持しています。
2. どういう場面で役立つか
- 昨日の続きから始めたい:
claude --continueで現在のディレクトリの最新セッションを再開します。終了後だけでなく、/clearの後でも再開できます(会話は保存されています)。 - 別のアプローチを試したいが、今の道筋も残したい:
/branchで会話のコピーを作り、そちらに切り替えます。元のセッションはそのまま残ります。 - 複数タスクを並行させている:セッションに名前を付けておくと、ピッカーで探しやすく、名前で直接再開できます。「これが最も重要になるのは複数タスクを並行して処理している場合」とページも述べています。
- PR から作業を辿りたい:
claude --from-pr <number>でその PR にリンクされたセッションを再開できます。ピッカーに PR / MR の URL を貼って検索することも可能です(GitHub、GitHub Enterprise、GitLab、Bitbucket)。
注意が必要なケース。
claude -pや Agent SDK で作られたセッションはピッカーに出ません。 セッション ID をclaude --resume <session-id>に渡せば再開できますが、開始されたディレクトリから実行する必要があります。ID の検索は現在のプロジェクトディレクトリとその git worktree にスコープされているためです。- 同じセッションを2つのターミナルで分岐せずに再開すると、両方のメッセージが1つのトランスクリプトに混ざります。 並行させたいなら分岐してください。
- トランスクリプトの JSONL を直接解析するスクリプトは壊れます。 形式は内部形式でバージョン間で変更されるため、
/exportかスクリプト用インターフェースを使います。
3. コード・コマンドの実例と解説
前提条件
- セッションはプロジェクトディレクトリごとに保存されます。既定でピッカーが見せるのは、現在の worktree のインタラクティブセッションと、
/add-dirで現在のディレクトリを追加した他の場所で始まったセッションです。 - 名前で再開する場合は、現在のリポジトリとその worktree 全体で解決されます。完全一致なら別の worktree にあっても直接再開します。
再開のエントリポイント
| コマンド | 機能 |
|---|---|
claude --continue | 現在のディレクトリで最新のセッションを再開します |
claude --resume | セッションピッカーを開きます |
claude --resume <name> | 指定されたセッションを直接再開します |
claude --from-pr <number> | そのプルリクエストにリンクされたセッションを再開します |
/resume | アクティブなセッション内から別の会話に切り替えます |
日常的にはこの5つで足ります。--resume <name> と /resume <name> は挙動が少し違い、あいまいな名前を渡したとき、前者はピッカーを開いて名前を検索語として事前入力しますが、後者はエラーを報告します(ピッカーを開きたいなら引数なしの /resume)。
セッションに名前を付ける
起動時なら claude -n auth-refactor、セッション中なら /rename auth-refactor(名前はプロンプトバーにも表示されます)、ピッカーからならセッションをハイライトして Ctrl+R です。Plan Mode でプランを受け入れた場合は、既に名前を設定していない限りプランの内容から自動で命名されます。
ここで1つ紛らわしい仕様があります。v2.1.196 以降、名前を付けていないインタラクティブセッションにも my-app-3f のようなデフォルト表示名が自動で付きます(作業ディレクトリ名+2文字のサフィックス)。ただしこれは再開ハンドルではありません。 claude --resume <name> もピッカーも、自分で設定した名前としか一致しません。デフォルト名は agent view や claude agents --json の一覧で識別するためのものです。
セッションを分岐させる
/branch try-streaming-approach
これまでの会話のコピーを作り、そちらに切り替えます。元のセッションは変更されず、ピッカーに残ります。名前を省略すると、会話の最初のプロンプトに基づいて命名されます。
claude --continue --fork-session
コマンドラインからなら、--continue または --resume に --fork-session を組み合わせます。
分岐で引き継がれないものが1つあります。「このセッションで許可」で承認したアクセス許可は、新しいブランチに引き継がれません。 また /branch の確認では2つのセッション ID(新しいブランチと元のセッション)が表示されるので、元に戻りたいときはその ID を /resume に渡します。
なお、フォークされたセッション(/branch、/rewind、--fork-session で作成)はピッカー上でルートセッションの下にグループ化されます。→ で展開できます。
ピッカーで探す範囲を広げる
検索範囲の拡張が実務では効きます。Ctrl+W でリポジトリのすべての worktree、Ctrl+A でこのマシン上のすべてのプロジェクトに広がり、もう一度押すと戻ります。Ctrl+B は現在の git ブランチのセッションだけに絞り込みます。Space でセッション内容をプレビューでき、/ または印字可能文字で検索モードに入ります。
関連のないプロジェクトのセッションを選んだ場合は、再開されるのではなく cd と再開コマンドがクリップボードにコピーされます。
スクリプトから会話を扱う
claude -p --resume <session-id> --output-format json "summarize what we changed" | jq -r '.result'
既存のセッションにフォローアップのプロンプトを送り、jq で答えを取り出す例です。/export が人間向けのレンダリング済みトランスクリプトを作るのに対し、こちらは構造化データを返します。他にも、claude -p を --output-format json / stream-json で1回実行して結果・セッション ID・使用状況・コストを取る方法、フックやステータスラインが受け取る transcript_path を読む方法(SessionEnd フックでのアーカイブなど)、Agent SDK で埋め込む方法があります。
その他(ピッカーのショートカット全一覧、/cd によるセッション移動の挙動、/export のメニュー詳細、CLAUDE_CONFIG_DIR・cleanupPeriodDays・CLAUDE_CODE_SKIP_PROMPT_HISTORY・--no-session-persistence の設定表)は公式ドキュメントを参照してください。
4. まとめと次回予告
- 再開は
--continue(最新)と--resume(選ぶ・名前指定)の2本柱。PR からも辿れます。 - 分岐は「今の道を残したまま別案を試す」ための操作。権限の一時承認は引き継がれません。
- 名前を付けるのは並行作業のためのコスト削減。自動で付くデフォルト名は再開には使えません。
セッション内でのコンテキスト管理も、このページの範囲です。 /clear は空のコンテキストで始め直しますが、以前の会話は保存されていて /resume で戻れます(同じプロセス内なら rewind メニューの「前のセッション」からも)。/compact [instructions] は履歴を要約に置き換え、指示を添えれば焦点を指定できます。/context は今何がコンテキストを消費しているかを表示します。第13回で見たとおり、圧縮で何が残るかは読み込まれ方で決まります。
トランスクリプトの置き場所も知っておくと役に立ちます。 既定では ~/.claude/projects/<project>/<session-id>.jsonl に JSONL で保存され、<project> は作業ディレクトリパスの英数字以外を - に置換したものです。1行が1つの JSON オブジェクト(メッセージ、ツール使用、メタデータ)になっています。ただし繰り返しになりますが、この形式は内部形式でバージョン間で変わるため、直接解析するスクリプトはリリースごとに壊れる可能性があります。第12回で触れたとおり暗号化もされていないので、保持期間や書き込み抑制の設定とあわせて扱いを決めてください。
次回予告:連載の締めくくりとして「ベストプラクティス」を取り上げる予定です。
関連ページ(本記事で触れた概念の詳細):並列セッションの分離 →「worktree」、コードと会話の巻き戻し →「チェックポイント」、圧縮後に何が残るか →「コンテキストウィンドウ」、claude -p の挙動 →「非対話的モード」、transcript_path →「Hooks」「ステータスライン」、埋め込み →「Agent SDK」、clear と compact の使い分け →「ベストプラクティス」。
本記事は執筆時点の公式ドキュメント(セッションの管理)に基づきます。最新は公式ドキュメントをご確認ください。

何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)

コメント