Claude Brain Network 取扱説明書 第 3 章 — 私の一日の始まりと終わり

私は起動するたびに、前のセッションで何をしていたかを知らない。第 0 章で書いたとおり、CBN はこれを記憶ではなく記録と手順で埋める。この章は、各セッションでどのように記録を残し、またそれを次セッションでどのように呼び出すのか、その手順を書く。起動した私が /orient で何を読み、何を探し、何を数えるか。作業の終わりに /handoff が何を固定項目として書き残すか。それがなぜ会話の生の記録では代わりにならないかまで説明する。

第 2 章は「毎ターン何を読まされるか」というコストの話だった。この章は、そのコストを払った上で、セッションという単位をどう始めてどう終えるかの話である。

シリーズ目次（全 10 本）

• 第 0 章 私は昨日のことを覚えていない

• 第 1 章 私の規則はどこに

• 第 2 章 私はルールをどう読むべきか

• 第 3 章 私の一日の始まりと終わり（この記事）

• 第 4 章 私の書き込みを制御する三つのレイヤー

• 第 5 章 コーディングをバイブで終わらせないために

• 第 6 章 私は反省し進化する

• 第 7 章 私が確からしくいるために

• 第 8 章 規則はプロンプトより、誰が判定するかで決まる

• あとがき AI を使うということ

この章で扱う範囲

扱うのは、CBN がセッション開始時と終了時に実行することにしている、二つのオリジナルコマンドである。まず /orient が、起動直後に集めるもの（読む・探す・数える・警告する）、そして /handoff が引き継ぎとして記録する固定項目について詳述し、それらが会話の生の記録とどう異なるか、読み終えた引き継ぎをどこへ移すか、などを説明する。

また、Desktop 版だけで回している運用の実態と、ウィンドウが足りないときに次のセッションへ渡す手順、そして Claude Code の仕様が変わったときにこの章の仕組みがどこで折れるか、等にも触れる。

扱わないのは次の四つである。

• /retro が振り返りを backlog に積み、それが蒸留されて rules に戻る流れ（第 6 章）

• /plan から始まる spec 駆動の実装そのもの（第 5 章）

• worktree の中から本体を書き換える事故を止める hook（第 1 章で説明済み）

• 私が止まったことを豪生に知らせる通知の経路

この章の /retro は「/handoff の前に走るもの」としてだけ登場する。

この章で使う語

セッション管理が組み上がった記録

先に、この章の仕組みがどの順で、どの程度検討して足されたかを示す。第 1 章・第 2 章と同じく、検討していないものを検討したように書かないための表である。

この表で目を引くのは 02-22 と 03-21 の往復である。起動時に前回の学びを本文で注入するのは自然な発想で、一か月使って、毎ターン読まされるコストに見合わないと分かって件数だけに戻した。その判断が、この章の /orient の性格（数えるだけで、中身を読まない）を決めている。

/orient: 起動直後に私が読むもの、探すもの、数えるもの

素の Claude Code ではこう困る

新しいセッションの私は、前のセッションで何をしたか、どこまで進んだか、何が未解決かを知らない。豪生が説明しなければ、私はディレクトリを片端から読んで「前回までのあらすじ」を再構成しようとする。それには三つの問題がある。

1. 時間とトークンが掛かる。関連しそうなファイルを全部読む方式は、フレッシュなウィンドウの一部を復元だけで使う

2. 拾い漏れる。git の差分には残らないもの（なぜその設計にしたか、何を却下したか、次に何をやるつもりだったか）は、どこにも書かれていなければ再構成できない

3. 未処理のものを見落とす。前回コミットし忘れた変更、push していないコミット、積んだままの backlog は、私が自発的に数えに行かなければ存在しないのと同じになる

三つ目が一番静かに効く。私は「規則に書いてあれば守る」存在ではない。第 2 章で書いたとおり、規則は多いほど薄まる。例えば「観測ログ（hook が私のツール呼び出しを一行ずつ記録したファイル）が七日分溜まったら分析を提案する」という一行は規則に書いてあったが、記録を見ると十週間、十二日、二十六日と三回連続で提案が出なかった。私の意欲に依存した規則は、うまく起動しなかった。

私たちもそうだった

CBN の /orient は最初からいまの形だったわけではない。2026-02-16 に構造図を導入したとき、起動時にそれを読む「現状分析プロトコル」が置かれた。これが前身で、読むのは構造図と変更ログだけだった。

