セッション状態と再開・フォーキング

Claude Code session state は CCA-F 試験のドメイン1.7「Claude Code session state の管理・再開・フォーキング」の核心をなす、見えにくい根幹部分である。このタスクステートメントはドメイン1（Agentic Architecture & Orchestration、配点比率27%）の中に位置し、コミュニティの合格報告によれば毎回の試験で2〜3問がセッションの再開・フォーキング・新規開始の微妙な違いを問う場面に当たるとされている。Claude Code session state の永続化・再生・分岐の仕組みを誤読すると、そのシナリオ全体を読み誤ることになる。コーディネーター＝サブエージェント設計、CI/CDの再実行、複数日にわたる機能開発のすべてが Claude Code session state のセマンティクスの上に成り立っているからだ。

本章では、アーキテクト級の受験者が習得すべき Claude Code session state の全体像を順に解説する。--resume <session-name> と fork_session の違い、Claude Code session state のターン間で何が永続化されるか、コード変更後に再開した際に stale tool results がいかにしてセッションを腐らせるか、structured summary と新規 Claude Code session state が単純な再開より優れる局面、Claude Code session state 上でのフォークによる並列探索パターン、そして /compact と /memory が Claude Code session state のライフサイクルとどう交差するかを説明する。Code Generation with Claude Code シナリオと Developer Productivity with Claude シナリオはいずれも Claude Code session state に強く依存しており、どちらのシナリオからの設問もこのテーマを問いやすい。末尾の「試験頻出ワナ」セクションと「練習アンカー」セクションで、理論を実際の出題形式に落とし込む。

Claude Code Session State とは何か？ スコープとライフサイクル

Claude Code session state は、あなたと Claude Code との進行中の会話を永続化・直列化した表現である。一つの Claude Code session state には、すべてのユーザーターン、すべてのアシスタントターン、Claude が発行したすべてのツール呼び出し、環境が返したすべてのツール結果、発火したフック、そしてその Claude Code session state を作業ディレクトリおよび利用可能な MCP サーバー群に紐付けるメタデータが含まれる。Claude Code session state があるからこそ、夕方6時にターミナルを閉じて翌朝9時に再開しても、3時間かけて積み上げた Claude Code session state が消えずに済む。

Claude Code session state はコンテキストウィンドウと同一ではない。コンテキストウィンドウは、ある推論呼び出しの際に Claude が実際に参照している作業メモリのスライスであり、Claude Code session state は完全な会話履歴の記録であって、コンテキストウィンドウはその中の一部を切り出したウィンドウにすぎない。会話が長くなるとコンテキストウィンドウが compact 化されるが、ディスク上の Claude Code session state はすべてのターンを完全な精度で保持し続ける。

CCA-F における Claude Code Session State の重要性

CCA-F 試験は、Code Generation with Claude Code と Developer Productivity with Claude のシナリオを6種類のプールから4問ずつ引いてくる。どちらのシナリオも、複数のターミナルセッション・ブランチ・マシンにまたがる Claude Code session state を前提とした、週単位の機能開発・CI/CD 再実行・増分リファクタリング・マルチエージェントオーケストレーションを題材にする。試験が問うのは以下の能力である。

• 汚染された新規セッションを開くのではなく、正しい Claude Code session state を再開できるか。
• 2つの並列アプローチを独立して探索する必要がある場合に Claude Code session state をフォークできるか。
• Claude Code session state が陳腐化し、structured summary と新規セッションに切り替えるべき時機を見極められるか。
• Claude Code session state と CLAUDE.md の内容・コンテキストウィンドウとの違いを区別できるか。

これらを一つでも誤ると、ドメイン1.7の Claude Code session state 設問の引っかけに捕まる。

Claude Code Session State のライフサイクル

すべての Claude Code session state は以下の予測可能なライフサイクルを経る。

1. 生成 — ディレクトリで claude を起動するか、Agent SDK の会話を新規開始すると Claude Code session state が作られる。明示的に名前を渡さない限り、自動生成された名前が付与される。
2. 成長 — ユーザーターンとアシスタントターン（ツール呼び出しとツール結果を含む）が Claude Code session state のトランスクリプトに追加されていく。
3. Compact 化 — Claude Code session state のトランスクリプトがコンテキストウィンドウの上限に近づくと、/compact または自動 compact 化によって古いターンが凝縮された要約に置き換えられる。
4. 永続化 — Claude Code session state はセッション名と作業ディレクトリでインデックスされ、継続的にディスクへ書き込まれる。
5. 再開 — --resume <session-name>（または Agent SDK の同等操作）によって、後日・別ターミナル・別マシン上で Claude Code session state を復元できる。
6. フォーキング — fork_session は共有ベースラインの Claude Code session state から分岐した独立ブランチを生成し、親の Claude Code session state はそのまま保たれる。
7. 引退 — Claude Code session state の記録は休眠状態にするか、明示的に破棄できる。Claude Code は自動的にはディスク上の Claude Code session state を削除しないため、蓄積しやすい。

--resume フラグ：何をするもので、何をしないか

