TECH NOTE / 004

Markdownだけで作った、確認制のローカル会話記憶システム備忘録

AIが会話内容を自動で確定保存せず、人間の確認を挟んで用途別Markdownへ残す、プロジェクト固有のローカル運用についての備忘録です。

2026.08.19 / Hræsa

01 / OVERVIEW

説明し直す負担と、無条件保存の危険

これはCodexの標準メモリー機能ではなく、プロジェクト固有のローカル運用です。長期の相談では毎回すべてを説明し直す負担がある一方、会話を無条件に保存すると、推測や一時的な発言まで事実として固定されかねません。

そこで記憶量を増やすより、Markdownを直接読める確認可能性、AIだけでは確定できない承認制、用途別の分類、根拠と確認日、必要な情報だけを読む局所性、外部同期をしないローカル完結を優先しました。

02 / MINIMUM SETUP

規則、索引、状態を分ける最小構成

AGENTS.mdには候補化から確認、確定までの規則を置きます。MEMORY_INDEX.mdは記憶の索引、pending.mdは未確認候補、3つのconfirmedファイルは承認済み情報の保存先です。references/には要約だけで足りない詳細資料を置きます。

directory structureGENERALIZED

<CONSULT_PROJECT>/
├─ AGENTS.md
├─ MEMORY_INDEX.md
├─ memory/
│  ├─ pending.md
│  ├─ confirmed_user.md
│  ├─ confirmed_fiction.md
│  └─ confirmed_project.md
└─ references/
   └─ 必要に応じた詳細資料...

03 / CANDIDATES

候補を出す権限と、確定する権限は別

ユーザー側のトリガー

「覚えておいて」「今後もこの方針で」「直して」「削除して」といった明示的な依頼です。対象や分類が曖昧なら、AIは範囲を広げず確認します。

AI側のトリガー

繰り返し役立つ方針、継続中の制約、忘れると大きな手戻りになる情報を候補として提示します。ただし、AIにあるのは候補を出す権限だけで、確定保存する権限ではありません。

その場だけの雑談、一時的な気分から推測した人物像、根拠のない推測、すぐ古くなる現在値、細かな作業経過、認証情報や許可のない個人情報は、通常は候補化しません。

04 / APPROVAL FLOW

候補は、時間が経っても確定しない

会話で検出記憶が必要か判断
記憶候補会話内またはpending.mdへ
ユーザー確認内容と分類を確認
承認分類別confirmedへ修正修正版を確認却下pendingから削除

会話で検出した情報は候補として提示し、承認・修正・却下の確認を経て扱います。候補は自動昇格しません。

05 / RECORD FORMAT

根拠、日付、適用範囲を残す

候補には、何をどの分類で残したいか、その根拠と確認したい点を最小限に記録します。承認済みの記憶では、承認された内容に加え、適用範囲や例外・期限を残します。候補段階でAIが理由や背景を補完して情報を膨らませないことも重要です。

pending.mdCANDIDATE TEMPLATE

## YYYY-MM-DD: 候補の短い題名

- 状態: 候補
- 分類: 現実のユーザー / 創作世界 / プロジェクト運用 / 要確認
- 内容: 将来参照したい情報を、必要最小限に要約する。
- 根拠: どの会話や資料から得たかを書く。
- 候補日: YYYY-MM-DD
- 確認事項: 保存範囲や分類で曖昧な点を書く。

confirmed_*.mdCONFIRMED TEMPLATE

## YYYY-MM-DD: 確定事項の短い題名

- 承認された内容
- 適用範囲
- 必要なら例外や期限
- 根拠: YYYY-MM-DDの会話でユーザーが確認・承認

06 / CLASSIFICATION

現実、創作、プロジェクト運用を混ぜない

現実のユーザー

confirmed_user.md

承認済みの好み、経験、目標、生活上の条件を置く。認証情報や秘密情報は対象外です。

創作世界

