Claude Code のセッションを変えても仕事の文脈を失わない方法

翌朝、前の日の続きをやるつもりで新しいセッションを開いた。最初に打ったのは「昨日どこまでやったか」だった。セッションは当然知らない。知っているのは私たちだけで、私たちも細かいところは忘れている。

/clear した直後も同じだ。同じ判断を 2 回説明したことが何度もある。「この方式はやめた、理由はこれ」を、別のセッションに向けてもう一度書く。書いている間は、何も進んでいない。

文脈と呼んでいるものの中身は 2 種類ある。ひとつはコーディング規約、使っているフレームワーク、環境の癖、やってはいけない操作。これは寿命が長い。もうひとつは、この仕事は何のためか、何を決めたか、どうなったら終わりか。これは仕事が終われば用済みになる。

CLAUDE.md は前者の置き場として良くできている。毎回読まれるのが前提だから。問題は後者をそこに書き始めたときだ。終わっても消えないので伸びる。私たちのは一度 200 行を超えて、肝心な規約まで読み飛ばされるようになった。今は 200 行を目安に分けている。

試した順に書く。今でも併用しているものもある。

最初は何でも CLAUDE.md に足した。読まれるのは確実だし、置く手間もない。ただ終わった仕事の注意書きが残る。しばらく経って読むと、もう存在しない関数について警告している行がある。削る作業を誰もやらない。私たちもやらなかった。

次に、中断するときに handoff.md を書いて次のセッションに読ませた。これはかなり効いた。今でもやる。困るのは、仕事が 3 つ並行しているときにファイルが 1 つしかないこと。仕事ごとに分けると、どれが今のものか分からなくなる。

前のセッションの会話をまるごと貼るのもやった。一番正確ではある。ただ長い。肝心な決定は 100 行の中に 2 行しかなくて、読み飛ばされることがある。あと単純に、毎回貼るのが面倒だった。

/compact で要約して続けるのは、同じセッションを伸ばす分には効く。翌日には関係ない。ChatGPT で考えて Claude Code で実装する、みたいにクライアントをまたぐときにも渡らない。

クライアントの記憶機能も使っている。書き方の好み、環境の罠のような恒久的な事実はここが合う。ただ、その仕事の完了条件をここに入れる気にはならなかった。仕事ごとの情報が混ざると、終わった仕事の記憶を消す作業が増える。それにそのクライアントの中でしか読めない。

ファイルに書く方法はどれも、今どの仕事がどうなっているかを持てない。終わった仕事の分を片付けるのも人の手作業だ。会話を渡す方法はその仕事のことを全部持っているのに、セッションの外に出ない。クライアントの記憶機能は、そのクライアントの中でしか読めない。

私たちが欲しかったのはその間だった。仕事 1 件ぶんの目的と判断と完了条件が、仕事そのものにくっついていて、どのクライアントからも番号で引ける状態。

私たちのカードは、作った瞬間には完成していない。最初はタイトル 1 行だけのことが多い。会話 AI と話しながら、目的・背景・完了条件を後から足していく。最初から整った仕様を書く気力がある日は、そんなに多くない。

具体的には、話している途中で「さっきのカードに今決めたことを書いといて」と言う。決めた理由ごと追記される。私たちが議事録を書く手間はない。これが一番よく使う操作かもしれない。

効いてくるのは数週間後だ。止まっていた案件に戻るとき、「あの案件、何を話してたっけ」を AI に聞ける。添付した資料も一緒に読ませる。私たちが思い出して説明し直すのではなく、読ませてから始める。

体感では、同じ判断を 2 回説明することはほぼなくなった。残っているのは、決めたのに書かせ忘れたとき。これは私たちの落ち度で、仕組みでは防げていない。

私たちが欲しかったのは、この仕事は何のためで、何を決めて、どうなったら終わりかが、仕事そのものに書いてあることだった。しかも番号ひとつで、どのクライアントからも同じものが読めること。セッションの記憶にも、人の頭にも置きたくなかった。

1. 1仕事 1 つにカード 1 枚。カードには dz51 のような番号が付く。
2. 2カードには目的、背景と決めたこと、完了条件を置く。最初から全部埋まっている必要はない。会話の途中で「dz51 に今決めたことを書いといて」で足りる。
3. 3新しいセッションでは「dz51 を見て」と言うだけ。本文と完了条件がそのまま読まれる。前の会話は貼らない。
4. 4プロジェクト側にも目的・現状・背景を置ける。「このプロジェクトの今の状況を教えて」と言えば、プロジェクトの情報と未完了のカードがまとめて返る。恒久的な決まりごとは CLAUDE.md のまま。こっちには今の状況を置く。
5. 5仕様書や要件定義は添付する。AI が書いたものもそのまま付けられて、後のセッションは添付をそのまま読める。チャット履歴を探しに行かない。
6. 6完了条件は 1 項目ずつチェックが付いていく。どこまで済んだかがカードに残るので、途中で切っても次のセッションが拾える。
7. 7完了にできるのは人が承認したあとだけ。AI が自分の判断で完了にすることはない。証拠を一緒に残すので、何をもって終わりにしたかが後から読める。

カードの本文は短くさせていない。一度、渡すトークンを節約できるかと思って背景を削る案を試したことがある。実際に測ったら、本文 1 枚は 700 トークン台で節約にならなかった。むしろ削った側では設計判断が逆に倒れて、調べ直す往復が 2 倍以上になった。それで全文を渡すことにした。

新しいセッションの最初の 1 往復が、「昨日どこまで」から「dz51 を見て」に変わった。説明を書く時間がなくなった。

/clear が怖くなくなった。文脈がセッションの外にあるので、詰まったら捨ててよくなった。

考える AI と実装する AI の間で同じ説明を繰り返すことが減った。ChatGPT で決めて、番号を Claude Code に渡すだけになった。

解決していないこともそのまま書く。決めたことは誰かが書かないと残らない。私たちは AI に書かせているが、書かせ忘れれば消える。カードは会話の記録ではないので、試行錯誤の細かい流れは残らない (必要なら添付にする)。プロジェクト全体の決まりごとは今も CLAUDE.md の仕事で、カードに移す理由はない。あとカードが増えると、どのカードに何を書いたかを探す手間が出てくる。検索は単語の一致なので、意味では引けない。