AIとの会話履歴を資産にする：メモリと引き継ぎ文書

AIに手伝ってもらう作業が1日で終わらないものになってくると、会話の履歴そのものが作業の土台になります。このサイトの記事作成もそうで、テーマ決めから下書き、品質チェックまでを複数のAIで分担しながら進めていて、進捗と決定事項は引き継ぎ用のメモに残して回しています。

ところが、履歴に頼りきると早々に詰まります。セッションが長くなるほど要点は下の方に沈みますし、担当のAIを変えた瞬間、最初から説明し直しです。説明し直すたびに微妙に前提がずれて、そのずれが後で「前に決めたはずなのに」という形で返ってくる。

そこでやっているのが、履歴とは別に「決まったこと」を書き残す運用です。この記事では、何を残すか、どういう型で残すか、古くなった情報とどう付き合うかを整理します。特定の製品のメモリ機能の話ではなく、手元のテキストファイルで回せる運用の話です。

なぜチャット履歴だけでは足りないのか

理由は大きく3つあります。

1つ目は肥大化です。会話は時系列に伸びていくので、重要な決定ほど過去の発言の中に埋もれます。「あの件、どう決めたっけ」を履歴から探す作業は、長くなるほど高くつきます。AI自身にとっても同じで、長い履歴を全部読ませれば要所は薄まりますし、読み切れていなければ見落としが起きます。

2つ目は、担当をまたげないことです。チャットの履歴は、そのAI・そのセッションの中に閉じています。別のAIに作業を移す、あるいは新しいセッションを立て直すと、蓄積はゼロに戻ります。年単位で続く作業ほど、担当の交代は必ず起きます。

3つ目は、決定と試行錯誤が混ざることです。履歴の中には、採用した案も、検討して捨てた案も、途中で翻した案も、同じ重さで並んでいます。後から入ってきた側は、どれが「今の決定」なのかを文脈から推測するしかありません。

考え方： チャット履歴は「議事録」であって「現況」ではありません。議事録を全部読めば現況は分かりますが、それを読ませる手間と読み違えのリスクを毎回払うのは割に合いません。現況だけを切り出した文書が別に要ります。

残すのは「会話」ではなく「決定」

引き継ぎ文書に残すのは、会話の要約ではありません。要約はどうしても「何を話したか」になりがちで、次に必要な「何が決まっていて、何をやってはいけないか」が薄くなります。

実際に残しているのは、次の6種類です。

種類	残す中身	書き方の例
決定事項	何を、どう決めたか	「記事の本数は36本。日付は2026年内に散らす」
前提・制約	作業の土台になる条件、上限、期限	「参照は一次情報のみ。実体験の捏造は禁止」
進捗	どこまで終わり、何が残っているか	「バッチA完了・確認済み。B〜Fが残り」
禁止事項	やってはいけないこと、勝手に変えてはいけないもの	「公開とpushは本人のOKが出てから」
成果物の置き場	ファイルやURLなど、正本のありか	「原稿は batch-A/ フォルダが正本」
未決事項	まだ決まっていないこと、誰の判断待ちか	「取り込み時のスキーマ照合は未実施」

大事なのは、この6種類だけに絞ることです。感想や作業の感想文、検討の過程そのものは残しません。過程が要るのは「なぜそう決めたか」という理由の部分だけで、それも決定事項の行に短く添える程度にしています。

理由を添えるかどうかは悩ましいところですが、実感としては、理由のない決定は後で蒸し返されやすいです。「なぜダメなのか」が分からない禁止事項は、別の担当が善意で破ってしまいます。1行でいいので根拠を添える、が今の落としどころです。

引き継ぎ文書の最小テンプレート

型はこれだけです。新しい作業をAIと始めるときは、まずこの形のファイルを作ります。

# 引き継ぎ：◯◯プロジェクト

## 目的
- 何のための作業か（1〜2行）

## 決まっていること
- 決定事項を箇条書き。変えたものは「旧：◯◯ → 新：△△（理由）」で差し替えを明記

## 前提と制約
- 上限、期限、使うツール、参照してよい情報源など

## 禁止事項
- 勝手にやってはいけないこと、再承認なしに変えてはいけないもの

## 進捗
- 完了したもの／進行中のもの／未着手のもの

## 成果物の置き場
- 正本のファイル・フォルダ・URL

## 次の一手
- 次にやること。判断待ちなら、誰の何待ちか

ポイントは2つあります。

まず、1プロジェクト1ファイルに集約することです。日付ごとにメモを分けたくなりますが、分けると「今の正本はどれか」が分からなくなります。時系列の記録が欲しいなら履歴側（チャットやコミットログ）が担うもので、引き継ぎ文書は常に現況だけを持つ方が強いです。

もう1つは、日付で更新するのではなく状態で更新すること。「6月20日：◯◯した」というログ形式にすると、読み手が全部を追わないと現況が分かりません。そうではなく、該当箇所そのものを今の状態に書き換える。決定が変わったら、古い決定を消すのではなく差し替えとして明記するのがコツです。消してしまうと、別の場所に残っていた古い決定と衝突したときに、どちらが新しいのか判断できなくなります。

なお、この「目的・前提と制約・禁止事項を先に固める」という考え方は、AIに仕事を渡すときの指示の書き方とも共通しています。指示側の型については AIへの指示の型：目的・制約・出力形式を固定で渡す にまとめました。

肥大化と矛盾をどう防ぐか

運用を続けるうえでの敵は、書くこと自体よりも「古い情報が残り続けること」です。対策は地味なものばかりですが、効く順に挙げます。

• 書く単位を「決定」に固定する。 1回の作業でメモに追記するのは、決まったこと・変わったことだけ。作業ログは書かない。これで増加量がだいぶ絞れます
• 矛盾したら、その場で直す。 新しい決定と古い記述がぶつかったら、直すのは新しい方ではなく古い方。差し替えとして書き、古い記述には「→ ◯◯に変更済み」と残す
• 定期的に棚卸しする。 プロジェクトの節目（バッチの切り替わり等）で一度通読し、終わった未決事項や失効した制約を圧縮する。長さの上限を決めておくのも手です
• 正本は1つに保つ。 同じ内容のコピーを複数のAIやツールに持たせない。参照させるときは正本を渡す。コピーが増えた瞬間、どれが最新かという問題が再発します

引き継ぎ前に、私はこの3点だけざっと見ています。

• 決定事項は、経緯を読まなくても1行で伝わるか
• 禁止事項と未決事項が最新か（終わったものが残っていないか）
• 成果物の置き場が、実際のファイルの状態と一致しているか

なお、AI製品側にも会話を覚えるメモリ機能はありますが、私はそれに任せきりにはしていません。自動で覚えた内容は自分で編集しにくく、担当のAIを変えたら持ち運べないからです。「自分で書いて、自分で直せるテキスト」が手元にあることが、この運用の要点だと思っています。担当を変えても困らないようにする考え方は、AIツールの乗り換えコストを下げる：データを持ち運べる形に でも整理しました。

おわりに

人間同士の引き継ぎと構造は同じで、立派な文書である必要はなく、「次に触る人が迷わない」ことが合格ラインです。AIが相手だと、その効果が素直に出ます。相手は毎回まっさらな状態で来るので、引き継ぎ文書の質がそのまま作業の質になります。

逆に言えば、履歴が溜まってきたのに引き継ぎ文書がない作業は、いつか必ず説明し直しと前提のずれで足を取られます。作業が年単位になりそうだと思った時点で、テンプレートのファイル1つ置いておく。それだけで、以後のセッションの引き継ぎコストはほぼ消えます。