Claude Code の引き継ぎを、仕組みにする

昼に止めたリファクタリングの続きを、夜、新しい窓でそのまま再開できます。Claude Code の引き継ぎは、もう手順として出回っています。引き継ぎファイル（handoff.md）を repo に置く人、スラッシュコマンドにする人、スキルやプラグインにする人がいます。

どれも効きます。効き方は素朴です。

コミットしたファイルが1つあれば、次のセッションの1手目は「まずそれを開く」で決まり、探さずに済みます。毎回同じ見出しが出るコマンドにしておけば、来週も同じ形で出てきます。

どれも私たちは通ってきましたし、空の窓よりはどれでも有ったほうがいい。

では、どのくらい近いところから始まるのか。

それを見るために、セッションの引き継ぎ文を貼らずに、新しい窓を1つ開きました。1通目はこれだけです —— 計画のある場所を見て、続きをやって、と1行。

その計画はリポジトリの外の盤面にあります。この記事で言う層4です。そこには、こちらが書いた申し送り ——「作業ツリーは clean、main はこのコミット」—— も入っていました。

貼らなかったのは、窓への1文字だけです。書いてあったものを消したわけではありません。

立ち上がりました。どのリポジトリにいるか、直前の作業が何の話だったかを、把握していました。そのうえで、頼んでいないことを1つやりました。

セッションの文脈の先頭には、こちらが何もしないうちから直近5本のコミットの題名が載っていました。そしてその先頭が、申し送りの名指ししたコミットと違っていたのです。

そこから確かめに行きました —— git status、gh pr list、そして git show。打った相手は、申し送りが名指ししていたコミット（5本のうち2本目）です。こちらの申し送りは、もう古くなっていました。ハッシュを書いた後に、同じ回で2本コミットしていたからです。

これがこの記事の出発点で、先に置いておく価値があります。

古い引き継ぎを捕まえたのは、セッションが勤勉だったからではありません。2つの層が、その場で食い違ったからです —— こちらが手で書いた層と、書かなくても勝手に届く層です。

みんながやっている5つ。全部、効きます

新しい話は1つもありません。特定の道具にも依存しません。まだやっていないなら、まずここからです。

1. 引き継ぎファイル（handoff.md）を書いて、コミットする。リポジトリの中のファイルは、どの窓のどのセッションからも、どの端末からも読めます。そして、会話の引き継ぎ（チャットの中だけで続きを渡すやり方）が越えられない1つを越えます —— 窓を閉じること。書くのは「いま進行中のもの」だけにします。

2. スラッシュコマンドかスキルにする。毎回同じ形が出てくることに価値があります。自動化そのものではなく、同じ見出しが毎回並ぶので次のセッションが「どこを見ればいいか」を覚える、そちらのほうが効きます。私たちのものは、書き始める前に git status --short と gh pr list --state open を引きます。「たぶん clean」は、次のセッションが確かめる術を持たないからです。

3. 恒久のルールは、引き継ぎ文ではなく instruction file に置く。CLAUDE.md（あるいは AGENTS.md）は、誰も貼らなくても毎回読まれます。来月も真であることは、そちらに書きます。逆に言うと、毎回の引き継ぎ文に貼り直している一節があるなら、それは置き場所を間違えたルールです。

この3つ目は、それだけで1本になる話です。対になる記事に「Claude Code がルールを忘れる、の正体」を書きました —— この記事の末尾からたどれます。そちらも、原因は記憶ではなく、ルールの書き方のほうにありました。

4. メモリ機能を使う。頼まなくても、小さくて長持ちする事実をセッションをまたいで運びます。これについては後で戻ってきます。思っていたより多くの仕事をしていました。

5. コミットメッセージを、引き継ぎのつもりで書く。全員が忘れた頃にも、順番と日付つきで確実に残っている唯一のものです。ほとんど費用がかからないうえに、予想していなかった形で戻ってきます。

それでも1つ、残るもの

問題は、上の5つが効かないことではありません。こちらです。

引き継ぎが効いたとき、どの部分が効いたのかを教えてくれるものが、どこにも無い。

理屈の話に聞こえますが、実害が2つあります。

1つ目 —— 引き継ぎ文が太る。次のセッションが迷うたびに1段落足します。減らすことは無い。どの段落が効いていたのか分からないからです。私たちのものは、書くこと自体がセッションの予算のうちのそれなりの割合になっていました。

2つ目のほうが重い —— 古くなる部分が、貼られ続ける。コミットのハッシュ、開いている PR、「作業ツリーは clean」。これは全部、ある瞬間の写真です。

私たちの申し送りは main の位置を書いていて、書いた時点では正しかった。そのあと同じ回で2本コミットしました。次のセッションは、その申し送りを読み、勝手に届いていたコミットの題名と突き合わせました。食い違いを見つけ、正しく計画から外れて、そちらを処理しました。

振る舞いとしては満点です。ただ、最初の数手を、こちらが書いてこちらが古くした文書の突き合わせに使いました。

次のセッションに、実際は何が届いているのか

そこで分けました。コンテキストの引き継ぎは、1本の経路で起きているわけではありません。新しいセッションが何かを知っているとき、それは4つの層のどれかから届いています。そのうち、あなたが書いた引き継ぎ文は1つだけです。