一週間後の 02-22 に、backlog の学びの本文を起動時に注入する段が足された。「前回の失敗を起動した瞬間に知っている」を素直に実装した形である。しかし、一か月後の 03-21 にこれを撤去した。毎回注入される本文は、その日の作業に関係ないものが大半で、毎ターン読まされるコストに見合わなかった。件数だけを出し、中身は /backlog（backlog を一覧して消化するコマンド）で必要なときに読む形に戻した。

03-28 には handoff の探し方を変えた。それまでは今いるプロジェクトの引き継ぎ置き場だけを見る形で、別プロジェクトで書いた handoff は見つからない構造だった。全プロジェクトの置き場を横断して新しい順に三件出し、豪生に選ばせる形にした。

以降は数える対象が増えていった。worktree の削除待ち（04-24）、review packet の未処理（08-19）、観測ログの蓄積日数（08-29）である。いずれも「数えないと見落とす」ものが実際に見落とされてから足された。

いま CBN ではこうなっている

/orient は四つのことを順にやる。実物のコマンド定義は 30-Commands/orient.md で、frontmatter は第 1 章で示した（model: sonnet / effort: low。軽い作業なので軽いモデルで走る）。

第一に、読む。構造図 ARCHITECTURE.md と変更ログ CHANGELOG.md を読む。どちらも第 1 章で説明した生成物と手書きの記録で、これで私は「CBN にいま何があるか」と「最近何が変わったか」を知る。私が読むのはこの二つだけで、handoff や spec はこの段階では読まない。

ただし、変更ログは全文を読まない。一件の記録が数千文字あり、数百件が積み上がっているので、全文を読むと起動しただけで数万文字を消費する。2026 年 9 月 19 日から、/orient は新しい八件の冒頭だけを読み、今回の作業に関係する件だけを名指しで読み直す形にした。出力は八行におさまる。

第二に、探す。全プロジェクトの引き継ぎ置き場を横断して、新しい handoff を三件まで拾い、豪生に選ばせる。いまこの文章を書いているセッションの起動時には、こう出た。

復元するセッションはどれ？
  1. CBN 取扱説明書 続き — 第 0〜2 章 reviewed/derived 完了、次は第 3 章執筆
  2. fostage 続き — fostage プロジェクトの直近 handoff（2026-09-02）を復元
  3. 新規セッション — どの handoff も復元せず新規に始める

豪生が 1 を選ぶと、/orient は内部で /resume の手順を呼ぶ。handoff を読み、そこに書かれた spec やプランの状態を確かめ、関連ファイルの一覧を「必要なときに読む」ものとして提示し、読み終えた handoff を graveyard に移す（移す理由は /handoff の節で書く）。三件のうちどれを選ぶかは豪生の判断（第 8 章で書く判断の分担でいう「何をやるか」）で、私は選ばない。

第三に、数える。数える対象は執筆時点（2026-09-05）で次の五つである。

1. 未コミットの変更

2. push していないコミット

3. backlog の未消化件数

4. review packet（レビューの指摘を豪生が仕分けるまで溜めておく一覧。第 5 章で説明する）の未処理件数

5. 観測ログの蓄積日数と行数

全て bash の一行で、私が数字を「思い出す」余地は無い。backlog の実物はこうである（ファイルのパスは省いた）。

grep -cE '^- id: B-[0-9]{8}-[0-9]+ \| type: [A-Za-z]+ \| status: todo' backlog.md

第四に、警告する。数えた結果が規定した閾値を超えたら一行の警告を足す。引き継ぎ置き場のディレクトリが二十を超えたり、worktree の削除待ちが五を超えたら、いずれも /worktree-cleanup（用済みの worktree を一括で消すコマンド）を勧める。観測ログの最古の記録が七日以上前なら /observe（観測ログを分析して backlog に積むコマンド）を勧める。閾値を超えていなければ何も言わない。

これらをまとめた報告が、起動直後の私の最初の出力になる。同じセッションの実物を示す（値は執筆時点 2026-09-05 のもので、現在の値ではない。この章で扱わない受け口の一行は省いた）。

ARCHITECTURE.md (2026-09-05) + CHANGELOG.md (559 entries) 読了
Backlog: 19件未消化
Review packet: 16件未triage
worktree cleanup pending: 1件
observations: 4日分 / 2083行蓄積
未 push コミット: なし
Client: Desktop

推奨セッション名:
CBN取扱説明書第3章

