長い 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 を使用し、最終確認と公開の責任は筆者が持ちます。