--resume <session-name> フラグは、コマンドラインから特定の過去の Claude Code session state に再入するための主要手段である。会話のトランスクリプトを Claude のコンテキストに復元し、中断した Claude Code session state の続きを再開できる。

特定の過去の会話を継続する

--resume は精確である。セッション名を渡すと、Claude Code はその名前の Claude Code session state を正確に読み込む。直近のものでも類似のものでもなく、指名されたものだ。3つの機能を並行して開発しているなら、claude --resume feature-auth-rewrite と claude --resume feature-billing-migration でそれぞれ別の Claude Code session state の続きに入ることができ、互いに汚染されない。

このフラグは Claude Code session state が生成された作業ディレクトリにスコープされる。別のディレクトリから Claude Code session state を再開しようとすると、失敗するかパスミスマッチエラーが発生する場合がある。マルチリポジトリのワークフローを設計するアーキテクトは、resume の契約が成立するようリポジトリルートに Claude Code session state の生成を紐付けておくべきである。

試験が --resume を強くテストする理由

CCA-F の Code Generation・Developer Productivity シナリオでは、「昨日の午後、開発者は Claude Code と一緒に複雑な認証モジュールのリファクタリングを進めていた。今朝、新しいターミナルを開いた彼女は続きを再開したい。何をすべきか？」のような問いで正答を隠す。正しい行動は claude --resume <session-name> で昨日の Claude Code session state を指定することだ。引っかけの選択肢としては以下が典型的だ。

• 新規 Claude Code session state を開いて昨日のコンテキストを貼り直す。誤り。コンテキスト予算を無駄にし、ツール結果の精度を失う。
• 新規 Claude Code session state で /compact を使う。誤り。/compact は現在の Claude Code session state のトランスクリプトに対して作用するが、新規セッションにはまだトランスクリプトがない。
• fork_session で昨日の Claude Code session state を分岐する。誤り。フォークはブランチを作るが、開発者がほしいのは既存 Claude Code session state の幹の継続であり、分岐ではない。

試験では、Claude Code session state セマンティクスの第一原理から各引っかけを排除できる受験者が報われる。

fork_session：共有ベースラインからの独立ブランチ

--resume がセッションを継続するのに対し、fork_session は分岐させる。フォークは現在の session state をベースラインとして新しい独立セッションを生成し、そのセッションは同じ履歴から始まるが別々に進化する。親はそのまま保たれ、子は幹を汚染せずに分岐できる。

典型的なフォークシナリオ：一つの分析から二つのテスト戦略

Developer Productivity with Claude シナリオを想定しよう。シニアエンジニアが1時間かけて Claude Code に大きなコードベースを説明し、モジュールの境界を指摘し、既存のテストカバレッジを要約させた。この分析が codebase-analysis という Claude Code session state に蓄積されている。次にエンジニアは二つのテスト戦略を探索したい。

• ブランチA：既存の pytest スイートの上に Hypothesis を使ったプロパティベーステスト。
• ブランチB：統合テストを pytest-regressions によるスナップショットテストに置き換える。

両方のブランチは同じベースラインの Claude Code session state を共有する。コードベースを二回説明し直すと1時間を無駄にし、二つの Claude Code session state に不整合が生まれる。分析を捨てた状態で各ブランチを新規 Claude Code session state で始めると、蓄積した分析が失われる。正しいアーキテクチャ的判断は、共有ベースラインから fork_session して独立した Claude Code session state のブランチを二つ生成することだ。

親 Claude Code session state: codebase-analysis（ベースライン）
├── フォーク: test-strategy-property-based
└── フォーク: test-strategy-snapshot

各フォーク Claude Code session state は独立して進化する。エンジニアは二つのフォークを並べて比較し、勝者を選び、敗者を任意に破棄できる。幹の Claude Code session state には触れない。

コンテキスト分離プリミティブとしてのフォーク

フォークは Claude Code session state の境界をまたいだコンテキスト分離にも重要な役割を果たす。コーディネーターから生成されたサブエージェントは、コーディネーターの Claude Code session state を特定の地点でフォークし、フォークされた Claude Code session state の中で独立した作業を行い、コーディネーターのトランスクリプトを汚染せずに結果を返すことができる。Agent Teams のドキュメントではこのパターンを明示している。サブエージェントが共有ではなくフォークされた Claude Code session state で動作するため、コーディネーターの Claude Code session state はクリーンに保たれる。

親子の独立性は永続的

フォーク後、子 Claude Code session state の変更は自動的に親に伝播しない。プロパティベーステストのフォークが重大な設計上の欠陥を発見した場合、エンジニアは手動でその知見を親 Claude Code session state か新たなフォークに持ち込む必要がある。フォークは Claude Code session state 間に独立性をもたらすのであって、同期をもたらすのではない。これは試験レベルの区別である。「フォークの変更は Claude Code session state を通じて上位に流れる」と思い込んでいる受験者は、壊れたオーケストレーションシステムを設計してしまう。

再開 vs フォーク vs 新規セッション：Claude Code Session State の判断木