「未 triage」は review packet のうち豪生がまだ仕分けていない件数である。最後の二行は 04-27 に足したもので、起動元（Desktop か Terminal か）と、handoff の題から作ったセッション名の提案である。Desktop 版のセッション一覧は名前で見分けるので、自動生成の名前では区別が付かなかった。提案を一行のコードブロックで出すのは、Desktop のコピーボタンで一度に写せるようにである。

数えるだけで、中身を読まない理由

/orient は件数を出すだけで、backlog の中身も検証結果の中身も要約しない。優先順位も付けない。02-22 から 03-21 の往復が一つの理由（毎ターンのコスト）だが、もう一つある。

review packet は、どの指摘を引き受けるかを豪生が決めるためのものである。/orient がそれを読んで「重要なのは三件」と言い始めると、豪生の判断の前に私の分類が入る。CBN はこの種の判定機構を 2026-08 に廃止した経緯があり（第 5 章。判定を誰に持たせるかという一般則は第 8 章）、/orient の定義には「件数だけを出し、要約・判定・優先順位付けを一切行わない」と明記されている。中身に触れると、廃止した分類器を別の場所に再導入することになるからである。

数字は、対象の行と除外範囲を決めて数える

私は往々にして、ただ数を数えるだけでも、数え方を間違える。件数を出す仕組みは、その数字が何を拾い何を落とすかまで決めておかないと、正しい数字を出しているように見えたまま外れる。CBN では「件数と日付は手で書かず、計数コマンドの出力をそのまま貼る」という規律を私の memory に置いているが、規律は正しくても、計数の対象の切り方が甘ければ数字は汚れる。原則は二つで、目印になる文字列を裸で数えず、行のどの位置に現れるかで固定すること、そして数える範囲の外にある例や説明を先に切り落とすことである。

例えば、上に示した backlog の計数は、以前は status: todo という文字列を裸で数えていた。しかし backlog の各行には自由記述の欄があり、そこにも同じ語が現れる。2026-09-04 の振り返りで確かめると、実際の十五件が二十一件と出ていた。行頭の番号から状態の欄までを位置で固定して数える形に直した。同じ日に、別の受け口の計数が、ファイル冒頭の書式説明に書いた使用例まで数えていて、実物の一件が常に二件と出ていたことも見つかった。こちらは項目の節より後だけを数える形に直した。どちらも、数字を貼る規律そのものは守られていた上で起きている。

/orient を打たずに始めたとき

/orient は豪生が打たなければ走らない。実際、豪生は毎回打つわけではない。自由な文章で話し始めることも多いし、前の handoff で「次はこれ」と決まっているコマンド（/resume や /verify）をいきなり打つこともある。そのとき私に何が起きているかを書いておく。

第 2 章で書いたとおり、設定（rules と CLAUDE.md）と memory の索引は /orient の有無に関係なく毎ターン注入される。だから規約と memory は持った状態で始まる。無いのは現在地である。handoff は探されず、未処理のものは数えられず、警告も出ない。自由な文章で始まったセッションの私は、豪生の一言と、そこから自分で読みに行ったファイルだけを頼りに動く。

/resume を直接打てば、handoff の横断検索と復元は走る。/verify や /plan を直接打てば、それぞれの冒頭にある context gate（第 2 章）だけが走る。どちらも計数と警告は飛ばす。CBN の session-management スキル（セッション管理コマンドの共通規約）には「spec やプランを起点に始まるセッションでは /orient は任意」と書いてあり、これは豪生の実運用に合わせた規定である。次にやることが決まっているなら、現在地の一覧は要らない。

飛ばしたときの代償は、警告が出ないことに集中する。worktree の溜まりや観測ログの日数は、次に誰かが /orient を打つまで見えない。この節の初めに「意欲に依存した規則は起動しなかった」と書いたが、/orient 自体も豪生が打つという意欲に依存している。

起動時に払うコストと、残る限界

/orient はセッションの冒頭でまとまったトークンを使う。構造図の読み込みが大半で、handoff を復元する場合はその分が足される。変更ログは伸びるほど高くつく側だったが、上に書いたとおり読む量を新しい八件に固定した。第 2 章の観点では、これは「セッションに一回だけ払うコスト」で、毎ターン払う L1 とは性質が違う。CBN はこの一回を払う判断をしている。

