セッション、こういうときどうしてますか
セッションを動かしてると、こういう瞬間ってありませんか。
- タスクの最中に「これもやりたい！」って思いついたとき
- 「なんか AI の返答が荒れたぞ！」って思ったとき
- 並列でセッションを回してて、頭がパンクしてるとき
作業がひと段落して、「よし、ここまではできた」ってなる。でもまだコミットは打てない段階。まぁセッションが長くなったら性能が落ちるって話はもうだいぶ有名ですよね。
このときに僕がやっているのは、AI にドキュメントを作らせることです。次のセッションへの発注書ですね。そこに人間の監査を入れて質を上げるというのが今回のお話です。
これ、チャットで新しい会話を始める人にも同じことは起きると思うんですが、そっちはGeminiの答えが雑になってきた人へ。会話は使い捨てでいいんですに書きました。ここでは Claude Code の話に絞ります。
セーブポイントって、もう機能でありますよね
引き継ぎのドキュメントと言われると、セーブポイントの機能がもうあるじゃないかと思う方もいると思います。たしかにその通りで、Claude Code には正式に checkpointing という機能があります。しかもこれ、プロンプトを送るたびに勝手に作られてるんですよね（100個まで保持されて、30日で消えます）。
セーブポイントっぽい操作、実は3つあります。
/resume：セッションをまたいで、中断したところを一括で復帰する/rewind：同一セッション内。地点を選んで戻せます。選べるのは5択（コードと会話／会話だけ／コードだけ／ここから先を要約／ここより前を要約）/compact：同一セッション内。会話を構造化サマリーに置き換えます。/compact focus on 〜で焦点を指示することもできます
実際に1ヶ月ぶんの履歴を数えてみたら、/clear が221回でした。それに対して /rewind は0回、/compact も0回。引き継ぎドキュメントを作ったのは18回です。（基本的に1セッションに収まるだけのタスクに切り分けられている感じですね）
ただし /resume だけは、VSCode が落ちたときの復旧の際に使っています。
前提として /rewind と /compact は同一セッション内でしか使えない操作です。選べるのは範囲か焦点までなんですよね。どれを残すかを自分で決める工程がない。/rewind は「いつ」しか選べないし、/compact は焦点を指示できても、実際に書くのは AI です。実際にセッション内でどう解釈されたのか？といったことを確認することができないんです。なので、セッション内でAIとの間に誤解が生まれたらそれを気づくことができないって感じですね。
/resume は全部持っていきます。これはセッションをあとからAIに分析させるイメージですね。これをそのまま使うのもありなんですが、トークン効率的に極力やりたくはないですね。
/rewind はガチのセーブポイントですね。特定の起点にタグを打って、またそこから再スタートするみたいなことができます。/compact のほうは、AI 自身が会話を圧縮するのが課題です。AI の出力が荒れているとして、荒れた人が圧縮したらその圧縮を信用していいのか？ってなりますよね。
ただ3つ並べてみると、これ全部「過去をどう残すか」の道具になります。地点まで戻す、要約して残す、丸ごと運ぶ。向きが全部うしろです。
発注書は逆で、何をやったかじゃなくて次に何をやるかが書いてある紙です。0回なのもたぶんそういうことで、機能が足りないんじゃなくて、僕が欲しかったものが保存じゃなかった。
AIに指示をまとめた発注書を作らせる
発注書だと思うと、わざわざドキュメントにしている理由もはっきりします。セーブデータって、人間は読まないんですよ。復元する側が読むものなので。でも発注書は、出した人が読み返して「あ、これ違う」って直すものですよね。会話の中に埋まっているうちは、自分がどう解釈されたのかを確かめられません。ドキュメントになると読み返せます。読み返せるから、AI との間にできた誤解をこっちが見つけて直せます。
そもそも、いつ渡すのか
引き継ぎを作るのは会話が重くなってからだと思われがちなんですが、人間の都合にも使えます。
- 物理的に中断されるとき（移動する、その日の作業を終える）
- 並行させたいとき（別のことを同時に走らせる）
- AIの出力が不安定になったとき（「ヒヤリハットなんで切り替えようか」）
- 長文が出されて頭が鈍ってきたとき
冒頭に挙げた3つの瞬間も、全部この側です。実際、さっきの18回のうち半分以上は6〜10手・11〜49分で撃っていて、コンテキストが溢れたから切ったわけじゃないんですよね。
続きをやるなら next、別のタスクなら new
使っているのは2つです。どっちもセッションは切り替えます。違うのは、持っていくもののほうです。
next（同じ話の続きをやる）：ゴール／現在地／再開ポイント／主要ファイル／保留・未確定／コミット状態new（別のタスクに移る）：次のタスク／引き継ぐ情報／前提・スコープ
項目は大体共通ですが、テンプレートは付録に置いておきます。分けているのはシチュエーションのほうです。
next を撃つのは、セッションに要らない話が溜まってきたときです。議論の途中で出た脇道とか、もう決着した話とか、そういうものを抱えたまま進むのがしんどくなってくる。決まったことを一回ドキュメントに起こして、そこから続きをやります。
new は、サブエージェントに投げるまでに少し議論が必要なものですね。元セッションの文脈は少しだけ要る、みたいなやつです。今のセッションの続きではないので、必要なぶんだけ持って出ます。
すり合わせた結果が、引き継ぎドキュメントになります
AI に書かせたものを、そのまま渡すわけじゃないんですよね。まず余計なものを落とします。引き継ぎドキュメントを書いてというと、Claudeさんはやったことをすべて書きがちです。放っておくと、発注書じゃなくてセーブポイントを作ってくるんですよね。そこには本筋じゃないけど「これ今やったほうがいいかも」みたいな課題がぽろっと出てくることがあって、あれを混ぜると、次のセッションが何をすればいいか分からなくなります。
だから決めていることは2つあります。ひとつめは基準です。選ぶ軸は「次にやること」であって、今やった成果物じゃありません。やった成果物はコミットしておいてもう決定済みにするのが確実ですね。ふたつめは除外で、余計な内容を混ぜないことです。単純に「引き継ぎ書を書いて」だと、セッションで踏んだ罠やそれをどう回避したのか？など結構いろんな情報を詰め込んできます。そういった教訓はファイルなどに別途切り出して保存するのが良いですね。
そのうえで読み返すと、だいたいこの3つが出てきます。
- 議論の結論が真逆になっている。長いやり取りの末に決めたことが、引き継ぎでは逆に書かれている
- 決まったことが未決になっている。「保留・未確定」の欄に、もう決めたはずのものが並んでいる
- 情報がてんこ盛りで読むのがそもそもつらい・余計な情報が書かれている
どれも、読まないと気づかない類のズレです。ドキュメントだから読めます。読むから見つかる。見つけたら、人間が直します。
この落として直す往復を抜けたものが、次のセッションに渡る発注書です。冒頭に書いた「なんか AI の返答が荒れたぞ！」の瞬間に、ちゃんと打てる手ができるということですね。
おまけで1つ。「これもやりたい」って思いついたやつは、new で持ち出せば別ペインで並行してやれます。並列で頭がパンクしてるときも同じです。あとでやろうとか思いついたタイミングで next を作っておけば、思い出さなくても余裕ができた時に作業として再開することができます。
選ぶのは軽くするためじゃありません。自分が読めるようにするためなんですよね。
付録：そのままコピーして使えるもの
本文では「項目は大体共通」と流しましたが、実物が無いと持ち帰れないと思うので置いておきます。next と new のそれぞれについて、フォーマットと、毎回同じ形で出すためのカスタムコマンドを並べます。中括弧のところを埋めれば、そのまま次のセッションの先頭に貼れます。
続きをやる next のぶん
## 引継ぎ（継続）: {トピック名}
### ゴール
{このトピックで達成したいこと 1〜2行}
### 現在地（どこまで / どこで止めた）
{中途状態を端的に。議論中なら論点、実装中なら未完部分}
### 再開ポイント（最初にやること）
{次セッションで最初に実行する具体アクション}
### 主要ファイル
- {フルパス}: {1行説明}
### 保留・未確定
- {保留した判断・選択肢とその理由}
### コミット状態
{git status / git log -3 のサマリ}
僕はこのフォーマットを Claude Code のカスタムコマンドにしていて、/session-handoff-next と打つと生成してファイルに保存するところまでやってくれます。実物から効いてる部分だけ削り出したのがこれです。.claude/commands/session-handoff-next.md に置けば動きます。
---
description: 同じトピックの継続用引継ぎプロンプトを生成
argument-hint: [トピック名]
allowed-tools: Bash, Read, Write, Glob, Grep
---
# Handoff: 継続タスク用
同じトピックを次セッションで継続再開するための引継ぎを生成する。
## Step 1: 継続に必要な分だけ集める
網羅ではなく「復元最小セット」。ゴール／現在地／再開ポイント／主要ファイル／保留・未確定／
コミット状態（`git status` と `git log -3`。未コミットがある時のみ）。
⚠️ 教訓はここに書かない。普遍的な学び（手法・注意点・再利用できるパターン）は別の置き場へ送る。
ここに残すのは、このトピック固有の復元コンテキストだけ。
## Step 2: 生成する
上の `next` のフォーマットで書く（6セクション固定。これ以上増やさない）。
内容が薄いセクションは見出しごと省く。
## Step 3: ファイルに保存して開く
`docs/tmp/handoff-next-{YYYYMMDD-HHMMSS}.md` に保存し、エディタで開く。
応答本文には保存先のパスだけを出す（全文を再掲しない）。
別のタスクに移る new のぶん
先頭が「次のタスク」なのがポイントで、ここが決まっていないと下の2つを選べません。
## 引継ぎ（新タスク開始）: {次のタスク名}
### 次のタスク
{次セッションで取り組む内容を 1〜3行で}
### 引き継ぐ情報（このタスクに関係する分だけ）
- {次タスクに効くファイル / 判断 / 制約だけ。無ければ「引き継ぐ成果物なし」}
### 前提・スコープ
- {必要なファイルパス・参照ドキュメント}
- {既知の制約・やらないこと}
コマンドのほうも同じで、Step 1 が本体です。ここが決まらないと選別が始まりません。
---
description: 別タスクへの切替え用引継ぎプロンプトを生成
argument-hint: [次のタスク名]
allowed-tools: Bash, Read, Write, Glob, Grep
---
# Handoff: 別タスク切替え用
現セッションから、次のタスクに効く情報だけを選んで渡す。
これは「現セッションの完了報告」ではない。
## Step 1: 次のタスクを確定する
引継ぎ全体の選別基準になるので、ここを最優先で固める。
⚠️ 曖昧なままファイルを作らない。何をするタスクか／現セッションのどの成果物を引き継ぐ必要があるか／
やらないことが不足していたら、必ずユーザーに確認する（推測で埋めない）。
## Step 2: 次のタスクを基準に選別する
共有するファイル・次タスクに影響する設計判断や制約・引き継ぐべき落とし穴だけを抜く。
無関係な進捗や議論ログは捨てる。引き継ぐものが無ければ「引き継ぐ成果物なし」でよい。
## Step 3: 生成する
上の `new` のフォーマットで書く。前提情報は最小限にして、AI が自力で見つけられるものは省く。
## Step 4: ファイルに保存して開く
`docs/tmp/handoff-new-{YYYYMMDD-HHMMSS}.md` に保存し、エディタで開く。
フォーマット自体はどうでもよくて、効いてるのは2つの決めごとのほうです。基準は「次にやること」、除外は余計な内容（教訓とか）を混ぜないこと。ここだけ持って帰ってもらえれば、中身は自分の書きやすい形でいいと思います。