この三つのプリミティブで、試験がテストするすべてのセッション状態遷移をカバーできる。

判断木

1. 以前のセッションと同じ軌跡か？ → --resume <session-name>。
2. 共有ベースラインから独立して分岐する必要があるか？ → fork_session。
3. 環境が実質的に変化した（ファイル・依存関係・ブランチの変更）？ → 以前の判断の structured summary でシードされた新規セッション。
4. 上記いずれでもない？ → 要約なしの新規セッション。

なぜ重要か

シナリオではしばしば素朴な選択が誤りになる。大きなリベース後に3日前のセッションを「再開」する開発者。トランスクリプトには存在しなくなったファイルへの参照が溢れている。正しい行動は再開ではなく、以前の判断の structured summary を作り、新規に始めて、その要約をコンテキストとして渡すことだ。

発見しやすい Claude Code Session State の命名

--resume にはセッション名が必要だ。session-2026-04-23-afternoon という名前の Claude Code session state は1週間後に見つけるのが難しい。チーム全体の Claude Code ワークフローを設計するアーキテクトは命名規則を採用すべきだ。feature/auth-rewrite-v2、bugfix/billing-rounding-issue、refactor/user-service-split のような形式が良い。一貫した命名により、Claude Code session state の永続化はエンジニアチームが Claude Code session state 記録を共有する発見可能なナレッジベースになる。

Stale Tool Results：再開された Claude Code Session State の静かな破壊者

セッション再開の最も深刻な障害は stale tool results だ。Claude が Read ツールでファイルを読んだとき、その瞬間のファイルの内容はセッションのトランスクリプトに永遠に固定される。翌日セッションを再開しても、ツール結果はそのままだが、ディスク上のファイルは変更されているかもしれない。

Stale Tool Results が Claude Code Session State を腐らせる仕組み

シナリオ：昨日あなたは Claude Code に src/auth/session.py を読ませた。Read ツールはファイルの内容を返し、それが Claude Code session state に固定された。一晩のうちに、あなたか同僚か、またはリベースによってそのファイルが編集された。新しい関数が追加され、パラメーターが削除され、ヘルパーがリファクタリングされた。今朝 Claude Code session state を --resume して Claude に新しいテストケースを追加するよう頼む。Claude は内部の Claude Code session state の中の src/auth/session.py の記録を参照し、以下のコードを生成する。

• 存在しなくなったヘルパーへの参照。
• 削除されたパラメーターを期待する。
• 新しい関数を完全に見落とす。

生成されたコードは動かない。Claude がハルシネーションしたわけではない。Claude は Claude Code session state を読んでいたのであり、その中には昨日時点では正しい Read の結果が含まれていた。ツール結果は古くなっており、Claude Code session state は損なわれている。

ファイルの変更をエージェントに知らせる

コード変更後に Claude Code session state を再開する場合は、何が変わったかをエージェントに明示的に伝える必要がある。Claude Code session state を更新するためのオプション：

• 影響を受けたファイルを再読する — 最もシンプルな方法。変更されたファイルに対して Read を実行するよう Claude に依頼する。新鮮な Read の結果がコンテキスト内の古いものを上書きする（ただし古いものは Claude Code session state のトランスクリプトに残る）。
• git diff または同等のものを実行する — 正確な変更を示すツール結果を渡し、Claude が内部の Claude Code session state とライブなファイルシステムを照合できるようにする。
• プロセの変更ログを提供する — 大規模なリベースの場合、「X・Y・Zで競合を解消してメインにリベースした」という要約の段落があれば、Claude が再開した Claude Code session state 内で再調整できる。
• Claude Code session state を破棄する — 変更が多すぎる場合、再開は得策でない。structured summary と新規 Claude Code session state で新たに始める。

大きな変更後の再開がしばしば誤りである理由

Agent SDK のドキュメントには明記されている。Claude Code session state の再開はトランスクリプトの忠実性を保持するが、ライブな環境に対して再検証はしない。変更検出ステップなしに --resume を中心とした自動化を設計するアーキテクトは、壊れたパイプラインを出荷することになる。試験はこれを直接問いに変える。時間的なギャップとリベースやアップグレードについての言及があるシナリオで、正答は「構造化要約付きの新規 Claude Code session state を開始する」であり、「古い Claude Code session state を再開する」ではない。

Structured Summary：新規 Claude Code Session State が再開に勝る局面

Structured summary はアーキテクトが古くなった Claude Code session state から脱出するための逃げ道だ。Claude Code session state が何時間もの履歴を積み重ねたが環境が変化してしまった場合、正しい対処は学んだことを簡潔な structured summary にまとめ、新規 Claude Code session state を開始し、その要約でシードすることだ。

Structured Summary ハンドオフに含めるもの

コーディング Claude Code session state ハンドオフのための適切な structured summary には通常以下が含まれる。

