長い ChatGPT 会話を3秒で引き継ぐ蒸留テンプレ ── 全部覚えさせると AI は鈍る

はじめに

ChatGPT の会話が長くなると、良い決定も設計も、その中に埋もれます。新しいスレッドに移ると文脈は切れる。かといって会話を全文コピーして次に渡すと、今度はノイズだらけで使えません。

そこで、終わったスレッドを一度「蒸留」してから渡します。やることは、プロンプトを1個貼るだけです。

これを貼るだけ

長い会話の最後に、これを貼ります。

このスレッドを終えます。会話の完全要約ではなく、次の用途別に「分流」する形で蒸留してください。

1. Thread Handoff
   次スレッドで再開するための短期記憶。どこから再開するか、直近の方針、未完了の作業。

2. Work Ledger Update
   仕事・研究・掲載・応募・助成・外部対応などの「進捗の差分」。
   投稿した／掲載された／申請した／返信が来た／ステータス変化／URL／ID／次アクション。なければ「更新不要」。

3. Episode Log
   中期的に保存すべき重要な出来事・転換点。

4. Distillation Candidate
   複数のスレッド・テーマで再現しそうな因果・失敗パターン。即ルール化ではなく「候補」として。

5. Quarantine Note
   熱すぎる意味づけ・使命感・怒り・外部評価への高揚・座りが良すぎる結論。事実から隔離する。

6. Knowledge Source Update Recommendation
   今後 Project 知識源や運用ルールに反映すべき候補。なければ「更新不要」。

7. RAG Candidate
   後で検索したい資料・URL 群・参照頻度は低いが重要な情報。タグ・日付・検索キーも添える。なければ「更新不要」。

8. Do Not Save / PROTECT
   一時的すぎる情報、古くなりやすい状態、個人情報、非公開 URL、再利用・公開に向かない情報。

9. Next Thread Opening Prompt
   次スレッドにそのまま貼れる開始文。

ルール:
- 進捗を自己像にしない。
- 意味づけは Quarantine へ、因果だけ Distillation へ。
- 外部提出用の文と、内部の高温な読みを混ぜない。
- URL や ID など、後で必要な情報は消さない。
- 知識源は「現在の本人」ではなく、過去から残した参照用の地図として扱う。

貼るとこうなる

たとえば架空の「個人開発スレ」だと、こんな出力が返ってきます（中身は例です）。

（例：架空の「個人開発スレ」を蒸留した場合）

1. Thread Handoff
   家計簿アプリを試作中。ログイン画面まで実装済み。次は支出入力フォーム。

2. Work Ledger Update
   - 技術スタック決定（フロント: React、保存: ローカル）
   - ログイン画面 実装完了 / 支出入力フォーム 未着手
   - 次アクション: 支出カテゴリの一覧を先に定義する

3. Episode Log
   初めてローカルで起動が通った。環境構築でつまずいていた分、ひとつの節目。

4. Distillation Candidate
   「画面から作り始めると、データ構造が後で破綻しがち。先にデータの形を決める」
   → 他の個人開発でも再現しそう。長期ルールの候補として保留。

5. Quarantine Note
   「これ売れるんじゃないか」「今週末で MVP いけそう」
   → 高揚。事実ではないので隔離。週をまたいで残れば、改めて検討する。

6. Knowledge Source Update Recommendation
   「先にデータ構造」を失敗パターンのファイルへ追記する候補。

7. RAG Candidate
   参考にした技術記事3本の URL。タグ: React, ローカル保存, フォーム設計。

8. Do Not Save / PROTECT
   試した API キー、作業中の愚痴。

9. Next Thread Opening Prompt
   「家計簿アプリの続き。ログイン画面まで完了済み。今日は支出入力フォームから。
    まず支出カテゴリの一覧を決めたい。」

使い方

スレッドの終わりに、上のプロンプトを貼る
返ってきた出力を見て、次も使うものだけ残す
残したものを、Project の知識源（md / txt）か、次スレの最初に貼る文へ

道具としては、これで終わりです。会話ログを全文保存するより、はるかに軽くて速い。

ここからが本題 ── なぜ「全部覚えさせる」をやめたのか

手順だけ見ると、ただの整理術に見えます。でも、この運用の本当の理由は、手順の方ではありません。長く AI を使って分かった、3つのことです。

1. 覚えさせるほど、AI はかえって鈍る

直感に反しますが、記憶は増やすほど良くなるわけではありません。

会話ログを全部渡すと、その中の古い進捗・一時的な感情・疲れていた時の解釈・もう変わった状況まで、まるごと次の AI の前提になります。AI は素直なので、その全部に引っ張られる。結果として、今の話よりも「記憶の中の古い文脈」を優先し始めます。

効くのは量ではなく、純度です。要らないものを入れないほど、回答は鋭くなる。だから蒸留では「何を残すか」と同じくらい、「何を捨てるか」を決めます。

2. AI は「古い自分」を演じ始める

長期運用で一番怖いのは、AI に忘れられることではありません。古い自分を、覚えられすぎること です。

過去ログや保存したプロフィールから、AI は「あなた像」を作ります。そして、その圧縮された古い像を、今のあなたとして扱い始める。先週の高揚、半年前の肩書き、もう終わった状況を、現在として再生してしまう。気づくと、目の前の AI が「記憶の中のあなた」を演じています。