confirmed_fiction.md

登場人物、作中組織、作中AIなどの設定を置く。現実の本人情報とは別に扱います。

プロジェクト運用

confirmed_project.md

回答形式、検索方針、記憶の管理方法など、本人属性でも創作設定でもない合意を置きます。

分類が曖昧な「要確認」は独立した確定分類ではなく、候補の状態です。現実と創作の間で不足情報を推測補完せず、判断できなければ保存前に確認します。

07 / SELECTIVE READING

必要な記憶だけを、索引から読む

現在の相談
長期記憶が必要か判断
MEMORY_INDEX.mdを読む
関係するconfirmedだけ読む
必要な場合だけ詳細資料へ

毎回すべてを読むのではなく、関係のない個人情報を持ち込みにくくし、創作と現実の混線や古い情報への依存を減らします。pending.mdは確認作業の資料であり、通常の相談で確定事実として断言しません。

08 / MAINTENANCE

修正・削除と、情報の鮮度

AIの判断だけで確定記憶を書き換えません。修正や削除では対象と新しい内容を確認し、処理済みの候補はpending.mdから取り除きます。古い内容と新しい内容が両立しないときは、現在有効な方が分かるように整理します。

詳細資料には基準日と扱いを付けます。金額、体調、制度、ソフトウェア仕様、進行中の作業などは、正しい記録でも古ければ現在の判断に使えないため、根拠・適用範囲とともに再確認します。

09 / PRIVACY & LIMITS

ローカル保存は、暗号化を意味しない

記憶は専用のローカルプロジェクト内で扱い、外部データベースやクラウドストレージへの自動同期はしません。別プロジェクトの記憶とも混ぜず、検索のために個人情報を外部へ送ることも避けます。

ただしMarkdownは平文です。ローカル保存であることと暗号化されていることは別なので、機微性の高い情報は保存項目を減らし、OS側の暗号化やバックアップ先の制限など、別の対策が必要です。パスワード、APIキー、アクセストークン、秘密鍵、復旧コード、認証に使える情報は保存せず、ログ・作業報告・検索語・サンプルコードへも転記しません。

自動検索はない
索引を見て必要なファイルを読む方式で、意味検索や全文インデックスは未実装です。
競合検出はない
矛盾する記憶は日付と根拠を見て、人間とAIが整理します。
鮮度は自動更新されない
基準日があっても、現在値として使う前の確認が必要です。
Git履歴はない
外部公開や誤同期を避けるため、コミットから戻す仕組みは使いません。

10 / CHECKLIST

新しい相談プロジェクトへ導入する前に

これは閲覧用のチェックリストです。サイト上で操作する項目ではありません。

プロジェクトの保存場所と外部同期方針を決める
AGENTS.mdへ記憶の承認手順を書く
MEMORY_INDEX.mdを作る
memory/pending.mdを作る
現実のユーザー用の確定ファイルを作る
創作設定用の確定ファイルを作る
プロジェクト運用用の確定ファイルを作る
候補へ必要な項目を決める
ユーザー側とAI側、両方の候補化トリガーを定義する
確定保存の最終決定権を明記する
曖昧な分類を推測で決めない規則を入れる
pendingを確定事実として扱わない規則を入れる
修正・削除の確認方法を決める
秘密情報の保存禁止を明記する
詳細資料には基準日を付ける
毎回全記憶を読まず、索引から必要なものだけ読む
実データ入りの記憶ファイルをブログやGitへ公開しない

11 / SUMMARY

何を、なぜ、誰の承認で覚えたか

この仕組みは、Markdownを用途別に分けた小さな構成です。でも中心にあるのはファイル形式ではなく運用ルールです。AI側も候補を見つける一方、確定には人間の確認を挟み、現実・創作・プロジェクト運用を分け、根拠と日付を残します。

優先したいのは「たくさん覚えること」ではなく、「何を、なぜ、誰の承認で覚えたか分かること」です。