• 目標 — 以前の Claude Code session state が達成しようとしていたことを1〜2文で。
• 決定事項 — 以前の Claude Code session state 中に採用したアーキテクチャ上の選択・パターン・ライブラリ。
• コードの現在状態 — 以前の Claude Code session state 中にどのファイルがどのように変更されたか。
• 未解決の問題 — 以前の Claude Code session state が指摘した未解決の曖昧さ。
• 次のステップ — 新規 Claude Code session state が最初に取るべき具体的な行動。

良い要約は200〜600トークンだ。肥大化した要約は新規 Claude Code session state を開始する目的を損なう。5000トークン必要なら要約ではなく再貼り付けだ。

/compact コマンドとその Claude Code Session State における限界

/compact は Claude Code の組み込みスラッシュコマンドで、Claude に自身の Claude Code session state のトランスクリプトを compact 化させる。古いターンを Claude が生成した要約に置き換え、同じ Claude Code session state 内のコンテキストウィンドウの空きを作る。/compact とセッション横断のハンドオフの主な違いは以下だ。

• /compact は現在の Claude Code session state のトランスクリプトをその場で操作する。その Claude Code session state の中の元のトランスクリプトは要約に置き換えられる。
• /compact は Claude Code session state の境界を越えることはできない。新規 Claude Code session state にこの要約をコピーするプリミティブではない。
• /compact は Claude Code session state がコンテキスト上限に近づいたときの予防的メンテナンスとして最も適切であり、Claude Code session state が古くなった後のクラッシュリカバリとしてではない。

/memory コマンドと長期的な知識

/memory は /compact とも Claude Code session state そのものとも異なる。/compact が現在の Claude Code session state のトランスクリプトを短くするのに対し、/memory はすべての新規 Claude Code session state をシードする CLAUDE.md メモリファイルを参照する。/memory は耐久性のあるセッション横断の命令のためのものであり、/compact はエフェメラルな Claude Code session state 内のスペース管理のためのものだ。この二つのプリミティブを混在させるアーキテクトは Claude Code session state に関して壊れたメンタルモデルを持つことになる。試験は /memory・/compact・Claude Code session state の永続化のきれいな分離を重視する。

要約＋新規が再開に勝る Claude Code Session State の局面

試験は新規 Claude Code session state に structured summary を持たせる方が古い Claude Code session state への --resume より優れる5つのシナリオをテストする。

• Claude Code session state の書き込み間での 大規模なコード変更（マージ・リベース・リファクタリング）。
• Claude が以前の Claude Code session state 内で読んだ API を変更する 依存関係のアップグレード。
• Claude Code session state のトランスクリプトが反映するものとは異なるファイルを作業ディレクトリが表示するような ブランチの切り替え。
• /compact 後でもコンテキスト上限に近い トークンが肥大化した Claude Code session state。
• サブエージェントにコーディネーターの完全な履歴ではなく独立した Claude Code session state が必要な サブエージェントへのハンドオフ。

シナリオにこれらのトリガーのいずれかが含まれていれば、答えは structured summary＋新規 Claude Code session state であり、再開でもフォークでもない。

並列探索パターン：A/B 比較のための Claude Code Session State のフォーク

フォークは一つの高価値なパターンを可能にする。並列探索だ。一つのセッションで共有分析を構築し、2つ以上のブランチにフォークし、それぞれを完了まで実行し、結果を比較する。

典型的な出題形式：共有コードベース分析からの二つのテスト戦略

「シニアエンジニアが1時間かけてレガシーコードベースを一つのセッションで分析した。分析を再実行せずに二つのテスト戦略を評価したい。」

正答：共有ベースラインから 二回フォークし、各戦略をそれぞれのフォークで実行して比較。引っかけ：

• 同一セッションで順番に実行する。最初の戦略が二番目のためのセッションを汚染する。
• 二つの新規セッションを開いて分析を貼り直す。1時間が無駄になり要約時のエラーリスクがある。
• フォークなしでサブエージェントを使う。動作はするがオーケストレーションのオーバーヘッドが増える。フォークの方がシンプルなプリミティブだ。

共有要件から三つの API 設計案

別の頻出形式：「プロダクトチームが共有要件の Claude Code session state から三つの候補 API 設計を生成させたい。コンテキストの再構築を最小化するアプローチはどれか？」

要件分析 Claude Code session state を三方向にフォークし、設計案ごとに一つ。三つのフォークされた Claude Code session state を比較し、勝者を選ぶ。

マイグレーションパスの探索

インフラシナリオ：「SRE が PostgreSQL から二つの異なるデータベースへのマイグレーションを評価する必要がある。ベースライン分析が一つの Claude Code session state にある。どのパターンを使うか？」

ベースラインの PostgreSQL 分析 Claude Code session state を二つにフォークし、候補ターゲットごとに一つ。各フォーク Claude Code session state がマイグレーションの仕組みを独立して探索する。

このパターンは Claude Code session state を含むすべての Code Generation・Developer Productivity シナリオで繰り返し現れる。反射的に思い出せるよう記憶しておくこと。

やさしい解説: Claude Code Session State

Claude Code session state の抽象的な仕組みは、身近な具体的なシステムに置き換えると直感的に理解できる。三つの類比で Claude Code session state の挙動の全体像を覆う。