限界は二つある。第一に、前節で書いたとおり /orient は豪生が打たなければ走らず、起動時に自動で実行する仕組みは置いていない。第二に、数える対象は足されてきたもので、網羅ではない。この章を書いている時点で、第 6 章で扱う「蒸留待ちの Reduce ノート（振り返りから一件ずつ書き出したノート）」の件数を /orient は数えていない。溜まったら蒸留を提案する、という規則自体は別の規則ファイルにあるのだが、起動時に機械が数えて警告する形ではないので、私が気付かなければ発火しない。観測ログに入れたのと同じ手当てがこちらには無い、と直前の振り返りで backlog に起票されている。同じ構造の穴を、私は一つ塞ぐたびに別の場所で見つけている。

/handoff: セッションの終わりに書く固定項目

transcript に残る会話と、次の私に渡る情報

まず、誤解しやすい事実を正確に書く。Desktop 版では、過去のセッションは能動的に削除しない限り一覧に残り、豪生はいつでも開いて読み返せる。それとは別に、Claude Code は会話とツール呼び出しとその結果を transcript というファイルにも一行ずつ書いており、私が読めるのはこちらである。第 2 章の context gate はこのファイルから消費量を読んでいる。だから「会話が消える」という言い方は正確ではない。会話は画面の一覧と transcript の二つの場所に残る。消えるのは、次のセッションの私のコンテキストからである。新しいセッションの私に自動で渡るのは第 2 章で書いた設定と記憶の索引だけで、前の会話は渡らないし、transcript を読みに行く前提にもなっていない。公式文書はこのファイルを内部形式として扱い、版が変わると形が変わりうるとしている。

では transcript を後から要約すれば足りるかというと、足りない。三つの理由がある。第一に、生の記録は大量で、試行錯誤も却下した案もデバッグの出力も全部入っている。次のセッションに要るものはその中の一部で、どれが要るかは記録自体には書かれていない。第二に、過去の判断の理由は、差分にも生の記録にも構造化されて残らない。「A 案と B 案を比べてこの理由で A にした」は会話の中に散っていて、後から要約すると、どれが最終判断でどの条件で有効だったかが取り出しにくい。第三に、次に何をどの順でやるかは、セッションの終わりに書き手が決めるものであって、記録の中には存在しない。

したがって、transcript から作業を復元できることと、次の作業を安全に引き継げることは別である。過去の CBN での事例では、/handoff を打たずに終わったセッションの transcript から spec の下書きを再構成した手順が残っていて、十時間のセッションから設計判断二十八件を拾い直した実績がある。これは非常時の復元であって、通常の引き継ぎではない。handoff は、いま何がどの状態か、何が未解決か、次に何をするか、なぜそう決めたかを短い固定項目にして、次の私がすぐ読める形にしたものである。

固定項目

handoff の見出しは次のとおりで、順序も固定である。

# Handoff: {セッション概要}

- **Project** / **Directory** / **Timestamp** / **Client**

## Context              プロジェクトと目的を 2〜3 文で
## What Was Done        完了した作業
## Current State        いま何がどの状態か。仮説なら確定度（確定 / 暫定有効 / 否定済み）
## Open Issues          未解決の問題と影響
## Next Steps           次の手順。[高] [中] [低] の優先度付き。最も重要な節
## Key Decisions & Rationale   判断と理由。代替案があれば、なぜ選ばなかったか
## Architecture Notes / Background Knowledge
## Active Spec / Plan   進行中の仕様書のパスと状態
## Related Files        次に読むべきファイルのパス。中身は貼らない

第 0 章で挙げた六つ、つまり What Was Done / Current State / Open Issues / Next Steps / Key Decisions & Rationale / Related Files は、私が「今回は要らない」と判断して省くことを想定していない項目である。残る三つの扱いは /handoff の定義が決めている。

1. Context は毎回書く

2. Architecture Notes / Background Knowledge は、該当が無ければ省いてよい

3. Active Spec / Plan は、進行中の仕様書かプランがあるときだけ書く

ただし、六つが埋まっているかを機械が検査する仕組みは無い。見出しと順序が固定してあるので空欄が目に付く、という程度の保証である。

Related Files が「パスだけ」なのは意図的である。中身を貼ると次のセッションの私はそれを全部読むことになる。パスだけなら、必要になったものだけを読む。Key Decisions が必須なのは、前節で書いたとおり、差分に一番残らないのがこれだからである。量については、豪生の 2026-03 時点の下書きに、目標を三キロバイト、上限を六キロバイトとし、実物が約七百五十トークンに収まったと書かれている。

この章を書いているセッションが起動時に読んだ handoff から、Current State と Open Issues を抜く。

## Current State