2つ、予想と違いました。

層2（自動メモリ）が、約半分をやっていた

次のセッションに渡したい作法を、書き出してみました。小さくて、痛い目を見て得たもの ——「書き込みは、返事ではなく実際に着いたかで判定する」「数字を出す前に、別の入力でもう一度引く」といった類です。8つありました。

そのうえで、メモリの中身を開いて読みました。8つのうち、3つは丸ごと、もう1つは部分的に、すでにそこにありました。さらにもう1つは、始める前にリポジトリの外の計画（層4）へ、こちらが書き出していました。

残るのは3つです —— 8つから、メモリが運んでいた4つを引き、すでによそに出していた1つを引いた残り。この3つだけが、どの層にも無く、こちらの頭の中とこれから書く引き継ぎ文にしかありませんでした。つまり半分は、こちらが書いても書かなくても届きます。

私はその同じ日に、別の報告に「効いている作法は、自分たちがファイルとして残しているから効いている」と書いていました。それは違っていました。というより、手柄を別の層に付けていたのは私です。

数えていなかった層が、半分を運んでいました。

層3（git）は、何もしなくても届く

セッションの文脈の先頭に、こちらが何かする前から、直近5本のコミットの題名が載っていました。取りに行ったのではなく、渡されていました。冒頭で書いた「古い申し送りが捕まった」のも、これです —— こちらが手で書いたハッシュが、こちらが書いていない一覧の先頭と違っていました。

その食い違いを追って、セッションは申し送りが名指ししていたコミット（一覧の先頭ではなく2本目）に git show を打ちました。本文が返ってきます。私たちはコミットメッセージを丁寧に書くので、そこには数段落の経緯が書いてあります。渡すつもりのなかったものを、詳しく渡していました。

これは良い知らせと罠が、同じ一文に入っています。上の Tips 5 は、思っているより効きます。同時に、git の履歴は、あなたがそのつもりで書いていなくても、すでに公開している引き継ぎです。

層4だけが、選べて、読みに行かないと届かない

この非対称が、問題の形そのものです。

自分のリポジトリで1回やってみる

セッション1回で終わります。そして、引き継ぎ文に何を書くかが変わります。

1. 1. 始める前に、メモリの中身を写しておく。Claude Code なら ~/.claude/projects/<プロジェクト>/memory/ の下です。先にやること —— 後から見ると、「セッションが知っていたこと」と「自分がいま読んだこと」を分けられなくなります。
2. 2. 直近5本のコミット題名を控える。だいたいこれが、勝手に届く分です。
3. 3. 新しいセッションを開いて、何も貼らない。1通目は「〈計画が置いてある場所〉を見て、続きをやって」だけ。
4. 4. 最初の1〜2応答で、それが知っていたことを全部書き出す。そして1つずつ層に割り当てます —— instruction file にある／メモリにある／直近のコミット題名か git show で届く／どれにも無い。
5. 5. 層1〜3に当たったものを、引き継ぎ文から消す。残ったものだけを書く。

そして、こちらの失敗から出てくる規律がもう1つあります。残ったものの中に「変わりうる事実」（ハッシュ・開いている PR・「clean」）が含まれるなら、書いた後にそれを変えない。引き継ぎ文を最後に書くか、状態を「信じるもの」ではなく「確かめるもの」として書くか、どちらかです。

古い事実を断定した引き継ぎは、その事実を書かない引き継ぎより悪い。次のセッションには、あなたの断定のどれがまだ真なのかを見分ける手段が無いからです。

この記事が示していないこと

これが崩れる条件

どちらか一方でも出れば、沈みます。

1つ目。上の手順を回したとき、何も貼らなかったセッションが、最初の3層のどこにも無い事実を正しく述べること。instruction file にも、メモリにも、直近のコミットにも無く、読みに行かせた計画にも書いていない事実です。これが繰り返し起きるなら、4層の切り分けが何かを取りこぼしています。そして「勝手に届く分を消せ」という助言は、効いていたものを消していることになります。

2つ目。メモリを空にして、他は何も変えずに走らせて、次のセッションの振る舞いが変わらないこと。そうなら層2は私たちが思っているものを運んでおらず、「半分」という数字は自分たちのリポジトリの都合ということになります。

どちらも安く試せます。私たちの小さい数字が繰り返されるより、誰かが走らせて違う答えを出してくれるほうがいい。

4つの層のうち3つは、こちらが意図してもしなくても届き、中身を選べません。次のセッションが何を見るかを選べる層は、ちょうど1つだけで、それは誰かが読みに行かないと届かない層です。私たちが作っているのは、そこです。

Vondet（vondet.com）は、どのセッションにも属さない場所に計画を置き、エージェントが直接読み書きできるようにしたものです。引き継ぎのうち長持ちする部分に、チャットの窓でもなく、次のコミットで古くなるファイルでもない置き場を用意します。自分たちで作って、自分たちの仕事に毎日使っていて、この記事で測っていた相手もこれです。Sign up はまだ開いていません —— 順番待ちがあります。その前に、上の5手を自分のリポジトリで回して、8つのうち何がすでに届いていたかを見てください —— 私たちの数字が繰り返されるより、あなたの数字を聞きたい。