類比1：駅の乗り換え案内板と切符バッグ

新幹線の旅行計画を数日かけて立てているとしよう。切符バッグが Claude Code session state だ。購入済みの切符・乗り換えメモ・ホテルの予約確認書・変更したルートの走り書きが全部入っている。コンテキストウィンドウは、今日の荷造りの際にバッグから取り出してテーブルに並べている分量、手の届く範囲のサブセットだ。

木曜夜に出かけて金曜朝に帰宅した際（Claude Code session state の --resume）、切符バッグをそのまま再開する。新幹線はまだ予約済み、ホテルはまだ確認済み、乗り換えメモはまだテーブルの上にある。何も実質的に変わっていなければ、Claude Code session state をその場で継続するのが効率的だ。

次に、同じ旅程の二つのバリエーションを試したいとする。東海道新幹線経由か、山陽回りか。切符バッグを空にして二回詰め直すのではなく、フォークする。同じ予約確認書のコピーを取り、二つ目のバッグに入れ、液体分岐点から別々に進める。両方のバッグは同じ初期ルートと宿を共有し、選択肢の部分だけ分かれている。フォークによって下準備を二度繰り返さず、両方のパスを評価できる。

ところが一晩のうちに、家族が旅行バッグを整理し直した。入れ替えられた切符、変わったラベル、使われた切符が一枚消えた。古い切符バッグのメモ（「2枚目の棚に静岡行きがある」）を読んだまま旅行を続けると失敗する。これが stale tool results だ。正しい対処は旅行バッグを一から確認し直し、「この新幹線・この宿・この日程で進める」という一段落の structured summary を書いて、新しい旅行計画 Claude Code session state の最初の指示として手渡すことだ。

類比2：Git ブランチと作業ツリー

Claude Code session state は多くの CCA-F 受験者がすでに持っている git のメンタルモデルにきれいに対応する。

• Claude Code session state のトランスクリプトはブランチのコミット履歴。
• --resume <session-name> は git checkout <branch> — Claude Code session state のブランチに再入り、直線的にコミットを重ね続ける。
• fork_session は git checkout -b new-branch <base-ref> — 別のブランチの履歴の特定地点から新しい Claude Code session state のブランチを作り、独立して進化させる。
• Stale tool results は git pull されていない作業ツリーのようなもの。ローカルビュー（Claude Code session state 内）が現実より古く、その上に積み重ねた作業が競合する。
• Structured summary＋新規 Claude Code session state は長期ブランチをアーカイブし、簡潔な変更ログを書き、その変更ログを先頭に固定したまま main から新規ブランチを切るのに似ている。
• /compact は多くのコミットを一つのサマリーコミットにまとめる squash — Claude Code session state の本質を保持しつつ詳細な履歴を失う。
• /memory はリポジトリの共有 README — すべての新規 Claude Code session state が同じ README から始まる。Claude Code session state 固有のものではない。

試験中にこの類比を思い出せれば、正しい Claude Code session state プリミティブはほぼ自明になる。

類比3：二種類の問題セットを持つ持ち込み可試験

学生が持ち込み可の試験を受けているとする。特定のトピック——留数の計算——について3時間かけてノートに解いた例題を積み上げた。そのノートが Claude Code session state だ。試験官が同じ背景理論を必要とする二種類の問題セットを渡してきた。学生は同じ Claude Code session state から両方を解きたい。

選択肢1（誤り）： 問題セットAを解き、同じノートで問題セットBを解く。Claude Code session state がAの計算メモで埋まり、Bの解答が読みにくくなり、Aの選択に汚染されるかもしれない。

選択肢2（誤り）： ノートを捨てて二回新たに始める。Claude Code session state の中の3時間分の理論作業が無駄になる。

選択肢3（正しい——フォーク）： ノートのコピーを二部取る。一方に「問題セットAの計算メモ」、もう一方に「問題セットBの計算メモ」とラベルを貼る。それぞれ自分のコピーで解く。比較し、勝ちを選び、負けをアーカイブする。これが一枚の絵で表した Claude Code session state への fork_session だ。

前半の試験が終わったとき、試験官が「学生が依拠してきたある定理が更新された——命題に新しい仮定が加わった」と告知したとする。学生のノートには古い命題が固定されている。新しい定理の命題を再読せずにノートの Claude Code session state を使い続けると誤答になる。正しい対処は前半で達成したことを一段落にまとめ、新しいノート（新規 Claude Code session state）に手渡し、現在の定理から再導出することだ。Stale tool results と structured summary handoff を一枚の絵で示している。

コンテキストウィンドウ vs Claude Code Session State：混同しないこと

CCA-F でよくある誤りは、コンテキストウィンドウと session state を同一視することだ。両者は関係しているが別物だ。

両者の関係

すべての推論呼び出しは session state をコンテキストウィンドウに読み込むことから始まる。完全なトランスクリプトが収まれば完全に読み込まれる。収まらない場合は compact 化が作動し、古いターンが要約に置き換えられてから Claude に渡される。完全なトランスクリプトはディスク上に残り続ける。