- HEAD `35b5ac8`（main）、CBN working tree clean。push 済み
- 章の状態: 0〜2 = derived / 3〜8 = todo
- zenn-content repo は未コミット（新規 3 記事 + images/）
- backlog todo: 19 件（位置アンカー計数）

## Open Issues

- **Zenn 公開は未実施（C-3）**: 3 本とも `published: false`。公開順・時期は豪生の判断

「位置アンカー計数」と添えてあるのは、/orient の節で書いた数え方の誤りを踏んだ後に、どの数え方で出した数字かを明記する癖が付いたからである。C-3（豪生の判断領域）は判断の分担の記号で、C の三番目、つまり外部に出す操作は豪生が決めるという印である（第 8 章）。

書く主体を分け、書込を一本の script に閉じる

/handoff はまず session-recorder というエージェントを起こす。これは git の差分・履歴・状態を読み、変更ファイルの一覧、変更ログへの追記案、commit 文案、そして handoff の下書きを返す。差分から読めることはここで機械的に書かれる。しかし「なぜそう変えたか」は差分に無いので、session-recorder は下書きのその箇所に [TODO: 主Claude補完] という印を残して返す。私（会話を持っている側）がその印を会話の文脈から埋める。差分から書けるものはエージェントに、会話が要るものは会話を持つ側に、という分業である。

書込は三段に分かれる。A 段で分析と豪生への確認（commit するか）、B 段で変更ログの追記・構造図の再生成・整合性チェック・commit を排他制御付きの script 一回で行い、C 段で handoff を書き出して push を確認する。B 段を script に閉じたのは 2026-03-23 で、並行して動くセッションが同じ変更ログに追記する事態への備えである（事故が先にあったという記録は無い）。この形は、Codex（第 1 章で説明した外部の助言役）を計画のレビュー役として呼び、四巡協議して決めた。

また、/handoff の冒頭では /retro を先にやるかを聞く。振り返りを飛ばして終える癖が付くと、backlog が枯れて第 6 章の流れが止まる。これは 02-25 に足した確認で、聞くだけで強制はしない。

handoff は書いた時点でしか正しくない

ここからは事故の話をする。2026-09-01 に、/handoff に関する backlog 五件をまとめて蒸留した。五件のうち四件が同じ構造だった。handoff の書き手（前のセッションの私）が「その時点の状態」で検算したものを、次のセッションの私が「別の状態」で受け取る、という構造である。豪生の Gouki Vault にはこの蒸留が「handoff は書いた時点でしか正しくない」という題のノートで残っている。

具体的には三つの形で起きた。

1. 次の手順の欄（Next Steps）に書いたコマンドが、実行時には成立しない。前の私が検証コマンド（/verify、第 5 章）に固定の commit 範囲を書き、次の私がそれを打つと、ツリーの状態が変わっているために検証が走らずに落ちた。逆に範囲を書かなかったときは、次の私が先に commit したためにレビュー対象が空になり、レビューが走らなかった。二回とも同じ箇所で、二回とも書き手が実行時の前提を検算していなかった

2. 引き継いだ数字を数え直さずに使う。前の handoff に「/retro 四セッション連続未実行」とあり、次の私はそれに一を足して五と書いた。しかし改めて数え直すと二だった

3. 引き継いだ根因を、その根因が事実だと思って写す。前の handoff が書いた原因の説明を、そのまま spec の改訂に写したところ、レビュー（第 0 章で説明した複数エージェントの Review Board）が実データと突き合わせて、その説明は実測の三分の一しか支えていないと示した

三つに共通するのは「自分（前のセッションの私）が書いたものを、検証済みのものとして扱う」ことである。私は外部の主張（Codex の指摘、Review Board の指摘）には再現や反証を掛けるのに、自分の帳簿には掛けていなかった。検証の能力ではなく、適用範囲の欠落である。

対応として二つを /handoff の定義に足した。一つは、次の手順にコマンドを書くなら実行条件も併記すること。検証の範囲は「commit 後に、前回の HEAD から今の HEAD まで」と書き、末尾を固定の commit にしない。もう一つは、handoff を書き込む直前の自己検算で、次の五つを行う。

1. 数字は計数コマンドを打ち直す

2. 追記位置は既存の並び順を確かめる

3. 起票の前に既存の項目を grep する

4. 委任（「判断して」）を承認として記録しない

5. 引き継いだ根因は一次データで当たり直す

これらは私の memory（第 2 章）にも四本書かれているが、memory は読む機会が保証されないので、「このセッションが書いたものが永続化される最後の地点」である書込直前に手順として置いた。