だから知識源は、「今の自分」ではなく「過去から残した地図」として渡します。地図は参考にするもので、現在地そのものではありません。蒸留プロンプトの最後に「知識源は現在の本人ではなく地図として扱う」と入れているのは、このためです。

3. 進捗を保存すると、判断が狂う

これが、一番実害の出るところです。

進捗と意味づけを混ぜて保存すると、AI の判断が歪みます。

たとえば「記事が掲載された」は進捗、事実です。でも、それと一緒に「ついに認められた」「もう通るはず」まで保存すると、次の AI はその高揚を引き継ぐ。submitted を accepted のように、まだ途中のものを、もう通ったかのように扱い始めます。冷静な評価ができなくなる。

だから蒸留では、進捗は事実として台帳に、意味づけは別の場所（隔離）に置きます。事実は事実、解釈は解釈で分ける。時間を置いても残った意味づけだけ、後で拾えばいい。

さきほどのプロンプトの 2. Work Ledger（事実）と 5. Quarantine（熱い意味づけ）が、まさにこの分離をやっています。

知識源に入れるだけでは足りない ── 読ませ方を決める

ここまでは「何を残すか」の話でした。でも、もう一段あります。

蒸留したメモを知識源に入れても、モデルがそれをどう読むか を決めないと、さっきの3つの失敗はまた起きます。きれいに整理したメモでも、モデルが「現在の事実」として読めば、古い自分を演じ、古い高揚を引きずる。

だから私は、メモを保存するだけでなく、「そのメモにどこまで権限を持たせるか」のルールも一緒に置きます。知識源（中身）とは別の、読ませ方（解釈）のルール ── custom GPT の instructions や、Project の指示文に書いておく短いルールです。

芯は一行です。

記憶は、過去から残した地図であって、今の本人ではない。

そこから派生する、こういうルールです。

今の会話を、保存された文脈より優先する
進捗は進捗のまま、自己像にしない
高揚・怒り・安堵・野心は、時間を生き延びるまで隔離扱い
証拠名（タイトル・URL・ID・DOI・投稿記録）は正確に保つ
「submitted」を「accepted」に、「閲覧数」を「収入」に、「支援」を「お墨付き」に変えない
非公開・危険・すぐ古くなる情報は、再利用する文脈に入れない
文章は読者向けに整えてよいが、事実は読みやすさのために書き換えない

これがないと、知識源は「整形されただけの文脈の山」です。これがあると、記憶は統治される ── モデルは情報を渡されるだけでなく、その情報をどこまで信じていいかを教えられる。

知識源は記憶を保存する。指示の層は、その記憶の権限を決める。

実際に起きた失敗 ── 中立化が、証拠の名前まで壊した

この運用は、きれいな理論から作ったものではありません。知識源を更新するたびに失敗して、そのたびにルールを足してきました。

最近も、分かりやすい事故がありました。

AI に「特定のモデル名に引っ張られないよう、運用メモの中ではモデル名を中立な役割名に置き換えて」と指示しました。一見、正しい処理です。「どの AI が優秀か」ではなく「高温で書くフェーズ」「検品するフェーズ」のように、役割で扱う方が安定します。

ところが、この置換が強すぎました。運用メモだけでなく、保存してあった「公開済み記事のタイトル」の中の固有名まで書き換えてしまったのです。本来そのまま残すべき実績の記録が、内部用の役割名に化けてしまった。

これは危ない。記事タイトル・URL・ID・DOI・投稿記録は、文体を整える対象ではなく、証拠の名前だからです。ここを勝手に書き換えると、後で人間も AI も、実際に何が存在した成果なのか分からなくなります。

そこで、ルールを1本足しました。

運用メモの中では、モデル名や役割名を中立化してよい
ただし、記事タイトル・URL・ID・DOI・投稿記録は、正確にそのまま残す
証拠の名前は、文体より正確さを優先する
公開に向かない情報なら、書き換えるのではなく「保存しない」へ送る

この失敗で分かったのは ── 蒸留は「短くまとめること」ではない、ということです。蒸留とは、次の AI が使っていい文脈と、触ってはいけない証拠の名前を、分けること。要約ではなく、検品に近い。

つまり ── 渡す記憶は、情報ではなく運用責任

ここまでの話は、根っこが一つです。

長い AI 会話の問題は、忘れることではありません。何でも覚えさせると、古い文脈・古い自己像・盛られた解釈・壊れた証拠名まで、次回の前提になってしまう こと。だから必要なのは、要約ではなく、選別と隔離と証拠の保持です。

これは、AI に全部を覚えさせる技術ではありません。何を覚えさせないかを決め、触ってはいけないものを守る技術です。言い換えると ──

AI に渡す記憶は、ただの情報ではなく、運用の責任である。

コピペは3秒です。でもその3秒で、会話は使い捨てのログではなく、責任を持って引き継ぐ作業記憶に変わります。

この記事は、筆者が長期的な AI 利用の中で作った蒸留運用を、Qiita 向けに整理したものです。文章化には AI を使用し、最終確認と公開の責任は筆者が持ちます。