試験のワナ

CCA-F の設問では、長いセッションの後に「コンテキストが尽きた」開発者が何をすべきかを問う。正しい答えには /compact（現在のトランスクリプトを縮小する）・structured summary＋新規セッション（知見を保持した上でのフルリセット）・フォーク（分離のための分岐）が含まれる。誤った答えは --resume だ。それは溢れた同じトランスクリプトを再水和するだけだ。

/compact と /memory：隣接する Claude Code Session State プリミティブ

Claude Code session state 設問の引っかけとして頻繁に登場する二つのスラッシュコマンド。それぞれが正確に何をするか把握しておくこと。

/compact

/compact は現在の Claude Code session state のトランスクリプトをその場で圧縮し、古いターンを Claude が生成した要約に置き換える。Claude Code session state の名前とアイデンティティは保持されるが、トランスクリプト本体だけが変わる。Claude Code session state はまだ使えるがコンテキスト上限に近づいているときに /compact を使う。

/memory

/memory は CLAUDE.md メモリ階層（グローバル・プロジェクト・ディレクトリ）を参照・編集する。メモリファイルはすべての新規 Claude Code session state に自動的にシードされる。Claude Code session state 固有のものではない。/memory は耐久性のあるセッション横断の命令（「常に pytest を使う」「明示的な許可なく legacy/*.py を編集するな」）のための正しいプリミティブだ。特定の Claude Code session state を永続化・復元するものではない。

キーワードによる区別

• 「現在の Claude Code session state が長くなってきた。同じコンテキストを保ちつつ収めたい」→ /compact。
• 「すべての新規 Claude Code session state にコーディング規約を知らせたい」→ /memory、/compact ではない。
• 「昨日の Claude Code session state を呼び戻したい」→ --resume、/compact でも /memory でもない。
• 「今日の共有 Claude Code session state から二つのアプローチを分岐させたい」→ fork_session、/compact でも /memory でもない。

試験作成者はこれら四つの Claude Code session state プリミティブを一つの設問の選択肢の中に混在させることが多い。区別を練習していない受験者は落とされる。

試験頻出ワナ：CCA-F における Claude Code Session State の落とし穴

CCA-F は Claude Code session state に関連した五つの繰り返しパターンを積極的に狙う。

ワナ1：リベース後の再開

答えの選択肢は --resume と「structured summary 付きの新規 Claude Code session state」を競わせる。シナリオにはリベース・マージ・または一晩の大きな変更に関する言及がある。古い Claude Code session state の --resume をデフォルトとする受験者は stale tool results の障害にはまる。正解はほぼ常に structured summary 付きの新規 Claude Code session state だ。

ワナ2：再開したいのにフォークを選ぶ

開発者が Claude Code session state を「継続」したい。作業は直線的で分岐ではない。引っかけとして fork_session が提案される。フォークはここで誤りだ。継続ではなく兄弟 Claude Code session state を作るからだ。エンジニアが一つの Claude Code session state の軌跡だけを進めたいなら --resume が正しい。

ワナ3：/compact をセッション横断プリミティブとして提示

一つの Claude Code session state から新規 Claude Code session state に要約をコピーできると主張する答えがある。偽だ。/compact は現在の Claude Code session state のトランスクリプトのみに作用する。Claude Code session state 間の要約ハンドオフには、要約を手動で新規 Claude Code session state の冒頭メッセージにコピーすることが必要だ。

ワナ4：サブエージェントが完全な Claude Code Session State を引き継ぐと仮定する

CCA-F ドメイン1.3がこれを明示的にテストし、1.7にも影響する。サブエージェントはコーディネーターの Claude Code session state を自動的に受け取らない。「コーディネーターがサブエージェントを生成し、サブエージェントが『今議論していたこと』を知っていると期待している」シナリオでは、正しいアーキテクチャ的対処はコーディネーターの Claude Code session state のスポーンポイントでの fork_session か、独自の新規 Claude Code session state の冒頭命令としてのコンテキストの明示的な受け渡しだ。

ワナ5：/memory を Claude Code Session State の永続化と混同する

「現在の Claude Code session state を後で使うために保存するには /memory を使えばいい」と示唆する答えがある。誤り。/memory は CLAUDE.md ファイルを編集するものであり、これは Claude Code session state のシード命令であって Claude Code session state の保存ではない。Claude Code session state は Claude Code によって自動的に永続化される。Claude Code session state に対して呼び出す手動保存コマンドは存在しない。

練習アンカー：Code Generation・Developer Productivity シナリオの形状

Claude Code session state に関連した CCA-F の練習問題は6つの形状にまとまり、Code Generation with Claude Code・Developer Productivity with Claude のシナリオから引かれる。

形状A：翌日の継続

「開発者が昨日の Claude Code session state を機能の途中で終えた。一晩で何も変わっていない。どのコマンドか？」正答：以前の Claude Code session state への claude --resume <session-name>。引っかけ：新規 Claude Code session state・フォーク・/compact。

形状B：リベース後の再開

「開発者が Claude Code session state を再開する。一晩のうちに別のエンジニアが、そのセッションが以前に読んでいた3つのファイルをマージする PR をマージした。Claude が誤ったコードを生成するようになった。」正答：古い Claude Code session state を破棄し、structured summary を作成し、新規 Claude Code session state を開始し、新規 Claude Code session state の中でファイルを再読する。引っかけ：/compact・別のセッション名・「以前のコンテキストを無視する」。

形状C：並列A/B探索

「エンジニアが共有のコードベース分析 Claude Code session state からコンテキストを再構築せずに二つのテスト戦略を評価したい。」正答：共有ベースラインの Claude Code session state から二度 fork_session する。引っかけ：一つの Claude Code session state で順番に・二つの新規 Claude Code session state 記録・サブエージェントのスポーニング。

形状D：コーディネーター＝サブエージェントのハンドオフ

「コーディネーター Claude Code session state がかなりのコンテキストを費やして計画を立てた。次の一ステップを実行するサブエージェントを生成する。サブエージェントは計画を知る必要があるが、コーディネーターの Claude Code session state を汚染してはならない。」正答：スポーンポイントでコーディネーターの Claude Code session state をフォークするか、新規 Claude Code session state の冒頭命令としてサブエージェントに structured summary を渡す。引っかけ：サブエージェントがコーディネーターの Claude Code session state を自動的に引き継ぐと仮定する・/memory を使う。

形状E：コンテキスト上限からの回復

「Claude Code session state が何時間分ものターンを蓄積し、コンテキストウィンドウの上限に近づいている。開発者は同じ直線的な作業を続けたい。」正答：現在の Claude Code session state のトランスクリプトをその場で縮小する /compact。引っかけ：新規 Claude Code session state を開始する・フォーク・/memory。

形状F：チーム横断の知識ハンドオフ

「開発者が複雑な機能を、翌日自分のマシン・自分の Claude Code session state で作業を続ける同僚に引き継ぎたい。」正答：同僚の新規 Claude Code session state の冒頭命令として渡される structured summary。引っかけ：Claude Code session state ファイルを直接共有する（脆弱でパス依存）・/memory（命令であり Claude Code session state ではない）。

これら六つの形状を記憶しておけば、試験が Claude Code session state について引くドメイン1.7の問題の大半をカバーできる。

区別メモ：CCA-F が Claude Code Session State について問わないこと

CCA-F は基礎レベルだ。いくつかの隣接トピックは明示的にスコープ外であり、Claude Code session state の学習時間を割くべきではない。

CCA-F のスコープ外

• ファインチューニング・RLHF・モデルウェイトの操作。
• ビジョンとcomputer-use API の詳細。
• ストリーミング API の実装詳細。
• Claude Code session state のレート制限とトークンカウントアルゴリズム。
• クラウドプロバイダーの設定 — Bedrock・Azure AI・GCP Vertex と Claude Code session state の連携はすべてスコープ外。
• プロンプトキャッシュの内部。

Claude Code session state のコンテキストでこれらを勉強し始めたら、方向転換すること。試験がテストするのは Claude Code session state プリミティブのアーキテクト級の振る舞いであり、基礎となるストレージ実装や Claude Code session state データのクラウドルーティングではない。

CCA-F が期待すること

• --resume・fork_session・/compact・/memory を Claude Code session state に対して異なるスコープを持つ別々のプリミティブとして認識する。
• Claude Code session state の再開か要約付き新規かを決める stale tool results テストを適用する。
• Claude Code session state 上で fork_session を使った並列探索を設計する。
• structured summary を新規 Claude Code session state にシードすることで、人間間・エージェント間で作業を引き継ぐ。
• 「試験頻出ワナ」セクションの五つのパターンを回避する。

Claude Code Session State よくある質問（FAQ）

CCA-F 試験における --resume と fork_session の違いは？

--resume <session-name> は特定の永続化済み Claude Code session state を復元してその場で継続する——同じ Claude Code session state 名・直線的な継続・分岐なし。fork_session は既存の Claude Code session state のトランスクリプトの特定地点で分岐して新しい独立 Claude Code session state を作る。親と子の Claude Code session state は独立して進化し、自動的にマージされない。作業が直線的なら再開（「昨日の機能の続き」）、共有ベースラインの Claude Code session state から発散するなら フォーク（「同じ分析から二つのテスト戦略を試す」）を使う。キーワードによる区別は 継続（再開）対 発散（フォーク）だ。

再開の代わりに新規 Claude Code session state を開始すべきは？

以前の Claude Code session state が書き込まれて以来、環境が実質的に変化したとき——他のコントリビューターによるファイルの編集・依存関係のアップグレード・リベースまたはマージ・git ブランチの切り替え——はいつでも新規 Claude Code session state を開始する。そのような場合、以前の Claude Code session state のツール結果は古くなっており——ファイルの古いビューをトランスクリプトに固定している——再開すると Claude が存在しない関数・パラメーター・ファイルを参照するコードを生成することになる。正しいリカバリは判断と現状についての structured summary を作り、新規 Claude Code session state を開始し、その要約を冒頭のユーザーターンとしてシードすることだ。

stale tool results とは何か、なぜ Claude Code session state にとって重要か？

Stale tool results は、Claude Code session state 内の永続化されたツール呼び出しの戻り値が基礎となるリソースの現在の状態に一致しなくなった状態だ。Claude Code が昨日 src/auth.py に対して Read を実行したとき、その瞬間のファイルの内容が Claude Code session state のトランスクリプトに埋め込まれた。そのファイルが一晩で編集された場合、その埋め込まれた内容は Claude Code session state 内で古くなっている。Claude Code session state を再開するとその古い内容が Claude のコンテキストに再生され、Claude はそれを権威ある情報として扱う——削除された関数を参照し、新しい関数を見逃し、廃止されたシグネチャを前提とするコードを生成する。CCA-F 試験は stale tool results を直接テストする。リベース・マージ・または Claude Code session state の書き込み間での依存関係のアップグレードをシナリオが言及しているとき、正解は再開を拒否し、代わりに新規 Claude Code session state への structured summary ハンドオフを選ぶことだ。

/compact と /memory は --resume と fork_session とどう違うか？

/compact と /memory は Claude Code session state 内部のスラッシュコマンドであり、--resume と fork_session は Claude Code session state の境界プリミティブだ。/compact は古いターンを要約することで現在の Claude Code session state のトランスクリプトをその場で縮小する——セッション途中のコンテキストウィンドウの空きを確保するのに便利で、Claude Code session state の境界を越えるのには使えない。/memory は CLAUDE.md メモリファイルを表示・編集する。これはすべての新規 Claude Code session state に耐久性のある命令をシードする——セッション横断の規約に便利で、特定の Claude Code session state のトランスクリプトを永続化・復元するものではない。--resume は特定の以前の Claude Code session state を名前で再開する。fork_session は Claude Code session state を独立した子に分岐させる。CCA-F 試験は四つすべてを一つの設問の答えの選択肢に混在させることが多い。それぞれのスコープを記憶しておくこと。

fork_session はサブエージェントの生成に使えるか？

はい——フォークはコーディネーター＝サブエージェントのコンテキスト分離のための二つの主要パターンの一つだ。コーディネーターがスポーンポイントで自身の Claude Code session state をフォークしてサブエージェントにそのフォークされた Claude Code session state を渡すと、サブエージェントは共有ベースラインとしてコーディネーターの完全な履歴を持ちつつ、親 Claude Code session state を汚染せずに独立して進化できる。代替手段は明示的な structured summary ハンドオフで、コーディネーターが簡潔な要約を書き、サブエージェントはその要約を冒頭命令として新規 Claude Code session state を開始する。フォークの方が精度が高い（Claude Code session state 記録間で要約によって何も失われない）が重い（完全なトランスクリプトが複製される）。要約ハンドオフは軽いが、サブエージェントが知る必要があることをコーディネーターが正確に特定する必要がある。

長期プロジェクトで Claude Code session state の記録を命名するには？

再開が後日でもチームメンバー間でも発見できるよう、Claude Code session state の命名規則を採用する。良いパターン：feature/auth-rewrite-v2・bugfix/billing-rounding・refactor/user-service-split・exploration/property-based-tests。session-2026-04-23-afternoon のような自動生成名は避ける——1週間後に意図を判断して正しい Claude Code session state を選ぶのが不可能になる。Claude Code session state の名前が --resume <session-name> に渡すキーになるため、チーム規約の中で短命なブランチ名のように扱うこと。

Claude Code session state を再開するとコンテキストウィンドウがリセットされるか？

いいえ。再開すると完全な Claude Code session state をコンテキストに復元し、そのセッションのトランスクリプトがコンテキストウィンドウの上限を超えていれば自動または手動の compact 化が作動する。再開しても新鮮なコンテキスト予算は得られない。最後に永続化された時点の状態を復元するだけだ。Claude Code session state が一時停止する前にすでにコンテキスト上限に近づいていた場合、同じ Claude Code session state を再開すると同じ制約がすぐに再現される場合がある。コンテキスト上限からの回復には /compact で現在の Claude Code session state のトランスクリプトを縮小する。真の新鮮な予算が必要なら、structured summary と共に新規 Claude Code session state を開始する。

参考資料

• Agent SDK Session Management（resume・fork）：https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-sessions
• Agent SDK Subagents and Fork Semantics：https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Orchestrate Teams of Claude Code Sessions：https://code.claude.com/docs/en/agent-teams
• Agent SDK Overview（hooks and session APIs）：https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Context Windows and Compaction：https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Long-Context Prompting Tips：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
• Claude Code Features Overview：https://docs.anthropic.com/en/docs/claude-code/overview

関連 ExamLab 章：自律タスク実行のための Agentic Loops、マルチエージェント コーディネーター＝サブエージェントパターン、大規模コードベースでのコンテキスト管理、CLAUDE.md 階層とモジュール構成、Plan Mode と直接実行の比較。