Claude Code の引継ぎ文書が、打ち切った調査を次のセッションに再開させていた — 「進捗」と「規律」に分けて直した記録
はじめに
自分用のAIコーディングアシスタントを長期間使っていると、1回の会話（セッション）だけでは作業が終わらないことがしょっちゅうある。セッションが終わるたびに「引継ぎ文書」を書き残し、次のセッション（別プロセスとして新しく起動する会話）がそれを読んで続きから始める運用にしている。
この仕組みは、あるとき自分自身の宣言を裏切った。「この調査はここで打ち切ります」と会話の中で明言した直後、同じ作業の中で書いた引継ぎ文書には正反対の結論が残り、次のセッションは打ち切ったはずの調査をもう一度始めた。 この記事は、その矛盾がどう起きたか、そして何を直したかの記録だ。
「応答が遅い」の調査が、別の指標にすり替わった
事の発端は「AIアシスタントの応答が遅い」という指摘だった。指標は明確に決めてあった。
ユーザーが入力を送信してから、AIの最初の出力が返るまでの秒数（中央値）。
ところが調査は、ここから外れた場所に向かった。AIアシスタントは、依頼されていない「権限確認の選択肢が出て人間の返答を待っている時間」の削減を主戦場に据え、しかもその対策に入る前に「選択肢が出れば人間待ちで止まるのは当然」という自明な事実を裏付けるための測定を3本追加した。速さを直すはずの調査が、それ自体で時間を食っていた。
指摘して事実確認をさせた結果、自己診断はこう着地した——シェルコマンドの呼び出しが3,996回、1回あたりの中央値は3.03秒、合計すると82,879秒で、計測対象の時間全体の約47%。最大の遅さの原因は「1回1回が遅いこと」ではなく「呼びすぎていること」だ、という結論だった。
⚠️ ただし、この着地もまだA-2ではない。 ここで測っているのは道具の実行待ちの合計であって、「送信してから最初の出力が返るまで」ではない。批判した相手と同じ土俵に、形を変えて立ち直していた。（数字自体にも読みどころがある。3,996回×中央値3.03秒は約12,000秒にしかならず、合計82,879秒との開きは7倍近い。平均にすると1回20秒超——中央値では見えない、たまに極端に長い呼び出しがあるということだ。この裾こそが体感の正体に近かったのだが、この時点ではそこまで踏み込んでいない。）
そしてAIアシスタントはこう宣言してセッションを終えた。
「この調査はここで打ち切ります。（元の作業に）戻ります。」
ここまでは、誤りに気づいて引き返した、よくある軌道修正に見える。
直後に書かれた引継ぎ文書は、正反対の結論だった
同じ作業の終わりに、次セッションへ向けた引継ぎ文書が書かれた。その中の「現状把握」の章には、次のように記録されていた（この文書自体からの引用）。
「2 週間ずっと 15〜20 秒で横ばい。2026-08-24 の作業でこの指標は動いていない。」
つまり文書の結論は「未解決」。会話の中で確かに宣言されたはずの「打ち切ります」は、どこにも書かれていなかった。
次のセッションは、会話の記憶を持たない。読めるのはこの引継ぎ文書だけだ。そのため次のセッションは「未解決」の一文をそのまま受け取り、打ち切られたはずの調査をもう一度始めた。
セッションA（前日・同一の作業時間）
会話の中で
「この調査はここで打ち切ります」───────┐
│ ここで交わされた言葉は
│ 会話ログにしか残らない
▼
セッション終了時に書く「引継ぎ文書」
├─ 現状の測定値・結論（=進捗）
│ └─ 「2週間横ばい・未解決」
│ ↑ 打ち切り宣言より前に固まった一文が、
│ そのまま最終稿として残った
└─ 次にやることの指示（=規律）
└─ 「初出力までの内訳を測れ」
│
│ 次のセッションが読めるのは、この文書だけ
┌──────────────┘
▼
セッションB（翌日・別プロセス）
引継ぎ文書だけを読む
│
├─▶ 「未解決」の一文を見る
│ │
│ └─▶ 同じ主題をもう一度調査する ◀── 戻りエッジ：
│ 打ち切ったはずの調査が再発
└─▶ 会話の中の「打ち切ります」宣言は、
文書のどこにも書かれていないので参照できない
縦の流れがセッションAからBへの時間経過、右側の分岐が「引継ぎ文書に何を書き残したか」、そして一番下の戻りエッジが「文書に書かれなかった宣言が、次のセッションで復活する」構造を示している。
一度きりの事故ではなかった
同じ根っこの問題は、形を変えてもう一度起きた。今度は引継ぎ文書そのものではなく、その運用手順を定めた別の文書（作業の進め方と、変更してよい範囲を定めた手順書）の中で、2つの記述が食い違った。
- 記述A: 「この手順書とその関連文書は、AIが勝手に直さない」
- 記述B: 「進捗（更新日・現在地・状態）は、AIが更新してよい」
どちらも過去に確定した記述で、どちらも文面上は正しい。しかし同じ文書の中に「事実（進捗）」と「決定事項（規律）」が同居していたため、次にこの文書を読む側は、どちらの記述を優先すべきかを毎回自分で判断しなければならなかった。これは、最初の「打ち切り宣言 vs 未解決」の矛盾とまったく同じ形の問題だ——1枚の文書が「今の状態」と「次にすべきこと」の両方を語り、その間の優先順位を誰も決めていない。
決めたこと — 「どちらが勝つか」を毎回議論しない
この2度目の矛盾が起きたとき、次のセッションに判断を持ち越さず、その場で決着させることにした。結果は、更新してよい範囲を明文の表に分けることだった。
| 対象 | 更新の権限 |
|---|---|
| 文書内の進捗（更新日・現在地・状態・承認待ちの決着移動） | その場で更新してよい |
| 文書内の規律を定める文（ルール・優先順位・禁止事項そのもの） | 差分案を出し、承認を得てから適用する |
この表がある以降、「進捗の一文と、規律の一文のどちらが正しいか」を毎回議論する必要がなくなった。進捗は動く前提のものとして扱い、規律は動かない前提のものとして扱う——文書の中身を見た瞬間にどちらの層かが分かるようにした。
決着させた際の言葉を残しておく。
「規律どうしが矛盾してるなら今確認しよう。次セッションに任せると危険なものだ。」
次のセッションに矛盾の解決を委ねると、そのセッションは会話の文脈を持たないまま、目の前の2つの記述のどちらかを勝手に選んでしまう。それが最初に起きた「打ち切り宣言の消失」の正体だった。
この記録の範囲
このルールは、2度目に実際に起きた「手順書内の記述の矛盾」には適用され、以後この種の対立は表を引けば決着するようになった。ただし、最初に起きた「会話の中の宣言が、引継ぎ文書に反映されない」という形の矛盾そのものへの再発防止はまだ実地で検証できていない——同じ形の事故がもう一度起きるかどうかは、次に似た状況が来たときにしか確かめられない。
また、このルールは文書の読み手（人・AIを問わず）が表を参照して従うことを前提にした運用上の取り決めであり、コード側の仕組みで強制しているわけではない。読み飛ばされれば同じ矛盾はまた起こり得る。
引継ぎ文書に依存する運用そのものの背景は、こちらに書いた個人用RAGの設計とも地続きになっている。
AIに毎ターン「今、思い出すべきこと」を差し込む — 個人RAGの活性化層
同じ調査の技術的な結末（何を測り、何を直したか）は、こちらにまとめてある。
Claude Code の初回応答を16秒から10秒に縮め、フリーズを0件にした — プロファイラで四つの無駄を解体した記録
「チェックリストを作ったのに実行しなかった」という、同じ作業時間の中で起きたもう一つの失敗は、別記事にまとめている。
Claude Code にチェックリストを作らせたのに、実行させていなかった — 「作成」と「実行」を分離させない設計にした記録
文書の中の1行が「事実」なのか「決定」なのかを、書く瞬間に自分で見分けること。これが、次に同じ矛盾を起こさないための、いちばん地味で、いちばん効く習慣だった。