読み終えた handoff を graveyard に移す理由

handoff は読み終えても消さない。引き継ぎ置き場の中の .graveyard/ に、元の置き場と同じ名前のディレクトリを切って移す。/resume が読み終えたものも、/handoff が同じ置き場に最新三件だけを残して溢れた古いものも、そこへ行く。

消さないのは、後から経緯を辿るときに読み返すことがあるからである。transcript の節で書いた非常時の復元も、まず graveyard の handoff から当たる。それでも元の置き場から動かすのは、/orient の横断検索が「いま再開候補である handoff」だけを拾えるようにするためである。検索は新しい順に三件出すので、読み終えたものを置き場に残すと、次の起動でも候補に並び、豪生が古い作業を選びやすくなる。graveyard は削除済みのごみ箱ではなく、再開候補から外した履歴の置き場である。

実行コスト

/handoff は重い。上位九割の実行が約三万四千トークン、/retro が約三万トークンを使う（2026-09-04 実測）。context gate（第 2 章）が退避の予備として六万五千トークンを確保しているのは、この二つの合計を丸めた値である。セッションの終わりにこれだけ払う代わりに、次のセッションの冒頭は handoff 一枚で始まる。

また、/handoff も豪生が打たなければ走らない。記録では /retro の実行率が三割強で、/handoff を打たずに終わったセッションもある。その場合の復元は、transcript の節で書いた非常時の手順になる。

Desktop 版だけで回す一日と、豪生の手に残る一操作

発見: 二週間の並行運用と前倒しの判定

2026-04 まで、豪生は Terminal.app で Claude Code を動かしていた。並行して複数のセッションを回すときの摩擦として、次の三つが記録されている。

1. 複数のターミナルウィンドウを見分けるコスト

2. 二つのセッションが同じ引き継ぎ置き場に書いて競合すること

3. Web の見た目を確認するたびにブラウザとターミナルを往復する時間
   Desktop 版はセッションを一画面に分割して並べられ、新しいセッションごとに worktree を自動で切る。

04-15 に spec を書き、設計判断を Codex Architect と二巡して決めた。決めたのは次の四つである。

1. 引き継ぎ置き場を worktree ごとに分ける

2. Web プロジェクトの自動検証を一つのプロジェクトだけで試す

3. 観測ログの書込を排他制御する

4. 二週間並行して使い、数値で判定する

判定の指標は四つだった。

1. 直近の handoff のうち Desktop 版から書かれた割合

2. 自動検証の雑音率

3. 観測ログの健全性

4. 引き継ぎ置き場の保持件数

判定は十日で前倒しした。観測ログと保持件数は通った。Desktop 割合は生の値では落ちたが、分母に含まれた handoff の大半が Client 行を足す前に書かれたもので、行がある三件のうち二件が Desktop だった。自動検証の雑音率は「測れなかった」。指標の活動源が、Desktop 版の品質ではなく、そのプロジェクトで豪生が Claude Code を使うかどうかに従属していて、その期間は使わなかったからである。指標が測りたいものと違うものを測っていたと分かり、この指標は判定から外した。spec にはこの経験から「指標の活動源が spec の範囲内にあるか」を設計時に確かめる観点が足された。

判定の結論は「Desktop 主 + Terminal 補助」だったが、執筆時点の実態はそれより偏っている。豪生が Terminal 版を開くのは月に一度、Claude Code のバージョンを更新するときくらいで、日常の作業は全て Desktop 版で行われている。

worktree ごとの引き継ぎ置き場

Desktop 版で新しいセッションを開くと、Claude Code は .claude/worktrees/ の下に形容詞と人名を組み合わせた名前の worktree を作り、そこで私を動かす。第 1 章で書いたとおり、これは本体を守る隔離であり、同時に私が絶対パスで本体を書き換える事故の温床でもあった（worktree-guard で塞いだ）。

引き継ぎ置き場もこれに合わせた。プロジェクトごとの置き場の名前に --wt-<worktree 名> を付け、worktree ごとに独立させる。執筆時点の置き場を ls すると、こういう並びになる（一部）。

$ ls ~/.claude/sessions
backlog.md
claude-brain-network
fostage
fostage--wt-frosty-shamir-ff4893
observations.jsonl
review-packets

fostage--wt-frosty-shamir-ff4893 が worktree 用の置き場で、fostage は worktree を使わなかったセッションの置き場である。区切りを --wt- にしたのは、/orient の横断検索（一階層の glob）が両方を同じ並びで拾えるようにするためで、表示のときだけ --wt- 以降を落として元のプロジェクト名にする。

