会話が途切れると振り出しに戻る、本当の原因

長い作業をAIに任せていると、接続の切断や利用上限、あるいは新しいセッションへの移行によって、それまでの経緯がまとめて消えてしまうことがあります。多くの解説記事は、この現象を「モデルの記憶力の限界」として扱い、対策としてコンテキストウィンドウの大きいモデルに乗り換えることや、会話を要約して次のチャットに貼り付けることを勧めています。

しかしこの捉え方には抜けがあります。そもそも進捗や決定事項を会話の中にしか置いていなければ、モデルをどれだけ強化しても、会話が切れた瞬間に参照できる場所自体がなくなってしまいます。実際に、コンテキストウィンドウが大きいモデルへ切り替えても、この問題は解決しません。1つのセッションの中で参照できる範囲が広がるだけで、セッションをまたいだ引き継ぎの仕組みそのものは変わらないためです。会話が終われば、参照先は結局ゼロに戻ります。

問題の本質は記憶力ではなく、作業の状態を会話の外に残しておく「引き継ぎ設計」が最初から存在していないことにあります。

引き継ぎに必要な情報は「4種類」に整理できる

会話の外に何を残せばよいかを考えるとき、闇雲に全履歴を保存しても意味がありません。次に作業を引き継ぐ側（AIであっても人であっても）が本当に必要とする情報は、次の4種類に整理できます。

  • 今どこまで終わったか（完了した範囲とその根拠）
  • 次に何をするか（未着手のタスクと優先順位）
  • 確定した決定事項とその理由（なぜその選択にしたか）
  • 触ってはいけない前提（変更すると他の部分が壊れる制約）

たとえば「このAPIのレスポンス形式は変更禁止」「この設定値は本番環境と揃えるため固定」といった前提を書き残しておかないと、次の作業者が良かれと思って変更し、既存の動作を壊してしまうことがあります。

進捗ファイルに何を書くかを考えるとき、逆に「何を書かないか」も同じくらい重要です。検討の過程で試した選択肢や、途中でボツにした案をすべて残すと、ファイルは膨らむ一方で、次に読む人がどこが本当に重要な情報かを見分けられなくなります。試行錯誤の過程は記録から外し、最終的な結論とその理由だけを残すことで、短時間で読める記録に保てます。たとえば、ある実装方法を試して失敗した記録よりも、「Aは採用しない。理由はB」という結論だけを残すほうが、次に読む人にとって有用です。

この4つのうち、抜け落ちやすいのが3番目の「理由」です。結論だけを記録して理由を残さないと、次に読んだ人は、なぜその決定に至ったかを判断できず、同じ検討を最初からやり直すことになります。

要約を渡しても同じ議論を繰り返してしまう理由

会話が長くなったときの定番の対処法は、それまでのやり取りを要約して新しいチャットの冒頭に貼り付けることです。この方法は「何をしたか」という結論は引き継げますが、「なぜそうしたか」という理由まではきれいに残らないことがほとんどです。

理由が抜け落ちると何が起きるかというと、再開後のAIは結論だけを見て、本当にこの方針でよいのかを改めて検討し始めます。その結果、前回すでに検討し却下した案が再び提案され、同じ議論を繰り返すことになります。要約を引き継ぐこと自体が悪いのではなく、要約が結論だけに寄りやすく、判断根拠が落ちやすいことが問題です。

これを防ぐには、決定事項を書くときに必ず理由もセットで残す運用にすることが有効です。「Aを採用した」ではなく「BではなくAを採用した。理由はBが将来の変更に弱いため」という形で書けば、再開時に同じ検討をやり直す必要がなくなります。

進捗は「作業の最後」でなく「区切りごと」に書く

進捗の記録は、作業がすべて終わってからまとめて書けばよいと考えがちです。しかし、この運用には弱点があります。作業の途中で接続が切れたり、時間切れで中断したりした場合、記録を書く前に作業が止まってしまい、何も残らないまま次回を迎えることになるためです。

これを避けるには、区切りごとに、その都度、進捗ファイルへ追記する運用に切り替えます。区切りの例としては、次のようなタイミングが挙げられます。

  • 1つの機能や工程が完了した時点
  • 大きな仕様変更や方針を決めた時点
  • 次回に持ち越す判断が発生した時点

最後にまとめて書く前提をやめるだけで、どの地点で中断しても、直前の区切りまでの状態が確実に残るようになります。

書き忘れを防ぐには、区切りの定義をあいまいにしないことが有効です。「きりのいいところで書く」ではなく、「この工程が終わったら必ず書く」「この判断をしたら必ず書く」というように、書くタイミングをあらかじめ決めておきます。さらに、記録を書き終えるまでは次の工程に進まない、という順序を徹底すると、書き忘れたまま作業が進んでしまう事態を防げます。

再開時は記録を鵜呑みにせず、現物を読み直す

進捗ファイルを用意しても、それを無条件に信頼してよいわけではありません。前回の記録を書いたあとに、別の作業で関連ファイルが変更されていたり、記録した内容と実際の状態がずれていたりすることがあるためです。

そのため、作業を再開するときは、記録された内容を読むだけでなく、対象のファイルやコードの現物を実際に確認してから動き始めることが欠かせません。記録はあくまで「前回はこう認識していた」という情報であり、現在の事実そのものではないという前提で扱います。この一手間を省くと、古い前提のまま作業を進めてしまい、かえって手戻りが増えることになります。

記録と実態がずれていた場合は、記録ではなく実態を正として扱います。記録はあくまで過去の時点でのスナップショットであり、その後に方針が変わっていれば、現物の状態のほうが正しいからです。

また、作業の途中で方針そのものが変わることもあります。このとき、古い決定をただ消してしまうと、なぜ以前の方針をやめたのかという情報が失われ、後になって同じ方針を再検討してしまうことがあります。古い決定は消さずに「変更履歴」として残し、変更後の決定と合わせて、なぜ変えたかの理由も添えておくと、同じ経緯をたどるリスクを避けられます。

AIに任せる部分と、人が判断すべき部分の線引き

引き継ぎ設計そのものは、機械的な作業に見えて、すべてをAIに任せてよいわけではありません。進捗ファイルへの追記や、決定事項の整形といった「書く作業」はAIに任せられますが、何を「確定した決定事項」として記録するかどうかの判断は、人が行うべき領域です。

もしAIが自分の判断だけで「決定事項」を記録してしまうと、まだ確定していない仮説が確定事項として残り、次回以降の作業がその誤った前提の上に積み上がっていきます。運用の目安になるのは、「その進捗ファイルを、AIではなく人に渡して続きをお願いしても成立するか」という問いです。成立するなら、引き継ぎの設計として機能していると判断できます。

この判断をもう一段具体化すると、進捗ファイルを渡された人が、専門用語やその場限りの略語なしに、今どこまで進んでいて次に何をすればよいかを理解できるかどうかで確認できます。AI同士でしか通じない省略表現や、会話の中でだけ共有していた前提が残っていると、人に渡した瞬間に成立しなくなります。逆に言えば、人にそのまま渡して続きをお願いできる資料は、AIが読んでも迷わない資料でもあります。

  • その場だけの略語や社内用語を使っていないか
  • 結論だけでなく理由も書かれているか
  • 次にやることが1つのタスクとして特定できるか

この3点を、記録を書き終えた直後に自分で確認するだけでも、引き継ぎ資料の質は大きく変わります。

実際に、工程数の多い開発を進める際には、進捗をまとめた台帳ファイルと状態ファイルを会話の外に置き、途中で作業を中断しても同じ地点から再開できるようにコマンドを用意しておく、という運用が実務でも有効に機能しています。