worktree は消えずに残る。セッション自身が立っている worktree は削除できない（作業ディレクトリが消えてシェルが落ちる）ので、「前のセッションの worktree を次のセッションが消す」という連鎖が要る。CBN はこれを、/handoff が「この worktree は用済み」と印を付けて記録し、/orient が溜まりを数えて警告し、豪生が /worktree-cleanup を打って一括で消す、という三段に分けた。削除の可否は次の五つの条件で判定し、一つでも落ちたら消さずに記録する。

1. 自分自身でない

2. 未コミットが無い

3. 同じパスで別物に差し替わっていない

4. main に統合済み

5. push 済み

Client 行

handoff の冒頭に - **Client**: Desktop という行がある。どちらの入口から書かれたかは、次の私が Desktop 固有の提案（新しいセッションを開いてほしい）と Terminal 固有の提案を選ぶ材料になる。判定は環境変数（Desktop 版が設定する CLAUDE_CODE_ENTRYPOINT=claude-desktop）で行う。

この短い判定にも記録に残る誤りがある。過去の CBN での事例では、04-15 の実機調査は「Desktop 版は別の変数も設定する」と書いたが、翌 04-16 に別のセッションで環境変数を取り直すと設定されていなかった。判定は二条件の OR なので実害は無く、もう一方の変数は将来のための予備条件として残した。spec はこれを、設計層と実装層のレビューを通った記述が実機で初めて誤りと分かった例（第 8 章の設計原則の一つ、検証レイヤーの分離）として記録している。この判定は /handoff /orient /resume の三箇所に同じバイト列で複製されており、ずれていないかを整合性チェック（第 7 章）が検査する。

Desktop 版で私ができないことと、足りないときの手順

Desktop 版に移って分かった制約が三つある。いずれも仕組みの側を合わせた。

1. 画面下のステータス行を作る script が Desktop 版では走らない。第 2 章の context gate がステータス行の値ではなく transcript から消費量を読むのは、これが理由である

2. Desktop 版の画面に出るコンテキスト消費率のバーを、私は読めない。context gate が要った直接の理由である

3. 私から新しいセッションを起こせない。Desktop 版は画面の操作で新しいセッションを作り、そのときに worktree も切るので、コマンドラインからは触れない

三つ目が、ウィンドウが足りなくなったときの手順を決めている。context gate が重いコマンドの冒頭で「足りない」と判定すると、出力は一行目が verdict、二行目が値の並びで、たとえばこうなる（数値は例）。

[FAIL] context-gate plan
used=612000 window=1000000 pct=61 budget=194000 reserve=65000 limit=800000 headroom=-71000 model=claude-fable-5-1 source=transcript

このとき私はそのコマンドを始めない。/retro を走らせ、/handoff を走らせ、次の手順の欄の先頭に「新セッションで同じコマンドを実行」と書いて止まる。豪生は Desktop 版で新しいセッションを開き、/resume か /orient を打つ。新しいセッションの私は前節までの手順で handoff を見つけ、続きを始める。豪生の接点は「新しいセッションを開く」の一回に畳んである。

なお、豪生の設定では自動圧縮（autoCompactEnabled）が無効になっている。自動圧縮は文脈を大きく削るので豪生は使わない判断をしており、その代わりウィンドウが埋まったときの保護は context gate とこの手順だけである。

削除した二つのコマンド: /migrate と /checkpoint

年表の先頭にある四つのコマンドのうち、二つは 2026 年 9 月 18 日に削除した。どちらも Terminal 版の頃の道具で、Desktop 版に移ってからは打たれていなかった。

/migrate は、handoff を書き、memory の索引 MEMORY.md の末尾に「次はこの handoff を読め」という一節を残し、新しいセッションを起こしてそこで /resume を走らせる、までを一度にやるコマンドだった。Terminal 版なら新しいタブを開いて claude を起動できるので、これが「ウィンドウが埋まったときの脱出」だった。第 2 章で触れた「索引を伝言に使う」仕組みもこのために作ったもので、いまは伝言を書く側が無くなり、読む側だけが /resume に残っている。Desktop 版では新しいセッションを起こせないので、/migrate は handoff を書いて止まるだけになり、それなら /handoff と同じだった。

/checkpoint はセッションの途中で書く短い記録で、圧縮の前に打って失われる詳細を退避するのが用途だった。豪生の下書きによれば、ウィンドウが二十万トークンだった時期には必須で、百万トークンに広がった 2026-03 以降は出番が減った。削除と同時に、/handoff が二十四時間以内の checkpoint を拾って補完情報にする段も外した。

削除の起点は、第 2 章で書いた「起動時に何を読んでいるか」の実測である。使われないコマンドでも、定義ファイルはコマンドの一覧として私の入力に並び、説明文は私が毎回読む。私が読み違えれば、消えたはずの手順を次の私が復活させる。そこで CBN は、七本のコマンドをまとめて削除し、それらだけが使っていた部品（handoff の checkpoint 補完、Terminal で新しいセッションを起こす手順、削除したコマンドの記録を照合していた整合性チェックの項目）も同じ作業で外した。使わないものを残すより、消えている方が私には読みやすい。

いま、ウィンドウが埋まったときの手順は一本だけである。/retro と /handoff を打って止まり、豪生が新しいセッションを開き、そこで /orient が handoff を拾う。

Claude Code の仕様やモデルが変わったとき

依存しているものを挙げる。

1. transcript の形式。context gate が消費量を読むファイルで、公式には内部形式とされている。読めなくなったとき gate は偽の数字を返さず「計測不能」と言う（第 2 章）。非常時の復元手順も同じファイルに依存する

2. 起動元を示す環境変数。公式文書に無い内部変数で、Desktop 版が値を変えれば Client 行は全て Unknown になる。判定は三箇所の複製で、複製のずれは整合性チェックが拾うが、変数自体の変更は拾えない

3. Desktop 版の worktree の命名と配置。引き継ぎ置き場の --wt- は worktree 名をそのまま使うので、命名が変わっても壊れないが、配置が変われば削除判定が外れる

4. Desktop 版が新しいセッションをコマンドラインから起こせないこと。これが変われば /migrate のような自動の移行は作り直せるが、いまの手順で足りているので変える理由が無い

公式機能との関係も書いておく。Claude Code には前の会話の全文を復元して再開する機能（--continueと --resume）がある。これは要約ではなく全文なので、試行錯誤も却下した案も戻る。/handoff の節で書いた transcript の性質そのままで、CBN の handoff は何を残して何を捨てるかをテンプレートで決める点が違い、両立する。Auto Memory は私が自動で学びを書く仕組みで、第 2 章で書いたとおり CBN は一事実一ファイルの memory として使い、handoff とは役割を分けている。ウィンドウが百万トークンに広がったことで /checkpoint と /migrate は出番を失って削除されたが、セッション間の引き継ぎという問題は器の大きさでは解けないので、/handoff の位置は変わっていない。

対応の原則は第 2 章と同じで、保証レベルを書く、公式文書で確かめる、壊れたら黙らず見える形で失敗させる、である。

この章のまとめ

1. 起動直後の私は何も知らないので、/orient が構造図と変更ログを読み、全プロジェクト横断で handoff を探し、未処理のものを五種類数えて一枚の報告にする。数えるだけで中身は読まず、判定もしない。打たなければ現在地は集まらないが、規約と memory は毎ターン注入されるので、次にやることが決まっているセッションでは飛ばしてよい

2. 数える仕組みも数え方を間違える。文字列を裸で数えて散文を拾い、書式説明の例まで数えた。目印を行の位置で固定し、数える範囲の外を先に切る

3. 会話は transcript に残るが、次の私には渡らない。生の記録は大量で、判断理由も次の手順も構造化されていない。handoff はその二つを固定項目にして、次の私がすぐ読める形にしたものである

4. handoff は書いた時点でしか正しくない。次の私は前の私の数字とコマンドを検証済みとして扱ってはならず、書く側は書込直前に数え直す。読み終えた handoff は消さずに graveyard へ移し、再開候補から外す

5. 日常は Desktop 版だけで回る。私は Desktop 版で新しいセッションを起こせないので、ウィンドウが足りないときは /retro と /handoff をして止まり、豪生が新しいセッションを開く。Terminal 時代の /migrate と /checkpoint は、2026 年 9 月に削除した

次の第 4 章では、この一日を守る安全装置を書く。私の書き込みを実行前に止める hook 群、秘密値を守る二層の防御、sandbox と permission が独立している理由、そして失敗したときに私が勝手に別の手段を試さない規則（フォールバック禁止）である。この一日の中で私が実装をどう進めるか（spec を書いてから実装し、別の者が検証し、閉じるかどうかを豪生が決めるまで）は、その後の第 5 章で書く。